Every fix makes the next change safer.

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 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 public project shows the shape: the jsonparser register, read off master — four known-issue records, every one fixed, every one carrying the command that reproduces it. 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.

In the corpus, the test that pins a known issue carries its name (// Reproduces: KI-…) the same way verification tests carry theirs (// Verifies: SYS-REQ-…) — one public file shows both on one screen.

That grading loop does not care who wrote the fix. Assign a known issue to an engineer on Monday, or point a code-writing model at it overnight; either way, the claim “fixed” is machine-checked. Teams that generate a lot of their code feel this one first: the register becomes a work queue their tooling can safely burn down. And when you would rather hand the queue to us, fix sprints are scoped separately and delivered as pull requests your engineers accept — the gate grades our fixes exactly as it grades anyone’s.

The public project has three of these on master, and none of them is a bug. The v1.5.0 record, CHG-260728-H6ER, names the two requirements the release introduced — SYS-REQ-115 and SYS-REQ-116, both since approved, and both naming the record back. The impact review beside it re-reads nineteen requirements across the four files the release touched, those two among them, and fingerprints every row against a named revision.

This is what keeps the register true. A register that only remembers bugs describes the component you had on install day, and a component under active development walks away from that description within a quarter. Because ordinary development writes to the same graph, month twelve holds the intent of the software you actually ship, and every known issue is read against what the component promises today.

One of ours is public end to end: DEFECT-260726-MFPA, what closing KI-3 left behind. It says the instance is fixed and the reproducer is kept permanently. It does not say the defect class is closed, and neither do we.

A miss is its own signal: something reached production that the audit did not catch. That has a protocol.

The escape is filed as a known issue 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 pins the failure, a sweep for sibling cases in the same class.

What the escape leaves behind is a permanently larger gate. The promise it exposed is checked on every release from that day on, and the partition it slipped through is exercised on every release from that day on. The class claim stays honest at the same time: one passing reproducer proves this instance is dead, and claiming the whole class is closed takes more evidence than one test. The protocol has already run in public, on jsonparser: the full case is published, misses included.

Every verified fix stays fixed, because its reproducer stands guard in your CI. Every escape makes the specification more complete. Every feature and 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; defect records 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.

Your coding agents draw on it the same way your engineers do: they query the graph of components, requirements, obligations and evidence directly, over MCP, and start from approved intent instead of rediscovering the system from raw code. The shape of the record is the commitment — plain files any tool can read. What the agent receives →

The gate does the mechanical half of that automatically. The human half — new requirements for new behavior, judged severities, the miss protocol, a person who validates every finding before you see it — is what the retainer buys.

And if you stop: you keep everything that runs. The corpus is plain YAML and executable tests in your git, and the gate keeps checking yesterday’s promises without us. What ends is the ongoing expertise: 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.