One idea has been carried from the first project to the last, through a year of clean rewrites: the thing the user sees is a document — a composed shape — and keeping it truthful against relational tables is the whole problem.
Each project was a clean rewrite rather than a refactor of the one before. That sounds wasteful and wasn't: every rewrite was an attempt to say the same thing more exactly, and what survived a rewrite had earned the trip.
Each stage also names the Claude model it was built with, read off the commit trailers — except for the first two, which predate the trailers recording it and are from memory. The run from Opus 4.5 to Fable 5.1 is part of this history, not a footnote to it: the work got more ambitious as the collaborator did.
September 2025 – January 2026 · Claude Opus 4.5
A database-first compiler: declare a domain, compile it to Postgres stored functions, a typed client and generated stores. "Document" meant the denormalised read shape the client holds — a get returned a rich document, and the client patched it in place through a compiled map from tables to paths.
It named the crux and didn't solve it: the view maintenance problem. When a write lands, which client documents did it touch? The resolver for that question was never finished. That loose end drives everything after it.
January – February 2026 · Claude Opus 4.6
Commands and events over a single WebSocket. The runtime had no document at all — but the modelling database did, as its hub. Its schema header was the manifesto: documents are central — they're what clients get and update.
The method arrived with it: start from "what does the user see?", sketch the document, and derive the entities from it. Design the screen, and let the tables follow.
February – April 2026 · Claude Opus 4.6
A pair of tools: easy to model with, simple to build with. Easy held the domain in a small database behind a CLI and a browsable site, and its entry point was the story — a use case, an actor and an action, linked to the entities and documents that serve it. Design started from what people do.
In simple, documents are screens — one per screen, declared as a root entity plus an expansion tree, compiled into a single database function. And dzql's unfinished question got a declarative answer: which documents a write targets is derived from the expansion trees, carried with the change, merged by the client. The rule of the house: never re-fetch. Refreshing a document defeats the whole architecture.
March – June 2026 · Claude Opus 4.6, then 4.7
Railroad is a small UI library — signals, JSX compiled to real DOM, no virtual DOM and no build step. It grew a module where a document is a named, patch-synced tree whose identity on the client is a signal: open it by name, get a signal, send changes as three verbs — add, replace, remove — on paths.
Then the deliberate split: railroad gave the module up. It had been the proving ground; delta was the finished thing. Delta made the document the unit of everything — the subscription, the version, the write path, the permission boundary — and composed it in the database from relational tables. Document names became data. And it refused optimistic writes: the echo renders the write, so what you see is what actually happened.
May – June 2026 · Claude Opus 4.7, then 4.8
The modelling line rebuilt, and sharpened into a thesis: a document is not a view of an entity; it is what an actor sees in order to do a job. Design lives at document altitude — actor and task — and resists the constant pull down to tables and CRUD mirrors.
Where the earlier tool drew diagrams to browse, hjeli runs predicates after every change: is everything reachable; does every write an actor can make echo back into something they watch; does every story have the permissions it needs. Completeness became the product. One proven model now lowers onto several different runtimes — and what a target can't express is routed to a named stub rather than half-built.
July – August 2026 · Claude Fable 5, with Opus 5
Not a library: a few thousand lines that live in your app. It merged the two halves — the delta is the signal — and deleted the seam that delta and railroad had both kept.
The registry moved into the database itself: one table of documents, one log of changes serving as event log, audit trail and undo log at once. One read path, where the composition function is the permit: if you can't compose it, you can't see it. And dzql's original question finally dissolved rather than being answered — the commit that records a change also bumps, logs and notifies in one place, so nothing needs to work out afterwards which documents were affected.
Anything you render is a document — live, permitted, versioned, because there is no other door.
September 2026 · Claude Fable 5.1
Two specifications, written as documents rather than code, and tested by building from the text alone: hand the words to a fresh session, see whether the app comes out, and treat every ambiguity as a finding. Twenty-odd such builds, each one cutting a new edition.
Pears says how a change travels — a graph of nodes that watch each other, with a stated order, and a notification framed by the deepest thing that contains the change. Apples says how a document is drawn and touched: a collection projected onto space, time or colour gives a reading — lanes, calendar, timeline, map, tally — and each reading implies the one gesture it offers. Every row gets the same panel, derived from the declaration, so no reading has to draw a form.
August – September 2026 · Claude Fable 5.1
Epsilon, plus the screen. A screen is itself a document, composed on the server from the app's document by a pure function, sent once whole and thereafter as the same three verbs. The client opens the screen and nothing else.
A gesture is one verb on one path: a node you can touch carries the write it would make, the executor sends exactly that, and the echo recomposes the screen. Nothing that reaches the browser names a function.
14–17 September 2026 · Claude Fable 5.1 and Sonnet 5 · where the work is now
A kernel for live, multi-person apps, made of three things that compose.
Documents. The whole app is documents, each with one read and one patch. A write is a patch: a document, a path, a value.
Render. The server is the only renderer. It turns a document into HTML for one person, and the browser keeps that HTML alive by morphing it, so a re-render never disturbs what someone is in the middle of doing — and a render can be as small as the change.
Applets. Where a page needs behaviour of its own — a figure being dressed, a price board moving — an applet takes its data as props and answers with writes.
What that buys:
It is for small teams and solo builders making live apps where reversibility and legibility matter more than scale. It is not a consumer product at CDN scale, and does not try to be.
How eta was made — four days, sixty-four releases, one dependency, and a review that graded it D.
dzql asked the question. seiro made documents the design centre. easy and simple designed them from use cases and made them screens. hjeli made the method provable. railroad and delta made documents live runtime objects. epsilon answered the original question in the schema itself. apples and pears wrote down how a change travels and how a document is drawn. zeta made the screen a document too. eta made the whole thing small.
Underneath all of it is one artifact, attempted over and over: a shared state with two faithful readers. For the machine it has to be precise enough that regenerating the app is not a gamble. For the person it has to be legible enough to scroll through with a customer and ask — is this true?
None of the tools is the product. The state is.