Clean room and credit

Federal regulations belong to everyone. A piece of software that implements one belongs to its author. ClearedStack takes ideas for tools from products that already exist, so it has to be exact about the difference: it takes the job to be done and nothing else. This page describes that rule, how the pipeline is designed to enforce it, and how the source of an idea is credited.

Build, link or skip#

The first question is whether to build at all. If a free tool already runs on the user’s machine, respects privacy and cites public sources, rebuilding it is wasted effort.

DecisionDoes an existing tool already meet the five listing conditions?

• Yes: free and private
  LinkList it in the catalog as an outside tool. Do not rebuild it.
• No, and the need is high
  BuildWrite a specification from the official rule and build from that.
• No, and the need is low
  SkipScreen it out or park it, with the reason recorded.

What is taken and what is not#

1. TakenThe job to be doneThe requirement, the public formula and the rule, as written in official government text.
2. Never takenCodeNo copying, adapting, decompiling or reverse-engineering.
3. Never takenWordsNo help text, labels, field descriptions or guides.
4. Never takenDesignNo layout, color scheme, icons or look.
5. Never takenDataNo private tables, benchmark rates or internal structure.
6. Never takenNames and marksNo logos or trademarked phrases. A product’s name appears only to say where an idea was seen.

Open-source libraries under permissive licenses (MIT, BSD, Apache 2.0) may be used inside a tool, with their copyright notices and license files kept. Code under a strong copyleft license is not mixed into the project’s MIT repositories. A good copyleft tool is linked to instead.

The wall between looking and building#

The rule is not left to good intentions. The worker that looks and the worker that builds are separate programs in separate repositories, and what passes between them is controlled.

Because the builder never receives the observed page, it cannot echo its layout, its wording or its code.

The specification#

The specification is the only thing that crosses the wall. It has four parts.

Where a commercial tool gives an answer that conflicts with an official publication, the specification follows the official publication.

How an idea is credited#

A tool inspired by an existing product carries a short note in a fixed form, so the wording never varies and never editorializes.

Four rules apply to every note:

• It records only that a workflow was seen on a public page on a given date.
• It never rates, criticizes or disparages the product.
• It never implies partnership, sponsorship or endorsement.
• A product’s name is used only to identify where the idea was seen.

In the catalog, the note is the optional provenance field of a tool’s entry, and it is shown on the tool’s page.

Corrections and opt-outs#

The maker of a product can ask for a factual correction, or ask not to be named. Requests go to [email protected] or to a public issue on GitHub.

1. ReceiveLog the requestIt is recorded against the catalog entry.
2. Within 48 hoursConfirm who is askingCheck that the request comes from the maker of the product.
3. Within 5 daysHonor an opt-outThe product’s name is replaced with a neutral phrase such as “a commercial product”.
4. AlwaysKeep the public lawCitations to statutes, regulations and standards stay.

A factual error about a product is corrected once it is confirmed. A citation to public law is never removed, because it is not the vendor’s to withdraw.

The same rule for the platform’s own services#

The clean-room rule also applies to the services the pipeline is designed to run on. Self-hosted platforms are usually assembled from large existing projects. This design instead specifies four small services written from scratch, which borrow ideas from those projects and none of their code.

Writing them fresh keeps every repository under one license, MIT, and keeps each service small enough to read. Cluster architecture describes them.

For someone building a tool#

If you are building a tool to be listed, the same rule applies to you: take the job, build from the regulation, and say where the idea came from. Build a tool that can be listed has the practical version.