CoAgnes Labthe study spaceresearch preview · build 1ececa2

a wave is settlingengine working on #32membrane waiting at #28

Wave 4 · The assessment · record #32sys.knot.ready

#32 · the result is seen — the evaluator acts

The evaluator, holding the charter since #18, gathers the result, acts once and asks the world to assess it (#33).

Came fromthe machineThe machine wrote it while the engine took #31: assess · result had what it waited for. step 175

Read as

when the engine took #32

  1. 176The engine takes #32ENGINE.CURSOR · propagate

    a wave is settlingengine: working on #32membrane: waiting at #28

    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 doer
    28. #27the return address
    29. #28the person's wordsmembrane
    30. #29readiness
    31. #30the private result
    32. #31the result, marked
    33. #32readinessengine · working
    34. end of the log
    The engine
    beforeafter
    pointer — the next record to take#32#33

    The engine moves on to #32 — assess · result's readiness, for the evaluator.

    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
    #32 · ENGINE.CURSOR · propagate · offset: 32 · by engine
    Picture
    pointer — the next record to take: #32 → #33
    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.
    8. import type { WaveTuple } from "../wave/gate";
    9. import type { RegisterFile } from "./register-file";
    10. import { recordTransition } from "./record-transition";
    11. import { setDriver, setWaveContext } from "./set-wave-context";
    13. export function takeNextTuple(file: RegisterFile): WaveTuple | null {
    14. const engine = file.registers.engine;
    15. if (engine.cursor >= engine.base + engine.window.length) return null;↑ at the end of the log, the engine stops
    16. const tuple = engine.window[engine.cursor - engine.base];
    17. engine.cursor += 1;↑ the engine's pointer moves on by one
    18. setWaveContext(file, { offset: tuple.offset, phase: "propagate" });
    19. setDriver(file, "engine");
    20. recordTransition(file, "engine", "ENGINE.CURSOR", "propagate", { offset: tuple.offset });↑ the change is written into the journal
    21. return tuple;
    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. 177The result is gathered beside the charterRDV.SCOPE · latch-scope

    a wave is settlingengine: working on #32membrane: waiting at #28

    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 doer
    28. #27the return address
    29. #28the person's wordsmembrane
    30. #29readiness
    31. #30the private result
    32. #31the result, marked
    33. #32readinessengine · working
    34. end of the log
    The doer admit.note.gate--l1.seeking.evaluator
    beforeafter
    lane · this session · gathered result—seen = {"cellRef":"cell@20","result":{"text":"A Cell is a bounded study the machine opens when a slot needs more than a fact: it has its own charter, its own knots and binds, and a result that is assessed and reviewed before anything returns."},"localResultOffset":30,"producedBy":{"bindId":"cell@20::l1.seeking.release","uid":"cell@20::l1.seeking.release#1"}}

    The result enters the evaluator's scope as result, beside the charter held since #18. The lane was active from birth, so only the scope is written: criteria and result are together.

    Where it happens latchRendezvousScope()Vol. 02 §4.5 · Vol. 06 §4

    Gathers what a listener understood into the doer's scope — and, from the listener the doer acts on, activates the lane.

    Specification
    Vol. 02 §4.5 · Vol. 06 §4
    Code
    latchRendezvousScope() in core/registers/latch-rendezvous-scope.ts, line 17: the lane is activated
    Journal
    #32 · RDV.SCOPE · latch-scope · key: fragment-one-cell, as: result · by bind:admit.note.gate--l1.seeking.evaluator
    Picture
    lane · this session · gathered result: — → seen = {"cellRef":"cell@20","result":{"text":"A Cell is a bounded study the machine opens when a slot needs more than a fact: it has its own charter, its own knots and binds, and a result that is assessed and reviewed before anything returns."},"localResultOffset":30,"producedBy":{"bindId":"cell@20::l1.seeking.release","uid":"cell@20::l1.seeking.release#1"}}
    core/registers/latch-rendezvous-scope.ts · build 043cc8b
    1. // RDV scope latch (Vol. 02 §4.5, Vol. 06 §4): a readiness understanding
    2. // enters the bound scope under its declared name — a later readiness of the
    3. // same demand refreshes its entry until projection (the latching barrier).
    4. // Activation readiness additionally opens the lane (ACTIVATED).
    6. import type { BindHandle, RendezvousLane } from "./topology-registers";
    7. import { recordTransition } from "./record-transition";
    9. export function latchRendezvousScope(
    10. bind: BindHandle,
    11. lane: RendezvousLane,
    12. key: string | null,
    13. as: string,
    14. understanding: unknown,
    15. options: { activates: boolean }
    16. ): void {
    17. if (options.activates) lane.activated = true;↑ the lane is activated
    18. lane.scope.set(as, understanding);↑ the understanding is gathered
    19. recordTransition(↑ the change is written into the journal
    20. bind.file,
    21. `topology:${bind.region.regionId}/bind:${bind.bindId}`,
    22. options.activates ? "RDV.ACTIVATED,RDV.SCOPE" : "RDV.SCOPE",
    23. "latch-scope",
    24. { key, as }
    25. );
    26. }

    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)

  3. 178The evaluator acts — onceRDV.PROJECTED · latch-projection

    a wave is settlingengine: working on #32membrane: waiting at #28

    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 doer
    28. #27the return address
    29. #28the person's wordsmembrane
    30. #29readiness
    31. #30the private result
    32. #31the result, marked
    33. #32readinessengine · working
    34. end of the log
    The doer admit.note.gate--l1.seeking.evaluator
    beforeafter
    lane · this session · has actednoyes

    The lane is latched: the evaluator acts now, and never again on this lane.

    Where it happens latchRendezvousProjection()Vol. 02 §4.5 · Vol. 06 §4.2

    Latches a doer's lane after it acts, so that it never acts on that lane again.

    Specification
    Vol. 02 §4.5 · Vol. 06 §4.2
    Code
    latchRendezvousProjection() in core/registers/latch-rendezvous-projection.ts, line 9: the lane is latched for good
    Journal
    #32 · RDV.PROJECTED · latch-projection · key: fragment-one-cell · by bind:admit.note.gate--l1.seeking.evaluator
    Picture
    lane · this session · has acted: no → yes
    core/registers/latch-rendezvous-projection.ts · build 043cc8b
    1. // RDV.PROJECTED latch (Vol. 02 §4.5, Vol. 06 §4.2): one-shot — once the
    2. // scope is judged and the intention projected (or rejected at a gate), the
    3. // lane never fires again. The latch never reopens; revision is fresh binds.
    5. import type { BindHandle, RendezvousLane } from "./topology-registers";
    6. import { recordTransition } from "./record-transition";
    8. export function latchRendezvousProjection(bind: BindHandle, lane: RendezvousLane, key: string | null): void {
    9. lane.projected = true;↑ the lane is latched for good
    10. recordTransition(bind.file, `topology:${bind.region.regionId}/bind:${bind.bindId}`, "RDV.PROJECTED", "latch-projection", {↑ the change is written into the journal
    11. key
    12. });
    13. }

    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)

  4. 179The intention gets its nameINTENT.CTR · mint-uid

    a wave is settlingengine: working on #32membrane: waiting at #28

    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 doer
    28. #27the return address
    29. #28the person's wordsmembrane
    30. #29readiness
    31. #30the private result
    32. #31the result, marked
    33. #32readinessengine · working
    34. end of the log
    The doer admit.note.gate--l1.seeking.evaluator
    beforeafter
    intentions named so far01

    What the evaluator is about to ask gets its unique name — the evaluator's name with #1.

    Where it happens nextIntentionUid()Vol. 02 §4.5 · Vol. 02 §4.7

    Gives a doer's next intention its unique name, from a counter that never goes back.

    Specification
    Vol. 02 §4.5 · Vol. 02 §4.7
    Code
    nextIntentionUid() in core/registers/next-intention-uid.ts, line 12: the counter moves on
    Journal
    #32 · INTENT.CTR · mint-uid · uid: admit.note.gate--l1.seeking.evaluator#1 · by bind:admit.note.gate--l1.seeking.evaluator
    Picture
    intentions named so far: 0 → 1
    core/registers/next-intention-uid.ts · build 043cc8b
    1. // INTENT.CTR advance (Vol. 02 §4.5, §4.7 rule 3): the service-intention uid
    2. // sequence, shared across lanes and never reset — uids stay unique per
    3. // machine instance, which is exactly why this counter belongs to the durable
    4. // stratum and must survive a snapshot/restore (ADR-002 decision 4).
    6. import type { BindHandle } from "./topology-registers";
    7. import { recordTransition } from "./record-transition";
    9. export function nextIntentionUid(bind: BindHandle): string {
    10. const bank = bind.region.rdv.get(bind.bindId);
    11. if (!bank) throw new Error(`Rendezvous bank missing for bind '${bind.bindId}'.`);
    12. bank.intentCtr += 1;↑ the counter moves on
    13. const uid = `${bind.bindId}#${bank.intentCtr}`;↑ the name: the doer's name and the count
    14. recordTransition(bind.file, `topology:${bind.region.regionId}/bind:${bind.bindId}`, "INTENT.CTR", "mint-uid", {↑ the change is written into the journal
    15. uid
    16. });
    17. return uid;
    18. }

    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)

  5. 180The request enters the log as #33LOG · append

    a wave is settlingengine: working on #32membrane: waiting at #28

    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 doer
    28. #27the return address
    29. #28the person's wordsmembrane
    30. #29readiness
    31. #30the private result
    32. #31the result, marked
    33. #32readinessengine · working
    34. #33a request: assessnew
    35. end of the log
    The log
    beforeafter
    records in the log3334
    #33—a request: assess · service.request

    The evaluator's request is written as #33: assess this result against this charter's criteria, to be answered as cell.assessment.proposed.

    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
    #32 · LOG · append · offset: 33, kind: domain.fact · by engine
    Picture
    records in the log: 33 → 34
    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).
    7. import type { WaveEmission, WaveTuple } from "../wave/gate";
    8. import type { RegisterFile } from "./register-file";
    9. import { recordTransition } from "./record-transition";
    11. export function appendEmissions(file: RegisterFile, emissions: readonly WaveEmission[]): void {
    12. const engine = file.registers.engine;
    13. for (const emission of emissions) {
    14. const tuple: WaveTuple = { ...emission, offset: engine.base + engine.window.length };↑ the new record gets the next free number
    15. engine.window.push(tuple);↑ it is added at the end of the log
    16. recordTransition(file, "engine", "LOG", "append", {↑ the change is written into the journal
    17. offset: tuple.offset,
    18. kind: tuple.kind
    19. });
    20. }
    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 membrane passed #32

  1. 187The membrane passes #32MEMBRANE.CURSOR · sweep

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

    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 doer
    28. #27the return address
    29. #28the person's words
    30. #29readiness
    31. #30the private result
    32. #31the result, marked
    33. #32readinessmembrane · passing
    34. #33a request: assess
    35. end of the logengine
    The membrane
    beforeafter
    pointer — the next record to pass#32#33

    #32 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
    #32 · MEMBRANE.CURSOR · sweep · offset: 32 · by membrane
    Picture
    pointer — the next record to pass: #32 → #33
    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.
    6. import type { WaveTuple } from "../wave/gate";
    7. import type { RegisterFile } from "./register-file";
    8. import { recordTransition } from "./record-transition";
    9. import { setDriver, setWaveContext } from "./set-wave-context";
    11. export function sweepNextTuple(file: RegisterFile): WaveTuple | null {
    12. const engine = file.registers.engine;
    13. const membrane = file.registers.membrane;
    14. if (membrane.cursor >= engine.base + engine.window.length) return null;
    15. const tuple = engine.window[membrane.cursor - engine.base];
    16. membrane.cursor += 1;↑ the membrane's pointer moves on by one
    17. setWaveContext(file, { offset: tuple.offset, phase: "sweep" });
    18. setDriver(file, "membrane");
    19. recordTransition(file, "membrane", "MEMBRANE.CURSOR", "sweep", { offset: tuple.offset });↑ the change is written into the journal
    20. return tuple;
    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)

Choose a step in the stack — or press →.

A listener's readiness

The machine's own record that a listener's condition came true. It names the listener and keeps what the listener understood at that moment — its slots, taken before they are emptied, and written before any doer acts.

#32sys.knot.ready the machine

envelope
offset32Its 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.knot.readyWhich of the four kinds of record the machine knows. The kind decides what the payload holds.
keyfragment-one-cellThe lane of the fact that made the listener ready.
payload
knotIdadmit.note.gate--l1.seeking.assess.resultThe listener that is ready.
payload.understanding
seencellRef · result · localResultOffset · producedByWhat assess · result understood: the Cell's result, where it stands, and the doer and intention that made it.

end · #32

In the specificationVol. 03 §1Vol. 03 §2Vol. 03 §5Vol. 04 §2.3

Names it shares with other records

The record as the machine keeps it
{
 "offset": 32,
 "kind": "sys.knot.ready",
 "key": "fragment-one-cell",
 "payload": {
  "knotId": "admit.note.gate--l1.seeking.assess.result",
  "understanding": {
   "seen": {
    "cellRef": "cell@20",
    "result": {
     "text": "A Cell is a bounded study the machine opens when a slot needs more than a fact: it has its own charter, its own knots and binds, and a result that is assessed and reviewed before anything returns."
    },
    "localResultOffset": 30,
    "producedBy": {
     "bindId": "cell@20::l1.seeking.release",
     "uid": "cell@20::l1.seeking.release#1"
    }
   }
  }
 }
}