The technology: the functions that check, register, and assemble

How exactly is this implemented at the program level, and how does a fragment prove itself before it is trusted.

Source: lib/application/figure-records.ts, validate-figure.ts, programme-shelf.ts, act-deepen.ts; lib/core/registers/{register-knot-definition,register-descriptor-definition}.ts; lib/side/figures/composer-fixture.ts.

§From records to registration tuples

figureEmissions is the smallest function in this whole chain, and it is worth seeing because everything else in this part ultimately calls it: given a plain list of {kind, payload} records — whether typed by hand into YAML, assembled live by the composer, or built programmatically by deepen — it does exactly one thing per record: refuse anything that is not one of the two registration kinds, refuse a payload with no string id, and otherwise stamp key: null (registration always rides the lane-less, ambient channel — no programme's own lane hears it by accident) and hand it back as a ready emission. Every single fragment in this book, however it was authored, passed through this one function on its way into the log.

§The probe, precisely

validateFigure is PROGRAMME_MANUAL.md's "the machine judges its own food," as code. It converts the records via figureEmissions; refuses an empty list outright; then opens a disposable, in-memory session — built purely for this one check, discarded immediately after — and ingests the records into it exactly as a real session would. If the real registration machinery throws (an unknown strategy, a condition it cannot parse, a duplicate id) the function catches it and returns {valid: false, error}, in the machine's own words. Only a clean pass returns {valid: true, recordIds}. Nothing about this check is a separate, lighter-weight linter approximating the real rules — it is the real rules, run once on a throwaway copy before the real thing sees the records at all.

§Landing in the register file

Once records pass the probe, two functions actually place them: registerKnotDefinition stores a listener's definition and, in the same movement, creates its fresh bank of per-key lanes (with one "probe" lane at a null key, present before any real fact arrives, purely so a replay of the journal can reconstruct the listener's birth before its first real use). registerDescriptorDefinition stores a doer's definition and indexes it under every knot it cares about, so that when a readiness tuple later names that knot, the topology processor knows exactly which doers to wake. Re-registering an id under either function replaces the old definition and clears any accumulated lane state — described plainly in the source as "the machine's only edit," and used nowhere in ordinary operation; a revision is a fresh figure, never a patch to an old one.

§The composer's own local action

assemble@1 — the pure, local function behind the composer's harvest bind (3.3) — is worth naming precisely because it is not a call to the outside world: it takes the four slots' accumulated content (the bind identity, the perception settings, the array of questions gathered one commit at a time, and the harvest trigger) and folds them, deterministically, into a well-formed blueprint — the very same shape figureEmissions and validateFigure will later check. Composing a new figure by hand, through the UI, and composing one by writing YAML converge on literally the same downstream check; the composer only changes how the blueprint gets written, never what is required of it once written.

§The one generic ceremony, reused everywhere

admissionCeremonyRecords(prefix, accepts, budget, publish?) is the function version of composer.yaml's eight hand-written records: a charter gate and author, a canonical-charter listener, a blueprint listener, a planner that seeds the Cell once both are present, and an independent evaluator. Every seat opened by deepen across this whole book — the four press-release readers of Part 4, every level of Part 2's cascade if opened as a Cell, the composer's own admission — expands from this one function, parameterised only by a namespacing prefix, what the new Cell may hear, and its budget. There is exactly one admission ceremony in the entire codebase; everything that looks like a different one is this same template with different arguments.

§Two sizes, one shape, side by side

The toy example from 3.1 and a real fragment from a worked study, shown together, so the correspondence is not just asserted but visible:

// the toy — a test fixture, two records
{ id: "note.gate", strategy: "deterministic",
  wind: { collect: [{ as: "note", match_type: "note.given", reduce: "latest", field: "text" }] },
  condition: "note != null" }
{ id: "note.publish", subscribesTo: "note.gate", actionConfig: { writes: "note.published" } }

// the real thing — one vector of a press-release study, two records
{ id: "press.facts.wanted", strategy: "deterministic",
  wind: { collect: [
    { as: "question",  match_type: "press.vector.given",  reduce: "latest", field: "text", where: [{ field: "vector", equals: "facts" }] },
    { as: "findings",  match_type: "press.findings.given", reduce: "latest", field: "text", where: [{ field: "vector", equals: "facts" }] }
  ] },
  condition: "question != null && findings != null" }
{ id: "press.facts.found",
  operator: { on: "press.facts.wanted", service: { instruction: "Release the vector's question and findings as a ledger entry.",
    emit: { writes: "press.facts.found" }, action: "release@1" } } }

The only real difference is that the second listener waits for two things instead of one, and its doer is an operator bind with a named local action rather than a bare emit descriptor — a slightly richer instance of exactly the same two-record shape, not a different construct. The full journal behind this exact fragment, tuple by tuple, is walked in full, tuple by tuple, in the companion technical reference.