Reversal Record

An architecture function has 180 decision records, review coverage of 70% and a dashboard. Asked how many of those decisions it has reversed, the answer is none.

That is not good judgement. Across three years and 180 decisions, zero reversals means one of two things: no decision carried a falsifiable expectation, or reversals happen and are not recorded. Either way the register is a publication record rather than a decision record, and the coverage number beside it is unaudited.

Why it matters

Architectural decisions have a feedback delay measured in years, so the loop closes only if something closes it deliberately. A register that accumulates decisions and retires none is a system with an input and no output, and its accuracy is unmeasurable by construction. A function also spends credibility every time it says no, and publishing reversals buys it back more cheaply than anything else, because the claim is unexpected and cannot be faked. The pattern across them shows which class of decision the function is systematically bad at.

Implementation patterns

• Make each decision reversible-on-a-signal when it is made. A record with no named observable and threshold cannot produce a reversal.
• Four fields per reversal: the original decision, the signal that fired, the date, and what replaced it - short enough that writing one is not a project.
• Publish the count with its denominator, one number a quarter against live decisions.
• Separate reversal from revision. Tightening a decision's scope is a revision; concluding it was wrong and undoing it is a reversal. Mixing them inflates the count and destroys its meaning.
• Name the unwind cost: engineer-weeks, systems carrying both shapes meanwhile, and whether anything became irreversible. A log without costs trains optimism.
• Tie review cadence to the signal, not the calendar. "Revisit in 12 months" produces no reversals; "revisit when write throughput passes 3000 per second" produces one on the day it matters.

Industry example

The practice is the organisational analogue of published postmortems. Across the documented incidents of 2017 to 2024, organisations that published their own analyses - a deleted primary database, a configuration push that pegged CPU worldwide, a failover that cost a day of reconciliation - gained credibility out of proportion to the embarrassment. A reversal record does the same for decisions rather than incidents: the organisation that publishes its corrections is the one whose other claims become believable. The difference is that an incident forces the write-up and a reversed decision does not, which is why it needs a named place to live.

Failure scenarios

• Zero reversals treated as success - the commonest failure, and the one that invalidates every other governance number.
• Reversals filed as new decisions, so the old record stays "accepted", the new one contradicts it, and nobody can tell which is current.
• A reversal that was not possible. The signal fires, the decision is agreed wrong, and a migration has passed its point of no return - the entry documents a cost rather than a correction.

Trade-offs

What it buys: a closed feedback loop on multi-year decisions, credibility unavailable by other means, and a diagnosis of the decision class the function handles badly.

What it pays: visible fallibility, landing on whoever runs the function. Six reversals reads as learning to a sympathetic audience and as repeated failure to a hostile one, and that interpretive risk is why most functions keep no such log. Making decisions falsifiable also costs time at decision time, because somebody must name a threshold and own a signal.

When not to use it

Below the volume where a rate means anything. A function making six decisions a year cannot produce a meaningful count - one reversal is either 17% or noise. Name the two or three decisions that must not be made twice, attach falsifiers, and review them individually.

And never as a substitute for the upstream discipline. The log is downstream of decisions carrying observables. Introduce it first and you get an empty page and the conclusion that the function is accurate - the precise misreading it exists to prevent.

Interview question

Q: "Your decision register has 180 entries and no reversals in three years. Argue that this is good, then tell me what you would actually conclude and what you would change first."

What a strong answer covers: the honest case for zero - a conservative function making low-variance choices - and why it fails at 180 decisions, since the expected number of wrong calls over three years is not zero unless the decisions were trivial. Then the diagnosis, testable by sampling ten records for a named observable with a threshold and an owner. Then the change: falsifiers on new decisions, and a published quarterly count with its denominator.

Quick check

Quiz: A function has 180 decision records and zero reversals in three years. What are the two explanations and which sample distinguishes them? Either no decision carried a falsifiable expectation or reversals happen unrecorded; sample ten records and check whether each names an observable with a threshold and an owner.

Flashcard: What four fields does a reversal entry need, and why is a non-zero rate healthy? - The original decision, the signal that fired, the date and what replaced it, plus the unwind cost; a function making dozens of falsifiable decisions a year and reversing none is uncalibrated.