When Facts Are Wrong
Corrections, amendments, and compensating transactions
The immutability axiom from Truth Doesn’t Change and the immutability of facts holds absolutely: facts are immutable; the past does not change (corollaries 1–2). An event that happened, happened. It cannot be un-happened.
But humans make errors. Machines fail. The patient’s ID was entered incorrectly. The sensor was miscalibrated for three months. The model produced a wrong classification (inference as fact). The physician ordered the wrong test. Reality turns out to be different from what was recorded.
How does an immutable system handle this? Corollary 3: correction is a new fact that references what came before — not mutation of the original. When something is wrong, the right response is to record a new event that acknowledges and addresses what was wrong. The log remains append-only. The past remains fixed. And the record becomes richer, not corrupted.
This produces a set of patterns that apply across every domain. Understanding them prevents the temptation — which is strong — to simply update or delete the original record.
Why not just fix it?
The temptation to fix an error by updating the original record is understandable. It is cleaner, simpler, and leaves no trace of the mess. This is precisely the problem.
When a record is silently corrected, three things are lost:
The fact that an error occurred. Errors are events. The fact that a radiographer entered the wrong patient ID is as real as any other fact in the system. Erasing it does not make the error not have happened — it makes the error invisible. And invisible errors cannot be learned from, cannot be investigated, and cannot be defended against.
The accountability for the correction. Who noticed the error? When? How was it detected? Who authorised the correction? These are facts that belong in the record alongside the original error. A silent update preserves none of them.
The history of downstream effects. Between the original error and the correction, downstream systems may have acted on the erroneous data. Those actions are real and permanent. Silently fixing the source does not undo them — it just removes the explanation for them.
The immutable log is not just a performance choice. It is an epistemic commitment: the record contains what actually happened, including the mistakes and the corrections, not a sanitised version of events. It is also, as the previous part argued, a defence against the deliberate burial of inconvenient truth — you cannot quietly delete what was never deletable.
Pattern 1 — Supersession
A new decision references and supersedes an old decision. Both remain in the record.
This is the right pattern when a judgment or commitment turns out to be wrong, but the original was made validly — with the information available at the time, by a qualified authority, in good faith.
The radiologist documents DiagnosisDocumented: pneumonia. Six months later, a specialist concludes it was early-stage lung cancer missed at the initial reading.
The original diagnosis stands as a permanent fact: this authority, this conclusion, this moment. The specialist’s assessment does not erase it. It adds to the record:
Now the record contains both facts: what was concluded initially, and what was concluded on review. This is more truthful than a system that silently overwrites the first diagnosis. It also preserves accountability — the original radiologist is not erased from history, and the specialist’s revision is explicitly attributed.
Supersession applies broadly: hypothesis withdrawn when evidence rules it out (HypothesisWithdrawn), order cancelled when a better approach is identified (XRayOrderCancelled), policy decision reversed when circumstances change. Each reversal is a new commitment referencing the old one. Both coexist permanently.
Pattern 2 — Correction event
A factual error in the recording of an event is corrected by a new event that references the original and provides the corrected value.
This pattern applies when the underlying process was valid but the recording was wrong. The radiographer successfully completed the X-ray imaging process — but entered the wrong patient ID into the system. The imaging happened correctly. The attestation carried an error.
The original XRayTaken event stands — it is a permanent fact that this attestation occurred. The correction event adds two new facts: the content of the original event was wrong in a specific way, and someone took responsibility for correcting it.
This pattern preserves the full accountability chain. Who made the error (the radiographer who entered it), who detected it (the scheduling system), who corrected it (the same radiographer), and when all of these happened — all permanent, all traceable.
Note that the correction event itself is a decision event: an attestation that the corrected value is the right one. It carries the same accountability properties as any other attestation.
Pattern 3 — Compensating transaction
A real-world effect produced by an action must be undone. The original action and its effect are permanent. A new action compensates — it does not delete.
This is the pattern familiar from financial systems, but it applies everywhere.
PaymentCharged { amount: 150.00, customerId } produced a real-world effect: money moved. If the charge was wrong, the response is not to remove the charge event — it is to add a new event:
Both events are permanent. The charge happened. The refund happened. The net effect is zero. But both facts exist in the record, with full accountability for each.
Compensating transactions appear everywhere: orders cancelled after fulfilment (requiring return and refund processes), prescriptions revoked after dispensing (requiring intervention), deployments rolled back after going live. In each case, the original action is permanent, the compensation is a new action, and both are recorded with full accountability.
Machine error cases — the differences that matter
Human errors and machine errors look similar from the outside but have different accountability structures.
Machine self-report of failure. An automated scanner publishes ScanFailed: equipment error. This is a pragmatic observation — the machine reporting its own state. No correction is needed to the log: the failure is itself the ground truth. The response is operational: repair the equipment, retry the process. The failure event is a permanent record of what happened.
Machine reports completion but output is invalid. The scanner publishes XRayTaken but the resulting image file is corrupted — all pixels zeroed out. The event is a valid record of what the machine reported. The artifact it claims to have produced is separately invalid.
The response requires distinguishing these two things:
The discarding is itself an attestation decision: a system (or human) assessed the artifact and committed to treating it as unusable. This triggers a retry — a new XRayOrdered or direct re-execution — which produces its own chain of events. Two outcome chains exist in the log: the failed one and the successful one. Both are real. Both are traceable to the same original order.
Calibration drift. An instrument has been reading 0.5°C too high for three months. All its readings are in the log as pragmatic observations — they correctly record what the instrument reported. They cannot be corrected, because they are truthful records of the instrument’s output at the time.
What can be recorded is:
Downstream consumers who need accurate temperatures for that period now have the information to adjust their analyses. The original readings stand as permanent records of what the instrument reported; the calibration event is a new fact that puts those readings in context.
This distinction — between records of what was reported and corrections to their meaning — is important. The readings were not wrong as records. They were accurate measure captures of what an inaccurate instrument reported. The calibration event does not correct the readings; it characterises them. It is the difference between measure capture (what was reported) and the claim built on top (what was true).
Correction events make accountability visible, not invisible
There is a counterintuitive property of this approach. A system with explicit correction events appears messier than a system that silently fixes mistakes. The log contains errors. It contains corrections. It contains failed attempts alongside successful ones.
This appearance of messiness is actually superior accountability. The errors happened. The corrections happened. Who made the error, when it was detected, who corrected it, by what authority — all permanent. The corrected record is not a fiction of a system that never made mistakes. It is an honest record of a system that made mistakes and dealt with them.
In regulated domains — healthcare, finance, legal — this is not just preferable. It is required. The audit trail is not an optional feature. It is the record of what actually happened. Silent corrections are not cleaner records. They are falsified records.
The three patterns summarised
Every error and correction case in any domain resolves into one of these three patterns:
Supersession — new decision references and supersedes old decision. Both remain. Used for: judgment revisions, cancellations, withdrawals, revoked hypotheses, changed conclusions.
Correction event — factual error in a recording is corrected by a new recording that references the original. Both remain. Used for: mis-entries, wrong values, clerical errors where the underlying process was valid.
Compensating transaction — real-world effect is reversed by a new action. Original and compensation both remain. Used for: reversing the consequences of committed actions that produced real-world effects.
These three patterns are sufficient for all cases. The common thread: the log is append-only. Errors produce new events, not mutations. The record gets richer, not sanitised. And the same discipline that lets a system correct itself gracefully — the refusal to overwrite the past — is what non-propagating refutation (The Retraction vignette) needed and lacked: a refutation that is itself a recorded fact, able to propagate to everything that depended on the claim it overturns. Part IV develops that propagation formally in The Epistemic Ladder — after we name how strongly any claim is supported.
Part III complete — into the facets
Part III established bind (The Moment of Commitment), standing (But Commitment Is Not Enough), and correction without erasure (this article). Part IV — The Facets of Trustworthiness asks the next question: given a claim in the log, how strongly is it actually supported? It begins with the scale every statement needs — Every Statement Has a Tier.