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

138Record #26 enters the logLOG · append
a wave is settlingengine: next: #25membrane: waiting at #25
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
#15the charter proposed
#16the charter defined
#17readiness
#18readiness
#19a request: a Cell
#20the seed
#21the Cell is open
#22inner listener
#23inner doer
#24the Cell's context
#25return listenerenginemembrane
#26return doernew
end of the log
The log
What before after
records in the log 26 27
#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
// 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 number
engine.window.push(tuple);↑ it is added at the end of the log
recordTransition(file, "engine", "LOG", "append", {↑ the change is written into the journal
offset: 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)

What	before		after
records in the log	26	→	27
#26	—	→	return doer · `sys.descriptor.defined`

when the engine took #26

143The engine takes #26ENGINE.CURSOR · propagate
a wave is settlingengine: working on #26membrane: waiting at #25
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
#15the charter proposed
#16the charter defined
#17readiness
#18readiness
#19a request: a Cell
#20the seed
#21the Cell is open
#22inner listener
#23inner doer
#24the Cell's context
#25return listenermembrane
#26return doerengine · working
#27the return address
end of the log
The engine
What before after
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
// 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 stops
const tuple = engine.window[engine.cursor - engine.base];
engine.cursor += 1;↑ the engine's pointer moves on by one
setWaveContext(file, { offset: tuple.offset, phase: "propagate" });
setDriver(file, "engine");
recordTransition(file, "engine", "ENGINE.CURSOR", "propagate", { offset: tuple.offset });↑ the change is written into the journal
return 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)
144The return doer is added to the figureBIND.DEFS · register-descriptor
a wave is settlingengine: working on #26membrane: waiting at #25
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
#15the charter proposed
#16the charter defined
#17readiness
#18readiness
#19a request: a Cell
#20the seed
#21the Cell is open
#22inner listener
#23inner doer
#24the Cell's context
#25return listenermembrane
#26return doerengine · working
#27the return address
end of the log
The figure
What before after
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
// BIND.DEFS and DISPATCH write (Vol. 02 §4.2): the registration payload
// lands as data; the dispatch table indexes the descriptor id under every
// declared interest (the activation knot plus every demand for an operator
// bind, the one subscription for an emit descriptor). Duplicate-id rejection
// is the station's verdict (ADR-011 finding 3) — this op only records an
// accepted registration.

import type { DescriptorDefinedPayload } from "../topology/gate";
import type { TopologyRegisters } from "./topology-registers";
import type { RegisterFile } from "./register-file";
import { recordTransition } from "./record-transition";

export function registerDescriptorDefinition(
file: RegisterFile,
region: TopologyRegisters,
payload: DescriptorDefinedPayload,
interests: readonly string[]
): void {
region.bindDefs.set(payload.id, payload);↑ the description is stored under its name
for (const interest of interests) {
const list = region.dispatch.get(interest);
if (list) list.push(payload.id);
else region.dispatch.set(interest, [payload.id]);↑ listed under the listener it waits for
}
recordTransition(file, `topology:${region.regionId}`, "BIND.DEFS", "register-descriptor", {↑ the change is written into the journal
id: payload.id,
interests
});
}
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)

What	before		after
pointer — the next record to take	#26	→	#27

What	before		after
doer `return.cell-20`	—	→	on `return.cell-20.gate`: writes `represent.requested`
when `return.cell-20.gate` is ready, it wakes	—	→	`return.cell-20`

when the membrane passed #26

149The membrane passes #26MEMBRANE.CURSOR · sweep
a wave is settlingengine: at the endmembrane: passing #26
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
#15the charter proposed
#16the charter defined
#17readiness
#18readiness
#19a request: a Cell
#20the seed
#21the Cell is open
#22inner listener
#23inner doer
#24the Cell's context
#25return listener
#26return doermembrane · passing
#27the return address
end of the logengine
The membrane
What before after
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
// 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 one
setWaveContext(file, { offset: tuple.offset, phase: "sweep" });
setDriver(file, "membrane");
recordTransition(file, "membrane", "MEMBRANE.CURSOR", "sweep", { offset: tuple.offset });↑ the change is written into the journal
return 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)

What	before		after
pointer — the next record to pass	#26	→	#27

Choose a step in the stack — or press →.

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
`offset`	`26`Its 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.descriptor.defined`Which 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
`id`	`return.cell-20`The doer's name, unique in the machine.
`subscribesTo`	`return.cell-20.gate`For the simplest sort of doer: the listener whose readiness makes it write — no rendezvous, no scope.
payload.actionConfig
`writes`	`represent.requested`The 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"
  }
 }
}