Mutable History
Correcting the past by altering records instead of appending to them
The past does not change — corrections are new facts that reference what came before, never silent rewrites.
An error is discovered. The instinct is to fix it — update the row, delete the bad entry, re-run the pipeline with corrected inputs so the history looks clean. The record now shows what should have happened. What actually happened has been erased, and with it the ability to explain every downstream action taken on the wrong data.
When concealment is deliberate — hiding deviations, inventing events, backdating binds — the failure crosses into record falsification, not merely negligent overwrite.
In software systems
The failure takes several forms, all violating append-only discipline. Direct mutation: UPDATE patients SET diagnosis = 'corrected value' WHERE id = 10293. Soft deletion: tombstone flags that remove events from consumer views while claiming immutability. Replay-with-erase: reprocessing an event stream from a checkpoint and overwriting projections as if earlier states never existed.
Database administrators perform “data fixes” under change tickets that authorise mutation rather than compensating events. Audit tables exist but are optional and inconsistently populated. When a sensor miscalibration is discovered, three months of readings are bulk-updated rather than corrected through ReadingSuperseded events that preserve the original attestations. Downstream analytics recomputed on sanitized data lose the window during which decisions were made on wrong inputs — making root cause analysis impossible.
In human organisations
Organisations maintain mutable histories through document revision culture. Policy manuals are reissued with identical version numbers and altered text. Meeting minutes are edited after the fact to reflect “what we meant.” HR records replace entries rather than annotating corrections. Email threads are the only semi-immutable artifact — and even those get deleted under retention policies that confuse hygiene with truth.
The organisational instinct toward clean narrative is strong. Admitting error in the permanent record feels like liability exposure. Legal counsel sometimes advises silent correction. The result: nobody can reconstruct the sequence that led to a bad outcome because the sequence was laundered. Training cases cannot use real failures because failures were erased. Accountability diffuses because the record no longer shows who knew what when.
In socio-technical systems
Financial reconciliation exposes the compounded failure. A payment was applied to the wrong account. Operations updates both account balances directly in the core banking system. The customer’s statement shows continuity; the error window is invisible. When the customer disputes a later charge, support cannot explain intermediate states because those states were never recorded as events — only the current balance exists.
Regulators request transaction history and receive a coherent ledger with no trace of the misallocation or its correction. The software supported mutation; the organisation authorised it through override procedures; the socio-technical norm treats the current state as the only state worth keeping. Compliance dashboards turn green. Forensic reconstruction becomes an act of archaeology across backup tapes and oral history.
Structural causes
Diffuse write authority
When many actors can mutate the same facts — admins, support tools, batch jobs, “break-glass” operators — history becomes negotiable. Immutability of facts requires a single append-only discipline; diffuse write paths make silent UPDATE the path of least resistance. Each privileged writer can “fix” without emitting a compensating L0 event.
Corrections belong in the log as new facts — supersession, correction events, compensating transactions — never as erasure. The single writer principle limits who may commit changes to a domain; combined with forward-only correction events, mutable history becomes architecturally impossible rather than culturally discouraged.
CRUD as domain language
Generic Updated events and update-as-truth naming teach consumers to treat the latest row or event as authoritative — correction by overwrite feels natural. When tier-one vocabulary is CRUD-shaped, mutable history is the failure mode teams observe; CRUD-ism is the structural habit that keeps producing it even inside —event-sourced— systems.