a wave is settlingengine working on #26membrane waiting at #25

Wave 3 · record #26sys.descriptor.defined

#26 · the return doer

When the engine takes it, the machine stores it. It is the simplest doer the machine has.

Came froma personThe person's act of opening a Cell sowed it at the door: the second record of the return figure. step 138

Read as

when it came in at the door

  1. 138Record #26 enters the logLOG · append

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

    The log
    1. #0a listener
    2. #1a doer
    3. #2listener: the charter
    4. #3doer: the author
    5. #4listener: charter seen
    6. #5listener: blueprint seen
    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. #15the charter proposed
    17. #16the charter defined
    18. #17readiness
    19. #18readiness
    20. #19a request: a Cell
    21. #20the seed
    22. #21the Cell is open
    23. #22inner listener
    24. #23inner doer
    25. #24the Cell's context
    26. #25return listenerenginemembrane
    27. #26return doernew
    28. end of the log
    The log
    Whatbeforeafter
    records in the log2627
    #26—return doer · sys.descriptor.defined

    The door adds #26: the return doer, which will ask for the answer to be presented again once the return listener is ready.

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

    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 #26

  1. 143The engine takes #26ENGINE.CURSOR · propagate

    a wave is settlingengine: working on #26membrane: waiting at #25

    The log
    1. #0a listener
    2. #1a doer
    3. #2listener: the charter
    4. #3doer: the author
    5. #4listener: charter seen
    6. #5listener: blueprint seen
    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. #15the charter proposed
    17. #16the charter defined
    18. #17readiness
    19. #18readiness
    20. #19a request: a Cell
    21. #20the seed
    22. #21the Cell is open
    23. #22inner listener
    24. #23inner doer
    25. #24the Cell's context
    26. #25return listenermembrane
    27. #26return doerengine · working
    28. #27the return address
    29. end of the log
    The engine
    Whatbeforeafter
    pointer — the next record to take#26#27

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

    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. 144The return doer is added to the figureBIND.DEFS · register-descriptor

    a wave is settlingengine: working on #26membrane: waiting at #25

    The log
    1. #0a listener
    2. #1a doer
    3. #2listener: the charter
    4. #3doer: the author
    5. #4listener: charter seen
    6. #5listener: blueprint seen
    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. #15the charter proposed
    17. #16the charter defined
    18. #17readiness
    19. #18readiness
    20. #19a request: a Cell
    21. #20the seed
    22. #21the Cell is open
    23. #22inner listener
    24. #23inner doer
    25. #24the Cell's context
    26. #25return listenermembrane
    27. #26return doerengine · working
    28. #27the return address
    29. end of the log
    The figure
    Whatbeforeafter
    doer return.cell-20—on return.cell-20.gate: writes represent.requested
    when return.cell-20.gate is ready, it wakes—return.cell-20

    The machine writes return.cell-20 into its list of doers. It is the simplest doer the machine has: no rendezvous, no scope — when its listener is ready, it writes one fact.

    Where it happens registerDescriptorDefinition()Vol. 02 §4.2

    Stores a doer's description under its name, and lists it under every listener it waits for.

    Specification
    Vol. 02 §4.2
    Code
    registerDescriptorDefinition() in core/registers/register-descriptor-definition.ts, line 19: the description is stored under its name
    Journal
    #26 · BIND.DEFS · register-descriptor · id: return.cell-20, interests: ["return.cell-20.gate"] · by region:root
    Picture
    doer return.cell-20: — → on return.cell-20.gate: writes represent.requested
    core/registers/register-descriptor-definition.ts · build 043cc8b
    1. // BIND.DEFS and DISPATCH write (Vol. 02 §4.2): the registration payload
    2. // lands as data; the dispatch table indexes the descriptor id under every
    3. // declared interest (the activation knot plus every demand for an operator
    4. // bind, the one subscription for an emit descriptor). Duplicate-id rejection
    5. // is the station's verdict (ADR-011 finding 3) — this op only records an
    6. // accepted registration.
    7. import type { DescriptorDefinedPayload } from "../topology/gate";
    8. import type { TopologyRegisters } from "./topology-registers";
    9. import type { RegisterFile } from "./register-file";
    10. import { recordTransition } from "./record-transition";
    11. export function registerDescriptorDefinition(
    12. file: RegisterFile,
    13. region: TopologyRegisters,
    14. payload: DescriptorDefinedPayload,
    15. interests: readonly string[]
    16. ): void {
    17. region.bindDefs.set(payload.id, payload);↑ the description is stored under its name
    18. for (const interest of interests) {
    19. const list = region.dispatch.get(interest);
    20. if (list) list.push(payload.id);
    21. else region.dispatch.set(interest, [payload.id]);↑ listed under the listener it waits for
    22. }
    23. recordTransition(file, `topology:${region.regionId}`, "BIND.DEFS", "register-descriptor", {↑ the change is written into the journal
    24. id: payload.id,
    25. interests
    26. });
    27. }

    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 membrane passed #26

  1. 149The membrane passes #26MEMBRANE.CURSOR · sweep

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

    The log
    1. #0a listener
    2. #1a doer
    3. #2listener: the charter
    4. #3doer: the author
    5. #4listener: charter seen
    6. #5listener: blueprint seen
    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. #15the charter proposed
    17. #16the charter defined
    18. #17readiness
    19. #18readiness
    20. #19a request: a Cell
    21. #20the seed
    22. #21the Cell is open
    23. #22inner listener
    24. #23inner doer
    25. #24the Cell's context
    26. #25return listener
    27. #26return doermembrane · passing
    28. #27the return address
    29. end of the logengine
    The membrane
    Whatbeforeafter
    pointer — the next record to pass#26#27

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

    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)

Step 138: Record #26 enters the log

138 Record #26 enters the log

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

The log
  1. #0a listener
  2. #1a doer
  3. #2listener: the charter
  4. #3doer: the author
  5. #4listener: charter seen
  6. #5listener: blueprint seen
  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. #15the charter proposed
  17. #16the charter defined
  18. #17readiness
  19. #18readiness
  20. #19a request: a Cell
  21. #20the seed
  22. #21the Cell is open
  23. #22inner listener
  24. #23inner doer
  25. #24the Cell's context
  26. #25return listenerenginemembrane
  27. #26return doernew
  28. end of the log
The log
Whatbeforeafter
records in the log2627
#26—return doer · sys.descriptor.defined

The door adds #26: the return doer, which will ask for the answer to be presented again once the return listener is ready.

Where it happens · appendEmissions()

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

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)

A doer's definition

Brings a doer into the machine: its name, the listener it acts on, what else it needs, and what it does once it may act — release a fact itself, ask the world for a fact, or ask the world for a whole Cell. The return doer is the simplest sort: it writes one fact when its listener is ready.

#26sys.descriptor.defined a person

envelope
offset26Its place in the log — the only address a record has. The engine gives it when the record is added, the next free number, and it never changes.
kindsys.descriptor.definedWhich of the four kinds of record the machine knows. The kind decides what the payload holds.
key∅No lane (∅): a definition belongs to the whole machine, not to one lane.
payload
idreturn.cell-20The doer's name, unique in the machine.
subscribesToreturn.cell-20.gateFor the simplest sort of doer: the listener whose readiness makes it write — no rendezvous, no scope.
payload.actionConfig
writesrepresent.requestedThe type of the one fact it writes.

end · #26

In the specificationVol. 03 §1Vol. 03 §2Vol. 03 §5Vol. 04 §2.2Vol. 06 §2Vol. 06 §3Vol. 12 §3

The record as the machine keeps it
{
 "offset": 26,
 "kind": "sys.descriptor.defined",
 "key": null,
 "payload": {
  "id": "return.cell-20",
  "subscribesTo": "return.cell-20.gate",
  "actionConfig": {
   "writes": "represent.requested"
  }
 }
}