Reading aids · CoAgnes Lab
The machine in figures The Lab's drawings of the Nest runtime, gathered in the set's reading order — the log, the stations, the membrane, the settle loop, the formats and the extensions — each beside the section of the set that governs it.
They are reading aids, drawn by CoAgnes Lab from the volumes' text and marked as such; where a figure and its section could be read differently, the section governs. On a phone every figure is drawn upright, top to bottom. Each also stands on its volume's page, after the section it draws.
00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 Lab fig. 00·1 Eight stations along one line from left to right: the map (00), orientation 01 to 03, the reference 04 to 07, the machine 08, authoring 09 and 10, growth 11 to 13, conformance 14, vocabulary 15. Under growth: 11 current and declared, 12 proposed, 13 seed. Under the reference and the machine runs a dashed band: the refimpl book, chapters 01 to 07 beside the volumes, and 08 on shells. The map 00 Orientation 01 02 03 Reference 04 05 06 07 The machine 08 Authoring 09 10 Growth 11 12 13 11 current · declared 12 proposed 13 seed Conformance 14 Vocabulary 15 the refimpl book: 01–07 beside the volumes · 08 sketches shells Lab fig. 00·1 Eight stations along one line from left to right: the map (00), orientation 01 to 03, the reference 04 to 07, the machine 08, authoring 09 and 10, growth 11 to 13, conformance 14, vocabulary 15. Under growth: 11 current and declared, 12 proposed, 13 seed. Under the reference and the machine runs a dashed band: the refimpl book, chapters 01 to 07 beside the volumes, and 08 on shells. The map 00 Orientation 01 02 03 Reference 04 05 06 07 The machine 08 Authoring 09 10 Growth 11 12 13 11 current · declared 12 proposed 13 seed Conformance 14 Vocabulary 15 the refimpl book beside: 01–07; 08 sketches shells Lab fig. 00·1 The set in its reading order: the map, then orientation, the reference an implementer keeps open, what a machine must do, how to write for it, where it grows, what conforming means, and the vocabulary — with the reference-implementation book read beside the reference, and each volume's status where it is not CURRENT. A reading aid by CoAgnes Lab; §2.3 governs. Lab fig. 01·1 A circle with a triangle inscribed. The top vertex is the topology — knots, binds and controller claims. From it one edge descends to the inner return at the lower left and one to the outer return at the lower right. A short curve closes the inner return on the wave log at the bottom; a wide curve, passing outside the circle through the world, closes the outer return on the same log. Topology knots · binds · controller claims re-authored from below declared outward claims Inner return emissions committed and wound into further understanding — quiescence scale The wave log one append-only truth Outer return intentions discharged, computed by the world, re-entering as facts — world scale The machine The world The membrane controller the world computes Lab fig. 01·1 A circle with a triangle inscribed. The top vertex is the topology — knots, binds and controller claims. From it one edge descends to the inner return at the lower left and one to the outer return at the lower right. A short curve closes the inner return on the wave log at the bottom; a wide curve, passing outside the circle through the world, closes the outer return on the same log. Topology knots · binds · controller claims re-authored from below declared outward claims inner outer The wave log one append-only truth The machine The membrane The world controller the world computes Inner return emissions committed and wound into further understanding — quiescence scale Outer return intentions discharged, computed by the world, re-entering as facts — world scale Lab fig. 01·1 The machine's figure, redrawn: the topology at the top directs both descents and is itself re-authored from below; the inner return closes at quiescence scale, the outer return at world scale — two radii, one kind: both are returns to the log. A reading aid by CoAgnes Lab; §3 governs. Lab fig. 01·2 A row of records, the log, across the middle. Above it an activation knot takes a matching fact from the log and writes its readiness back; a bind descriptor takes that readiness and writes an integration back. Below it a controller standing on the membrane takes a tuple it claims, discharges it once to the world, and the world's answer returns to the end of the log as a fact. At the top right an observer reads the log along dotted lines and writes nothing. Activation knot winds · reports readiness Bind descriptor gathers · judges · publishes #0 #1 #2 #3 #4 #5 #6 #7 #8 The log matching facts readiness integration a tuple it claims The machine The world Output controller discharged exactly once the world computes the answer, as facts observer reads everything; emits nothing that changes behaviour Lab fig. 01·2 A row of records, the log, across the middle. Above it an activation knot takes a matching fact from the log and writes its readiness back; a bind descriptor takes that readiness and writes an integration back. Below it a controller standing on the membrane takes a tuple it claims, discharges it once to the world, and the world's answer returns to the end of the log as a fact. At the top right an observer reads the log along dotted lines and writes nothing. The log #0 #1 #2 #3 #4 #5 #6 #7 #8 observer reads everything; emits nothing that changes behaviour Activation knot winds · reports readiness Bind descriptor gathers · judges · publishes a tuple it claims Output controller The world discharged exactly once the world computes the answer, as facts Lab fig. 01·2 Three stations receive committed tuples, each with one competence: a knot winds the facts it matches and reports readiness; a bind, woken by that readiness, gathers its scope, judges it and publishes an integration; a controller discharges what it claims to the world exactly once and returns the answer as facts. An observer may read everything and emits nothing that changes behaviour. A reading aid by CoAgnes Lab; §4 governs. Lab fig. 02·1 A row of numbered records — the log — with two pointers above it, MEMBRANE.CURSOR two records behind ENGINE.CURSOR, and the runtime's registers DISCHARGE.TABLE and SETTLING. Then the topology's four: KNOT.DEFS, CLEWS[k], BIND.DEFS, DISPATCH. Under CLEWS[k], three clews for keys null, a and b; clew a opens onto six registers — SLOTS, STATE, GRADE, DELTAQ, INFLIGHT.UID, WIND.CTR — with COLLECTED beneath for a deterministic knot. Under BIND.DEFS, an operator bind with lanes RDV[a] and RDV[b], each holding ACTIVATED, SCOPE and PROJECTED, and one INTENT.CTR shared by both. The architectural register file — one machine instance The log and its two cursors §4.1 · §4.6 #0 #1 #2 #3 #4 #5 #6 MEMBRANE.CURSOR ENGINE.CURSOR LOG grows only at the tail; the two cursors are independent Runtime §4.6 DISCHARGE.TABLE SETTLING discharges in flight one settling wave at a time Topology §4.2 knot-id → {factory, config} KNOT.DEFS knot-id → key → clew CLEWS[k] descriptor-id → executor BIND.DEFS knot-id → descriptors DISPATCH one clew per key null a b clew a — semantic knot · §4.3 SLOTS STATE GRADE DELTAQ INFLIGHT.UID WIND.CTR COLLECTED deterministic knot · §4.4 a clew's registers reset at readiness under on_ready; under never, none clears one rendezvous per key lane · §4.5 RDV[a] ACTIVATED SCOPE PROJECTED RDV[b] ACTIVATED SCOPE PROJECTED INTENT.CTR shared across lanes No register is programme-addressable: a programme observes machine state only through committed tuples. Lab fig. 02·1 A row of numbered records — the log — with two pointers above it, MEMBRANE.CURSOR two records behind ENGINE.CURSOR, and the runtime's registers DISCHARGE.TABLE and SETTLING. Then the topology's four: KNOT.DEFS, CLEWS[k], BIND.DEFS, DISPATCH. Under CLEWS[k], three clews for keys null, a and b; clew a opens onto six registers — SLOTS, STATE, GRADE, DELTAQ, INFLIGHT.UID, WIND.CTR — with COLLECTED beneath for a deterministic knot. Under BIND.DEFS, an operator bind with lanes RDV[a] and RDV[b], each holding ACTIVATED, SCOPE and PROJECTED, and one INTENT.CTR shared by both. The architectural register file Log · two cursors §4.1 · §4.6 #0 #1 #2 #3 #4 MEMBRANE.CURSOR ENGINE.CURSOR LOG grows only at the tail; the two cursors are independent Runtime §4.6 DISCHARGE.TABLE SETTLING discharges in flight one settling wave at a time Topology §4.2 KNOT.DEFS knot-id → {factory, config} CLEWS[k] knot-id → key → clew BIND.DEFS descriptor-id → executor DISPATCH knot-id → descriptors Per clew in CLEWS[k] · §4.3 · §4.4 one clew per key: null a b clew a — semantic knot · §4.3 SLOTS STATE GRADE DELTAQ INFLIGHT.UID WIND.CTR COLLECTED deterministic knot · §4.4 a clew's registers reset at readiness under on_ready; under never, none clears Per operator bind in BIND.DEFS · §4.5 one rendezvous per key lane RDV[a] ACTIVATED SCOPE PROJECTED RDV[b] ACTIVATED SCOPE PROJECTED INTENT.CTR shared across lanes No register is programme-addressable: a programme observes machine state only through committed tuples. Lab fig. 02·1 The complete mutable state of one machine between tuples, by owner: the log and its two independent cursors; the runtime's in-flight discharges and its re-entrancy latch; the topology's four maps; one register bank per clew — per knot and key — and, for an operator bind, one rendezvous per key lane, with the service-uid sequence INTENT.CTR shared across its lanes. None of it is programme-addressable: a programme observes machine state only through committed tuples. A reading aid by CoAgnes Lab; §4 governs. Lab fig. 02·2 Five records of the log, each with its kind and, beneath it, what the topology does with it: #0 sys.knot.defined registers knot k and its null-key probe clew; #1 sys.descriptor.defined constructs bind b and indexes its interests in DISPATCH; #2 domain.fact on key a reaches the clew for key a, which winds it and turns ready, and an arrow marked committed leads to #3 sys.knot.ready on key a; #3 wakes b, and an arrow from b leads to #4, its emissions, appended. Kind dispatch — tuple by tuple, in log order sys.knot.defined sys.descriptor.defined domain.fact · key a sys.knot.ready · key a emissions #0 #1 #2 #3 #4 KNOT.DEFS null register knot definition; create null-key probe clew b DISPATCH construct executor; index interests in DISPATCH CLEWS[k][a] created lazily matches → wind; test → ready: emit sys.knot.ready, snapshot before reset committed b execute every descriptor in DISPATCH[k] with {knotId, key, understanding} appended records before facts: a fact committed before its knot's registration is not delivered retroactively descriptors are activated by the committed readiness tuple, never synchronously Lab fig. 02·2 Five records of the log, each with its kind and, beneath it, what the topology does with it: #0 sys.knot.defined registers knot k and its null-key probe clew; #1 sys.descriptor.defined constructs bind b and indexes its interests in DISPATCH; #2 domain.fact on key a reaches the clew for key a, which winds it and turns ready, and an arrow marked committed leads to #3 sys.knot.ready on key a; #3 wakes b, and an arrow from b leads to #4, its emissions, appended. Kind dispatch, in log order #0 sys.knot.defined register knot definition; create null-key probe clew #1 sys.descriptor.defined construct executor; index interests in DISPATCH #2 domain.fact · key a clew CLEWS[k][a], created lazily matches → wind; test → ready: emit sys.knot.ready — snapshot before reset committed #3 sys.knot.ready · key a execute every descriptor in DISPATCH[k] with {knotId, key, understanding} #4 emissions, appended records before facts: a fact committed before its knot's registration is not delivered retroactively descriptors are activated by the committed readiness tuple, never synchronously Lab fig. 02·2 Kind dispatch along a short log. The records come first — knot k, then bind b — and the fact on key a reaches the clew CLEWS[k][a], created lazily, which winds it and becomes ready; the topology commits that readiness as sys.knot.ready on the same key, with the understanding snapshot taken before reset. Only when that tuple is dispatched is b executed: the log records the full activation chain. A reading aid by CoAgnes Lab; §5 governs. Lab fig. 03·1 A strip of numbered records from #3 to #8. Records #4, inference.request, and #8, inference.response, each carry a gold stamp with the uid k#1, and a dashed bracket above the strip joins them; #5 to #7 between them are bracketed as unrelated tuples. From #4 an arrow runs down to a controller on the membrane and on to an asynchronous discharge in the world; the answer climbs back across the membrane into #8, a seed of a later engine run. The log — totally ordered by offset the same winding uid, k#1, in both payloads — a happens-before edge #3 #4 inference.request k#1 #5 #6 #7 #8 inference.response k#1 unrelated tuples MAY appear between The machine The world The membrane controller asynchronous discharge the answer re-enters as a seed of a later engine run causality is carried in payloads, not in envelope fields — consumers MUST rely on happens-before edges, never on adjacency Lab fig. 03·1 A strip of numbered records from #3 to #8. Records #4, inference.request, and #8, inference.response, each carry a gold stamp with the uid k#1, and a dashed bracket above the strip joins them; #5 to #7 between them are bracketed as unrelated tuples. From #4 an arrow runs down to a controller on the membrane and on to an asynchronous discharge in the world; the answer climbs back across the membrane into #8, a seed of a later engine run. The log totally ordered by offset #3 #4 inference.request k#1 #5 #6 #7 #8 inference.response k#1 unrelated tuples MAY appear between k#1 in both payloads — a happens-before edge The machine The world controller asynchronous discharge the answer re-enters as a seed of a later engine run causality is carried in payloads, not in envelope fields — consumers MUST rely on happens-before edges, never on adjacency Lab fig. 03·1 Cause and answer on one log: a winding intention committed at #4 is discharged asynchronously, and its answer re-enters as a seed of a later engine run, at #8, with unrelated tuples between. What joins the two is not their position but the same winding uid in both payloads — consumers MUST rely on happens-before edges, never on adjacency. A reading aid by CoAgnes Lab; §3 governs. Lab fig. 03·2 A strip of six numbered records, each showing its key: #0 null, #1 nest-1, #2 nest-2, #3 nest-2, #4 nest-1, #5 nest-1; #0 is marked sys.knot.defined, lane-less and machine-wide. On one side of the strip a ring, the clew for key nest-1, winds #1 and #4 and writes its readiness back as #5, sys.knot.ready, on the key of the fact that completed the clew. On the other side a second ring, the clew for key nest-2, winds #2 and #3. Knot k — one clew per key The log #0 null #1 nest-1 #2 nest-2 #3 nest-2 #4 nest-1 #5 nest-1 sys.knot.defined lane-less, machine-wide clew — key nest-1 readiness sys.knot.ready on the key of the fact that completed the clew clew — key nest-2 the key partitions winding without partitioning the log a shell chooses keys at ingress — opaque to the machine, no format imposed Lab fig. 03·2 A strip of six numbered records, each showing its key: #0 null, #1 nest-1, #2 nest-2, #3 nest-2, #4 nest-1, #5 nest-1; #0 is marked sys.knot.defined, lane-less and machine-wide. On one side of the strip a ring, the clew for key nest-1, winds #1 and #4 and writes its readiness back as #5, sys.knot.ready, on the key of the fact that completed the clew. On the other side a second ring, the clew for key nest-2, winds #2 and #3. Knot k — one clew per key The log #0 null #1 nest-1 #2 nest-2 #3 nest-2 #4 nest-1 #5 nest-1 sys.knot.defined lane-less, machine-wide clew — nest-1 readiness sys.knot.ready, on the key of the fact that completed the clew clew — nest-2 the key partitions winding without partitioning the log; a shell chooses keys at ingress — opaque to the machine, no format imposed Lab fig. 03·2 One log, two keys: facts on nest-1 and nest-2 interleave in a single offset order, while knot k winds one clew per key, so facts on parallel keys accumulate independent understanding. The readiness tuple carries the key of the fact that completed its clew; the registration at #0 is lane-less, with key null. A reading aid by CoAgnes Lab; §5 governs. Lab fig. 04·1 Two rows drawn in the same shape. Above, the winding protocol: a knot projects an inference.request stamped knotId and uid, on the clew's key; a controller claims it and answers with inference.response, inference.failed and inference.reasoning, each stamped with the same uid; a bracket marks the first two as exactly one terminal answer, and reasoning as never terminating. Below, the operator protocol: an operator bind, a service.request stamped bindId and uid on the activation key, a controller, and the delegated publication, service.failed and service.reasoning, marked the same way. The winding protocol inference.* semantic knot inference.request knotId uid: <knotId>#<n> key: the clew's key controller inference.response inference.failed inference.reasoning exactly one terminal never terminates The operator protocol service.* operator bind service.request bindId uid: <bindId>#<n> key: the activation key controller delegated publication service.failed service.reasoning exactly one terminal never terminates a correlation stamp — every answer carries the intention's uid Lab fig. 04·1 Two rows drawn in the same shape. Above, the winding protocol: a knot projects an inference.request stamped knotId and uid, on the clew's key; a controller claims it and answers with inference.response, inference.failed and inference.reasoning, each stamped with the same uid; a bracket marks the first two as exactly one terminal answer, and reasoning as never terminating. Below, the operator protocol: an operator bind, a service.request stamped bindId and uid on the activation key, a controller, and the delegated publication, service.failed and service.reasoning, marked the same way. The winding protocol inference.* semantic knot inference.request knotId uid: <knotId>#<n> key: the clew's key controller inference.response inference.failed inference.reasoning exactly one terminal never terminates The operator protocol service.* operator bind service.request bindId uid: <bindId>#<n> key: the activation key controller delegated publication service.failed service.reasoning exactly one terminal never terminates a correlation stamp: every answer carries the intention's uid Lab fig. 04·1 The two protocol families, drawn in one shape. A station mints an intention with its own uid — a semantic knot an inference.request, an operator bind a service.request; a controller claims it, and every answer carries that uid back. Exactly one answer terminates the uid — inference.response or inference.failed; the delegated publication or service.failed — and reasoning never does. A reading aid by CoAgnes Lab; §5 governs. Lab fig. 04·2 At the top, four record slabs for the envelope kinds, noted as taking new kinds only via core widening: sys.knot.defined, sys.descriptor.defined and sys.knot.ready, bracketed as reserved, the topology protocol, and domain.fact. From domain.fact a line leads down into a frame of its fact types: an open column (emit-descriptor publications, delegated publications, head facts, inputs) and a dashed reserved area — current bind.*, inference.* and service.*; proposed charter.*, cell.*, artefact.* and chat.* (Vol. 12); seed experience.*, evidence.*, system.*, claim.*, description.*, pipeline.*, library.* and learning.* (Vol. 13). A note: new protocol families are new namespaces here, not new kinds. Below the dashed membrane, a gold arrow of shell ingress rises from the world to the inputs line only. Envelope kinds new kinds only via core widening sys.knot.defined sys.descriptor.defined sys.knot.ready domain.fact sys.* — reserved: the topology protocol Fact types inside domain.fact, by factType Open emit-descriptor publications delegated publications head facts inputs (inputs[].writes) Reserved Current bind.* bind verdict facts inference.* the winding protocol service.* the operator protocol Proposed charter.* cell.* artefact.* chat.* Vol. 12 Seed experience.* evidence.* system.* claim.* description.* pipeline.* library.* learning.* Vol. 13 new protocol families: new namespaces here, not new kinds — those need a core widening The machine The world The membrane shell ingress declared input fact forms only — never a reserved namespace Lab fig. 04·2 At the top, four record slabs for the envelope kinds, noted as taking new kinds only via core widening: sys.knot.defined, sys.descriptor.defined and sys.knot.ready, bracketed as reserved, the topology protocol, and domain.fact. From domain.fact a line leads down into a frame of its fact types: an open column (emit-descriptor publications, delegated publications, head facts, inputs) and a dashed reserved area — current bind.*, inference.* and service.*; proposed charter.*, cell.*, artefact.* and chat.* (Vol. 12); seed experience.*, evidence.*, system.*, claim.*, description.*, pipeline.*, library.* and learning.* (Vol. 13). A note: new protocol families are new namespaces here, not new kinds. Below the dashed membrane, a gold arrow of shell ingress rises from the world to the inputs line only. Envelope kinds new kinds only via core widening sys.knot.defined sys.descriptor.defined sys.knot.ready domain.fact sys.* — reserved: the topology protocol Fact types inside domain.fact, by factType Reserved Current bind.* bind verdict facts inference.* the winding protocol service.* the operator protocol Proposed Vol. 12 charter.* cell.* artefact.* chat.* Seed Vol. 13 experience.* evidence.* system.* claim.* description.* pipeline.* library.* learning.* new protocol families: new namespaces here, not new kinds — those need a core widening Open emit-descriptor publications delegated publications · head facts inputs (inputs[].writes) The machine The world The membrane shell ingress declared input fact forms only — never a reserved namespace Lab fig. 04·2 The opcode map in two levels. The envelope kinds — the reserved sys.* kinds of the topology protocol, and domain.fact — admit new kinds only via core widening; inside domain.fact, the reserved factType namespaces, each with its status, stand beside the open fact types a pipeline declares. Shell ingress may commit only declared input fact forms, never a reserved namespace. A reading aid by CoAgnes Lab; §6 governs. Lab fig. 05·1 A row of four records: #0, the definition, then facts #1 on key a, #2 on key b and #3 on key a. Each passes down into a dashed band, the topology, which maintains one clew per definition and key. Below it three rings, each with its own box of registers: the null-key clew, constructed eagerly at registration, nothing wound yet; the clew of key a, created lazily at #1, winding #1 and #3; the clew of key b, created lazily at #2, winding #2. The log offset · key the definition #0 domain.fact #1 · a domain.fact #2 · b domain.fact #3 · a the topology maintains one clew per (definition, key) eagerly, at registration the null-key clew its registers nothing wound yet lazily, at #1 the clew of key a its registers winds #1 and #3 lazily, at #2 the clew of key b its registers winds #2 clews never share registers — parallel keys wind independent understanding Lab fig. 05·1 A row of four records: #0, the definition, then facts #1 on key a, #2 on key b and #3 on key a. Each passes down into a dashed band, the topology, which maintains one clew per definition and key. Below it three rings, each with its own box of registers: the null-key clew, constructed eagerly at registration, nothing wound yet; the clew of key a, created lazily at #1, winding #1 and #3; the clew of key b, created lazily at #2, winding #2. The log offset · key definition #0 domain.fact #1 · a domain.fact #2 · b domain.fact #3 · a the topology: one clew per (definition, key) the null-key clew eagerly, at registration nothing wound yet registers the clew of key a lazily, at #1 winds #1 and #3 registers the clew of key b lazily, at #2 winds #2 registers clews never share registers: parallel keys wind independent understanding Lab fig. 05·1 One definition, one clew per key. Registration constructs the null-key clew eagerly; the first domain.fact of a key creates that key's clew lazily. Clews never share registers: parallel keys wind independent understanding. A reading aid by CoAgnes Lab; §2 governs. Lab fig. 05·2 At the top a ring, the clew, with its registers in a row beneath it: DELTAQ, INFLIGHT.UID, WIND.CTR, STATE, GRADE. Accepted deltas flow into DELTAQ; a dotted arrow from GRADE points to a note that test() reads it. From DELTAQ an arrow leads down to an inference.request card — knotId and uid stamped, then questions, state: STATE, deltas, lane — which passes through a controller on a dashed line, the membrane, into the world. From the world an arrow returns across the membrane to an inference.response card with the same two stamps, then state, grade and lane, and from it up into GRADE. Between the two cards, the numbered steps of tact one and tact two. accepted deltas clew DELTAQ INFLIGHT.UID WIND.CTR STATE GRADE test() reads the freshly wound GRADE between tacts the clew is not ready inference.request knotId uid questions state: STATE deltas lane? inference.response knotId uid state grade lane? knotId · uid — the same two stamps Tact one — accept and project 1 push the deltas into DELTAQ 2 INFLIGHT.UID ≠ null → no emission 3 WIND.CTR ≥ declared budget → no emission 4 WIND.CTR += 1; INFLIGHT.UID ← uid; emit one inference.request Tact two — wind the integration 1 data.uid ≠ INFLIGHT.UID → ignore 2 STATE ← data.state; GRADE ← data.grade INFLIGHT.UID ← null 3 DELTAQ non-empty → the next intention The machine The world The membrane controller the world: an inference Lab fig. 05·2 At the top a ring, the clew, with its registers in a row beneath it: DELTAQ, INFLIGHT.UID, WIND.CTR, STATE, GRADE. Accepted deltas flow into DELTAQ; a dotted arrow from GRADE points to a note that test() reads it. From DELTAQ an arrow leads down to an inference.request card — knotId and uid stamped, then questions, state: STATE, deltas, lane — which passes through a controller on a dashed line, the membrane, into the world. From the world an arrow returns across the membrane to an inference.response card with the same two stamps, then state, grade and lane, and from it up into GRADE. Between the two cards, the numbered steps of tact one and tact two. accepted deltas clew DELTAQ INFLIGHT.UID WIND.CTR STATE GRADE inference.request knotId uid questions state: STATE deltas lane? inference.response knotId uid state grade lane? controller The membrane The world the world: an inference knotId · uid — the same two stamps Tact one — accept and project 1 push the deltas into DELTAQ 2 INFLIGHT.UID ≠ null → no emission 3 WIND.CTR ≥ declared budget → no emission 4 WIND.CTR += 1; INFLIGHT.UID ← uid; emit one inference.request Tact two — wind the integration 1 data.uid ≠ INFLIGHT.UID → ignore 2 STATE ← data.state; GRADE ← data.grade INFLIGHT.UID ← null 3 DELTAQ non-empty → the next intention test() reads the freshly wound GRADE; between tacts the clew is not ready Lab fig. 05·2 Winding through the world, in two tacts. Tact one pushes the accepted deltas into DELTAQ and — with no intention in flight and the budget permitting — projects one inference.request; tact two winds the inference.response whose uid matches INFLIGHT.UID into STATE and GRADE. Then test() reads the freshly wound GRADE: between tacts the clew is not ready. A reading aid by CoAgnes Lab; §5.2 governs. Lab fig. 06·1 Three knots on the left — A, the activation, and D1 and D2, the demands — send their readiness into a box for one key lane, RDV[k], where they fill the scope entries activation, d1 and d2; the box also shows ACTIVATED true and PROJECTED true. An arrow marked snapshot crosses a dashed barrier line, marked all and met by presence, not simultaneity, to a diamond: the gates, in declared order. From the diamond one arrow leads to a new service.request (bindId, uid, instruction, scope, schema, emit), another, marked a gate fails, to a new bind.rejected (bindId, reason). A note below: PROJECTED latches on both outcomes; later readiness is absorbed silently. Gather — one key lane each readiness on key k Judge · gates in declared order first failure wins Publish one-shot per key RDV[k] ACTIVATED true PROJECTED true A activation activation D1 demand d1 d1 D2 demand d2 d2 Barrier · all met by presence, not simultaneity snapshot service.request uid: <bindId>#<n> bindId · uid instruction · scope schema? · emit a gate fails bind.rejected bindId · reason a later readiness of a demand refreshes its entry until projection PROJECTED latches on both outcomes: later readiness is absorbed silently Lab fig. 06·1 Three knots on the left — A, the activation, and D1 and D2, the demands — send their readiness into a box for one key lane, RDV[k], where they fill the scope entries activation, d1 and d2; the box also shows ACTIVATED true and PROJECTED true. An arrow marked snapshot crosses a dashed barrier line, marked all and met by presence, not simultaneity, to a diamond: the gates, in declared order. From the diamond one arrow leads to a new service.request (bindId, uid, instruction, scope, schema, emit), another, marked a gate fails, to a new bind.rejected (bindId, reason). A note below: PROJECTED latches on both outcomes; later readiness is absorbed silently. Gather — one key lane each readiness on key k RDV[k] A activation activation D1 demand d1 d1 D2 demand d2 d2 a later readiness of a demand refreshes its entry until projection ACTIVATED true PROJECTED true Barrier · all met by presence, not simultaneity snapshot Judge · gates in declared order first failure wins Publish service.request a gate fails bind.rejected uid: <bindId>#<n> bindId · uid instruction · scope schema? · emit bindId · reason PROJECTED latches on both outcomes — one-shot per key: later readiness is absorbed silently Lab fig. 06·1 One operator bind, one key lane: the activation knot's readiness marks the lane activated and fills its scope entry; each demand knot's readiness latches its named entry, and a later one refreshes it until projection. Once the lane is activated and every demand name is present — presence, not simultaneity — the scope is snapshotted, the gates run in declared order and the lane projects once: a service.request, or bind.rejected at the first failing gate; later readiness is absorbed silently. A reading aid by CoAgnes Lab; §4 governs. Lab fig. 06·2 At the top, a service.request card with a stamped uid and its declared template, emit.unfold — for_each, knot, head, close — and beside it the result: items 1 to 3, supplied by the model. Below, the batch in log order: knot 1, knot 2, knot 3, close, head 1, head 2, head 3, grouped as knot records and the closing bind on key null, and head facts on the intention key. An arrow from head 1 reaches back to the knot that knot 1 registered, labelled registration precedes the facts that reach it; a dashed line joins the request's uid to every emission: emittedBy: uid. service.request uid emit.unfold — declared: for_each · knot · head · close result[for_each] item 1 item 2 item 3 the template: fixed at authoring time the items: supplied by the model (or other oracle) instantiated controller-side, after schema validation — in exactly this order: registered registration precedes the facts that reach it knot 1 knot 2 knot 3 close head 1 head 2 head 3 emittedBy: uid Knot records sys.knot.defined key null Closing bind sys.descriptor.defined key null Head facts domain.fact · head.writes intention key Lab fig. 06·2 At the top, a service.request card with a stamped uid and its declared template, emit.unfold — for_each, knot, head, close — and beside it the result: items 1 to 3, supplied by the model. Below, the batch in log order: knot 1, knot 2, knot 3, close, head 1, head 2, head 3, grouped as knot records and the closing bind on key null, and head facts on the intention key. An arrow from head 1 reaches back to the knot that knot 1 registered, labelled registration precedes the facts that reach it; a dashed line joins the request's uid to every emission: emittedBy: uid. service.request uid emit.unfold — declared: for_each · knot · head · close the template: fixed at authoring time result[for_each] item 1 · item 2 · item 3 the items: supplied by the model (or other oracle) instantiated controller-side, after schema validation, in exactly this order: knot 1 knot 2 knot 3 close head 1 head 2 head 3 registered registration precedes the facts that reach it Knot records sys.knot.defined key null Closing bind sys.descriptor.defined key null Head facts domain.fact · head.writes intention key emittedBy: uid — on every emission Lab fig. 06·2 An unfold, instantiated controller-side after schema validation: the model (or other oracle) supplies only the items; the pipeline fixed the record shapes, ids, schemas and closing form at authoring time, in the declared template. The batch is emitted in exactly this order — a knot record per item, the closing bind once, a head fact per item — so that registration precedes the facts that reach it. Records stand on key null, head facts on the intention key, and every emission carries emittedBy, the sowing intention's uid. A reading aid by CoAgnes Lab; §7 governs. Lab fig. 07·1 A strip of numbered records. One record sends one arrow up to a knot, which winds it, and one arrow down across a dashed line — the membrane — to a controller that discharges it to the world. From the world an arrow returns across the membrane to the end of the strip, where the answer is appended as a new record. The log — committed tuples #0 #1 #2 #3 #4 #5 #6 appended knot inward — a knot winds it The machine The world The membrane controller outward — a controller claims it discharge an external system the answer enters again only as a committed fact Lab fig. 07·1 A strip of numbered records. One record sends one arrow up to a knot, which winds it, and one arrow down across a dashed line — the membrane — to a controller that discharges it to the world. From the world an arrow returns across the membrane to the end of the strip, where the answer is appended as a new record. The log knot #2 #3 #4 #5 #6 inward The membrane The world outward controller discharge an external system the answer: a new fact Lab fig. 07·1 One committed tuple, two receptions: inward by the knots that wind it, outward by the controllers that claim it. The membrane is a second reading of the one truth — and what the world answers enters again only as committed facts. A reading aid by CoAgnes Lab; §1 governs. Lab fig. 07·2 A strip of numbered records with two pointers above it: the engine's at the end, the membrane's at record 4, moving on by one. Below, two controllers are asked about record 4: one says no, the other claims it and starts a discharge, marked started, not awaited. The log #0 #1 #2 #3 #4 #5 #6 ENGINE.CURSOR — at the end MEMBRANE.CURSOR +1 claims(#4)? controller A no controller B yes — it claims it discharge(#4) started, not awaited once per offset — no redelivery, no retry · between engine runs, never inside apply Lab fig. 07·2 A strip of numbered records with two pointers above it: the engine's at the end, the membrane's at record 4, moving on by one. Below, two controllers are asked about record 4: one says no, the other claims it and starts a discharge, marked started, not awaited. The log #0 #1 #2 #3 #4 #5 #6 MEMBRANE.CURSOR +1 ENGINE.CURSOR — at the end claims(#4)? controller A no controller B yes discharge(#4) not awaited once per offset — no redelivery, no retry between engine runs, never inside apply Lab fig. 07·2 The sweep: the engine's cursor runs ahead; the membrane's own cursor follows, once per offset, between engine runs. For each tuple every controller is asked whether it claims it; a claimed tuple starts a discharge, which is not awaited — and is never repeated. A reading aid by CoAgnes Lab; §3 governs. Lab fig. 07·3 On the left a service request with its fields — bindId, uid, instruction, scope, schema, emit. In the middle a controller with four numbered steps: compose, obtain, validate, publish. On the right the published answer with bindId, uid and result; the two stamps bindId and uid are marked on both. Below the validate step a branch leads to a service.failed fact. the same two stamps — bindId · uid service.request bindId uid instruction scope schema emit.writes: T controller 1 compose the task 2 obtain one result 3 validate: the schema 4 publish under emit T — the answer bindId uid result service.failed bindId · uid · reason if 3 fails: a failure fact, never half an answer Lab fig. 07·3 On the left a service request with its fields — bindId, uid, instruction, scope, schema, emit. In the middle a controller with four numbered steps: compose, obtain, validate, publish. On the right the published answer with bindId, uid and result; the two stamps bindId and uid are marked on both. Below the validate step a branch leads to a service.failed fact. the same two stamps — bindId · uid service.request bindId uid instruction scope schema emit.writes: T controller 1 compose the task 2 obtain one result 3 validate: the schema 4 publish under emit T — the answer bindId uid result service.failed bindId · uid reason if 3 fails: a failure fact, never half an answer Lab fig. 07·3 A service discharge, publication by proxy: the request carries everything needed; the controller composes the task, obtains one result, checks it against the declared schema, and publishes it under the intention's own emit declaration — with the same two correlation stamps. A result of the wrong shape is a failure fact, never half an answer. A reading aid by CoAgnes Lab; §4.2 governs. Lab fig. 08·1 A loop across the membrane. Above it, settle(seeds) asserts that no settle is running and sets SETTLING, then passes the seeds to engine.run, which propagates to quiescence; the quiescent log goes on to membrane.sweep, which starts new discharges. They cross the membrane into a group of discharges in flight, named DISCHARGE.TABLE. The earliest completed one sends its answers back up across the membrane into engine.run as the next run's seeds. Two exits on the right: settled, when DISCHARGE.TABLE is empty after a sweep (SETTLING cleared, the log returned), and defect, when a discharge is rejected — the settle aborts, and the log up to that point remains valid history. settle(seeds) assert ¬SETTLING SETTLING ← true seeds propagate to quiescence engine.run(pending) quiescent start new discharges membrane.sweep(log) The machine The membrane The world DISCHARGE.TABLE in flight await the earliest completed discharge its answers: the next run's seeds settled DISCHARGE.TABLE = ∅ SETTLING ← false return log rejected defect the settle aborts; the log up to that point remains valid history one settling wave at a time — a concurrent settle is a caller error answers interleave in completion order — consumers rely on correlation, not adjacency Lab fig. 08·1 A loop across the membrane. Above it, settle(seeds) asserts that no settle is running and sets SETTLING, then passes the seeds to engine.run, which propagates to quiescence; the quiescent log goes on to membrane.sweep, which starts new discharges. They cross the membrane into a group of discharges in flight, named DISCHARGE.TABLE. The earliest completed one sends its answers back up across the membrane into engine.run as the next run's seeds. Two exits on the right: settled, when DISCHARGE.TABLE is empty after a sweep (SETTLING cleared, the log returned), and defect, when a discharge is rejected — the settle aborts, and the log up to that point remains valid history. settle(seeds) assert ¬SETTLING SETTLING ← true seeds engine.run(pending) propagate to quiescence quiescent membrane.sweep(log) settled DISCHARGE.TABLE = ∅ SETTLING ← false return log The membrane The world start new discharges DISCHARGE.TABLE in flight defect a rejected discharge aborts the settle await the earliest completed discharge; its answers are the next run's seeds one settling wave at a time — a concurrent settle is a caller error answers interleave in completion order — consumers rely on correlation Lab fig. 08·1 The settle loop: the engine runs to quiescence, then the membrane sweeps and starts new discharges; while any is in flight, the runtime awaits the earliest completed one, and its answers re-enter as the next run's seeds. The loop returns — settled — only when nothing is in flight after a sweep; a rejected discharge aborts it with the defect. A reading aid by CoAgnes Lab; §3 governs. Lab fig. 08·2 Two bands divided by a rule. In the upper band, the runtime: a settle with two outcomes — settle rejected, a straight line to the state defect, and settle returned, a line down to the settled log, a row of records. In the lower band, the derived reading: a dotted line leads from the log to a dashed box, derived reading, which forks — no open path leads to the state settled, an open path to the state settled (unfinished), listed as unanswered intentions, a stalled clew, an open rendezvous. A note below: settled means the machine has nothing further to do, not that the answer is good. The runtime settle settle rejected defect settle returned #0 #1 #2 #3 #4 #5 #6 the settled log The derived reading ‘unfinished’ is a derivation over the settled log (unanswered-uid count, open lids), not a distinct runtime signal derived reading no open path settled an open path settled (unfinished) unanswered intentions, a stalled clew, an open rendezvous settled: “the machine has nothing further to do”, not “the answer is good” Lab fig. 08·2 Two bands divided by a rule. In the upper band, the runtime: a settle with two outcomes — settle rejected, a straight line to the state defect, and settle returned, a line down to the settled log, a row of records. In the lower band, the derived reading: a dotted line leads from the log to a dashed box, derived reading, which forks — no open path leads to the state settled, an open path to the state settled (unfinished), listed as unanswered intentions, a stalled clew, an open rendezvous. A note below: settled means the machine has nothing further to do, not that the answer is good. The runtime settle settle rejected defect settle returned #0 #1 #2 #3 #4 the settled log The derived reading ‘unfinished’ is a derivation over the settled log (unanswered-uid count, open lids), not a distinct runtime signal derived reading no open path an open path settled settled (unfinished) unanswered intentions, a stalled clew, an open rendezvous settled: “the machine has nothing further to do”, not “the answer is good” Lab fig. 08·2 Every run ends in exactly one of three honest states. The runtime gives two outcomes — settle returned or settle rejected; whether a returned settle is unfinished is read from the settled log (unanswered intentions, a stalled clew, an open rendezvous), not signalled by the runtime. Settled means the machine has nothing further to do — not that the answer is good. A reading aid by CoAgnes Lab; §7 governs. Lab fig. 09·1 On the left, a pipeline.yaml document with two knots, a and b, and a descriptor d, and below it a schema file. Dotted arrows lead from both into a dashed box, compile, listing five steps: validate the top level; branch ids and inputs; each knot, adding sys.knot.defined to the seeds; each descriptor, its schema resolved and embedded, adding sys.descriptor.defined; and, if there are errors, the seeds emptied. On any error, an arrow leads to an errors card, knots[1].condition, and zero seeds; on no error, an arrow leads down to the log, where the three records are appended. The document pipeline.yaml pipeline: <id> inputs: [ … ] knots: [ a, b ] descriptors: [ d ] schemas/d.schema.json { type: object, … } read through resolveSchemaRef, a callback — one compiler, many sources compile(document, resolveSchemaRef?) compile 1 validate the top level closed keys · runtime values 2 branch ids · inputs 'main' implicit · unique ids 3 each knot: validate seeds += sys.knot.defined 4 each descriptor: validate schemas resolved and embedded seeds += sys.descriptor.defined 5 if errors ≠ ∅: seeds ← [] all-or-nothing any error errors[] knots[1].condition: … one message per violation zero seeds no partial registration no error The log seeds[] — the records sys.knot.defined · a sys.knot.defined · b sys.descriptor.defined · d schema embedded — a run never depends on mutable files Lab fig. 09·1 On the left, a pipeline.yaml document with two knots, a and b, and a descriptor d, and below it a schema file. Dotted arrows lead from both into a dashed box, compile, listing five steps: validate the top level; branch ids and inputs; each knot, adding sys.knot.defined to the seeds; each descriptor, its schema resolved and embedded, adding sys.descriptor.defined; and, if there are errors, the seeds emptied. On any error, an arrow leads to an errors card, knots[1].condition, and zero seeds; on no error, an arrow leads down to the log, where the three records are appended. The document pipeline.yaml pipeline: <id> inputs: [ … ] knots: [ a, b ] descriptors: [ d ] schemas/ d.schema.json read through resolveSchemaRef — a callback compile(document, resolveSchemaRef?) compile 1 validate the top level closed keys · runtime values 2 branch ids · inputs 'main' implicit · unique ids 3 each knot: validate seeds += sys.knot.defined 4 each descriptor: validate schemas resolved and embedded seeds += sys.descriptor.defined 5 if errors ≠ ∅: seeds ← [] all-or-nothing no error any error sys.knot.defined · a sys.knot.defined · b sys.descriptor.defined · d The log seeds[] schema embedded a run never depends on mutable files errors[] knots[1].condition: … one message per violation zero seeds no partial registration Lab fig. 09·1 Compilation, all-or-nothing: the compiler validates the document and turns each knot and each descriptor into its record, the declared schema resolved through a callback and embedded — a run never depends on mutable files. With no error, the records are the seeds committed to the log; with any error, the document compiles to zero seeds, with one path-anchored message per violation. A reading aid by CoAgnes Lab; §6 governs. Lab fig. 09·2 Two package directories in the catalogue. On the left, a draft: its pipeline.yaml names the pipeline p and a schema reference, and a dotted arrow leads to that file, schemas/d.schema.json, inside the same directory — never outside it. A gold arrow, promotion, leads right to a template: pipeline.yaml, the schema file and a template.json provenance sidecar listing source draft, proving run and promotion time. Below the draft, a proving run ending in the state settled joins the promotion by a dotted line marked requires. A note: promotion refuses non-drafts, unknown or unsettled runs, and runs of a different pipeline. The catalogue drafts and templates: ordinary packages in dedicated catalogue subtrees A draft pipeline.yaml pipeline: p schema: schemas/d.schema.json schemas/d.schema.json service.schema: resolved relative to the package — never outside it promotion A template pipeline.yaml schemas/d.schema.json template.json — provenance source draft proving run promotion time the sidecar a template additionally carries settled requires A proving run a settled proving run of that same pipeline promotion refuses non-drafts · unknown or unsettled runs · runs of a different pipeline Lab fig. 09·2 Two package directories in the catalogue. On the left, a draft: its pipeline.yaml names the pipeline p and a schema reference, and a dotted arrow leads to that file, schemas/d.schema.json, inside the same directory — never outside it. A gold arrow, promotion, leads right to a template: pipeline.yaml, the schema file and a template.json provenance sidecar listing source draft, proving run and promotion time. Below the draft, a proving run ending in the state settled joins the promotion by a dotted line marked requires. A note: promotion refuses non-drafts, unknown or unsettled runs, and runs of a different pipeline. The catalogue drafts and templates: ordinary packages in dedicated catalogue subtrees A draft pipeline.yaml pipeline: p schema: schemas/d.schema.json schemas/d.schema.json service.schema: resolved relative to the package — never outside it promotion settled requires A proving run of that same pipeline A template pipeline.yaml schemas/d.schema.json template.json — provenance source draft proving run promotion time the sidecar a template additionally carries promotion refuses non-drafts · unknown or unsettled runs · runs of a different pipeline Lab fig. 09·2 A package: pipeline.yaml beside schemas/*.schema.json, its service.schema references resolved relative to the package, never outside it. Drafts and templates are ordinary packages; promoting a draft to a template requires a settled proving run of that same pipeline, and the template additionally carries a template.json provenance sidecar: source draft, proving run, promotion time. A reading aid by CoAgnes Lab; §8 governs. Lab fig. 10·1 Four panels. Sequence: a diamond, bind A, sends an arrow marked emit to a new record, #4 fact, at the end of a strip of records, the log; an arrow marked collect rises from it to a ring, a knot, and one marked ready runs on to a filled diamond, bind B. Join: three rings — the activation and the demands d1 and d2 — each send an arrow marked ready to a dashed line, the barrier (all); from it an arrow reaches a filled diamond, the gates, and one marked service leads to a new record, emit. Branching: a diamond, the gates, forks into two new records, emit and reject, each followed by a ring that collects it. Iteration: records flow into a ring with an arrow looping over it, marked collect until sufficient, and an arrow marked ready leaves it. Sequence bind B consumes the publication of bind A A emit #1 #2 #3 #4 fact The log collect knot ready B always through the log — hence inspectable and re-bindable Join a bind gathers several knots at once — demands ripen independently, in any order activation ready demand d1 ready demand d2 ready barrier · all gates service emit Branching is judgement gates split outcomes into emit vs reject gates emit reject each bindable downstream Iteration is accumulation a knot with reduce: append and a threshold condition facts it matches collect until sufficient ready it loops without any loop construct Lab fig. 10·1 Four panels. Sequence: a diamond, bind A, sends an arrow marked emit to a new record, #4 fact, at the end of a strip of records, the log; an arrow marked collect rises from it to a ring, a knot, and one marked ready runs on to a filled diamond, bind B. Join: three rings — the activation and the demands d1 and d2 — each send an arrow marked ready to a dashed line, the barrier (all); from it an arrow reaches a filled diamond, the gates, and one marked service leads to a new record, emit. Branching: a diamond, the gates, forks into two new records, emit and reject, each followed by a ring that collects it. Iteration: records flow into a ring with an arrow looping over it, marked collect until sufficient, and an arrow marked ready leaves it. Sequence bind B consumes the publication of bind A A emit #1 #2 #3 #4 fact The log collect knot ready B always through the log — hence inspectable and re-bindable Join a bind gathers several knots at once — demands ripen independently, in any order activation ready demand d1 ready demand d2 ready barrier · all gates service emit Branching is judgement gates split outcomes into emit vs reject gates emit reject each bindable downstream Iteration is accumulation a knot with reduce: append and a threshold condition facts it matches collect until sufficient ready it loops without any loop construct Lab fig. 10·1 The two moves every figure composes from: sequence — bind A's publication is collected from the log by a knot whose readiness activates bind B — and join — one bind gathers the activation channel and named demands under the barrier, the demands ripening independently, in any order. Below them, branching is judgement: gates split outcomes into emit and reject publications, each bindable downstream; and iteration is accumulation: a knot with reduce: append and a threshold condition loops “collect until sufficient”, without any loop construct. A reading aid by CoAgnes Lab; §1 governs. Lab fig. 10·2 First a filled diamond, the planner bind, an operator, with its service “unfold the problem into questions”; a gold arrow leads to its answer, questions: [q1 … qN], noted: the answer fixes only content and N; N bounded in the schema by maxItems — termination. A gold dashed bracket from the answer spans the sown part, headed fixed in advance by the template, sown by the controller, each emission stamped emittedBy — attribution. In three rows, q1, q2 and qN, a new head fact, cell: qi (question.seeded), points to a ring, the question cell cell.qi, whose readiness runs to a dashed line, the barrier (all); from it an arrow reaches a filled diamond, the harvest bind, with its gates (min_grade), and the harvest service leads to a new record, problem.frame.ready. Notes: each head fact must satisfy its cell's where and each cell's readiness must be demanded by the close — reachability; a weak cell rejects the harvest visibly, instead of diluting it. Planner bind operator service: “unfold the problem into questions” answer questions: [q1 … qN] the answer fixes only content and N N bounded in the schema by maxItems — termination Fixed in advance by the template sown by the controller, each emission stamped emittedBy — attribution Head facts ×N question.seeded Question cells ×N cell.q{index} Harvest bind demands q1 … qN cell: q1 cell.q1 readiness cell: q2 cell.q2 readiness cell: qN cell.qN readiness … … barrier · all gates · min_grade harvest service problem.frame.ready a weak cell rejects the harvest visibly, instead of diluting it each head fact must satisfy its cell’s where; each cell’s readiness must be demanded by the close — reachability Lab fig. 10·2 First a filled diamond, the planner bind, an operator, with its service “unfold the problem into questions”; a gold arrow leads to its answer, questions: [q1 … qN], noted: the answer fixes only content and N; N bounded in the schema by maxItems — termination. A gold dashed bracket from the answer spans the sown part, headed fixed in advance by the template, sown by the controller, each emission stamped emittedBy — attribution. In three rows, q1, q2 and qN, a new head fact, cell: qi (question.seeded), points to a ring, the question cell cell.qi, whose readiness runs to a dashed line, the barrier (all); from it an arrow reaches a filled diamond, the harvest bind, with its gates (min_grade), and the harvest service leads to a new record, problem.frame.ready. Notes: each head fact must satisfy its cell's where and each cell's readiness must be demanded by the close — reachability; a weak cell rejects the harvest visibly, instead of diluting it. Planner bind operator service: “unfold the problem into questions” answer questions: [q1 … qN] the answer fixes only content and N N bounded in the schema by maxItems — termination Fixed in advance by the template sown by the controller, each emission stamped emittedBy — attribution Head facts question.seeded Question cells cell.q{index} Harvest bind demands q1 … qN cell: q1 cell.q1 readiness cell: q2 cell.q2 readiness cell: qN cell.qN readiness … … barrier · all gates min_grade harvest service problem.frame.ready each head fact must satisfy its cell’s where; each cell’s readiness must be demanded by the close — reachability a weak cell rejects the harvest visibly, instead of diluting it Lab fig. 10·2 Unfold as a figure: the planner bind's answer fixes only content and N — N bounded in the schema by maxItems — while the template fixed every form in advance: the head fact type, the question cells' ids, lanes, budgets and conditions, and the closing harvest bind with one demand per item. The controller sows them, each emission stamped emittedBy. Each head fact must satisfy its cell's where and each cell's readiness must be demanded by the close, whose min_grade gates let a weak cell reject the harvest visibly instead of diluting it. A reading aid by CoAgnes Lab; §6 governs. Lab fig. 10·3 A line of stations in causal order, numbered as in the list: 1, a ring, the intake gate (deterministic), followed by a small diamond, its emit; 2, a ring, the truth cell (through-world); 4, a filled diamond, the planner bind (unfold), from which arrows marked sows fan out to rings q1, q2 … qN, the question cells, which ripen as a canvas, cross-pollinating within budget; their readiness converges on 6, a filled diamond, the harvest bind, under gates, which publishes a new record, problem.frame.ready. Apart from the line, 3, a ring, the journal, accumulating reasoning per key alongside. Below a rule: its vault, lids read backwards — harvest fact ← planner unfold ← intake emit — and the recorded acceptance run: 87 tuples, zero failures, zero unanswered intentions, settled, finished. 1 intake gate 2 truth cell 4 planner bind 5 question cells 6 harvest bind deterministic §2 emit through-world §3 unfold §6 q1 q2 qN … sows readiness ripen as a canvas, cross-pollinating within budget · §4 under gates problem.frame.ready 3 journal alongside — accumulates reasoning per key · §5 its vault, lids read backwards: harvest fact ← planner unfold ← intake emit the recorded acceptance run: 87 tuples, zero failures, zero unanswered intentions — settled, finished Lab fig. 10·3 A line of stations in causal order, numbered as in the list: 1, a ring, the intake gate (deterministic), followed by a small diamond, its emit; 2, a ring, the truth cell (through-world); 4, a filled diamond, the planner bind (unfold), from which arrows marked sows fan out to rings q1, q2 … qN, the question cells, which ripen as a canvas, cross-pollinating within budget; their readiness converges on 6, a filled diamond, the harvest bind, under gates, which publishes a new record, problem.frame.ready. Apart from the line, 3, a ring, the journal, accumulating reasoning per key alongside. Below a rule: its vault, lids read backwards — harvest fact ← planner unfold ← intake emit — and the recorded acceptance run: 87 tuples, zero failures, zero unanswered intentions, settled, finished. 1 intake gate deterministic · §2 emit 2 truth cell through-world · §3 4 planner bind unfold · §6 3 journal accumulates reasoning per key, alongside · §5 q1 q2 qN … 5 question cells ripen as a canvas, cross-pollinating within budget · §4 sows 6 harvest bind under gates problem.frame.ready its vault, lids read backwards: harvest fact ← planner unfold ← intake emit the recorded acceptance run: 87 tuples, zero failures, zero unanswered intentions — settled, finished Lab fig. 10·3 The full hybrid figure problem.frame in causal order: the deterministic intake gate and its emit; the through-world truth cell; the planner bind, projecting an unfold that the controller sows as N question cells, their heads and the harvest bind; the question cells ripening as a canvas, cross-pollinating within budget; and the harvest bind, gathering all cells under gates and publishing problem.frame.ready — with the journal accumulating reasoning per key alongside. Its vault reads backwards: harvest fact ← planner unfold ← intake emit. A reading aid by CoAgnes Lab; §8 governs. Lab fig. 11·1 A filled box, the invariant core — envelope, three contracts, append semantics — marked as changing only by deliberate, recorded widening. Five rails, each a double hairline, run from it, labelled strategy registry, processor list, controller list, emit-declaration union and protocol namespaces, each with its section. Each rail ends in a module box: new strategy names; observers and routers; new controllers with configuration records; writes or unfold, beside a dashed box for cell, proposed; new domain.fact namespaces. Beneath, the rule: new capability must not require the flat machine to change behaviour when it is absent, and each extension names how it preserves attribution, reachability and termination, and its honest states. Existing contracts Pluggable modules The invariant core envelope three contracts append semantics changes only by deliberate, recorded widening — §2 strategy registry — §3.1 processor list — §3.3 controller list — §3.4 emit-declaration union — §3.5 protocol namespaces — §3.6 new strategy names observers · routers new controllers + configuration records writes | unfold cell proposed new domain.fact namespaces new capability MUST NOT require the flat machine to change behaviour when it is absent each extension names how it preserves attribution, reachability, termination — and its honest states Lab fig. 11·1 A filled box, the invariant core — envelope, three contracts, append semantics — marked as changing only by deliberate, recorded widening. Five rails, each a double hairline, run from it, labelled strategy registry, processor list, controller list, emit-declaration union and protocol namespaces, each with its section. Each rail ends in a module box: new strategy names; observers and routers; new controllers with configuration records; writes or unfold, beside a dashed box for cell, proposed; new domain.fact namespaces. Beneath, the rule: new capability must not require the flat machine to change behaviour when it is absent, and each extension names how it preserves attribution, reachability and termination, and its honest states. The invariant core envelope · three contracts · append semantics changes only by deliberate, recorded widening — §2 strategy registry — §3.1 processor list — §3.3 controller list — §3.4 emit-declaration union — §3.5 protocol namespaces — §3.6 new strategy names observers · routers new controllers + configuration records writes | unfold cell proposed new domain.fact namespaces new capability MUST NOT require the flat machine to change behaviour when it is absent each extension names how it preserves attribution, reachability, termination — and its honest states Lab fig. 11·1 The growth rule, drawn: the five existing contracts the rule names — strategy registry, processor list, controller list, emit-declaration union, protocol namespaces — run from the invariant core as rails, and new capability plugs in at their ends as modules, each detailed in §3; the union's proposed third member, cell, is dashed. The core itself changes only by deliberate, recorded widening (§2), and new capability MUST NOT require the flat machine to change behaviour when it is absent. A reading aid by CoAgnes Lab; §1 governs. Lab fig. 11·2 Four stops along a line: proposed explicitly, motivated, agreed, landed. At landed, what lands with the widening in the same work item is named — terminology, requirements, formats, tests — and an arrow marked recorded leads to a card, the precedent log, with two entries dated 2026-07-02: IKnotExecutor.wind may return emissions; IDescriptorExecutor.execute receives the activation context, with the understanding() snapshot added. Apart, under the heading open, not agreed, three dashed boxes — log restore or continuation, a settlement or quiescence hook, a new envelope kind of any sort — with the note that extensions must not assume them. The invariant core envelope + three contracts + append semantics — changes only by deliberate, recorded widening proposed explicitly motivated agreed landed terminology requirements formats tests in the same work item recorded The precedent log 1 IKnotExecutor.wind may return emissions 2026-07-02 2 IDescriptorExecutor.execute receives the 2026-07-02 activation context; understanding() snapshot added Open — not agreed log restore / continuation §6.1 settlement / quiescence hook §6.2 a new envelope kind of any sort extensions MUST NOT assume them Lab fig. 11·2 Four stops along a line: proposed explicitly, motivated, agreed, landed. At landed, what lands with the widening in the same work item is named — terminology, requirements, formats, tests — and an arrow marked recorded leads to a card, the precedent log, with two entries dated 2026-07-02: IKnotExecutor.wind may return emissions; IDescriptorExecutor.execute receives the activation context, with the understanding() snapshot added. Apart, under the heading open, not agreed, three dashed boxes — log restore or continuation, a settlement or quiescence hook, a new envelope kind of any sort — with the note that extensions must not assume them. The invariant core envelope + three contracts + append semantics — changes only by deliberate, recorded widening proposed explicitly motivated agreed landed together with terminology, requirements, formats and tests — the same work item recorded The precedent log 1 IKnotExecutor.wind 2026-07-02 may return emissions 2 IDescriptorExecutor.execute 2026-07-02 receives the activation context; understanding() snapshot added Open — not agreed log restore / continuation §6.1 settlement / quiescence hook §6.2 a new envelope kind of any sort extensions MUST NOT assume them Lab fig. 11·2 A core widening in the volume's own words: proposed explicitly, motivated, agreed, and landed together with terminology, requirements, formats and tests — the same-work-item rule; the precedent log holds the two widenings recorded so far, both of 2026-07-02. The candidate widenings still open are not agreed, and extensions MUST NOT assume them. A reading aid by CoAgnes Lab; §2 governs. Lab fig. 12·1 A wide box, CellSpace, holds two dashed compartments: a Trial Cell named cell@42 — isolation subscribed, accepting evidence.granted — with a knot cell@42::evidence.ready and a bind cell@42::answer.fold; and the root Cell, whose records carry no home, with a knot and a bind answer.planner. Below the box runs one log: the seed at #42, whose offset is the CellRef; records, which rise to cell@42, their home; cell.context, targeted to cell@42; the private fact cell@42::analysis.partial, which rises to its owner only; and the public import evidence.granted, which rises both to the root Cell and to cell@42. All Cells are projections over the one wave log CellSpace routing · admission · materialisation · policy enforcement · lifecycle derivation cell@42 — a Trial Cell isolation: subscribed · accepts: evidence.granted cell@42::evidence.ready cell@42::answer.fold the root Cell records without home answer.planner The log #42 cell.seed the seed offset → CellRef records topology to their home cell.context targeted to its CellRef cell@42::analysis.partial private qualified · owner only evidence.granted import allowed by accepts ordinary tuples gain no cell_id — identity derives from committed offsets one public fact may reach several Cells: root first, then Cells in creation-offset order with no cell.seed on the log, the assembly MUST produce byte-identical logs to the flat machine Lab fig. 12·1 A wide box, CellSpace, holds two dashed compartments: a Trial Cell named cell@42 — isolation subscribed, accepting evidence.granted — with a knot cell@42::evidence.ready and a bind cell@42::answer.fold; and the root Cell, whose records carry no home, with a knot and a bind answer.planner. Below the box runs one log: the seed at #42, whose offset is the CellRef; records, which rise to cell@42, their home; cell.context, targeted to cell@42; the private fact cell@42::analysis.partial, which rises to its owner only; and the public import evidence.granted, which rises both to the root Cell and to cell@42. All Cells are projections over the one wave log CellSpace routing · admission · materialisation policy enforcement · lifecycle derivation the root Cell — records without home answer.planner cell@42 — a Trial Cell isolation: subscribed accepts: evidence.granted cell@42::evidence.ready cell@42::answer.fold The log the seed offset → CellRef #42 cell.seed topology to their home records targeted to its CellRef cell.context private qualified · owner only cell@42::analysis.partial import allowed by accepts evidence.granted no cell_id on ordinary tuples — identity derives from committed offsets; one public fact may reach several Cells Lab fig. 12·1 All Cells are projections over the one wave log. CellSpace holds the root Cell and a child, cell@42, named by its seed's offset, whose runtime names are qualified. The child's records reach it by their home, its cell.context is targeted to its CellRef, and its private facts reach their owner only; one public fact may reach several Cells — root first — and reaches this subscribed Cell because its accepts matches. A reading aid by CoAgnes Lab; §4 governs. Lab fig. 12·2 Two lanes and five numbered steps, 5.1 to 5.5. On the left, the committed input: charter.proposed, a bind's writes, untrusted; cell.seed, the whole package; the local result, from the Cell's result producer; cell.assessment.proposed, from an evaluator bind outside the trial; cell.reviewed, from human ingress. On the right, the canonical records CellSpace alone emits: charter.defined; cell.opened, records and cell.context; cell.result, staged, not yet public; cell.assessed; and three terminals reached by accept, revise and archive — cell.sealed with the accepted export, cell.revision.requested, cell.archived. An arrow runs from each input to its canonical record, and a curve leads from each canonical record down to the next input. Beside each canonical record stands its alternative: charter.rejected, cell.rejected, cell.failed, cell.assessment.rejected, cell.review.rejected. At the foot: four verdicts never collapse — admission, runtime success, assessment, human usefulness. Committed input Canonical — CellSpace only charter.proposed a bind's writes — untrusted 5.1 checks the causal request and the closed shape charter.defined CharterRef: the proposal's offset or charter.rejected cell.seed the whole package; envelope not trusted 5.2 checks the causal request; re-validates at admission cell.opened records cell.context CellRef: the seed's offset or cell.rejected — registers nothing local result by the Cell's result producer 5.3 checks bindId/uid and the embedded schema cell.result staged — not yet public or cell.failed cell.assessment.proposed an evaluator bind outside the trial 5.4 every criterion exactly once computes the aggregate itself cell.assessed weights from the Charter only or cell.assessment.rejected cell.reviewed human ingress — actor stamped server-side 5.5 accept cell.sealed accepted export revise cell.revision.requested archive cell.archived or cell.review.rejected four verdicts never collapse: admission ≠ runtime success ≠ assessment ≠ human usefulness unrelated committed tuples may appear between any two — happens-before, never adjacency Lab fig. 12·2 Two lanes and five numbered steps, 5.1 to 5.5. On the left, the committed input: charter.proposed, a bind's writes, untrusted; cell.seed, the whole package; the local result, from the Cell's result producer; cell.assessment.proposed, from an evaluator bind outside the trial; cell.reviewed, from human ingress. On the right, the canonical records CellSpace alone emits: charter.defined; cell.opened, records and cell.context; cell.result, staged, not yet public; cell.assessed; and three terminals reached by accept, revise and archive — cell.sealed with the accepted export, cell.revision.requested, cell.archived. An arrow runs from each input to its canonical record, and a curve leads from each canonical record down to the next input. Beside each canonical record stands its alternative: charter.rejected, cell.rejected, cell.failed, cell.assessment.rejected, cell.review.rejected. At the foot: four verdicts never collapse — admission, runtime success, assessment, human usefulness. Committed input Canonical — CellSpace 5.1 charter.proposed a bind's writes, untrusted charter.defined or charter.rejected 5.2 cell.seed the whole package; envelope not trusted cell.opened or cell.rejected records each with its home cell.context after every record 5.3 local result by the Cell's result producer cell.result staged, not yet public 5.4 cell.assessment.proposed evaluator bind, outside the trial cell.assessed aggregate by CellSpace 5.5 cell.reviewed human ingress, actor stamped server-side accept cell.sealed accepted export revise cell.revision.requested archive cell.archived or cell.review.rejected four verdicts never collapse: admission ≠ runtime success ≠ assessment ≠ human usefulness unrelated tuples may appear between any two Lab fig. 12·2 The protocol family in its required partial order. Four times a record committed by others — a bind's charter.proposed, a cell.seed with the package wrapped around the planner's blueprint, the Cell's local result, an evaluator's proposal — is checked by CellSpace, which alone emits the canonical record, or a rejection or failure. A human's cell.reviewed then chooses the terminal: only accept seals the Cell and publishes the accepted export. Unrelated tuples may appear between any two. A reading aid by CoAgnes Lab; §5 governs. Lab fig. 13·1 Five dashed stops along one dashed line, Tact 1 to Tact 5, each with its words: self-description of the runtime, every material claim evidenced or gapped; reflection proposes the pipeline, promoted only through review; describe CoAgnes with the real corpus; first external domain demo with an expert reviewer; internalise the trial as Cells. A dashed arc runs back from Tact 2 to Tact 1, marked could repeat Tact 1. A legend: dashed, a seed. Bootstrap sequence could repeat Tact 1 Tact 1 self-description of the runtime every material claim evidenced or gapped Tact 2 reflection proposes the pipeline compiled, fixture-run, promoted only through review Tact 3 describe CoAgnes with the real corpus incompatibilities become requirements or applicability limits, never silent prompt edits Tact 4 first external domain demo with an expert reviewer Tact 5 internalise the trial as Cells (Vol. 12) with identical Charter/ evidence/assessment/ review contracts and root-only compatibility dashed — a seed: nothing here is an active contract Lab fig. 13·1 Five dashed stops along one dashed line, Tact 1 to Tact 5, each with its words: self-description of the runtime, every material claim evidenced or gapped; reflection proposes the pipeline, promoted only through review; describe CoAgnes with the real corpus; first external domain demo with an expert reviewer; internalise the trial as Cells. A dashed arc runs back from Tact 2 to Tact 1, marked could repeat Tact 1. A legend: dashed, a seed. Bootstrap sequence Tact 1 self-description of the runtime every material claim evidenced or gapped Tact 2 reflection proposes the pipeline that could repeat Tact 1 compiled, fixture-run, promoted only through review Tact 3 describe CoAgnes with the real corpus incompatibilities become requirements or applicability limits, never silent prompt edits Tact 4 first external domain demo with an expert reviewer Tact 5 internalise the trial as Cells (Vol. 12) with identical Charter/evidence/ assessment/review contracts and root-only compatibility dashed — a seed: nothing here is an active contract Lab fig. 13·1 The bootstrap sequence the seed sets out, in five tacts: a self-description of the runtime, every material claim evidenced or gapped; reflection proposing the pipeline that could repeat Tact 1, promoted only through review; CoAgnes described with the real corpus; a first external domain demo with an expert reviewer; the trial internalised as Cells (Vol. 12). Drawn dashed: the volume is a seed, and nothing here is an active contract. A reading aid by CoAgnes Lab; §7 governs. Lab fig. 13·2 Eleven dashed stops along one dashed line: Charter, evidence, map/ledger, description, pipeline proposal, compiler verdict, trial, independent assessment, human decision, promoted package, fresh application. A bracket spans every stop and leads to five questions to answer at every step: what was committed, why the next operation was allowed, which evidence supports the result, which capability crossed the membrane, which exact package was accepted. A legend: dashed, a seed. The seed is viable when one user can traverse Charter evidence map/ledger description pipeline proposal compiler verdict trial independent assessment human decision promoted package fresh application At every step, answer what was committed why the next operation was allowed which evidence supports the result which capability crossed the membrane which exact package was accepted dashed — a seed: nothing here is an active contract Lab fig. 13·2 Eleven dashed stops along one dashed line: Charter, evidence, map/ledger, description, pipeline proposal, compiler verdict, trial, independent assessment, human decision, promoted package, fresh application. A bracket spans every stop and leads to five questions to answer at every step: what was committed, why the next operation was allowed, which evidence supports the result, which capability crossed the membrane, which exact package was accepted. A legend: dashed, a seed. The seed is viable when one user can traverse Charter evidence map/ledger description pipeline proposal compiler verdict trial independent assessment human decision promoted package fresh application At every step, answer what was committed why the next operation was allowed which evidence supports the result which capability crossed the membrane which exact package was accepted dashed — a seed: nothing here is an active contract Lab fig. 13·2 The seed is viable when one user can traverse from Charter to a fresh application — through evidence, map/ledger, description, pipeline proposal, compiler verdict, trial, independent assessment, human decision and promoted package — and at every step answer what was committed, why the next operation was allowed, which evidence supports the result, which capability crossed the membrane, and which exact package was accepted. Drawn dashed, like the whole volume: nothing here is an active contract. A reading aid by CoAgnes Lab; §7 governs. Lab fig. 14·1 Four nested boxes, each inside the next. The innermost, L, log-conforming, reader and tooling, sufficient for trace tools, digest services and UIs: it consumes and produces the envelope and JSONL of Vol. 03 and implements derivations as pure functions of the log. The box around it, M, machine-conforming, adds a band listing the obligations of Vol. 08 §6, from propagation to explicit rejection of unsupported constructs, and a dashed box inside it: the machine class, deterministic, semantic or hybrid, declared alongside. Around that, A, authoring-conforming, adds the compiler of Vol. 09 in six points; the outermost, E(x), extension-conforming, adds a named extension volume implemented in full, with its root-compatibility proof and regression catalogue, for example E(cells). Conformance classes an implementation claims one or more; each subsumes the previous L Log-conforming reader / tooling consumes and produces the envelope and JSONL of Vol. 03 implements derivations as pure functions of the log — Vol. 08 §8 sufficient for trace tools, digest services, UIs M Machine-conforming Class L plus the full obligations of Vol. 08 §6: propagation · topology dispatch and readiness reification · the two bundled strategies the two descriptor forms · membrane semantics · the settle algorithm honest terminal states · explicit rejection of unsupported constructs the machine class (deterministic / semantic / hybrid) is declared alongside — Vol. 08 §5 A Authoring-conforming Class M plus the compiler of Vol. 09: grammar acceptance · closed-key discipline · path-anchored diagnostics all-or-nothing compilation · schema subset · package layout E(x) Extension-conforming Class A plus a named extension volume implemented in full, including its root-compatibility proof and regression catalogue e.g. E(cells), per Vol. 12 §12 Lab fig. 14·1 Four nested boxes, each inside the next. The innermost, L, log-conforming, reader and tooling, sufficient for trace tools, digest services and UIs: it consumes and produces the envelope and JSONL of Vol. 03 and implements derivations as pure functions of the log. The box around it, M, machine-conforming, adds a band listing the obligations of Vol. 08 §6, from propagation to explicit rejection of unsupported constructs, and a dashed box inside it: the machine class, deterministic, semantic or hybrid, declared alongside. Around that, A, authoring-conforming, adds the compiler of Vol. 09 in six points; the outermost, E(x), extension-conforming, adds a named extension volume implemented in full, with its root-compatibility proof and regression catalogue, for example E(cells). Conformance classes an implementation claims one or more; each subsumes the previous L Log-conforming reader / tooling consumes and produces the envelope and JSONL of Vol. 03; implements derivations as pure functions of the log (Vol. 08 §8) sufficient for trace tools, digest services, UIs M Machine-conforming Class L plus the full obligations of Vol. 08 §6: propagation topology dispatch and readiness reification the two bundled strategies the two descriptor forms membrane semantics the settle algorithm honest terminal states explicit rejection of unsupported constructs the machine class is declared alongside (Vol. 08 §5): deterministic / semantic / hybrid A Authoring-conforming Class M plus the compiler of Vol. 09: grammar acceptance closed-key discipline path-anchored diagnostics all-or-nothing compilation schema subset package layout E(x) Extension-conforming Class A plus a named extension volume implemented in full, including its root-compatibility proof and regression catalogue e.g. E(cells), per Vol. 12 §12 Lab fig. 14·1 The conformance classes, each subsuming the previous: Class L consumes and produces the envelope and JSONL of Vol. 03 and implements derivations as pure functions of the log; Class M adds the full obligations of Vol. 08 §6, with its machine class declared alongside; Class A adds the compiler of Vol. 09; Class E(x) adds a named extension volume implemented in full. An implementation claims one or more of them. A reading aid by CoAgnes Lab; §1 governs. Lab fig. 14·2 A grid of seven rows and three columns. Each row names one matrix with its section and its guiding question: Truth, Deep, Connect, Service, Knowledge, Evolution and Responsibility; the three columns are artefacts affected by a change. Every cell is filled as answered except one in the Knowledge row, drawn dashed: a red cell. From it a dotted line runs down the right-hand side to two outcomes: a stop marked blocks the change, and a card, the honest-gap sections, blind spots and open decisions. Below the grid, a legend for the two kinds of cell and a note: answer each cell or record the gap; pretending is the only non-conforming option. The seven verification matrices each a dimension crossed with the artefact under review Affected artefacts one column per artefact Truth §4.1 Is every statement grounded in something inspectable? Deep §4.2 Does the specification reach the load-bearing level, not the surface? Connect §4.3 Does everything link — within the set, to the repository, to the seeds? Service §4.4 Does the set serve its readers' work? Knowledge §4.5 Is the knowledge complete and duplicated nowhere? Evolution §4.6 Can the machine and the set grow without breaking what stands? Responsibility §4.7 Are authority, trust, and consequence assigned? blocks the change the honest-gap sections blind spots · open decisions a cell: a question that must have a demonstrable answer a red cell: no demonstrable answer for a change: build the 7 × (affected artefacts) grid; answer each cell or record the gap pretending is the only non-conforming option Lab fig. 14·2 A grid of seven rows and three columns. Each row names one matrix with its section and its guiding question: Truth, Deep, Connect, Service, Knowledge, Evolution and Responsibility; the three columns are artefacts affected by a change. Every cell is filled as answered except one in the Knowledge row, drawn dashed: a red cell. From it a dotted line runs down the right-hand side to two outcomes: a stop marked blocks the change, and a card, the honest-gap sections, blind spots and open decisions. Below the grid, a legend for the two kinds of cell and a note: answer each cell or record the gap; pretending is the only non-conforming option. The seven verification matrices each a dimension crossed with the artefact under review affected artefacts Truth §4.1 Is every statement grounded in something inspectable? Deep §4.2 Does the specification reach the load-bearing level, not the surface? Connect §4.3 Does everything link — within the set, to the repository, to the seeds? Service §4.4 Does the set serve its readers' work? Knowledge §4.5 Is the knowledge complete and duplicated nowhere? Evolution §4.6 Can the machine and the set grow without breaking what stands? Responsibility §4.7 Are authority, trust, and consequence assigned? a cell: a question that must have a demonstrable answer a red cell: no demonstrable answer blocks the change the honest-gap sections blind spots · open decisions for a change: build the 7 × (affected artefacts) grid; answer each cell or record the gap pretending is the only non-conforming option Lab fig. 14·2 The seven matrices as one grid: each row is a dimension — Truth, Deep, Connect, Service, Knowledge, Evolution, Responsibility — crossed with the artefacts a change affects, and each cell is a question that must have a demonstrable answer. Applied to a change (§4.8), a red cell either blocks the change or lands in the honest-gap sections — blind spots, open decisions; pretending is the only non-conforming option. A reading aid by CoAgnes Lab; §4 governs. Lab fig. 15·1 A frame marked §7, the machine, closed below by the dashed membrane (§6). Inside it: a ring and a diamond, the two entities (§2), joined by an arrow marked readiness, each with the first terms inside it (§3, §4); a bracket beneath both over the cross-cutting terms (§5); and a row of records, the substrate (§1). On the membrane a controller takes from the records and discharges to the world, whose answer returns by ingress as a new record. Outside the frame, a document, the authoring pipeline (§8), feeds the records through the loader; apart, a dashed box holds the extension terms, PROPOSED or SEED (§9). §9 Extension terms PROPOSED / SEED Semantic Charter · Cell … defined in Vol. 12 and 13 §8 Authoring and loading authoring pipeline lives outside the machine loader: individual records, committed as seeds §7 The machine Nest runtime · assembly · machine class · seeds · settle … §2 The two entities activation knot · bind descriptor · clew readiness §3 Inside an activation knot condition · collection rule · wind · winding intention … §4 Inside a bind descriptor activation · affinity · head · demand · barrier … §5 Cross-cutting angle of perception · cascade · integration … §1 Substrate wave log · wave tuple · emission · wave · topology · key §6 The membrane membrane · output controller · claim · discharge … discharge the world ingress Lab fig. 15·1 A frame marked §7, the machine, closed below by the dashed membrane (§6). Inside it: a ring and a diamond, the two entities (§2), joined by an arrow marked readiness, each with the first terms inside it (§3, §4); a bracket beneath both over the cross-cutting terms (§5); and a row of records, the substrate (§1). On the membrane a controller takes from the records and discharges to the world, whose answer returns by ingress as a new record. Outside the frame, a document, the authoring pipeline (§8), feeds the records through the loader; apart, a dashed box holds the extension terms, PROPOSED or SEED (§9). §8 Authoring and loading authoring pipeline lives outside the machine loader: individual records, committed as seeds §7 The machine Nest runtime · assembly · machine class · seeds · settle … §2 The two entities activation knot · bind descriptor · clew §3 Inside an activation knot condition · collection rule · wind · winding intention … readiness §4 Inside a bind descriptor activation · affinity · head · demand · barrier … §5 Cross-cutting angle of perception · cascade · integration … §1 Substrate wave log · wave tuple · emission · wave · topology · key §6 The membrane membrane · output controller · claim · discharge … discharge the world ingress §9 Extension terms PROPOSED / SEED Semantic Charter · Cell … defined in Vol. 12 and 13 Lab fig. 15·1 The vocabulary as one map: the substrate beneath (§1); the two entities (§2), what lies inside each (§3, §4) and what cuts across them (§5); the membrane between the machine and the world (§6); the machine as a whole (§7); the authoring pipeline, outside the machine and loaded into it as records (§8); and, apart, the extension terms, PROPOSED or SEED (§9). Each region shows some of its entries, in the volume's order. A reading aid by CoAgnes Lab; §1 governs. Nest Runtime Specification Set — the work of the NestVM project, licensed CC-BY-4.0 . Source: github.com/harmogics/nestvm . Changes: none to the set — these are reading aids by CoAgnes Lab, gathered from the volumes' pages; they reproduce no text of the set.
Previous Questions the set answersPart of The Nest Runtime Specification Set