The specification: charter, policy, admission, lifecycle, routing

Where and how flows form (the machine's own contract for a Cell), and where the key vectors that move a finding between planes are declared.

Source: lib/core/cells/cell-protocol.ts, admit-cell-package.ts, materialise-cell-records.ts, create-cell-space.ts (NestVM Vol. 12 §2–§9, incubated in this repository per lib/README.md).

§The Charter

A Charter is four things, nothing more:

type SemanticCharter = {
  title: string;
  purpose: string;
  question: string;
  criteria: readonly { id: string; question: string; weight: number; minimum?: number }[];
};

It is proposed by a bind (through the world or a deterministic stand-in), then made canonical by the machine under a ref of the form charter@<offset of its proposal>, with a digest of its exact value. From that point the Charter is addressed by ref; it is never re-sent, and its value can never change under that ref — a new brief is a new ref, not an edit.

§The policy — what a Cell may hear, do, and spend

type CellPolicy = {
  mode: "trial";                                  // the only mode this slice implements
  isolation: "snapshot" | "subscribed";
  raw_input: "deny" | "allow";
  accepts: readonly { match_type: string }[];      // the ONLY fact types it may hear from outside
  capabilities: readonly string[];                 // v1 registry: "inference" only
  budget: { max_records: number; max_emissions: number; max_inference_calls: number };
  publish: { candidate: string; accepted: string }; // the one result path, declared before the Cell exists
};

This is the terms-of-reference document made executable: it is fixed by the planner bind at the moment the Cell is requested, travels into the sealed package unchanged, and the machine checks byte-for-byte that the admitted package's policy is identical to what was declared — a model or a discharge cannot widen its own remit between asking and receiving.

§Admission — how a Cell comes to exist, or does not

The sequence is the same eight registration records every time (admissionCeremonyRecords, one function, reused by every seat on the shelf): a knot waiting for the wanted Charter, a bind that authors it, a knot waiting for the canonical charter.defined, a knot waiting for the presented blueprint, a planner bind that — once both are present — asks for a Cell to be seeded under a policy fixed at registration, a knot waiting for the Cell's cell.result, and an evaluator bind demanding both the Charter and the result.

Seeding itself runs through admitCellPackage — a pure function, package in, plan or a list of errors out, all-or-nothing: no record is emitted until every check has passed. The checks are organised in ten groups covering, by the code's own count, seventeen individual rules (act-admit-blueprint.ts):

1. the package's outer shape is closed — no unrecognised field is silently accepted, and it declares version: 1;
2. the causal request that asked for this Cell exists, is unconsumed, and matches this seed's offset, key, bind and correlation id;
3. the Charter named by ref exists canonically, its key matches, and its digest matches both the package and the canonical definition;
4. the policy in the package is byte-identical to the policy declared when the Cell was first asked for;
5. the blueprint declares version 1, with no duplicate local ids and none using a reserved form (cell@…, …::…);
6. no listener or bind names a knot that is not local to the blueprint;
7. no local bind writes a protected lifecycle, review or export type;
8. exactly one bind is named as the producer of the declared result type, and it actually writes that type;
9. every fact type a local listener collects is either a reserved protocol type, one of the policy's declared accepts, or produced locally — nothing is heard from nowhere;
10. the blueprint's record count fits inside max_records.

Only a package that survives all of this is admitted — and admission is atomic with materialisation: local names are qualified (press.reader.gate becomes cell@37::press.reader.gate), every record is stamped home (which Cell it belongs to) and emittedBy (the planner's correlation id), and the Cell's cell.opened fact, its two records and its cell.context are written in that order — registration always lands before the first fact that could reach it.

§The lifecycle — four verdicts that never collapse

running → awaiting_assessment → ready_for_review → sealed
                                                   → archived
                          (any point, over budget or ceiling) → failed

The machine's own comment states the discipline plainly: "admission ≠ runtime success ≠ assessment ≠ human usefulness" — four distinct verdicts, four distinct facts (cell.opened, cell.result, cell.assessed, cell.reviewed/cell.sealed), never folded into one record. running becomes awaiting_assessment the moment the declared producer bind's answer lands. awaiting_assessment becomes ready_for_review only once an independent evaluator (checked mechanically: it may be neither the planner nor the producer) has graded every one of the Charter's criteria, with the aggregate recomputed by the machine from the Charter's own weights — a model-supplied aggregate is read and discarded. Only from ready_for_review can a human's cell.reviewed move the Cell to its one of two human-only terminals, sealed (accept) or archived (do not use); a premature or repeated review is refused and changes nothing.

§Routing — who hears what, and the one door out

Inside a Cell, facts qualified with :: (cell@37::press.reader.gate) route to that Cell's owner only — never to root, never to a sibling Cell. Outside, plain public facts route to root first, then to every open, subscribed Cell on the same lane whose declared accepts matches the fact's type — which is how the intention and, later, the person's own words reach a Cell's intake without being addressed to it by name.

Content leaves a Cell through exactly one gate: press.findings.accepted (or whichever type the policy's publish.accepted names) — a fact the machine itself writes, on acceptance, in an envelope that carries {cellRef, charterRef, assessmentOffset, reviewOffset, result}. This is the vector this whole book keeps returning to: the only authorised path by which anything a Cell produced can re-enter the study proper. A second, earlier-looking door — cell.result, public and visible at root the moment the producer bind answers — exists too, but only so the ceremony's own evaluator can grade the draft; it carries the raw content, but nothing in the study's declared vocabulary (a vector's findings slot, in the worked example) is ever filled from it. Only the accepted export, reached through represent (rail 4, the reuse move covered in 2.3), can fill a declared slot — which is exactly how the machine keeps "the evaluator peeked at a draft" and "the study accepted this finding" from ever being the same event.