Part 4 · 4.4 Technical Implementation
The technology: the acts behind all nine moves, and why they generalise
How exactly is this implemented at the program level, and how the same code serves every study on the shelf.
Source: lib/application/{act-intent,act-deepen,act-apply-data,act-review-cell}.ts, lib/application/ingest-register.ts.
§Every move, its act, its wire shape
| move | act | wire shape |
|---|---|---|
| 1–2. the door | actIntent | POST /api/ingest/intent {text} |
| 3. the question | actApplyData | POST /api/ingest/facts {facts: [{factType: "<vector>.given", data}]} |
| 4. delegate | actDeepen | POST /api/ingest/deepen {slot, seat, words} |
| 5. ask | actApplyData | POST /api/ingest/facts {facts: [{factType: "ask.given", data: {level}}]} |
| 6. attest/archive | actReviewCell | POST /api/ingest/cell.review {cellRef, decision} |
| 7. return/release | (no separate call — a direct consequence of move 6's own settle) | — |
| 8. synthesise | (no separate call — the report bind's own barrier firing) | — |
| 9. arrange the document | actApplyData | POST /api/ingest/facts {facts: [{factType: "sheet.pinned"/"sheet.unpinned", data: {ref}, key: null}]} |
Four acts, reused across nine moves — because, as 4.3 set out, moves 7 and 8 are never separately requested at all; they are the automatic downstream consequence of move 6's single settle, exactly as 1.4's loop runs to full quiescence before ever handing control back.
§Why the same code serves every study on the shelf
Nothing about actDeepen, actApplyData or actReviewCell names the press-release study, or any other study, anywhere in their own source. actDeepen is parameterised entirely by which seat is named in the request — the same function builds a press-reader's inner figure or a cascade level's inner figure from the identical code path, differing only in which blueprint-building helper the seat's own declared shape selects (3.3's "way three"). actApplyData does not know what a "vector" is at all; it only ever shapes whatever {factType, data} it is handed, refusing anything under a reserved name. actReviewCell does not know which Cell it is reviewing came from which study; the lifecycle it enforces (7.3) is identical for every Cell that has ever existed.
This is, concretely, why 4.2's claim — "any programme on the shelf follows the same nine moves" — is not an assertion taken on faith: the code that runs moves 1, 2, 4, 6, 7, 8 and 9 is genuinely, provably, the same code for every study, because it is written with no knowledge of any particular one. Only moves 3 and 5 — which questions a study asks, and what brief its readers carry — vary at all, and they vary entirely inside a programme's own YAML, never inside the application code that runs it. Swapping in physics for press releases, or fact-checking for either, changes a shelf file; it changes nothing described in this file.