Wave 4 · The assessment · record #33domain.factservice.request
#33 · the assessment request crosses
CellSpace indexes it; the membrane hands it to the admission's controller; the proposal enters the log as #34.
Came fromthe machineThe machine wrote it while the engine took #32: the evaluator acted — and its act is a request. step 180
when the engine took #33
181The engine takes #33ENGINE.CURSOR · propagate
a wave is settlingengine: working on #33membrane: waiting at #28
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 doer
- #27the return address
- #28the person's words
- #29readiness
- #30the private result
- #31the result, marked
- #32readiness
- #33a request: assess
- end of the log
The engine What before after pointer — the next record to take #33 #34 The engine moves on to #33 — the evaluator's request.
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
- #33 ·
ENGINE.CURSOR · propagate· offset: 33 · by engine - Picture
- pointer — the next record to take: #33 → #34
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)
182The request is indexed under its nameREQUESTS · index-request
a wave is settlingengine: working on #33membrane: waiting at #28
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 doer
- #27the return address
- #28the person's words
- #29readiness
- #30the private result
- #31the result, marked
- #32readiness
- #33a request: assess
- end of the log
CellSpace What before after requests admit.note.gate--l1.seeking.charter.author#1,admit.note.gate--l1.seeking.planner#1admit.note.gate--l1.seeking.charter.author#1,admit.note.gate--l1.seeking.planner#1,admit.note.gate--l1.seeking.evaluator#1CellSpace keeps the evaluator's request under its intention's name, so that the assessment that comes back finds its doer.
Where it happens
indexCausalRequest()Vol. 12 §5.1Indexes a request the moment it is written, under its intention's name — so that whatever answers it later finds the doer it belongs to.
- Specification
- Vol. 12 §5.1
- Code
indexCausalRequest()incore/registers/index-causal-request.ts, line 12: the request is kept under its name- Journal
- #33 ·
REQUESTS · index-request· uid: admit.note.gate--l1.seeking.evaluator#1, bindId: admit.note.gate--l1.seeking.evaluator · by cellspace - Picture
- requests:
admit.note.gate--l1.seeking.charter.author#1,admit.note.gate--l1.seeking.planner#1→admit.note.gate--l1.seeking.charter.author#1,admit.note.gate--l1.seeking.planner#1,admit.note.gate--l1.seeking.evaluator#1
core/registers/index-causal-request.ts· build 043cc8b// REQUESTS write (Vol. 12 §5.1): every committed service intention is// indexed by uid so later proposals prove their causal authority against a// real, unconsumed, same-key request — admission is an act, not a lookup// (KEY_ARCHITECTURE §5).import type { CausalRequest } from "../cells/gate";import type { RegisterFile } from "./register-file";import { cellsRegion } from "./cells-region";import { recordTransition } from "./record-transition";export function indexCausalRequest(file: RegisterFile, request: CausalRequest): void {cellsRegion(file).requests.set(request.uid, request);↑ the request is kept under its namerecordTransition(file, "cellspace", "REQUESTS", "index-request", {↑ the change is written into the journaluid: request.uid,bindId: request.bindId});}
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 #33
188The membrane passes #33MEMBRANE.CURSOR · sweep
a wave is settlingengine: at the endmembrane: passing #33
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 doer
- #27the return address
- #28the person's words
- #29readiness
- #30the private result
- #31the result, marked
- #32readiness
- #33a request: assess
- end of the log
The membrane What before after pointer — the next record to pass #33 #34 #33 is a request: the membrane's pointer moves past it, and the membrane looks for someone in the world who will take it.
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
- #33 ·
MEMBRANE.CURSOR · sweep· offset: 33 · by membrane - Picture
- pointer — the next record to pass: #33 → #34
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)
189The request is handed to the worldDISCHARGE.TABLE · track-discharge
a wave is settlingengine: at the endmembrane: passing #33
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 doer
- #27the return address
- #28the person's words
- #29readiness
- #30the private result
- #31the result, marked
- #32readiness
- #33a request: assess
- end of the log
The runtime No register changed its value.
Admission's controller claims #33 by its shape; the runtime notes the hand-out as discharge 1 — the count starts again with every wave — and waits.
Where it happens
trackDischarge()Vol. 02 §4.6 · Vol. 08 §3Notes, at the membrane, that a record has been handed to the world, and keeps it among those the machine still waits on.
- Specification
- Vol. 02 §4.6 · Vol. 08 §3
- Code
trackDischarge()incore/registers/track-discharge.ts, line 19: the hand-out gets the next number- Journal
- #33 ·
DISCHARGE.TABLE · track-discharge· id: 1, controller: controller.ceremony.local, offset: 33 · by runtime - Picture
- no register changed its value
core/registers/track-discharge.ts· build 043cc8b// DISCHARGE.TABLE entry (Vol. 02 §4.6, Vol. 08 §3): an in-flight discharge// joins the table under a fresh slot id. The defect path is part of the// entry's own movement: a rejected discharge leaves the table as the// rejection propagates, so the machine stays usable for the next wave// (refimpl 06 §1; host ADR-011 finding 2).import type { WaveEmission } from "../wave/gate";import type { RegisterFile } from "./register-file";import { recordTransition } from "./record-transition";import { setDriver, setWaveContext } from "./set-wave-context";export function trackDischarge(file: RegisterFile,claim: { controller: string; offset: number },discharge: Promise<readonly WaveEmission[]>): void {setWaveContext(file, { offset: claim.offset, phase: "sweep" }); // attribute to the claimed tuplesetDriver(file, "runtime");file.ephemeral.nextDischargeId += 1;↑ the hand-out gets the next numberconst id = file.ephemeral.nextDischargeId;file.ephemeral.inFlight.set(↑ it is kept among those still out in the worldid,discharge.then((emissions) => ({ id, controller: claim.controller, offset: claim.offset, emissions }),(defect: unknown) => {file.ephemeral.inFlight.delete(id);recordTransition(file, "runtime", "DISCHARGE.TABLE", "discharge-defect", { id, ...claim });↑ the change is written into the journalthrow defect;}));recordTransition(file, "runtime", "DISCHARGE.TABLE", "track-discharge", { id, ...claim });↑ the change is written into the journal}
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)
when the world answered
190The world answersDISCHARGE.TABLE · resolve-discharge
a wave is settlingengine: at the endmembrane: passing #33
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 doer
- #27the return address
- #28the person's words
- #29readiness
- #30the private result
- #31the result, marked
- #32readiness
- #33a request: assess
- end of the log
The runtime No register changed its value.
The controller returns one answer — a proposed assessment: for each criterion a grade, a reason, and the result's place in the log as evidence. The discharge closes.
Where it happens
resolveDischarge()Vol. 08 §3 · Vol. 03 §3.3Notes that the world has answered: the hand-out is closed, and what came back is ready to enter the log.
- Specification
- Vol. 08 §3 · Vol. 03 §3.3
- Code
resolveDischarge()incore/registers/resolve-discharge.ts, line 14: no longer waiting on the world- Journal
- #33 ·
DISCHARGE.TABLE · resolve-discharge· id: 1, emissions: 1, controller: controller.ceremony.local, offset: 33 · by runtime - Picture
- no register changed its value
core/registers/resolve-discharge.ts· build 043cc8b// DISCHARGE.TABLE settlement (Vol. 08 §3): the earliest completed discharge// leaves the table and its answers re-enter the wave as the next run's// seeds. Earliest completion wins; consumers rely on correlation, never// adjacency (Vol. 03 §3.3).import type { RegisterFile } from "./register-file";import { recordTransition } from "./record-transition";// The resolution names the claim it answers (controller · the swept tuple)// and is journaled under THAT tuple's wave context, so the tuple's own// journal states which discharge answered it (ADR-004 d17); the answer's// emissions are then appended under the same attribution.export function resolveDischarge(file: RegisterFile, id: number, emissionCount: number, claim?: { controller: string; offset: number }): void {file.ephemeral.inFlight.delete(id);↑ no longer waiting on the worldrecordTransition(file, "runtime", "DISCHARGE.TABLE", "resolve-discharge", { id, emissions: emissionCount, ...(claim ?? {}) });↑ the change is written into the journal}
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 de79653 (2026-09-11)
191The answer enters the log as #34LOG · append
a wave is settlingengine: next: #34membrane: waiting at #34
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 doer
- #27the return address
- #28the person's words
- #29readiness
- #30the private result
- #31the result, marked
- #32readiness
- #33a request: assess
- #34assessment proposednew
- end of the log
The log What before after records in the log 34 35 #34 — assessment proposed · cell.assessment.proposedThe proposal is written at the end of the log as #34 — attributed to the controller. It is a proposal, nothing more.
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
- #33 ·
LOG · append· offset: 34, kind: domain.fact · by engine - Picture
- records in the log: 34 → 35
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)
Step 191: The answer enters the log as #34
191 The answer enters the log as #34
a wave is settlingengine: next: #34membrane: waiting at #34
- #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 doer
- #27the return address
- #28the person's words
- #29readiness
- #30the private result
- #31the result, marked
- #32readiness
- #33a request: assess
- #34assessment proposednew
- end of the log
| What | before | after |
|---|---|---|
| records in the log | 34 | 35 |
| #34 | — | assessment proposed · cell.assessment.proposed |
The proposal is written at the end of the log as #34 — attributed to the controller. It is a proposal, nothing more.
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()incore/registers/append-emissions.ts, line 14: the new record gets the next free number- Journal
- #33 ·
LOG · append· offset: 34, kind: domain.fact · by engine - Picture
- records in the log: 34 → 35
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)
A fact: a request to the world
What a doer writes when it needs the world — complete in itself: what to do, about what, in which shape the answer must come, and as what. Admission makes three: write the charter, build the Cell's package, assess its result.
#33domain.factservice.request the machine
| envelope | |
|---|---|
offset | 33Its 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 | domain.factWhich of the four kinds of record the machine knows. The kind decides what the payload holds. |
key | fragment-one-cellThe lane it is asked on; the answer comes back on the same lane. |
| payload | |
factType | service.requestThe fact type, service.request — the shape a controller claims. |
| payload.data | |
bindId | admit.note.gate--l1.seeking.evaluatorThe doer that asks. |
uid | admit.note.gate--l1.seeking.evaluator#1The intention's name: the doer's name and a number. The answer must carry it back. |
instruction | «Assess the result against the charter.»What the world is asked to do. |
scope | charter · resultWhat it is about: the doer's scope when it acted — the charter wanted; the charter and the blueprint; or the charter and the result. |
schema | typeThe shape the answer must have. |
| payload.data.emit | |
writes | cell.assessment.proposedThe type the answer will be written as. |
end · #33
In the specificationVol. 03 §1Vol. 03 §4Vol. 03 §5Vol. 04 §5.1Vol. 06 §3Vol. 07 §4.2Vol. 12 §3
Names it shares with other records
admit.note.gate--l1.seeking.evaluator— also on #9 doer: the evaluator, #34 assessment proposedadmit.note.gate--l1.seeking.evaluator#1— also on #34 assessment proposed
The record as the machine keeps it
{
"offset": 33,
"kind": "domain.fact",
"key": "fragment-one-cell",
"payload": {
"factType": "service.request",
"data": {
"bindId": "admit.note.gate--l1.seeking.evaluator",
"uid": "admit.note.gate--l1.seeking.evaluator#1",
"instruction": "Assess the result against the charter.",
"scope": {
"charter": {
"definition": {
"ref": "charter@15",
"digest": "sha256:d697d7f3224e3a44a0888949eb98ee5ecf54aa09b2fc4aba2addca763458ec1b",
"value": {
"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
}
]
}
}
},
"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"
}
}
}
},
"schema": {
"type": "object"
},
"emit": {
"writes": "cell.assessment.proposed"
}
}
}
}