The technology: declaring a return, carrying a value, tracking a lineage

How exactly is this implemented at the program level, and where the key vectors between planes actually run in code.

Source: lib/application/act-deepen.ts, lib/side/world/create-represent-controller.ts, lib/application/read-lineage.ts, lib/application/log-address.ts.

§Sowing a return, in two ingests, atomically

Opening a Cell from a declared slot is, underneath, exactly two write requests treated as one act — and the split is deliberate, not incidental. The first request runs the whole admission ceremony (7.3); only if that request's own receipt actually contains cell.opened does the act go on to the second request: sowing, at the root, a fresh listener whose two demands are the Cell's own accepted-export type (discriminated by the new Cell's own reference) and a return.declared fact naming the exact slot to carry it into — followed immediately by an emit descriptor that republishes that listener's readiness as a request to the represent controller. If the first request is refused, the second is never sent at all — nothing half-registers a return address for a Cell that does not exist.

// lib/application/act-deepen.ts, condensed
const admitted = await actAdmitBlueprint(app, session, { blueprint, accepts, charter, id });   // request one
if (!admitted.opened) throw new Error(/* admission was refused; stop here */);
await ingestAct(app, session, [
  knotDefined("return.cell-N.gate", { meta: { returnOf: { cellRef, slot } },
    wind: { collect: [ { as: "export",  match_type: acceptedType, where: [{ field: "cellRef", equals: cellRef }] },
                        { as: "address", match_type: "return.declared", where: [{ field: "cellRef", equals: cellRef }] } ] },
    condition: "export != null && address != null" }),
  descriptorDefined("return.cell-N", { subscribesTo: "return.cell-N.gate", actionConfig: { writes: "represent.requested" } }),
  fact("return.declared", { cellRef, slot, as: theSlotsOwnHearing, exportType: acceptedType })
]);   // request two

§The carrier, precisely

createRepresentController answers represent.requested facts through two code paths that collapse three request shapes into them. A return request — recognisable by carrying both an address and an export together — takes the export's own result and places it into the address's declared field as it is: a plain string stays a string, a structured finding stays a structure, never flattened into encoded text along the way. A person's request — {from: {session, offset}, as: {factType, field, where}, mode} — reads the named tuple straight from the log by its address, never through any computed reading, checks that it is an ordinary, open fact (a Cell's still-private material, or anything under a reserved name, is refused outright), and places its value the same way. A bind's delegated request is not a third code path at all — it unwraps into the very same handling as the person's own, because underneath it is asking for exactly the same thing on someone else's behalf. Every answer, whichever path produced it, is stamped represented with its origin, and correlated to its own request by an id — never by simply sitting next to it in the log.

§Tracking a chain across whole sessions

readLineage answers "what is this session's place in a larger line of reasoning" by reading, not maintaining. intentOf fetches a session's first handful of positions by address — never by loading and folding the whole session — until it finds the opening intent.given fact and, if present, the parent {session, bind, knot, hearing} it carries; readLineage then walks that chain of parents upward to a root, and separately scans every stored session for one whose own parent.session names the session in question, to find its children. Nothing about a lineage is a separate index kept in step with the log — it is recomputed, cheaply, from the log itself, every single time it is asked for.

Cheaply is worth a word of honesty: the first version of this function read each ancestor's whole history to find one fact near the start of it, and on a shelf of many sessions that made the lineage reading slow enough to visibly stall a busy screen — a defect found and fixed, mid-project, precisely by reading by address instead. The fix changed nothing about what the reading returns; it only stopped it from doing far more work than the question actually required — a small, concrete instance of Part 6.2's point that a reading is only as trustworthy as it is honest about the cost of asking it.

§One return, worked from real offsets

Cell cell@37's return, from the same worked session as Part 7.4, seen this time through the carrying mechanism rather than the Cell's own lifecycle: the return listener, sown at admission, fires the instant both the accepted export (offset 60) and the declared address (offset 44, committed before the Cell was even asked anything) are present — at offset 61; the represent controller answers at 62; its answer lands directly in the vector's own findings slot at 63, in the exact field the listener was told, at birth, to expect. Every offset here, and the exact JSON each one carries, is reproduced in the companion technical reference's attest step.