Never overwrite a failure: the error register is evidence, not a task list.

The rule

Two classes of field, and only one of them is writable after the fact.

An error row carries evidence and it carries status. The evidence is the Error ID, the Test Run ID and Scenario ID that exposed the defect, the Expected ID whose contract failed, the expected and actual result pair, the failure class, and the severity assigned at discovery. None of it may be altered afterwards. The lifecycle fields — fix applied, latest retest ID, retest status, error status, and whether the issue blocks the next increment — are the only ones updated as a defect progresses. The separation is what allows the register to be simultaneously a live control surface and a permanent record, and collapsing the two is what turns it into neither.

What the preserved record buys

A failure history is the only way to see a pattern in defects.

The immediate value of an error row is operational — something is broken and needs fixing. The durable value is statistical. Preserved failure classes across many runs reveal whether a workbook family fails predominantly on lookups, on maturity states, on source routing, or on display, and that distribution is a far better guide to where the fragility lives than any individual defect. Overwriting evidence on repair destroys exactly this: the register ends up holding only currently-open issues, which is a task list. A task list can tell an operator what to do today and can never tell them that four of their last six defects were routing errors in the same tab.

• Failure class and severity recorded at discovery are the fields a pattern is built from — and the ones most tempting to revise later.
• Severity re-assigned after a fix is severity assigned by someone who knows the fix was easy.
• A register holding only open items has no memory, and a QA system with no memory relearns the same lesson repeatedly.

The retest rules

Same defect keeps its Error ID; a new defect earns a new one.

The retest doctrine resolves the cases that would otherwise corrupt the register. A defect still broken after repair keeps its original Error ID and gains a new Retest ID recording the failed attempt — creating a second error row would double-count one defect and inflate the blocker total. A defect fixed and passing retest has the pass recorded in the retest log, with only the original row's lifecycle fields updated; the pass proof does not belong in the register at all, because the register is for defects rather than for generic passes. A genuinely distinct defect discovered during a retest gets a new Error ID, because it is a separate issue that happened to surface in the same session. And a regression is flagged as such in the retest log, with an explicit decision about whether it warrants its own error row.

The false blocker problem

Only a real Error ID may block advancement.

There is a practical failure mode on the other side of the discipline. Master Control counts open critical and high blocking errors to decide whether advancement is safe, and if it counts rows whose Error ID is blank — placeholder rows carrying default severity or blocking values — the system will report blockers that do not exist. The consequence is worse than an inconvenience: a readiness signal that is wrong in the cautious direction still trains an operator to disregard it, and a blocker count that is routinely ignored is functionally identical to no blocker count. The rule is that severity, blocking flags, and status values only count when attached to a nonblank Error ID.

The key idea

A repair changes the system; it must not change the account of what was wrong.

Once a defect is fixed it becomes very easy to believe it was never serious, and an editable record will drift toward that belief one small revision at a time. Freezing the evidence at discovery is what keeps the register capable of contradicting the operator's memory of their own system's reliability.