Price-time priority, without a comparator.

The book is a price ladder per side: an ordered tree keyed by price (gb_trees), the bids descending and the asks ascending, so the best price is a tree edge. Within one price level, orders queue in a FIFO — and the FIFO key is the branded Snowflake stamped at admission. Mint order is arrival order, by construction, so "first at this price" is "smallest id at this price," and the same order holds in SQLite, Valkey, and Postgres COLLATE "C" alike by Appendix F's order theorem.

# Exchange.OrderBook (PROPOSED): a price ladder per side
# asks :: gb_trees keyed by price; each level a FIFO of branded ids
# best ask = the leftmost price (a tree edge), no scan
# within a level: oldest = smallest mint id = first filled

The consequence is a design with one ordering, not two: the sequence, the sort, the cursor, and the within-level priority are the same fourteen bytes, paid for once at mint. A separate sequence counter beside each level would be a second source of truth to keep in step with the first; the id removes it. This is the same move the ingress made in dive 1 — the chase sequence is the id — applied to the resting book.

Open-order indexes per account ride EchoData.BrandedTree — namespaced gb_trees with first/2, last/2, and page_after/4, "the oldest-first and pagination shapes a book needs already its verbs." A book asks for the oldest open order, or the next page after a cursor, and the branded tree answers in creation order without a sort step — the same page_after/4 the ingress consumer uses to resume from an id cursor in dive 1. Snapshots for projections freeze through the CHAMP / FrozenIndex family rather than copying mutable maps.

So the book and the ingress share one ordering verb. The id is the cursor on the ring, the FIFO key in the ladder, and the pagination key in the open-order index — three uses of the fourteen bytes the mint already stamped, with no comparator and no second counter anywhere in the engine.

The master invariant binds the two halves of the engine: one instrument's book is mutated by exactly one process — the sole drainer of its Ring — and the Ring's accepted count reconciles exactly with the Book's applied count plus the counted drops. Crossing orders produce fills; the publishes that were accepted equal the applies plus the drops, with nothing lost in between and nothing applied twice.

This is the TRD.2 gate, and it is PROPOSED — "the single-writer property under concurrent publishes" the design will gate at the rung that ships the Book. The reconcile is the shape the harness will check, not a number already on the record. The acknowledge-after-append rule is the spec's law: a command accepted then crashed before its events are appended is lost and the caller knows nothing, so the gate reconciles publishes against applies-plus-drops precisely to make that boundary visible.

The reconcile stands on a real, hardened seat. EchoCache.Ring — shipped Elixir at echo/apps/echo_cache/lib/echo_cache/ring.ex, the convergence target of the rung-gated EchoMQ program (/echomq, docs/echo_mq/emq.roadmap.md) that names the trading platform as its downstream consumer — already proves the admission half of the arithmetic: the accepted count and the counted drops are real today, its committed behavior on the B4.3 record:

G4 full ok -- the bound held its shape: 64 accepted, 136 refused with :dropped and counted -- never blocked, never overwritten -- then the release drained all 64 and publish 201 landed and applied: a storm bends the lane's at-most-once contract no further than the contract already bends
G1 surface ok -- the ring's surface is whole -- ... a fresh ring stands at occupancy 0
PASS 6/6

The accepted count, the counted drops, and the drained applies are the three terms the PROPOSED Book's reconcile will balance — the ring's record fixes the ingress side today (64 accepted, 136 refused); the Book's rung will fix the apply side. That is the two-layer discipline in one paragraph: the seat is real, shipped, and quoted; the trading engine on top — the Exchange.* writer that fills it — is PROPOSED and design-voiced; and no fill count, match latency, or throughput is claimed for an engine that has run no rung yet, while the substrate beneath it already has its numbers. The next module, B8.2 · The Log and the Ledger, carries the facts these fills emit into the journal — Chapter 4.4's posture as its subject.