Part 5 · 5.4 Technical Implementation
The technology: dispatch, the catalogue, and the rails behind it
How exactly is this implemented at the program level, and where the standing checks that govern the whole surface are written down.
Source: lib/entry/handle-request.ts, lib/session/create-document-session-host.ts, lib/application/catalogue.ts.
§One handler, two skins
Every request — whatever actually sent it — resolves to exactly one function, handleRequest in lib/entry, described in its own header as "the engine's own transport... a self-contained HTTP surface... any other consumer speaks the same roots." The web application's own routes (app/api/ingest/[type], app/api/projection/[contract], app/api/service/[...path]) are a thin second skin over it, with — by its own comment — "no logic of its own": they only translate a Next.js request into the same shape handleRequest already expects. This is why 6.4 could trace a gesture through two consecutive K4 layers without anything actually branching between them — one is the general-purpose transport, the other is that transport's Next-specific coat.
§The dispatch table, complete
handleRequest's whole job is reading the path's first segment and routing from there:
| route | method | what it does | |
|---|---|---|---|
service/sessions | GET | lists every stored session with its watermark | |
service/sessions/{id} | GET | one session's own meta — watermark, machine class, core and catalogue versions | |
service/catalogue | GET | the whole function catalogue, below | |
service/lineage?session= | GET | a session's ancestors and children ([[02-lines-of-reasoning/2-4-technology | 2.4]]) |
service/programmes | GET | the shelf, split into blueprint sets and records programmes | |
service/seats | GET | every seat a slot could open a Cell from | |
service/probe | POST | the draft-plane liberty — previews, commits nothing | |
service/… (anything else) | any | refused: "unknown service '…' " | |
ingest/{type}?session= | POST only | runs the named typed ingest; 405 on any other method | |
projection/{contract}?session=&… | GET only | serves the named projection; 405 on any other method | |
| any other root | any | refused: "the wave API has three: service · ingest · projection" | |
| (any refusal, anywhere) | — | status 422, the machine's own error text verbatim in the body |
Every refusal, notably, carries the machine's own words back to the caller — never a generic failure — which is the wire-level instance of a discipline that runs through this whole book: an honest failure states what actually went wrong, in the system's own vocabulary, rather than hiding behind a blank error code.
§The one request cycle, stated exactly
Every ingest, without exception, follows the same fixed sequence, set at what the codebase's own comments call "the human gate" and stated as four principles: no whole-log replay in normal practice; every ingest arrives with states read from persistent storage that completely reflect what the machine lived; full quiescence yields the fragment and the output states of every component; state is touched only through the state protocol — writes atomic with place, tuple, function and value together, reads never cached. In practice: load the session's stored state at its exact watermark; restore a machine from it; settle it fully (1.4's loop, run once); commit the new tuples, the journal, a fresh snapshot, and every affected reading's updated image, together, in one atomic movement guarded by that same watermark; then discard the machine entirely. Nothing is held in memory between one request and the next — the only thing that persists across requests at all is a simple queue per session, ensuring two requests for the same session never run at once.
§The catalogue — every named function, versioned
Beyond the ingest and projection registers, one further registry underlies almost everything else in this book: the catalogue of every reusable, named function a record is allowed to invoke by name — a knot's strategy, a bind's local action, a discharge station, a controller. Fifteen entries, current as of this writing:
| name@version | kind of station | what it does | |
|---|---|---|---|
deterministic@1 | knot | collect; test the closed null-guard condition — [[03-the-minimal-fragment/03-the-minimal-fragment | Part 3]]'s whole vocabulary |
semantic_evaluator@1 | knot | accumulate deltas; integrate through the world or locally; grade against declared questions — the strategy behind [[02-lines-of-reasoning/2-3-specification | the cascade's L7]] |
publish@1 | bind | emit the activation understanding verbatim, unmodified | |
format@1 | bind | fold the understanding into a deterministic text fragment by template | |
release@1 | bind | release the understanding (or the whole scope) as a result envelope — every vector's own ledger release | |
assemble@1 | bind | fold the composer's filled slots into a target blueprint ([[03-the-minimal-fragment/3-4-technology | 3.4]]) |
ceremony@1 | discharge | the deterministic local ceremony: charter, package, assessment — no world involved | |
study-double@1 | discharge | deterministic: assembles a Cell seed with no world call | |
gemini@1 | controller | semantic winding through the world | |
gemini@2 | controller | winding, plus schema-bound service answers — the version behind every real answer in [[04-the-standard-scenario/04-the-standard-scenario | Part 4]] |
programme-loader@1 | controller | sows a chosen or proposed programme, probed first, stamped with its own provenance | |
programme-choice-double@1 | discharge | deterministic stand-in: answers with the first allowed programme | |
schema-double@1 | discharge | deterministic stand-in: answers any schema-bound request with a self-naming placeholder of the right shape | |
inference-stub@1 | controller | the plain CI winding double | |
represent@1 | controller | the reuse move itself ([[02-lines-of-reasoning/2-4-technology | 2.4]]) |
Every entry is immutable once registered: a genuinely changed behaviour becomes a new version under the same underlying lineage — gemini@1 and gemini@2 share one lineage identity, two frozen versions — and a record may either pin an exact version or take a bare name, which always resolves to the highest version currently on the shelf. Nothing here is ever edited in place; a change is always a new, additional entry, findable beside the one it supersedes.
§The rails — a consolidated reference
Several of this book's key mechanisms are each anchored to one numbered principle in the project's own standing checklist — the "thinking rails" checked on every later decision. Three were unpacked at length where they belong (Part 2 for 4, 5 and 6; Part 6.3 for 11); the rest, named here once so the full set is in one place:
| rail | in one line | where this book uses it | ||
|---|---|---|---|---|
| 1 | pins and similar sanctioned side-channels are declared families, never a side effect of navigation | [[04-the-standard-scenario/04-the-standard-scenario | Part 4]]'s sheet | |
| 2 | (no citation found in this project's own sources) | — | ||
| 3 | a button, or an act, is a fact factory: it shapes a fact so declared rules can route it | [[5-1-idea | 5.1]], [[03-the-minimal-fragment/03-the-minimal-fragment | Part 3]] |
| 4 | represent — the one reuse move through the world | [[02-lines-of-reasoning/02-lines-of-reasoning | Part 2]] | |
| 5 | a return socket is declared at birth, never wired after the fact | [[02-lines-of-reasoning/02-lines-of-reasoning | Part 2]] | |
| 6 | authoring (opening a Cell) is categorically heavier than ordinary ingress, and must look it | [[02-lines-of-reasoning/02-lines-of-reasoning | Part 2]], [[04-the-standard-scenario/04-the-standard-scenario | Part 4]] |
| 7 | four distinct transitions — ready, completed, accepted, finished — must never visually collapse into one "done" | [[07-the-cell/7-3-specification | 7.3]]'s lifecycle | |
| 8 | the released rail holds bind publications only, never a listener's raw wound state | [[04-the-standard-scenario/04-the-standard-scenario | Part 4]] | |
| 9 | (cited nowhere in this project's own sources by that literal name, though the standing checklist itself carries a ninth rule) | — | ||
| 10 | (likewise, uncited here by name) | — | ||
| 11 | the formation boundary: information is formed once, core-side; every surface only presents it | [[06-the-code-map/06-the-code-map | Part 6]] |
Rails 2, 9 and 10 are stated plainly as gaps rather than guessed at — the discipline this whole book tries to follow applies to its own reference tables too.
§A shape worth noticing, once more
The three roads of 5.1 are, without the project ever naming them this way, one more instance of the same three-phase shape this book keeps meeting at every scale: ingest is collection — what may enter, declared in advance; the machine's own settle is accumulation — where the collected material is actually worked; projection is publication — the formed result, released under a declared, checkable shape. A single knot does this. A Cell does this. The whole wire protocol, standing back far enough, does it too.