The shape of the problem
Most systems that store data store the wrong thing. They keep the current answer and throw away the working. An account balance sits in a row as a single number; a customer record holds today's address; a document has one version, the latest one, and the rest is gone. This is efficient and it is also a kind of amnesia. The system can tell you what it believes. It cannot tell you why, and it cannot tell you what it believed last Tuesday.
Event sourcing is the alternative discipline. The durable record is not the current state but the ordered sequence of facts that produced it. An account balance is not a number; it is the sum of every deposit and withdrawal ever recorded, computed on demand. Current state becomes a derived artefact — a fold, in the technical sense: a left-reduction that walks the log from the start and applies each event to an accumulator. Because the events themselves are append-only and immutable, nothing is ever overwritten. You can rebuild any past state by folding up to that point and stopping. You can also compute a different answer from the same history by changing the function you fold with — a new reducer applied retroactively to old facts, yielding an interpretation the original system never held but the original facts fully support.
The distinction that matters is between state and history. A system built on current state answers "what is true now" and nothing else. A system built on an event log answers that question too, as one fold among many, but it also answers "what was true then," "what changed it," and "what would be true under a different rule." The log is the source of truth; every materialised view, including the one you read on a screen, is downstream of it and disposable.
Where it came from
The pattern is far older than computing. Double-entry bookkeeping, codified by Luca Pacioli in 1494, is event sourcing in ink. The journal is the append-only log; the ledger and trial balance are folds over it. An accountant who finds an error does not erase the entry — she posts a reversing entry, and the correction itself becomes a new event, fully attributed. Audit is possible only because the journal outlives every balance ever derived from it. Five centuries of financial trust rest on the refusal to overwrite.
In software the pattern arrived twice. First quietly: the write-ahead logs of System R and later ARIES, developed at IBM in the 1970s and 80s, kept an ordered record of every change for the sole purpose of crash recovery. The log existed so the database could reconstruct itself after a failure; no application was meant to read it. Second, deliberately: Greg Young named and argued for event sourcing as an application pattern around 2008–2010, pairing it with Command Query Responsibility Segregation, to solve a specific and narrower problem than the one this page is concerned with — domain models that silently lost business information every time a row was overwritten with its next value. Kafka, released by LinkedIn in 2011, then did for logs what relational databases had done for tables: turned an internal mechanism into cheap, durable, ordered infrastructure that any system could build on. The pattern moved from accounting technique, to recovery mechanism, to first-class architecture, in roughly that order.
The turn
Here is where the pattern stops being a storage choice and starts being a description of what a system is permitted to know. Consider what each of the three generations in the lineage — Large Language Model, Large World Model, Large Universe Model — is actually storing, and the event-sourcing vocabulary sorts them without effort.
A Large Language Model is trained on a corpus, then frozen. Its weights are a materialised view whose log was thrown away at the moment training ended. There is no way to ask such a model when it learned a given fact, no way to replay its beliefs as of a particular date, no reducer to rerun because there is no log to rerun it over. This is not a defect anyone forgot to fix. It is the direct consequence of a data model that keeps state and discards history.
A Large World Model does better, but only within a boundary. It folds a stream of sensor events into a running estimate for as long as a scene lasts — provenance exists, briefly, while the episode is live. But the window is short and closes: once the scene ends, the log is discarded, and only the final fold — the last materialised belief — survives. Provenance is real but ephemeral, which in event-sourcing terms is the rolling-window compromise teams use when they cannot afford to keep everything: useful, but structurally incapable of retraction after the fact, because the facts are gone.
A Large Universe Model is the case where the log never closes and is never thrown away. Every stream still arriving is appended, with source, timestamp and confidence attached, and every belief the system holds is a fold over that log rather than a stored conclusion. Change the reducer — because a better model of a sensor's reliability arrives, say — and old events can be refolded to produce a revised belief, with the revision itself logged. This is the same operation an accountant performs with a reversing entry, run continuously over every stream a system can observe.
The intake axis is exhausted at that point, and this is the substance of the claim, not decoration on it. Evidence arriving after continuous, provenance-bearing ingestion is adopted can be more voluminous, more trusted, or more timely. It cannot be of a fourth kind, because "everything, still running, with source and confidence attached" has no further direction to extend into. A Large Universe Model is not a grander architecture bolted onto a Large World Model. It is the identical fold with the stopping point removed and the log kept instead of discarded.
The misreading to disown
The weak version of this argument says: keep everything, forever, and truth will emerge from volume. It will not. A log stuffed with unattributed, unweighted events produces slower confusion, not better belief — more facts to be wrong about, no better means of adjudicating between them. The value in the pattern sits entirely in the pairing of an immutable event with a versioned reducer applied to it. Change the reducer and history yields a different answer; that is a strength only if you know which reducer produced which answer and can name both. Hoarding data is not epistemics. This page's claim concerns the capacity to recompute and retract cleanly, not the size of what is retained.
Objections that hold weight
Event sourcing has a poor track record. Logs grow without bound, replays take hours, event schemas rot, and most teams retreat to snapshots and CRUD within a few years.
True, and worth taking at face value. But the retreat, examined closely, is almost always from full replay on every read, not from keeping the log at all. Teams that abandon naive event sourcing typically keep the append-only history and add snapshots and checkpoints on top — which is precisely the architecture this argument requires: authoritative history plus cached folds for speed. That is cost engineering layered on the requirement, not an escape from it.
Folds assume an order, and at the scale this thesis cares about — billions of concurrent streams — there is no single true order. Clock skew and network partition mean the log is at best a partial order.
This is the sharpest objection and it narrows the claim rather than merely qualifying it. Global total order across independent streams is not available; Lamport clocks and vector clocks give causality, not chronology. The honest consequence is that reducers must be built to tolerate this — commutative, associative, idempotent, in the manner of a conflict-free replicated data type where possible, and explicit about representing disagreement where it is not. Naive determinism does not survive. The requirement for first-class provenance and confidence gets stronger, because it is exactly what lets a system represent "these two events cannot be ordered" instead of quietly guessing.
Provenance is not justification. A perfectly attested log of a lying sensor produces perfectly attested falsehood. Auditability is governance, not epistemics, and treating it as warrant smuggles in a philosophical conclusion it hasn't earned.
The distinction is correct and should be kept sharp. Provenance is necessary, not sufficient. What it buys is narrower: the capacity to revise. When a source is later shown unreliable, a system that recorded which beliefs depended on it can withdraw exactly those and refold the rest, in the manner of Jon Doyle's dependency-directed backtracking. Good sources and good reducers still have to be supplied from elsewhere. The log does not manufacture truth. It is what makes truth maintainable once you have it.
What this does and does not establish
Event sourcing establishes that a system required to hold revisable, auditable belief has exactly one viable storage shape: an immutable, provenance-bearing event log with state as a derived fold. It establishes that the Large Universe Model, so described, is the terminal point on the intake axis specifically — not the smartest system conceivable, not a claim about reasoning, planning or judgement, only about what may be taken in and how cleanly it may later be taken back. It does not establish that such a system is easy to build, cheap to run, or immune to disagreement about order and trust. It does not establish that more log makes for better belief; the reducer matters as much as the record. And it does not make the Large Universe Model a thing that exists on a shelf. It is an argued category, forced by the same logic that has kept accountants writing reversing entries for five hundred years, not yet, anywhere, a finished machine.