#5 · blueprint seen

1. 16Record #5 enters the logLOG · append

   a wave is settlingengine: next: #2membrane: waiting at #2

   1. #0a listener
   2. #1a doer
   3. #2listener: the charterenginemembrane
   4. #3doer: the author
   5. #4listener: charter seen
   6. #5listener: blueprint seennew
   7. ·end of the log

   What	before		after
   records in the log	5	→	6
   #5	—	→	listener: blueprint seen · sys.knot.defined

   The door adds #5: a listener — blueprint seen, which will hear the Cell's blueprint.

   Where it happens appendEmissions()Vol. 02 §4.1 · Vol. 03 §1

   The only function that adds records to the log. Each new record gets the next free number, at the end.

   Specification

   Vol. 02 §4.1 · Vol. 03 §1

   Code

   appendEmissions() in core/registers/append-emissions.ts, line 14: the new record gets the next free number

   Journal

   LOG · append · offset: 5, kind: sys.knot.defined · by engine

   Picture

   records in the log: 5 → 6

   1. 1// The one LOG writer (Vol. 02 §4.1, Vol. 03 §1): emissions become tuples by
   2. 2// receiving the next dense absolute offset — `base + window.length` — and
   3. 3// nothing else ever grows the log. Each append is journalled under the
   4. 4// ambient context, so a batch born of a propagated tuple carries that
   5. 5// tuple's offset as its cause — the cube's provenance line (ADR-002).
   6. 6
   7. 7import type { WaveEmission, WaveTuple } from "../wave/gate";
   8. 8import type { RegisterFile } from "./register-file";
   9. 9import { recordTransition } from "./record-transition";
   10. 10
   11. 11export function appendEmissions(file: RegisterFile, emissions: readonly WaveEmission[]): void {
   12. 12 const engine = file.registers.engine;
   13. 13 for (const emission of emissions) {
   14. 14 const tuple: WaveTuple = { ...emission, offset: engine.base + engine.window.length };↑ the new record gets the next free number
   15. 15 engine.window.push(tuple);↑ it is added at the end of the log
   16. 16 recordTransition(file, "engine", "LOG", "append", {↑ the change is written into the journal
   17. 17 offset: tuple.offset,
   18. 18 kind: tuple.kind
   19. 19 });
   20. 20 }
   21. 21}

   AGPL-3.0-onlyThe Lab's demonstration environment, as this fragment ran it (build 043cc8b). The code may change, and may differ from the code of a working machine.

   Nest VM core, incubated in the CoAgnes garden · build 043cc8b (2026-09-21) · this file last changed in f36e70d (2026-08-18)

when the engine took #5

1. 31The engine takes #5ENGINE.CURSOR · propagate

   a wave is settlingengine: working on #5membrane: waiting at #2

   1. #0a listener
   2. #1a doer
   3. #2listener: the chartermembrane
   4. #3doer: the author
   5. #4listener: charter seen
   6. #5listener: blueprint seenengine · working
   7. #6doer: the planner
   8. #7listener: assess · charter
   9. #8listener: assess · result
   10. #9doer: the evaluator
   11. #10the charter wanted
   12. #11the blueprint
   13. ·end of the log

   What	before		after
   pointer — the next record to take	#5	→	#6

   The engine's pointer moves past #5, and the machine reacts to it.

   Where it happens takeNextTuple()Vol. 02 §4.1

   The engine's step: take the record under its pointer and move the pointer on — or stop, if the pointer has reached the end.

   Specification

   Vol. 02 §4.1

   Code

   takeNextTuple() in core/registers/take-next-tuple.ts, line 15: at the end of the log, the engine stops

   Journal

   #5 · ENGINE.CURSOR · propagate · offset: 5 · by engine

   Picture

   pointer — the next record to take: #5 → #6

   1. 1// ENGINE.CURSOR advance (Vol. 02 §4.1) — the machine's instruction pointer:
   2. 2// returns the tuple at the cursor and moves it forward exactly once, or null
   3. 3// at quiescence. Advancing IS the context switch: the ambient wave context
   4. 4// moves to the propagated tuple in the same movement, so every transition
   5. 5// journalled during its propagation is attributed to it — the cube's spine.
   6. 6// The cursor never rewinds.
   7. 7
   8. 8import type { WaveTuple } from "../wave/gate";
   9. 9import type { RegisterFile } from "./register-file";
   10. 10import { recordTransition } from "./record-transition";
   11. 11import { setDriver, setWaveContext } from "./set-wave-context";
   12. 12
   13. 13export function takeNextTuple(file: RegisterFile): WaveTuple | null {
   14. 14 const engine = file.registers.engine;
   15. 15 if (engine.cursor >= engine.base + engine.window.length) return null;↑ at the end of the log, the engine stops
   16. 16 const tuple = engine.window[engine.cursor - engine.base];
   17. 17 engine.cursor += 1;↑ the engine's pointer moves on by one
   18. 18 setWaveContext(file, { offset: tuple.offset, phase: "propagate" });
   19. 19 setDriver(file, "engine");
   20. 20 recordTransition(file, "engine", "ENGINE.CURSOR", "propagate", { offset: tuple.offset });↑ the change is written into the journal
   21. 21 return tuple;
   22. 22}

   AGPL-3.0-onlyThe Lab's demonstration environment, as this fragment ran it (build 043cc8b). The code may change, and may differ from the code of a working machine.

   Nest VM core, incubated in the CoAgnes garden · build 043cc8b (2026-09-21) · this file last changed in 6730f58 (2026-09-13)

2. 32Blueprint seen is added to the figureKNOT.DEFS · register-knot

   a wave is settlingengine: working on #5membrane: waiting at #2

   1. #0a listener
   2. #1a doer
   3. #2listener: the chartermembrane
   4. #3doer: the author
   5. #4listener: charter seen
   6. #5listener: blueprint seenengine · working
   7. #6doer: the planner
   8. #7listener: assess · charter
   9. #8listener: assess · result
   10. #9doer: the evaluator
   11. #10the charter wanted
   12. #11the blueprint
   13. ·end of the log

   What	before		after
   listener admit.note.gate--l1.seeking.blueprint.seen	—	→	hears admit.note.gate--l1.seeking.blueprint.presented → slot blueprint; ready when blueprint != null

   The machine writes the listener …blueprint.seen into its list: it will hear the blueprint presented and keep it in a slot named blueprint.

   Where it happens registerKnotDefinition()Vol. 02 §4.2 · Vol. 04 §2.1

   Stores a listener's description under its name and gives it a bank of lanes with one trial lane.

   Specification

   Vol. 02 §4.2 · Vol. 04 §2.1

   Code

   registerKnotDefinition() in core/registers/register-knot-definition.ts, line 21: the description is stored under its name

   Journal

   #5 · KNOT.DEFS · register-knot · id: admit.note.gate--l1.seeking.blueprint.seen, strategy: deterministic, replaced: false · by region:root

   Picture

   listener admit.note.gate--l1.seeking.blueprint.seen: — → hears admit.note.gate--l1.seeking.blueprint.presented → slot blueprint; ready when blueprint != null

   1. 1// KNOT.DEFS write (Vol. 02 §4.2): the definition payload lands as data, and
   2. 2// re-registration of an id replaces the definition AND resets its clew bank
   3. 3// to a fresh null-key probe — accumulated clews of the old definition are
   4. 4// discarded (the machine's only 'edit'). The probe clew is supplied by the
   5. 5// resolved executor so invalid configuration has already failed at the
   6. 6// factory (Vol. 04 §2.1); the stale executor cache entry is dropped here so
   7. 7// the replacement takes effect for the next tuple.
   8. 8
   9. 9import type { KnotDefinedPayload } from "../topology/gate";
   10. 10import type { ClewRegisters, TopologyRegisters } from "./topology-registers";
   11. 11import type { RegisterFile } from "./register-file";
   12. 12import { recordTransition } from "./record-transition";
   13. 13
   14. 14export function registerKnotDefinition(
   15. 15 file: RegisterFile,
   16. 16 region: TopologyRegisters,
   17. 17 payload: KnotDefinedPayload,
   18. 18 probeClew: ClewRegisters
   19. 19): void {
   20. 20 const replaced = region.knotDefs.has(payload.id);
   21. 21 region.knotDefs.set(payload.id, payload);↑ the description is stored under its name
   22. 22 region.clews.set(payload.id, new Map([[null, probeClew]]));↑ its bank of lanes, with a trial lane
   23. 23 file.ephemeral.knotExecutors.delete(`${region.regionId}/${payload.id}`);
   24. 24 recordTransition(file, `topology:${region.regionId}`, "KNOT.DEFS", "register-knot", {↑ the change is written into the journal
   25. 25 id: payload.id,
   26. 26 strategy: payload.strategy,
   27. 27 replaced
   28. 28 });
   29. 29 // The clew station is born here, with its null-key probe lane — journaled
   30. 30 // on the station itself so fold(journal) holds it before any lane opens
   31. 31 // (the document model's oracle, ADR-004 d10; Vol. 02 §4.5).
   32. 32 recordTransition(file, `topology:${region.regionId}/clew:${payload.id}`, "CLEWS", "open-clew", { key: null, probe: true, replaced }, "registerKnotDefinition");↑ the change is written into the journal
   33. 33}

   AGPL-3.0-onlyThe Lab's demonstration environment, as this fragment ran it (build 043cc8b). The code may change, and may differ from the code of a working machine.

   Nest VM core, incubated in the CoAgnes garden · build 043cc8b (2026-09-21) · this file last changed in 6730f58 (2026-09-13)

   A finding for the machine's authors, recorded and left as it is: the journal stamps CLEWS·open-clew → core/registers/ensure-clew.ts for registerKnotDefinition(), which lives in core/registers/register-knot-definition.ts (the op map's file for that register · action).

3. 33It gets a trial laneCLEWS · open-clew

   a wave is settlingengine: working on #5membrane: waiting at #2

   1. #0a listener
   2. #1a doer
   3. #2listener: the chartermembrane
   4. #3doer: the author
   5. #4listener: charter seen
   6. #5listener: blueprint seenengine · working
   7. #6doer: the planner
   8. #7listener: assess · charter
   9. #8listener: assess · result
   10. #9doer: the evaluator
   11. #10the charter wanted
   12. #11the blueprint
   13. ·end of the log

   What	before		after
   lane · trial lane (no key)	—	→	open

   Before any fact arrives, the listener gets one trial lane with no key — proof that its description works.

   Where it happens registerKnotDefinition()Vol. 02 §4.2 · Vol. 04 §2.1

   Stores a listener's description under its name and gives it a bank of lanes with one trial lane.

   Specification

   Vol. 02 §4.2 · Vol. 04 §2.1

   Code

   registerKnotDefinition() in core/registers/register-knot-definition.ts, line 21: the description is stored under its name

   Journal

   #5 · CLEWS · open-clew · key: null, probe: true, replaced: false · by region:root

   Picture

   lane · trial lane (no key): — → open

   1. 1// KNOT.DEFS write (Vol. 02 §4.2): the definition payload lands as data, and
   2. 2// re-registration of an id replaces the definition AND resets its clew bank
   3. 3// to a fresh null-key probe — accumulated clews of the old definition are
   4. 4// discarded (the machine's only 'edit'). The probe clew is supplied by the
   5. 5// resolved executor so invalid configuration has already failed at the
   6. 6// factory (Vol. 04 §2.1); the stale executor cache entry is dropped here so
   7. 7// the replacement takes effect for the next tuple.
   8. 8
   9. 9import type { KnotDefinedPayload } from "../topology/gate";
   10. 10import type { ClewRegisters, TopologyRegisters } from "./topology-registers";
   11. 11import type { RegisterFile } from "./register-file";
   12. 12import { recordTransition } from "./record-transition";
   13. 13
   14. 14export function registerKnotDefinition(
   15. 15 file: RegisterFile,
   16. 16 region: TopologyRegisters,
   17. 17 payload: KnotDefinedPayload,
   18. 18 probeClew: ClewRegisters
   19. 19): void {
   20. 20 const replaced = region.knotDefs.has(payload.id);
   21. 21 region.knotDefs.set(payload.id, payload);↑ the description is stored under its name
   22. 22 region.clews.set(payload.id, new Map([[null, probeClew]]));↑ its bank of lanes, with a trial lane
   23. 23 file.ephemeral.knotExecutors.delete(`${region.regionId}/${payload.id}`);
   24. 24 recordTransition(file, `topology:${region.regionId}`, "KNOT.DEFS", "register-knot", {↑ the change is written into the journal
   25. 25 id: payload.id,
   26. 26 strategy: payload.strategy,
   27. 27 replaced
   28. 28 });
   29. 29 // The clew station is born here, with its null-key probe lane — journaled
   30. 30 // on the station itself so fold(journal) holds it before any lane opens
   31. 31 // (the document model's oracle, ADR-004 d10; Vol. 02 §4.5).
   32. 32 recordTransition(file, `topology:${region.regionId}/clew:${payload.id}`, "CLEWS", "open-clew", { key: null, probe: true, replaced }, "registerKnotDefinition");↑ the change is written into the journal
   33. 33}

   AGPL-3.0-onlyThe Lab's demonstration environment, as this fragment ran it (build 043cc8b). The code may change, and may differ from the code of a working machine.

   Nest VM core, incubated in the CoAgnes garden · build 043cc8b (2026-09-21) · this file last changed in 6730f58 (2026-09-13)

   A finding for the machine's authors, recorded and left as it is: the journal stamps CLEWS·open-clew → core/registers/ensure-clew.ts for registerKnotDefinition(), which lives in core/registers/register-knot-definition.ts (the op map's file for that register · action).

when the membrane passed #5

1. 71The membrane passes #5MEMBRANE.CURSOR · sweep

   a wave is settlingengine: at the endmembrane: passing #5

   1. #0a listener
   2. #1a doer
   3. #2listener: the charter
   4. #3doer: the author
   5. #4listener: charter seen
   6. #5listener: blueprint seenmembrane · passing
   7. #6doer: the planner
   8. #7listener: assess · charter
   9. #8listener: assess · result
   10. #9doer: the evaluator
   11. #10the charter wanted
   12. #11the blueprint
   13. #12readiness
   14. #13readiness
   15. #14a request: a charter
   16. ·end of the logengine

   What	before		after
   pointer — the next record to pass	#5	→	#6

   #5 asks nothing of the world, so the membrane's pointer simply moves on.

   Where it happens sweepNextTuple()Vol. 02 §4.6 · Vol. 07 §3

   The membrane's step: pass over the record under its pointer and move the pointer on — exactly once per record.

   Specification

   Vol. 02 §4.6 · Vol. 07 §3

   Code

   sweepNextTuple() in core/registers/sweep-next-tuple.ts, line 16: the membrane's pointer moves on by one

   Journal

   #5 · MEMBRANE.CURSOR · sweep · offset: 5 · by membrane

   Picture

   pointer — the next record to pass: #5 → #6

   1. 1// MEMBRANE.CURSOR advance (Vol. 02 §4.6, Vol. 07 §3): the membrane's own
   2. 2// reading of the one log — the second reception of one publication, never a
   3. 3// second truth. The cursor advances exactly once per offset per machine:
   4. 4// the exactly-once discharge guarantee lives in this movement.
   5. 5
   6. 6import type { WaveTuple } from "../wave/gate";
   7. 7import type { RegisterFile } from "./register-file";
   8. 8import { recordTransition } from "./record-transition";
   9. 9import { setDriver, setWaveContext } from "./set-wave-context";
   10. 10
   11. 11export function sweepNextTuple(file: RegisterFile): WaveTuple | null {
   12. 12 const engine = file.registers.engine;
   13. 13 const membrane = file.registers.membrane;
   14. 14 if (membrane.cursor >= engine.base + engine.window.length) return null;
   15. 15 const tuple = engine.window[membrane.cursor - engine.base];
   16. 16 membrane.cursor += 1;↑ the membrane's pointer moves on by one
   17. 17 setWaveContext(file, { offset: tuple.offset, phase: "sweep" });
   18. 18 setDriver(file, "membrane");
   19. 19 recordTransition(file, "membrane", "MEMBRANE.CURSOR", "sweep", { offset: tuple.offset });↑ the change is written into the journal
   20. 20 return tuple;
   21. 21}

   AGPL-3.0-onlyThe Lab's demonstration environment, as this fragment ran it (build 043cc8b). The code may change, and may differ from the code of a working machine.

   Nest VM core, incubated in the CoAgnes garden · build 043cc8b (2026-09-21) · this file last changed in 6730f58 (2026-09-13)