Demo · Immutable ledger

Why editing the books destroys history

Hard problem

An audit asks what the books said on a date in the past. A ledger you edit in place cannot answer, because each correction destroyed the version the question is about. The folder of copies named v1, v2 and final-FINAL is the workaround, and it is a versioning system nobody designed: which file is authoritative is a matter of memory, two people can edit different copies, and the history it preserves is whatever somebody thought to save.

Approach

Never overwrite, and versioning follows. Every change is appended, corrections included, so no past state is destroyed and any date is answered by replaying the log up to that point — immutability is the mechanism, being able to ask what the books said is what it buys. The pattern is event sourcing; the two clocks it needs, when a thing happened and when you learned it, are what bitemporal records are for.

The trick isn’t saving copies; it’s that history is a query: the books store what changed, and any past state is recovered by asking for it as of a moment in time. Below, the same journal in two books — one built that way, one not.

Two ways to keep a book

Same journal lines, same chart. One book remembers every state it ever held; the other forgets the moment you edit it. Play with both.

Immutable book

Each commit appends to an immutable log — nothing is overwritten. To fix a mistake you append an adjusting line; the original entry and its correction both stay on the record, and every past state stays queryable, plotted as its own series.

No versions yet — commit one to plot it.

Honest cost: the log only grows by what changed (0 entries), never by full copies. At scale you materialise the current state for speed and answer the past with as-of queries — but you never lose it.

Mutable book

Only one book exists. Every edit overwrites in place — the chart shows just the present, and the evidence the books ever said something else is gone.

Net: $1,700

— Current

$0 … $1,700

2026-01-312026-03-31

Time-travel: as of knowledge-time…nothing to travel to

The slider is inert: there is no history. 0 edits → 0 past states unrecoverable.

The trap: it looks tidy — one clean line, no clutter. That tidiness is the data loss.

The axes are the same on both: X = entry date, Y = cumulative net (revenue − expense). The only difference is what happens to the past when you change your mind.

What immutability buys you

Everything below falls out of the same property: state is derived from an append-only log of events.

Full audit trail

Every version is preserved, so you can answer “what did the books say on day N?” without a backup.

Corrections, not erasures

Fixing a mistake appends an adjusting entry. The original error — and its fix — both stay on the record.

Time-travel queries

Reconstruct any historical state on demand; reporting periods become a filter, not a snapshot you had to remember to take.

The idea in full, without the toy — Declarative accounting, explained; and where this property lets AI sit next to the books — the harness.