Failure, register, fix, retest, close: the lifecycle that forbids 'I think it's fixed.'

The lifecycle

Five stages, none skippable.

The cycle runs: failure discovered during inspection, registered in the Error Register with its full evidence, fixed in the target workbook, retested by rerunning the same scenario, and only then closed. Each stage produces a record — an Error ID, a fix note, a Retest ID, a status update — and the guide names the reason for the whole apparatus: it forces disciplined repair proof instead of 'I think it is fixed.' That sentence is the lifecycle's entire justification. Spreadsheet fixes are unusually prone to the illusion of completion, because changing a formula produces an immediate plausible output, and plausibility is exactly what black-box testing exists not to trust.

The evidence pair

Expected result and actual result — the row that makes a defect real.

An Error Register row carries the Test Run ID, Scenario ID, and Expected ID that produced it, alongside the core evidence pair: expected result against actual result. That pairing is what turns a complaint into a defect. 'The dashboard looks wrong' isn't actionable; 'under scenario S-004, block X was expected to show Blank per contract EXP-021 and showed 0.00' is a defect with a reproduction case, a contract reference, and an unambiguous pass condition for the eventual retest. The row also carries failure class, severity, blocking status, and formula audit status — so the register isn't just a list of problems but a triage surface.

The retest rule

Same defect, same Error ID, new Retest ID.

The identity convention is small and load-bearing: if the same defect is still broken after a fix attempt, it keeps its original Error ID and gets a new Retest ID; a genuinely new distinct defect gets a new Error ID. The rule preserves defect history honestly — a stubborn problem shows as one error with three retest attempts rather than three separate errors, which is a materially different picture of the workbook's health. And the corresponding failure mode is named in the troubleshooting table: a retest marked passed while the original error remains open, because the register's status was never updated from the retest log. Two logs, one truth, and a discipline about keeping them synchronized.

• The Error Register preserves defect history; the Retest Log proves the fix worked. Neither substitutes for the other.
• Placeholder rows should not block advancement — the register is for observed failures only, not speculative ones.
• Needs Review is a certification blocker, not a soft state. Unresolved ambiguity cannot be certified around.

Derived readiness

Master Control reports readiness — it never asserts it.

The QA cockpit summarizes the active workbook version, current run, scenario, blocking error count, readiness, latest retest status, and next action — and the doctrine is explicit that readiness is the downstream result of the logs being clean, not a manual opinion. That inversion is the governance point. A readiness flag an auditor can set by hand is a feeling with a checkbox; a readiness flag computed from open blocking errors and retest statuses is a fact about the record. It's the same architecture as every other authority in MARS: the state is derived from evidence, and no one gets to declare it.

The key idea

Proof of repair is a different claim from application of repair.

Most systems conflate them, and the conflation is where regressions live: a fix applied, assumed good, and quietly wrong until it surfaces months later in production data nobody can trace. The lifecycle separates the claims and demands evidence for the second one — rerun the scenario, record the result, close only on a pass. It's slower than fixing things, and it's the difference between a workbook that has been repaired and one that can prove it.