Reference · Verified recovery
Verified recovery
A case is recovered when the remedy is verified, not when the error stops. Verification is eight named checks, each recorded as a pass, a fail, or not applicable with the reviewer's reason; an approval binds to the exact scope it was given for; and a cost is a receipt, never an estimate dressed as one.
The eight checks
- builds
- The change compiles.
- tests
- The repository's own suite still passes.
- regression
- A test that reproduces the original defect and fails without the fix.
- guard-replay
- The guard the fix arms, replayed against the commit that introduced the defect, blocks it. A guard that would not have caught the original is a comment, not a guard.
- pr-ci
- The pull request's own checks passed.
- reproduction
- The failure was reproduced before the fix on the defective revision.
- deployment
- The fixed revision reached the environment the case came from.
- observation-window
- The source that observed the problem observed nothing matching for a stated window after deployment.
A check that did not run counts as failed, never as passed: an unavailable test runner is not evidence the tests pass. A check marked not applicable needs the reviewer's reason written down. The case's verification summary lists each check with its state and the reference it points at.
The exact-scope approval
A fix applies only under an approval whose fingerprint matches the scope it was given for: the action, the files, the brief, the target and the policy version. Change any of those and the approval no longer applies; the fix waits for a new one. The digest the desktop verified is recorded before the approval, so an approval pushed in the same snapshot binds to what was checked, not to what was described.
A drafted fix that cannot clear builds, tests and the guard replay is not shown at all. The finding is, with its attribution and the prompt behind it; the fix panel says the fix could not be written. Twenty plausible diffs would train a reviewer to approve the twenty-first unread.
Cost receipts
A receipt is one of three kinds: an actual amount from a metered call or a provider bill, an estimate from a modeled rate, or a refund. Actuals and estimates are shown apart and never added. A receipt without a known rate is counted as unpriced and given no amount. A share of a shared bill names its parent and its fraction, and a case never carries more than its part; a run priced against a prevention package is not counted again against the incident. The three usage lines a hosted run shows, priced, estimated and pending the provider's reconciliation, are never summed.
From a verified remedy to a lesson
A lesson is admitted only with the four facts: a confirmed cause (a person's finding, not two findings that conflict), a verified remedy (the eight checks say so), a repository, and a person doing the admitting. A draft is built from observed facts only, and a refused admission names the fact that is missing. What happens after admission, the package, the review and the rollout, is on Review a lesson and roll out a prevention package.
Recurrence
A new sighting after a case is resolved is a decision, never an automatic reopen. The versioned signature and the scope decide: a match reopens the case with the earlier resolution kept on the record and marks an admitted lesson for revision without touching its text; a sighting in scope with another signature links a new case; anything else is no match, with the evidence listed. A closed case that comes back is not a clean history rewritten; it is the same case with more on it.
Last updated