Part 6 · 6.4 Technical Implementation
One gesture, traced through every ring
How exactly is this implemented at the program level.
Take Attest · accept on a Cell that is ready_for_review — the same gesture Part 7.4 examined for what it does to a Cell. This file follows it the other way: not what it does, but which file, in which ring, does each part of it — down through every ring in 6.3's table, and back up.
§Down: the request
| ring | file | what happens here | |
|---|---|---|---|
| K5 · surface | huid/modules/cell-card.tsx | the click handler review("accept") sends POST /api/ingest/cell.review {cellRef, decision: "accept"} | |
| K4 · formation (Next skin) | app/api/ingest/[type]/route.ts → huid/formation/ingest-register.ts | the Next route hands the typed body to handleIngest, which does no logic of its own — it only translates into the engine's own HTTP shape | |
| K4 · entry (the engine's own transport) | lib/entry/handle-request.ts | resolves the path /ingest/cell.review against the ingest type register and calls that entry's run(app, session, body, options) | |
| K3 · application | lib/application/act-review-cell.ts (actReviewCell) | shapes exactly one cell.reviewed {cellRef, decision, actor} record; actor comes from the calling ring's own context, never the request body | |
| K3 · application | lib/application/ingest-act.ts (ingestAct) | the one write crossing every act shares — hands the record to the session harness, and once it settles, folds the wave's own fragment into every registered reading | |
| K2 · harness | lib/session/create-document-session-host.ts | loads the session's stored state at its watermark, restores a machine from it, asks that machine to settle the new record | |
| K1 · doors | lib/machine/settle-machine.ts | the only outside access into K0 — hands the record and the restored register file to the runtime | |
| K0 · register file & stations | lib/core/runtime/create-wave-runtime.ts → create-wave-engine.ts → create-cell-space.ts → handleReview | the actual work: the settle loop runs the engine, the engine's one top-level processor (CellSpace, wrapping the root topology) routes the fact to handleReview ([[07-the-cell/7-4-technology | 7.4]]), which closes the Cell and emits its accepted export; the engine keeps running until every consequence of that — the return figure's readiness, the represent controller's answer, the vector's own readiness, its ledger release — has also settled, because a wave never returns early |
By the time K0 hands control back, everything downstream of the attestation has already happened inside the same settle — the Cell sealed, the export emitted, the finding returned into its slot, the ledger entry released. Nothing above K0 had to ask for any of that separately; it was one wave, propagated to full quiescence, exactly as Axis I requires.
§Up: the commit, and what the surface learns
K2 commits, in one atomic movement guarded by the session's watermark, four things together: the new tuples, the wave's journal, a fresh station snapshot, and — because ingestAct folded them on the way — the updated images of every reading that watched this fragment (cell-lifecycle@1, publications@1, work-queue@1, sheet@1 among them). This last point matters: a reading is not recomputed lazily when the surface later asks for it; it is already advanced and stored at commit time, so the very next read of it is instant.
K3 hands actReviewCell's receipt ({committed, upToOffset, refs: {cellRef}}) back up through K4's two skins unchanged, and it lands at K5 as the response to the original fetch. cell-card.tsx calls onCommitted() — which the workbench page wires to bump a shared refresh key — and every module on the page that depends on that key (the Cell card itself, the released rail, the figure index) fires its own read of the relevant projection immediately, rather than waiting for the standing three-second poll that runs regardless. Both paths end at the same place: GET /api/projection/cell-lifecycle@1 (or publications@1, or sheet@1) travels back down through K4 to K3's readProjection, which — because the image was already advanced at commit — serves it straight from the stored image, and the response climbs back up to K5 as the Cell card's new state: sealed, the accepted export listed under Released, the vector's ledger entry now sitting on the rail.
§The point of walking it this way
Every one of those ten hops is a single, named, one-directional door — never a shortcut, never a ring reaching two rings deep. That is 6.1's picture made concrete: the gesture that looked like one click on screen is, underneath, a request that only ever moves one ring at a time, all the way to where the log actually is, and a response that only ever moves back the same way.