The technology: the functions that enforce the contract

How exactly is this implemented at the program level, and how can a human and the system attest and verify a Cell's work.

Source: lib/core/cells/create-cell-space.ts, admit-cell-package.ts, materialise-cell-records.ts, lib/core/registers/{open-cell,close-cell,record-cell-result,record-cell-assessment,count-cell-effect}.ts, lib/application/act-review-cell.ts. A fully worked instance of every function below, with real offsets, is walked tuple by tuple in the companion technical reference for Cell cell@37.

§Admission, function by function

admitCellPackage (lib/core/cells/admit-cell-package.ts) is the whole of §7.3's seventeen checks, as one pure function: {seed offset & key, package, matched causal request, matched Charter, parent capability ceiling} in, {plan} or {errors: string[]} out — no side effect, nothing written, until the caller has a clean plan.

materialiseCellRecords rewrites the checked blueprint's local names into the Cell's own namespace — press.reader.gate becomes cell@37::press.reader.gate — and stamps every record home: {cellRef, localId} and emittedBy (the planner's own correlation id), so a replayed log can always say which admission produced which listener.

openCell (a register-file op) is the one place a Cell's registers actually land: lifecycle at running, every counter at zero, its own nested topology region created empty — inserted into an ordered map that CellSpace's routing later iterates in that same order.

CellSpace.handleSeed ties these together inside the routing processor: find the causal request named in the package's own provenance, find the canonical Charter by ref, call admitCellPackage, consume the request either way, and on success emit cell.opened followed immediately by the materialised records and the cell.context fact — in exactly that order, so the very next tuple to be propagated already has somewhere to land.

§While it is open

interceptCellEmissions is the effect policy made literal: every batch of emissions a Cell's own nested topology produces passes through this function before it is allowed to become part of the log at all. For each emission it calls countCellEffect (increment a counter, compare with the policy's ceiling), refuses any of the reserved lifecycle/review/accepted types outright ("generated topology may not write lifecycle, review or accepted types" — a Cell cannot forge its own attestation), and — for anything that would cross the membrane — checks the inference capability before letting it through. The first violation of any kind closes the Cell with one honest cell.failed and stops there; it does not try to explain further, because by definition nothing more from that Cell can be trusted.

recordCellResult moves the Cell from running to awaiting_assessment the moment the declared producer bind's answer lands — one register write, journalled, nothing more.

CellSpace.handleAssessmentProposal is where the machine checks its own quality-control step: is the causal request real and unconsumed; is the Cell actually awaiting_assessment; is the evaluator a different bind from both the planner and the producer (checked by identity, not by convention); does every graded criterion belong to the Charter, exactly once, with a grade in [0, 1] and an evidence offset that is real committed history. Only if every one of those holds does recordCellAssessment move the Cell to ready_for_review, with the aggregate recomputed — never trusted — from the Charter's own weights.

§Confirming or refusing — the one human-only door

CellSpace.handleReview is the entire mechanics of attestation. Given a cell.reviewed fact: an unknown Cell is refused; a Cell already sealed or archived is a silent no-op (repeating a settled decision changes nothing); a Cell not yet ready_for_review is refused by name, stating the state it is actually in. Only from ready_for_review does decision: "accept" do anything — and what it does is two things in one movement: closeCell to sealed, and the emission of the accepted export itself, in the policy's declared publish.accepted type, carrying {cellRef, charterRef, assessmentOffset, reviewOffset, result}. decision: "archive" closes the Cell the same way but emits no export at all — an archived Cell's finding never enters the study.

On the surface this whole function is reached by one gesture. huid/modules/cell-card.tsx shows the two controls — gold Attest · accept, ghost Archive — only while a Cell's lifecycle reads ready_for_review; either one posts POST /api/ingest/cell.review {cellRef, decision}, which resolves to actReviewCell (lib/application/act-review-cell.ts), which shapes exactly one cell.reviewed {cellRef, decision, actor} fact and commits it through the one write door (Part 6 traces this whole vertical stack for the same gesture). The actor is stamped by the calling ring from its own authenticated context — never read from the request body — so a Cell's review can always be attributed to a real person, not to whatever the client happened to send.

§Verification, two kinds

A Cell is checked twice before its finding can be used, by two different means, and the book keeps both distinct on purpose:

• Machine verification, automatic, on every Cell. The independence check on the evaluator; the budget and capability interception on every emission; the recomputed aggregate; the refusal of a premature or repeated review. None of this asks whether the finding is true — all of it asks whether the process was followed: a real brief, an independent grader, spend within the declared ceiling, one human decision and no more.
• Human verification, the analyst's own reading. Whether the finding is actually right — whether a status is misapplied, a quote loose, a fact missing — is never checked mechanically; it is what Attest or Archive is for. Part 4.3 shows this concretely on a real reading; a genuine analyst's mis-read (an announced number marked "happened" as though audited, a company's stated opinion marked "declared" instead of separated out as opinion) is caught this way, not by any check above.

§One instance, worked in full

Cell cell@37 in session loop-sem-1 (semantic class, Gemini 2.5 Flash) ran through every function on this page in order: seeded at offset 37 from a planner's request, opened with two records (cell@37::press.reader.gate, cell@37::press.reader.answer), its context committed at 41; asked at 49, answered at 52 (cell.result at 53); assessed at 56 (cell.assessed at 57, aggregate 0.9, recommendation accept); attested by the person at 58 (cell.sealed at 59, the accepted export at 60); returned into the vector's own slot at 63, released as the study's ledger entry at 65. Every one of these offsets, its journal, and the exact JSON payload is reproduced in the companion technical reference: open a Cell, ask the world, attest.