Truth Doesn't Change
The axiom that everything else follows from
The nine failures of the previous article share a wound: a statement had an epistemic status, and the system failed to track it honestly. Before we can track the status of a truth, we have to be clear about what a truth is — and about the one property of truth that systems most often deny.
This article is expressed in terms of software, but it is not primarily about software systems. It is about human systems. The first insight — and the one everything else follows from — is that what happened does not un-happen. We state that insight as an axiom about facts, not as a slogan about truth in the abstract.
Systems that fight reality
There is a category of architectural problem that no amount of refactoring fully fixes. You add abstraction layers, introduce interfaces, reorganise modules — and the system improves, but the underlying problem remains. Data flows in ways nobody fully understands. Changes in one place cause failures in another. Audits are painful. Reproducing a past state is expensive or impossible.
These symptoms feel like complexity problems. They are not. They are truth problems.
The systems that produce these symptoms share a silent assumption: that the present state of a thing is more real than its history. That what something is now is the ground fact, and what it was is secondary — an audit trail bolted on, a log kept for compliance, a version history that nobody reads.
This assumption is wrong. And building on it produces systems that fight reality rather than model it.
What truth actually looks like
Consider a customer placing an order.
The conventional data model records the current state. There is an orders table. A row is inserted. Later, if the order is cancelled, the row is updated. The current row represents the current truth.
But what actually happened?
The customer added items to a cart — several times, with removals in between. They selected a shipping option. They applied a discount code. They reviewed the order. They confirmed it. Each of these was a discrete act at a specific moment.
The order row captures none of this. It captures a summary of the final state, discarding everything that led to it. The history — the actual sequence of what happened — is gone. What remains is a lossy compression of the truth.
When something goes wrong — a disputed charge, a fraud investigation, a regulatory audit — the question is always about history. What happened? In what order? Who did what and when? The system that stores only current state cannot answer these questions. The history was never recorded. It cannot be recovered.
The axiom
Axiom. Facts are immutable.
Corollaries.
- The past does not change.
- A system that allows the past to be modified is not modelling reality — it is replacing it with a more convenient fiction.
- Correction is a new fact that references what came before; it does not un-happen what was recorded.
The axiom is one predicate on one kind of thing: a fact is an occurrence that happened — specified by what occurred, when, and (where it matters) by whom. Immutability means such an occurrence does not become un-happened because something later edits the record. Corollary 1 is the same commitment in the language of time: the sequence of what occurred is fixed; later events add to history — they do not rewrite it. Corollary 2 is the consequence for systems that claim to hold facts: overwriting the record is not correction; it is replacing reality with a more convenient fiction and destroying information that cannot be recovered. Corollary 3 states what honest correction is: a new fact — cancellation, supersession, retraction — that references the earlier one; the original remains in the record. Immutability is not denial of error; it is refusal of silent rewrite. (Patterns for correction: When Facts Are Wrong — supersession, correction events, compensating transactions.)
An event that happened, happened. An order was placed at 14:32:07 on a specific date by a specific customer. That fact does not change when the order is cancelled. Cancellation is a new fact — a new event — not a modification of the original one.
This sounds obvious when stated plainly. It is violated constantly in practice.
The violation takes many forms. An update query that changes a record’s status. A migration that transforms historical data to fit a new schema. A data pipeline that replaces yesterday’s snapshot with today’s. Each one treats the past as mutable — the mutable history failure mode. Each one destroys information that cannot be recovered.
The properties that follow
The axiom is not interesting because it is philosophically tidy. It is interesting because of what it produces automatically — without additional design, without extra features, without bolted-on tooling.
Auditability. If every fact is recorded and nothing is deleted, the complete history of every event is always available. Audits become queries, not archaeology.
Replayability. If the history is complete, any past state can be reconstructed by replaying events up to a point in time. Debugging becomes time travel. Reproducing a problem means reconstructing the exact state that triggered it.
Evolvability. If the past is fixed, the future is always additive. New capabilities are new consumers of existing facts — never modifications to the facts themselves. Deploying a new feature cannot break existing behaviour because the ground truth it depends on has not changed.
Scalability. Immutable facts can be partitioned, replicated, and distributed without coordination. You cannot have a write conflict on something that is never updated. The hardest problems in distributed systems — consistency, coordination, conflict resolution — become simpler when the thing being distributed is append-only.
Decoupling. A producer of facts does not need to know who consumes them or for what purpose. The fact stands alone. Consumers can be added, removed, or replaced without the producer noticing.
Learning and improvement. A complete history of what happened is the raw material of every kind of learning. Patterns can be found in it; models can be trained on it; mistakes can be studied because they are still in the record rather than overwritten. A system that keeps only its current state can describe what it is; a system that keeps its history can explain how it got there, and therefore how to do better. This is also what makes intelligent automation possible at all — an automated system can only learn to act well from a faithful record of how things actually unfolded, including the decisions that turned out badly.
Retroactive capability. Because the past is preserved at full grain, a new feature is not limited to the future. A capability added today can be applied to the entire history and behave as if it had always been there. A new fraud signal can be computed over every transaction ever recorded. A new metric can be back-filled across years. A new view of the data can be derived from events that long predate the idea of it. State-based systems cannot do this — the detail the new feature would need was discarded when only the latest state was kept. Immutable history turns “we’ll have this data going forward” into “we have always had this data.”
Attribution and fair compensation. This is the property that matters most once people, not just machines, are in the picture. A faithful record of who decided what, who contributed what, and when, is the only honest basis for assigning credit. When the history is complete, the questions that decide reward can actually be answered: who made this call? whose contribution moved this outcome? who therefore deserves a share of what it produced? A system that overwrites its past cannot attribute fairly, because the evidence of contribution is gone — and in its absence, credit flows to whoever is loudest or most senior rather than to whoever did the work. An immutable record of decisions and contributions is the substrate on which attribution, recognition, and even dividends can be computed rather than negotiated. (Who is accountable for a decision, and how much their commitment weighs, is taken up in Part IV — Commitment, Authority, and Decisions; how contribution converts to fair reward is part of the work this series opens onto.)
None of these are features you design. They are consequences of one decision: treat facts as immutable (axiom), the past as append-only (corollary 1), and correction as forward-only (corollary 3).
Derivations are not truth
Not everything in a system is a fact. Some things are computations over facts — aggregates, summaries, projections, read models. A customer’s account balance is not a fact. It is a computation over a sequence of transactions. A product’s average rating is not a fact. It is a computation over a sequence of reviews.
These derived values are useful. Systems need them. But they are categorically different from the facts they are derived from.
The critical difference is directionality. You can always derive the balance from the transaction history. You cannot recover the transaction history from the balance. Derivation is a one-way function. Information flows from facts toward derivations and does not flow back.
This means:
- Facts are primary. Derivations are secondary.
- Facts are permanent. Derivations are rebuildable.
- Facts are the source. Derivations are caches of convenience.
- Facts can be depended on freely. Derivations must be depended on with explicit awareness of what has been assumed and what has been lost.
A system that treats a derived value as ground truth — that makes decisions based on a projection without tracing back to the facts that produced it — is standing on sand. When the derivation logic changes, the ground shifts. When the derivation has a bug, there is no way to recover what the correct value should have been. The facts that would allow reconstruction are gone, because nobody thought to keep them.
The question to ask — and its answer
When looking at any piece of data in a system, any artifact in a pipeline, any value in a computation, the right question used to seem simple: is this a fact or a derivation?
That binary is the right starting point. But it pushes further, and the further question turns out to be more important.
Even observations — sensor readings, log entries, instrument measurements — are not unmediated reality. A thermometer reading is not the temperature. It is the temperature as reported by an instrument, through a measurement chain, subject to calibration, noise, and drift. A chest X-ray is not the patient’s tissue. It is a transduction of the patient’s tissue through radiation, sensor, firmware, and compression. Every observation invites the question: what produced this? The regress continues.
And there is a third kind of thing that is neither a derivation nor an observation in this sense. When a physician documents a diagnosis, when a judge reaches a verdict, when an algorithm commits to a classification — something categorically different happens. A named authority converts their reasoning into a commitment. The act of committing and the fact of the commitment are the same thing. The regress stops — not by convention, but by nature.
The next part develops these kinds of truth in full. But there is a more immediate, more practical question first — one this article has quietly assumed away. We have said facts are immutable and systems must not rewrite the past. We have not said how truth gets into a system at all. A system holds only the truth it captured, and there is a right and a wrong way to capture it. That is where the next article goes, before we return to the kinds of truth themselves.
Facts are immutable. Build systems that know that — starting with how they capture them.