One Frame, Walked

Take one branded id and walk it across the whole frame. It is named at the substrate, where the app mints a 14-byte identity (E1). It is gated at the seam, admitted only on its 3-letter namespace (E2). It is carried by the bus as a branded JOB, claimed on a lease against the server clock (E3). It is answered by the memory in twenty-nine bytes — the id:version message that invalidates one cached row (E4). It is booked by the record under an RVL ledger key, paired and signed in one transaction (E5). And it is resolved on the surface, every response stamped with its plane and its as_of (E6). Six tiers, one identity, and at every boundary the same two facts hold: the id crosses, and a message about the id crosses — never an object graph.

This walkthrough is the BCS law told as a story. The law states that encapsulation boundaries are drawn around systems, not objects, and that the only values crossing a boundary are identities and messages about identities. The walk makes it literal: the id is minted once, at the consistent core where the ledger books it, and carried unchanged to cache, log, and surface — recorded once, read in many places. Each tier makes its own CAP trade — the ledger blocks, the cache answers, the surface stamps — yet they compose into one system not because they coordinate but because they share one identity. The frame is not a stack of layers propping each other up; it is a set of peers joined by a single thread, and the walk is proof the thread never frays.

The walk is worth pausing on because it doubles as an audit. At every seam, take the accounting: what actually moves? The id moves — fourteen bytes, the same fourteen from mint to surface. A message about the id moves — as a JOB reference the worker redeems for its payload, as a 29-byte id:version invalidation the store pushes over client tracking, as an RVL key in the ledger, as a plane + as_of stamp on the response. And what never moves: the owner's :private table, the object graph, an embedded id list. Each system keeps its store to itself and hands out only names, so the wire is always narrow — identities and small messages, never a serialized world.

That narrowness is the whole reason the frame can hold tiers with opposite CAP trades and remain one system. If the ledger's rows, the cache's tables, and the surface's views had to be shipped between tiers, their guarantees would have to be reconciled — and reconciling a consistency-first store with an availability-first one is exactly the impossibility the chapter opened on. Because only the id crosses, no such reconciliation is ever attempted: each tier answers for its own segment, on its own trade, and the id is the sole thing they agree on — that this is the same entity. The walkthrough, then, is not a tour of features; it is the demonstration that the platform's segmentation is safe, because its boundaries carry names, not graphs.

The thread rule — one identity crosses every boundary; at each seam only the id and a message about it pass, never the object graph. Minted once at the consistent core and carried unchanged to cache, log, and surface, the branded id is the single value every tier agrees on — which is why tiers with opposite trades compose into one system instead of one contradiction.