Chapter 5. What State Must Be
We need State to stop being abstract. But its structure is not mine to choose — the method forbids taste. It will be forced by three requirements, each drawn from the web itself.
The three requirements
R1 — Universality. The web hosts every application domain there is or will be. Therefore State must encode arbitrary application state, with no domain structure baked in. (Source: the observable web. Try to name the domain the web is “for.”)
R2 — Coordination-free composition. The web has no central schema authority — by design; decentralization is what “world wide” means. Therefore state held by independent parties who have never communicated must be composable. Composition without coordination has laws: it must accept any two states (checking compatibility is coordinating), in any order (agreeing an order is coordinating), with duplicates costing nothing (tracking copies is coordinating). And it preserves meaning only if the things composed are self-contained — a fact must carry its full meaning with it, because no surrounding structure survives a merge. Those four laws leave exactly one composition, and Appendix B proves it — set union:
State = 𝒫(Fact) merge = ∪ (5.1)State is a set of atomic facts, and two states, from any two parties, anywhere, compose by union. Order-free, idempotent, associative, commutative — every property that federation needs, in one move.
R3 — Global reference. A fact on one site can be about an entity described on another; the web’s entire value proposition is that things link. Therefore names inside facts need global scope. The web possesses exactly one global naming system — I, the URIs from Chapter 1 — and inventing a second one would itself violate R2 (two parties’ private naming schemes collide on merge). So references in facts are drawn from I. And note what R3 does and does not ask: names must be global; nothing requires that they dereference. They can, though, and that comes free with the construction: the naming system and the web’s address system are one. Chapter 18 confronts what that identification costs.
The one bridge
The scope of R2’s result, before anything is built on it. The merge laws govern composition’s mechanics: that any two states merge, without permission, in any order, at no cost. They do not promise that merged facts join — that two parties’ names for one turbine ever meet in a query. No data model can promise that: parties who never communicated have agreed on nothing, in every model ever proposed, and a requirement pretending otherwise would be a coordinator in disguise. A model does control two things: what an unjoined union already holds, and what a join requires once someone demands one. Chapter 17 takes that up, where federation stops being algebra and becomes deployment. Here it is enough to be exact about what R2 secures: merge, not meaning across sources. And it secures that completely.
Flagged in the open: the passage from “no coordinator” to the merge laws is the one bridge in the derivation. I name it the Transposition Thesis: the invariants the web already enforces at its document layer, transposed to the state layer, are exactly the merge laws just used. I claim the transposition is exact, row by row, and the table below is the claim in checkable form. And it is corroborated by a field with no stake in this book’s thesis. Distributed-systems research, forced to make replicas converge without coordination, derived the same laws as theorems — the CRDT (conflict-free replicated data type) literature. Two fields, disjoint motives, one algebra — the merge laws are not a matter of taste.
The transposition, row by row — four deployed invariants, four laws.
| the document layer, deployed | the state layer, transposed |
|---|---|
| anyone links to anything; no one is asked | composition is total — no compatibility check (B-2a) |
| content arrives by any path; intermediaries reorder it freely | composition is order-free (B-2b) |
| copies are free and unmarked; the cache hit is the resource | composition is idempotent (B-2c) |
| aggregators consume content outside its original arrangement, without its publisher’s consent | no meaning survives in arrangement (B-2d) |
Each left cell is deployed and citable — RFC 9111 carries the middle two, AWWW’s global-identifiers principle the first, and the last is every search engine and feed reader in operation. Each right cell is a numbered condition in Appendix B; B.4 proves none is redundant. Appendix C carries the CRDT citation. State-based replication requires a join-semilattice: totality, order-freedom, idempotence, derived in that literature from replication pressure alone. The theorem downstream is about the web exactly as far as this table holds.
The smallest fact
The question now is the smallest self-contained fact, and “smallest” is not an aesthetic preference. Every extra position a fact carries is one more thing independent parties must agree on — and agreement is what R2 forbids. So minimality is R2 again, applied to the shape of the fact itself. When a genuine requirement justifies an extra position, the derivation will grant it; Chapter 9 does exactly that.
Prop. 5.2 (Arity). The minimal self-contained fact is a triple.
Argument — a pair cannot name its own relation: (employee42, “2026-07-08”) is hired-on, or fired-on, or born-on.
A 1-tuple (x) asserts nothing — it names without claiming. A pair (entity, value) asserts a relation but cannot say which relation; the meaning lives outside the fact, which R2 forbids. Three positions — (entity, attribute, value) — is the first arity at which a fact names its own relation. And it is the last arity we need: any n-ary fact decomposes into triples by minting a fresh entity for the fact and attaching its n components as attributes. Minimality and universality pin the arity at exactly three. ∎
R3 forces the entity position into I. It forces the attribute position into I too, because attributes need global names just as much. Without global names, two sources cannot know they mean the same property, and R2 dies at the first merge. The value position is either a reference or an atomic literal — write V for the literals:
Fact = I × I × (I ∪ V) (5.3)
State = 𝒫(I × I × (I ∪ V))Chapter 3’s exhibit already wrote facts in this shape without saying so. The dashboard’s strip-2 block held one entity and two attributes: two facts, exactly. Written with ⟨·⟩ for a URI abbreviated to its fragment, they are (⟨…#panel-14⟩, title, "Current Power") and (⟨…#panel-14⟩, value, "15.5 kW"). Entity in I, attribute in I, value in V. The exhibit was the theorem, photographed early.
Interactive exhibit (online edition): two parties who have never met. Edit either side, shuffle, duplicate — every edit vanishes into the union except a genuinely new fact, and (5.1) is something you fail to break rather than something you believe.
The uniqueness theorem
Theorem 5.4 (Uniqueness). Any arity-minimal state model satisfying R1–R3 is isomorphic to (5.3). (Proof: Appendix B. The proof is an assembly of 5.1–5.3: R2 forces the set-of-atomic-facts shape and union-merge; R1 with minimality forces arity three; R3 forces positions one and two into I.)
The claim that (5.3) is the only shape the web itself permits sounds like rhetoric. Theorem 5.4 makes it a statement with escape clauses, and the clauses are the trap. Fault a step of the proof — Appendix B lays the steps out for that attack — or reject a requirement; each rejection has a name. Reject R1 and your model can’t host the web’s content. Reject R2 and your data needs a coordinator — a central schema authority, which is to say: you have built a silo. Reject R3 and your data cannot refer beyond itself — a silo again, by the other door. Reject minimality and you widen the tuple — a door left deliberately ajar; Chapter 9 walks through it with a fourth requirement, attribution. Every alternative data model the industry runs on will be located, in Part IV, at one of the first three exits.
The selection algebra
We are not done deriving — the same pattern now runs once more, one level up, quickly. select needs a minimal algebra over 𝒫(Fact): match a fact pattern with variables; join matches; union alternatives; project variables out. Each operation is forced by a page you can point at (any master–detail page is a join; any search page is a pattern; any page merging two lists — events from either calendar — is a union). The algebra reappears in Part III under its deployed name; what a write can do to a fact-set is Chapter 7’s subject.
A join, by hand. The dashboard’s operator holds panel-14 title "Current Power"; the turbine contractor — another party entirely — holds turbine-3 feeds panel-14. Merged, the pattern — triples written bare now, URIs still abbreviated, ? marking a variable —
?turbine feeds ?panel
?panel title ?namereturns one row — ?turbine = turbine-3, ?panel = panel-14, ?name = "Current Power" — and the row exists only because the two parties’ facts were merged first. Match, join, project: the algebra on one page.
Interactive exhibit (online edition): the algebra, exercised — patterns with variables, joined and projected over the state merged above. One preset only answers because the merge happened: it joins the operator’s facts to the contractor’s.
And notice what the theorem has done to the pipeline’s types. State is now a graph: entities are nodes, and each fact is an edge from entity to value. The join just walked that graph — the pattern crossed from the contractor’s facts to the operator’s along a reference, and references point anywhere. But every document Chapter 3 stripped was a tree. Somewhere between them, the shape must change. That is Chapter 6.