Continuous Correctness Audit
Life after the audit.
Most audits are events: intense, useful, over. Proof's is built to stay. This page is about month two and month twelve, because the findings are the smallest part of what you keep. What follows is what the findings turn into.
Unknown defects are risk. Known defects are work.
The first thing the audit leaves behind is a known-issue register: each issue named, its severity assessed with the basis recorded, an owner and a review date on file, a reproducer attached. A maintained instrument the gate itself checks for staleness, not a spreadsheet someone started and abandoned.
A register like that survives contact with a sprint-planning meeting: fixes sequenced by severity and reachability, budgets defensible, "what is still open" answerable without calling anyone. Each entry is delegable as well as plannable: every known issue on the engagement dashboard, the readable window over this register, carries a copy-ready prompt with the issue, its context and its reproducer, so any engineer or coding agent can pick up the fix with the reproducer as the finish line. The window is live for our public audit: browse the jsonparser register, every known issue with its reproducer command attached. When a customer or a board member asks what you know about the component's risks, there is a written answer with evidence behind it. The risk did not shrink; it stopped being invisible, and invisible is the expensive part.
Every finding arrives pre-wired for fixing.
A finding is a red test. The reproducer stays red until the defect is actually gone, and the gate re-checks the requirement, the traceability, and the coverage around the change. In the corpus, the test that pins a defect carries its name (// Reproduces: KI-…) the same way verification tests carry theirs (// Verifies: SW-REQ-…).
That grading loop does not care who wrote the fix. Assign a finding to an engineer on Monday, or point a code-writing model at it overnight; either way, the claim "fixed" is machine-checked before a human signs it. Teams that generate a lot of their code feel this one first: the register becomes a work queue their tooling can safely burn down.
A customer report meets the register before it meets a debugger.
When something arrives from the field, the first question changes. It is no longer "can we reproduce this"; it is "is this already known." A match closes triage in minutes, with severity and a reproducer already on file, and the customer gets an answer that reads like you were expecting the question.
A miss is its own signal: something reached production that the audit did not catch. That has a protocol.
Escapes retire their class.
No audit catches everything, and this practice publishes its own misses. What makes the difference is what an escape triggers.
The defect is recorded and root-caused to the exact gap that let it through: a requirement that was never written, a test partition that was never exercised, a coverage condition no test ever made matter. Closure then requires the corrective artifacts: the missing requirement written and approved, a reproducer that fails while the bug is present, a sweep for sibling defects in the same class.
And the class claim stays honest. One passing reproducer proves this instance is dead; claiming the whole class is closed takes more evidence than one test. The first entry in our ledger is this protocol applied to our own library; the full case is public.
What compounds by month twelve.
Point-in-time quality work is stateless: a scan today does not make next month's scan smarter, and a pentest does not remember. This audit keeps state.
Every fixed defect stays fixed, because its reproducer stands guard in your CI. Every escape makes the specification more complete. Every release adds requirements to the corpus. Nothing you have paid to learn about the component is ever un-learned.
There is a simpler name for all of this: memory. Engineering memory that lives with the code. Written-down intent; defects with their root causes; what was proven, and what was not. All of it versioned in the same repo and checked on every release. It survives departures, reorgs, and rewrites, and it is valuable enough that we treat it like source code: yours, in your repo, nowhere else. Most components have already lost more memory than anyone admits; week one usually proves it.
Month twelve checks more than month one, and it knows more. That is the audit that doesn't expire.
What the monthly invoice buys, and what happens if you stop.
A retainer month consists of: every release re-audited on the cadence you choose, up to daily; new and changed code held to the approved requirements; fixed findings re-verified and pinned; the register maintained, severities re-checked; and each quarter, one more component brought under the bar, included. The gate does the mechanical half of that automatically. The human half, new requirements for new behavior, judged severities, the miss protocol, a signature worth something, is what the invoice buys.
And if you stop: you keep everything that runs. The gate keeps checking yesterday's promises; nobody keeps writing tomorrow's. By month two your component has changed, and the register quietly stops being true. That is the whole trade, stated plainly.
Where this starts.
The engagement
Fixed fee, one component, roughly four weeks. Week one is where the component's memory starts.
The ledger
Including the miss, and the protocol running on our own code.