Immutability of Facts
The past is append-only — never rewritten in place
Facts are immutable; correction is always forward through new events, never silent modification of what was committed.
A fact that happened, happened — facts are immutable (Truth Doesn’t Change). An order placed at 14:32:07 on a specific date by a specific customer does not change when the order is cancelled; cancellation is a new fact, not an edit to the original. This principle is the operational form of that axiom: systems model reality by preserving history, not by storing lossy summaries that discard the sequence of what occurred.
Violating immutability destroys information that cannot be recovered. Update queries that overwrite status, migrations that transform historical rows, pipelines that replace yesterday’s snapshot with today’s — each treats the past as mutable. The symptoms feel like complexity problems; they are truth problems. Audit becomes archaeology. Replay becomes impossible. Appeals reference a record that no longer contains what was known at the time.
Immutability applies most strictly at L0 — atomic committed events — but the spirit extends upward: even aggregates and renderings must not silently rewrite what downstream systems treat as ground truth. When something was wrong, the principled response is corollary 3 in operation: supersession, a correction event, or a compensating transaction — visible in the record, not a backdated correction that pretends the error never existed.
Personal-data systems must reconcile immutability with lawful erasure and rectification — see GDPR, immutability, and erasure. Silent delete is neither principled immutability nor compliant erasure.