From Immutable Events to Immutable Software
Why a foundation of atomic ground truth makes software cheap to extend in the age of AI
This article states its conclusion first: a software system built on principled event-driven architecture — where L0 events capture atomic ground truth and nothing else — produces software that does not need to change. Not software that changes less. Software where the foundational layer is structurally immune to the forces that make most software increasingly expensive to maintain.
This is not a minor engineering benefit. In an era where writing new software with AI assistance is becoming cheap, the dominant cost is shifting entirely toward understanding, refactoring, and extending legacy systems whose foundations were built on assumptions that turned out to be wrong — the mutable history problem in slow motion. A system built on L0 atomic ground truth has fewer of those assumptions embedded in it — and the assumptions it does contain sit in layers that are expected to change, not in layers that everything else depends on.
The companies that build on this foundation will extend their software cheaply and quickly as AI capabilities grow. The companies that do not will spend an increasing share of their engineering effort fighting the accumulated cost of yesterday’s design decisions.
The argument rests on a facet we already have: atomicity. Why Atomicity Matters established that an artifact’s distance from the irreducible substrate — L0 through L3 — governs its schema stability. This article follows that one structural fact to its most important consequence.
See concept map: Trustworthiness dimensions (atomicity facet and L0–L3 ladder).
Schema immutability — the consequence that pays
An L0 event schema captures an irreducible truth. Its schema is defined by the structure of that truth — the authority, the moment, the minimal identifying information. XRayOrdered { orderId, physicianId, orderedAt, patientId, clinicalReason }. What would cause this to change? Only a change in what it means to order an X-ray. Not a downstream consumer’s requirements. Not a business strategy shift. Not a new reporting need.
Compare this to a schema designed to satisfy consumers: ClinicalOrderFeed { orderId, patientName, physicianEmail, departmentCode, priorityFlag, escalationContact, billingCategory }. Every field represents a different consumer’s current information appetite — a L2 or L3 projection shaped for today’s readers, the shape CRUD as domain language encourages when persistence verbs replace domain events. Every requirement change, every organisational restructure, every billing system migration touches it.
Schema instability is the dominant cost in most software organisations. Not the cost of writing new code — the cost of changing schemas that consuming systems depend on, migrating data to new shapes, updating contracts between teams, debugging inconsistencies during transitions. These costs are largely invisible until they accumulate into what is recognised, too late, as a legacy system.
When the organisation evolves, new L0 event schemas are added — not existing ones changed. XRayOrdered does not change. AIAssistedDiagnosisRequested is added alongside it. Old schemas are deprecated; new ones introduced. Append-only at the schema level, not just at the event level.
Change always flows downward — from world to L0 atom to L1 invariant to L2 compound to L3 rendering. L0 schemas are unchanged by any number of consumer changes downstream. L1–L3 schemas change constantly; that is expected and appropriate. The crucial property is that their changes never propagate upward.
The banking example — stabilisation in practice
A core banking system receiving payments from multiple standards illustrates both the mechanism and its payoff.
Switzerland operates across several payment standards: SIC (ISO 20022 camt.054 for CHF settlement), SWIFT MT103 (international correspondent banking), and SEPA pacs.008 (EUR payments). Each has its own schema, its own mandatory fields, subject to migration schedules the bank does not control.
The incoming payment messages are L0 designated observations at the integration boundary — one message, one moment, the system’s declared input from the external world (SWIFTPaymentReceived; Why Atomicity Matters, Captured Evidence). Their schemas are controlled by external bodies and are volatile.
An adapter layer translates each message and the bank commits acceptance as an internal posting at the commitment boundary — still L0, but in stable domain language: IncomingPaymentPosted { postingId, direction: CREDIT, transactionType: INCOMING_PAYMENT, counterparty.iban, sourceMessageRef }. The adapter is a named authority operating under a defined policy; sourceMessageRef preserves the committed provenance chain. These terms reflect banking concepts that outlast any payment standard.
When SIC migrates its message format, the SIC adapter is updated. The posting event schema is unchanged. Every downstream consumer — L1 balance computation (Enforcing Invariants Without Locks), L2 regulatory reporting, fraud models — is unaffected. The adapter absorbed the change at the boundary.
This is the stabilisation mechanism: volatile external observations normalised into stable L0 domain commits can provide a more stable contract than the raw message formats themselves. The information loss — MT103’s free-text remittance field normalised to a structured reference — is deliberate and characterised (data processing inequality). sourceMessageRef preserves the ability to retrieve the original if needed.
The L1 balance the posting stream maintains carries the same permanence once committed: “at 09:23:15, after posting LED-2024-0115-004521, the balance processor committed to the account balance being CHF 172,450.00.” That invariant is authoritative for the account stream, regardless of how many postings follow (One Authority Per Invariant).
Generalisation versus projection
Not all L1 and L2 artifacts are equally stable, and the distinction matters for where you invest.
A true L1 generalisation — a single-writer invariant over an ordered stream of L0 facts, as the account balance abstracts over payment standards via postings — is contract-stable. A L2 or L3 projection — selected and shaped for a specific consumer’s current needs — is contract-volatile. Both sit above L0; their volatility is dramatically different. What looks like L1 but spans incomplete or reordered history is really L2 (Why Atomicity Matters).
The architectural craft is to place true L1 invariants — and stable L0 domain commits at the boundary — where external volatility enters, so that volatility is absorbed and converted into stable internal concepts. Volatile, consumer-shaped L2 and L3 projections then sit downstream, where their churn harms nothing below them.
Stability propagates upward through the layers
Processors inherit this property. A processor that correctly maintains one stable L1 from a stable stream of L0 commits does not need to change when consumer projections churn. When requirements change, a new L2 or L3 consumer is introduced — the old one superseded, not mutated (When Facts Are Wrong). Container images (L1), deployment decisions (L0), running instances (L2): the same principle extends through every level (Immutable Infrastructure). Each layer inherits the stability of the layer below it.
In an era where writing new software with AI assistance is cheap, the dominant cost is refactoring legacy systems whose schemas were designed to satisfy yesterday’s consumers and have since been patched to satisfy today’s. A system built on L0 schemas that have not changed in ten years — because they correctly captured irreducible truths (Atoms of Truth) — is a system that can be extended cheaply, because the data contracts are stable, the semantics are clear, and new capabilities add to the foundation rather than negotiating with it.
Conclusion
The most important consequence of the whole framework is this: a system built on L0 atomic committed events has a foundational layer that almost never needs to change. Every layer above it — L1 invariants, L2 compounds, L3 renderings — may change freely, and those changes never propagate downward.
This is the property that allows software to be extended cheaply as requirements evolve. It is the property most legacy systems lack and cannot recover without reconstructing their history from scratch — because the history was never captured atomically in the first place (Truth Doesn’t Change).
The Swiss banking example showed that the facet is not merely analytical — it is architectural. The adapter layer absorbs payment-standard volatility by normalising volatile external observations into stable L0 domain commits, with L1 invariants downstream that inherit that stability. The commitment is only as trustworthy as the structural guarantees behind it — single writer, ordered stream, explicit causal chain. Get both right, and AI does not just help you write more software faster — it helps you extend a foundation that was built to last.
The deployment layer completes the arc — container images, deployment decisions, and rollback as committed events in Immutable Infrastructure.