Supersession (append-only correction)

Supersession is the correction discipline of an append-only financial ledger: when a calculated figure turns out to be wrong — late data arrived, a rate was amended, an eligibility decision changed — the correction is recorded as a new event that references the original, and the original is never edited or deleted. Current state is derived from the full event stream; history is derived from the same stream, unchanged.

Why overwriting is the audit trail’s failure mode

In a spreadsheet or a mutable database, a correction replaces the old number. The consequences compound quietly:

• Last quarter’s reported number becomes unreproducible. The figure that was certified at close no longer exists anywhere — only its replacement does. “Show me the number as it stood on March 31, and why” becomes a reconstruction project.
• The reason for the change evaporates. An overwrite records the new answer but not the delta, the cause, or the approver. Corrections stop being explainable events and become silent divergences between report runs.
• Errors and fraud look identical to routine edits. When everything is mutable, an auditor cannot distinguish a legitimate true-up from a number that was quietly moved. The control has to be architectural, not procedural.

What supersession looks like operationally

The original accrual event stands. A recalculation produces a correcting event that carries: a reference to what it supersedes, the delta, the cause (late returns, rate amendment, eligibility change), and the named human who approved it before it took financial effect. The true-up becomes a query over these events rather than a plug; the audit trail becomes a property of the data model rather than a discipline someone has to remember. Supersession is the mechanism underneath calculation lineage: lineage tells you where a number came from; supersession guarantees the history it points at is still there.