A continuous correctness audit closes the class, and keeps it closed: the defect is root-caused, its siblings are swept from the codebase, and the class is pinned by a regression test that runs on every release.
Everything on the screen to the right is a real, published outcome. The register it comes from is public.
▶ INSERT COIN 1 credit = 1 scoped componentOne defect fixed is a patch. A class made extinct is a different deliverable, and it takes six steps, in order, every time.
The defect is recorded on the register with severity, our assessment weighted by reachability and impact, and linked to the requirements it affects.
Every finding carries a runnable reproducer. A claim without a command you can re-run is an opinion, and the register does not hold opinions.
Analysis names the mechanism behind the symptom. The fix addresses the mechanism, so the analysis defines what else must be checked.
The codebase is searched for every sibling of the same mechanism. In our public audit, one unchecked-dereference class turned out to live at eight sites: seven found by the hazard sweep, the eighth by the root-cause analysis itself.
A regression test pins the class. The test file carries, on one screen, the finding it reproduces and the requirement it verifies.
The pin joins every pin ever written and runs on every release. This is why the respawn counter on this page reads zero, and stays there.
In our public audit of jsonparser, a data-loss defect in Set() escaped the review. A scalar-to-array overwrite fired its grow branch only for object-first arrays; every other shape was silently overwritten. The output was valid JSON, so nothing downstream complained. The affected code had 100% MC/DC coverage.
The report reached the practice from the community. We treated it the way we treat every finding: reproducer, root cause, sweep of the family, permanent pin. Then we published the postmortem in the same public repository as the audit itself. Its three axes: an unspecified partition, no output oracle, literal pattern matching.
"MC/DC has no notion of 'correct'; it has only 'exercised.'"from the published postmortem, docs/proof-gap-root-cause.md
Every claim on this page traces to a published artifact. Our own decade-old Go JSON library, jsonparser, is the live exhibit: the specifications, the findings register, and the pins sit on its public master branch, where anyone can re-run them.
Each finding is signed, links the requirements it affects, and carries its reproducer as a runnable command. The corpus compounds: pins are never retired, requirements only gain evidence, and each engagement inherits everything the last one proved.
The gate judges evidence, so it applies identically to code written by your engineers and code written by their agents. That symmetry is the point.
The engineers who own the component approve every requirement before any code is judged, about two hours of the owners' time. The standard is anchored outside the code and outside whoever wrote it.
Agent-ready prompts ship with the corpus. An agent picks up a finding, its reproducer, and the requirement it affects, and its output lands as evidence a reviewer can re-run.
Why this matters now: in the Stack Overflow Developer Survey 2025, 46% of developers distrust the accuracy of AI tool output, and 33% trust it. DORA 2025 reports 90% of practitioners using AI while 30% trust what it produces. Verification is the constraint. It is the part we industrialize.
From a prior engagement, an enterprise API gateway: 47 requirements approved in about two hours of the owners' time, zero production code changed, and one nil-pointer crash class surfaced that every existing test had missed.