Wave 2 · The charter · record #12sys.knot.ready
#12 · the charter gate is ready, the author asks
The author wakes, gathers the charter wanted, acts once, names its intention — and, having no local action, writes a request to the world as #14.
Came fromthe machineThe machine wrote it while the engine took #10: the charter gate had what it waited for. step 49
when the engine took #12
55The engine takes #12ENGINE.CURSOR · propagate
a wave is settlingengine: working on #12membrane: waiting at #2
The log - #0a listener
- #1a doer
- #2listener: the charter
- #3doer: the author
- #4listener: charter seen
- #5listener: blueprint seen
- #6doer: the planner
- #7listener: assess · charter
- #8listener: assess · result
- #9doer: the evaluator
- #10the charter wanted
- #11the blueprint
- #12readiness
- #13readiness
- end of the log
The engine What before after pointer — the next record to take #12 #13 The engine moves on to #12 — the charter gate's readiness, written by the machine itself.
Where it happens
takeNextTuple()Vol. 02 §4.1The 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()incore/registers/take-next-tuple.ts, line 15: at the end of the log, the engine stops- Journal
- #12 ·
ENGINE.CURSOR · propagate· offset: 12 · by engine - Picture
- pointer — the next record to take: #12 → #13
core/registers/take-next-tuple.ts· build 043cc8b// ENGINE.CURSOR advance (Vol. 02 §4.1) — the machine's instruction pointer:// returns the tuple at the cursor and moves it forward exactly once, or null// at quiescence. Advancing IS the context switch: the ambient wave context// moves to the propagated tuple in the same movement, so every transition// journalled during its propagation is attributed to it — the cube's spine.// The cursor never rewinds.import type { WaveTuple } from "../wave/gate";import type { RegisterFile } from "./register-file";import { recordTransition } from "./record-transition";import { setDriver, setWaveContext } from "./set-wave-context";export function takeNextTuple(file: RegisterFile): WaveTuple | null {const engine = file.registers.engine;if (engine.cursor >= engine.base + engine.window.length) return null;↑ at the end of the log, the engine stopsconst tuple = engine.window[engine.cursor - engine.base];engine.cursor += 1;↑ the engine's pointer moves on by onesetWaveContext(file, { offset: tuple.offset, phase: "propagate" });setDriver(file, "engine");recordTransition(file, "engine", "ENGINE.CURSOR", "propagate", { offset: tuple.offset });↑ the change is written into the journalreturn tuple;}
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)
56The author opens its rendezvousRDV · open-bank
a wave is settlingengine: working on #12membrane: waiting at #2
The log - #0a listener
- #1a doer
- #2listener: the charter
- #3doer: the author
- #4listener: charter seen
- #5listener: blueprint seen
- #6doer: the planner
- #7listener: assess · charter
- #8listener: assess · result
- #9doer: the evaluator
- #10the charter wanted
- #11the blueprint
- #12readiness
- #13readiness
- end of the log
The figure What before after rendezvous opened — admit.note.gate--l1.seeking.charter.authorThe charter's author waits for the charter gate, so this readiness wakes it: it opens its rendezvous, where it gathers what its listeners have said.
Where it happens
ensureRendezvous()Vol. 02 §4.5 · Vol. 06 §4.5Opens a doer's rendezvous the first time it is woken, and a lane in it for each new key.
- Specification
- Vol. 02 §4.5 · Vol. 06 §4.5
- Code
ensureRendezvous()incore/registers/ensure-rendezvous.ts, line 13: a rendezvous for this doer- Journal
- #12 ·
RDV · open-bank· bindId: admit.note.gate--l1.seeking.charter.author · by bind:admit.note.gate--l1.seeking.charter.author - Picture
- rendezvous opened: — →
admit.note.gate--l1.seeking.charter.author
core/registers/ensure-rendezvous.ts· build 043cc8b// RDV lane access (Vol. 02 §4.5): one rendezvous state per key lane, created// lazily on the first readiness that reaches the bind — activated at birth// when the bind declares no `on` (a demands-only bind, Vol. 06 §4.5).// Creation is a transition; an existing lane passes through as a read.import type { BindHandle, RendezvousLane, RendezvousRegisters } from "./topology-registers";import { recordTransition } from "./record-transition";export function ensureRendezvous(bind: BindHandle, key: string | null, activatedAtBirth: boolean): RendezvousLane {let bank: RendezvousRegisters | undefined = bind.region.rdv.get(bind.bindId);if (!bank) {bank = { lanes: new Map(), intentCtr: 0 };bind.region.rdv.set(bind.bindId, bank);↑ a rendezvous for this doer// A new bank changes the REGION's RDV register set (Vol. 02 §4.5) — the// region station journals it, so its document (rdvOrder) folds true// (the fold oracle, ADR-004 d11).recordTransition(bind.file, `topology:${bind.region.regionId}`, "RDV", "open-bank", { bindId: bind.bindId });↑ the change is written into the journal}let lane = bank.lanes.get(key);if (!lane) {lane = { activated: activatedAtBirth, scope: new Map(), projected: false };bank.lanes.set(key, lane);↑ a lane for this keyrecordTransition(bind.file, `topology:${bind.region.regionId}/bind:${bind.bindId}`, "RDV", "open-lane", {↑ the change is written into the journalkey,activatedAtBirth});}return lane;}
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 3530f2c (2026-09-07)
57A lane for this sessionRDV · open-lane
a wave is settlingengine: working on #12membrane: waiting at #2
The log - #0a listener
- #1a doer
- #2listener: the charter
- #3doer: the author
- #4listener: charter seen
- #5listener: blueprint seen
- #6doer: the planner
- #7listener: assess · charter
- #8listener: assess · result
- #9doer: the evaluator
- #10the charter wanted
- #11the blueprint
- #12readiness
- #13readiness
- end of the log
The doer admit.note.gate--l1.seeking.charter.author· appearsWhat before after lane · this session — open lane · this session · active — no lane · this session · has acted — no intentions named so far — 0 Inside the rendezvous, a lane for this session's key — not active yet: it becomes active when the listener it acts on is ready.
Where it happens
ensureRendezvous()Vol. 02 §4.5 · Vol. 06 §4.5Opens a doer's rendezvous the first time it is woken, and a lane in it for each new key.
- Specification
- Vol. 02 §4.5 · Vol. 06 §4.5
- Code
ensureRendezvous()incore/registers/ensure-rendezvous.ts, line 13: a rendezvous for this doer- Journal
- #12 ·
RDV · open-lane· key: fragment-one-cell, activatedAtBirth: false · by bind:admit.note.gate--l1.seeking.charter.author - Picture
- lane · this session: — → open
core/registers/ensure-rendezvous.ts· build 043cc8b// RDV lane access (Vol. 02 §4.5): one rendezvous state per key lane, created// lazily on the first readiness that reaches the bind — activated at birth// when the bind declares no `on` (a demands-only bind, Vol. 06 §4.5).// Creation is a transition; an existing lane passes through as a read.import type { BindHandle, RendezvousLane, RendezvousRegisters } from "./topology-registers";import { recordTransition } from "./record-transition";export function ensureRendezvous(bind: BindHandle, key: string | null, activatedAtBirth: boolean): RendezvousLane {let bank: RendezvousRegisters | undefined = bind.region.rdv.get(bind.bindId);if (!bank) {bank = { lanes: new Map(), intentCtr: 0 };bind.region.rdv.set(bind.bindId, bank);↑ a rendezvous for this doer// A new bank changes the REGION's RDV register set (Vol. 02 §4.5) — the// region station journals it, so its document (rdvOrder) folds true// (the fold oracle, ADR-004 d11).recordTransition(bind.file, `topology:${bind.region.regionId}`, "RDV", "open-bank", { bindId: bind.bindId });↑ the change is written into the journal}let lane = bank.lanes.get(key);if (!lane) {lane = { activated: activatedAtBirth, scope: new Map(), projected: false };bank.lanes.set(key, lane);↑ a lane for this keyrecordTransition(bind.file, `topology:${bind.region.regionId}/bind:${bind.bindId}`, "RDV", "open-lane", {↑ the change is written into the journalkey,activatedAtBirth});}return lane;}
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 3530f2c (2026-09-07)
58What the gate understood is gatheredRDV.ACTIVATED,RDV.SCOPE · latch-scope
a wave is settlingengine: working on #12membrane: waiting at #2
The log - #0a listener
- #1a doer
- #2listener: the charter
- #3doer: the author
- #4listener: charter seen
- #5listener: blueprint seen
- #6doer: the planner
- #7listener: assess · charter
- #8listener: assess · result
- #9doer: the evaluator
- #10the charter wanted
- #11the blueprint
- #12readiness
- #13readiness
- end of the log
The doer admit.note.gate--l1.seeking.charter.authorWhat before after lane · this session · active no yes lane · this session · gathered wanted — wanted = {"charter":{"title":"Seeking","purpose":"What are we seeking to understand, and for whom does it matter?","question":"What is a Cell, and why does the machine open one instead of answering in place?","criteria":[{"id":"q1","question":"What is this material about, and what exactly are we seeking to understand in it?","weight":1,"minimum":0.6},{"id":"q2","question":"Whose problem does it address, and why does it exist?","weight":1,"minimum":0.6}]}} The readiness activates the lane, and the charter wanted enters the author's scope under the name wanted. That scope is what its request will carry to the world.
Where it happens
latchRendezvousScope()Vol. 02 §4.5 · Vol. 06 §4Gathers 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()incore/registers/latch-rendezvous-scope.ts, line 17: the lane is activated- Journal
- #12 ·
RDV.ACTIVATED,RDV.SCOPE · latch-scope· key: fragment-one-cell, as: wanted · by bind:admit.note.gate--l1.seeking.charter.author - Picture
- lane · this session · active: no → yes
core/registers/latch-rendezvous-scope.ts· build 043cc8b// RDV scope latch (Vol. 02 §4.5, Vol. 06 §4): a readiness understanding// enters the bound scope under its declared name — a later readiness of the// same demand refreshes its entry until projection (the latching barrier).// Activation readiness additionally opens the lane (ACTIVATED).import type { BindHandle, RendezvousLane } from "./topology-registers";import { recordTransition } from "./record-transition";export function latchRendezvousScope(bind: BindHandle,lane: RendezvousLane,key: string | null,as: string,understanding: unknown,options: { activates: boolean }): void {if (options.activates) lane.activated = true;↑ the lane is activatedlane.scope.set(as, understanding);↑ the understanding is gatheredrecordTransition(↑ the change is written into the journalbind.file,`topology:${bind.region.regionId}/bind:${bind.bindId}`,options.activates ? "RDV.ACTIVATED,RDV.SCOPE" : "RDV.SCOPE","latch-scope",{ key, as });}
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)
59The author acts — onceRDV.PROJECTED · latch-projection
a wave is settlingengine: working on #12membrane: waiting at #2
The log - #0a listener
- #1a doer
- #2listener: the charter
- #3doer: the author
- #4listener: charter seen
- #5listener: blueprint seen
- #6doer: the planner
- #7listener: assess · charter
- #8listener: assess · result
- #9doer: the evaluator
- #10the charter wanted
- #11the blueprint
- #12readiness
- #13readiness
- end of the log
The doer admit.note.gate--l1.seeking.charter.authorWhat before after lane · this session · has acted no yes The lane is latched: the author acts now, and never again on this lane — however long the world takes to answer.
Where it happens
latchRendezvousProjection()Vol. 02 §4.5 · Vol. 06 §4.2Latches 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()incore/registers/latch-rendezvous-projection.ts, line 9: the lane is latched for good- Journal
- #12 ·
RDV.PROJECTED · latch-projection· key: fragment-one-cell · by bind:admit.note.gate--l1.seeking.charter.author - Picture
- lane · this session · has acted: no → yes
core/registers/latch-rendezvous-projection.ts· build 043cc8b// RDV.PROJECTED latch (Vol. 02 §4.5, Vol. 06 §4.2): one-shot — once the// scope is judged and the intention projected (or rejected at a gate), the// lane never fires again. The latch never reopens; revision is fresh binds.import type { BindHandle, RendezvousLane } from "./topology-registers";import { recordTransition } from "./record-transition";export function latchRendezvousProjection(bind: BindHandle, lane: RendezvousLane, key: string | null): void {lane.projected = true;↑ the lane is latched for goodrecordTransition(bind.file, `topology:${bind.region.regionId}/bind:${bind.bindId}`, "RDV.PROJECTED", "latch-projection", {↑ the change is written into the journalkey});}
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)
60The intention gets its nameINTENT.CTR · mint-uid
a wave is settlingengine: working on #12membrane: waiting at #2
The log - #0a listener
- #1a doer
- #2listener: the charter
- #3doer: the author
- #4listener: charter seen
- #5listener: blueprint seen
- #6doer: the planner
- #7listener: assess · charter
- #8listener: assess · result
- #9doer: the evaluator
- #10the charter wanted
- #11the blueprint
- #12readiness
- #13readiness
- end of the log
The doer admit.note.gate--l1.seeking.charter.authorWhat before after intentions named so far 0 1 What the author is about to ask gets a unique name — its own name with #1 — from a counter that never goes back. The world must return that name with its answer.
Where it happens
nextIntentionUid()Vol. 02 §4.5 · Vol. 02 §4.7Gives 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()incore/registers/next-intention-uid.ts, line 12: the counter moves on- Journal
- #12 ·
INTENT.CTR · mint-uid· uid: admit.note.gate--l1.seeking.charter.author#1 · by bind:admit.note.gate--l1.seeking.charter.author - Picture
- intentions named so far: 0 → 1
core/registers/next-intention-uid.ts· build 043cc8b// INTENT.CTR advance (Vol. 02 §4.5, §4.7 rule 3): the service-intention uid// sequence, shared across lanes and never reset — uids stay unique per// machine instance, which is exactly why this counter belongs to the durable// stratum and must survive a snapshot/restore (ADR-002 decision 4).import type { BindHandle } from "./topology-registers";import { recordTransition } from "./record-transition";export function nextIntentionUid(bind: BindHandle): string {const bank = bind.region.rdv.get(bind.bindId);if (!bank) throw new Error(`Rendezvous bank missing for bind '${bind.bindId}'.`);bank.intentCtr += 1;↑ the counter moves onconst uid = `${bind.bindId}#${bank.intentCtr}`;↑ the name: the doer's name and the countrecordTransition(bind.file, `topology:${bind.region.regionId}/bind:${bind.bindId}`, "INTENT.CTR", "mint-uid", {↑ the change is written into the journaluid});return uid;}
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)
61The request enters the log as #14LOG · append
a wave is settlingengine: working on #12membrane: waiting at #2
The log - #0a listener
- #1a doer
- #2listener: the charter
- #3doer: the author
- #4listener: charter seen
- #5listener: blueprint seen
- #6doer: the planner
- #7listener: assess · charter
- #8listener: assess · result
- #9doer: the evaluator
- #10the charter wanted
- #11the blueprint
- #12readiness
- #13readiness
- #14a request: a charternew
- end of the log
The log What before after records in the log 14 15 #14 — a request: a charter · service.requestThe author has no local action, so to act is to ask: its request — write the charter of the figure to admit — is written as #14, to be answered as
charter.proposed.Where it happens
appendEmissions()Vol. 02 §4.1 · Vol. 03 §1The 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()incore/registers/append-emissions.ts, line 14: the new record gets the next free number- Journal
- #12 ·
LOG · append· offset: 14, kind: domain.fact · by engine - Picture
- records in the log: 14 → 15
core/registers/append-emissions.ts· build 043cc8b// The one LOG writer (Vol. 02 §4.1, Vol. 03 §1): emissions become tuples by// receiving the next dense absolute offset — `base + window.length` — and// nothing else ever grows the log. Each append is journalled under the// ambient context, so a batch born of a propagated tuple carries that// tuple's offset as its cause — the cube's provenance line (ADR-002).import type { WaveEmission, WaveTuple } from "../wave/gate";import type { RegisterFile } from "./register-file";import { recordTransition } from "./record-transition";export function appendEmissions(file: RegisterFile, emissions: readonly WaveEmission[]): void {const engine = file.registers.engine;for (const emission of emissions) {const tuple: WaveTuple = { ...emission, offset: engine.base + engine.window.length };↑ the new record gets the next free numberengine.window.push(tuple);↑ it is added at the end of the logrecordTransition(file, "engine", "LOG", "append", {↑ the change is written into the journaloffset: tuple.offset,kind: tuple.kind});}}
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 #12
78The membrane passes #12MEMBRANE.CURSOR · sweep
a wave is settlingengine: at the endmembrane: passing #12
The log - #0a listener
- #1a doer
- #2listener: the charter
- #3doer: the author
- #4listener: charter seen
- #5listener: blueprint seen
- #6doer: the planner
- #7listener: assess · charter
- #8listener: assess · result
- #9doer: the evaluator
- #10the charter wanted
- #11the blueprint
- #12readiness
- #13readiness
- #14a request: a charter
- end of the log
The membrane What before after pointer — the next record to pass #12 #13 #12 asks nothing of the world, so the membrane's pointer simply moves on.
Where it happens
sweepNextTuple()Vol. 02 §4.6 · Vol. 07 §3The 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()incore/registers/sweep-next-tuple.ts, line 16: the membrane's pointer moves on by one- Journal
- #12 ·
MEMBRANE.CURSOR · sweep· offset: 12 · by membrane - Picture
- pointer — the next record to pass: #12 → #13
core/registers/sweep-next-tuple.ts· build 043cc8b// MEMBRANE.CURSOR advance (Vol. 02 §4.6, Vol. 07 §3): the membrane's own// reading of the one log — the second reception of one publication, never a// second truth. The cursor advances exactly once per offset per machine:// the exactly-once discharge guarantee lives in this movement.import type { WaveTuple } from "../wave/gate";import type { RegisterFile } from "./register-file";import { recordTransition } from "./record-transition";import { setDriver, setWaveContext } from "./set-wave-context";export function sweepNextTuple(file: RegisterFile): WaveTuple | null {const engine = file.registers.engine;const membrane = file.registers.membrane;if (membrane.cursor >= engine.base + engine.window.length) return null;const tuple = engine.window[membrane.cursor - engine.base];membrane.cursor += 1;↑ the membrane's pointer moves on by onesetWaveContext(file, { offset: tuple.offset, phase: "sweep" });setDriver(file, "membrane");recordTransition(file, "membrane", "MEMBRANE.CURSOR", "sweep", { offset: tuple.offset });↑ the change is written into the journalreturn tuple;}
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.
#12sys.knot.ready the machine
| envelope | |
|---|---|
offset | 12Its 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. |
kind | sys.knot.readyWhich of the four kinds of record the machine knows. The kind decides what the payload holds. |
key | fragment-one-cellThe lane of the fact that made the listener ready. |
| payload | |
knotId | admit.note.gate--l1.seeking.charter.gateThe listener that is ready. |
| payload.understanding | |
wanted | charterWhat the charter gate understood: the charter wanted. |
end · #12
In the specificationVol. 03 §1Vol. 03 §2Vol. 03 §5Vol. 04 §2.3
Names it shares with other records
admit.note.gate--l1.seeking.charter.gate— also on #2 listener: the charter
The record as the machine keeps it
{
"offset": 12,
"kind": "sys.knot.ready",
"key": "fragment-one-cell",
"payload": {
"knotId": "admit.note.gate--l1.seeking.charter.gate",
"understanding": {
"wanted": {
"charter": {
"title": "Seeking",
"purpose": "What are we seeking to understand, and for whom does it matter?",
"question": "What is a Cell, and why does the machine open one instead of answering in place?",
"criteria": [
{
"id": "q1",
"question": "What is this material about, and what exactly are we seeking to understand in it?",
"weight": 1,
"minimum": 0.6
},
{
"id": "q2",
"question": "Whose problem does it address, and why does it exist?",
"weight": 1,
"minimum": 0.6
}
]
}
}
}
}
}