The next change reuses what this one proved.

A team can plan from it. Each severity is recorded with its basis, and fixes are sequenced by severity and reachability. When someone asks what is still open, the answer is written down, with evidence. The risk did not shrink. It stopped being invisible, and invisible is the expensive part.

Each known issue carries an owner, a review date, and a copy-ready prompt with the issue, its context, and its reproducer. An engineer or a coding agent can pick up the fix. The reproducer is the finish line.

The public project shows the shape. The jsonparser register, read off master, holds four known-issue records. Every one is fixed. Every one carries the command that reproduces it.

The reproducer goes quiet only when the problem is gone. The gate re-checks the requirement, the traceability, and the coverage around the change.

In the corpus, the test that pins a known issue carries its name, // Reproduces: KI-…, the same way a verification test carries // Verifies: SYS-REQ-…. One public file shows both.

The loop does not care who wrote the fix. An engineer can take it. A coding agent can take it. Either way, the claim “fixed” is machine-checked. The register becomes a queue the team’s tooling can burn down.

When you would rather hand that queue to us, fix sprints are scoped separately and delivered as pull requests your engineers accept. The gate grades our fixes the same way 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 are approved. Both name the record back. The impact review beside it re-reads nineteen requirements across the four files the release touched. It 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. A component under active development walks away from that description within a quarter. Ordinary development writes to the same graph, so month twelve holds the intent of the software you actually ship. Every known issue is read against what the component promises today.

One record is public end to end. DEFECT-260726-MFPA is what closing KI-3 left behind. The instance is fixed, and the reproducer is kept permanently. The record 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. The root cause is the exact gap that let it through: a requirement never written, a test partition never exercised, or a coverage condition no test made matter. Closure writes the missing requirement and gets it approved. It adds a reproducer that pins the failure. It sweeps for sibling cases in the same class.

What remains is a larger gate. Retain the new promise and regression checks in the release workflow. Their protection depends on the configured checks continuing to run. A passing reproducer supports closure of the tested instance. Closing the whole class takes more evidence than one test. The protocol has already run in public, on jsonparser. The full case is published, misses included.

Fix the issue. Keep the lesson. Retained regression checks help detect a returning failure when they run. Escapes can expose missing requirements and weak checks; resolving them adds knowledge for the next change. Keep those records current, and preserve the history when a promise is intentionally superseded.

There is a simpler name for this: memory. It lives with the code. Written intent, defect records and their root causes, what was proven, and what was not. It is versioned in your repository and checked by the release checks you configure. Your team owns the records and can preserve them through departures, reorgs, and rewrites. Evidence packages and review exports can carry that history to the people who need it.

Your coding agents use that memory the same way your engineers do. They query the Software Intent Graph over MCP: components, requirements, obligations, and evidence. They start from approved intent instead of rediscovering the system from raw code. The next change spends less time reconstructing why the software works. The record is plain files any tool can read. What the agent receives →

New and changed code is held to the approved requirements. Fixed findings are re-verified and pinned. Severities are re-checked. The added component is install-grade. It is sized into the retainer when it is scoped, not a surprise line item.

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

If you stop, you keep everything that runs. The corpus is plain YAML and executable tests in your git. The gate keeps checking yesterday’s promises without us. What ends is the ongoing expertise. Nobody keeps writing tomorrow’s. Your team can continue maintaining those records. Without that work, later changes can leave requirements, mappings and evidence out of date.