Glossary

The terms this book relies on, in one alphabetical list: those the book coins or uses in its own way, and the established vocabulary of the machine, each tied to a real example from the walked session.

§Admission (the ceremony)

The fixed sequence by which a Cell comes to exist: a charter is wanted → authored → defined; a package (charter + blueprint + policy + context + provenance) is assembled by a planner bind and the ceremony discharge; the machine checks the package (some seventeen checks) and either opens the Cell — records first, context after — or rejects it registering nothing. The eight ceremony records are sown at the root under the prefix admit.<slot>--<seat>.

§Assessment

An independent grading of a Cell's result against its Charter's criteria, proposed by an evaluator bind (through the ceremony discharge, deterministic in this session: 0.9 for any non-empty result) and normalised by the machine: the aggregate is recomputed from the Charter's weights, the recommendation is recorded, and the Cell becomes ready for review. The machine assesses; it never decides.

§Attestation (review)

The person's committed decision on a Cell that is ready for review: Attest · accept commits cell.reviewed {cellRef, decision: accept, actor} — the Cell seals and exports; Archive closes it without export. The actor is stamped by the transport from its context, not taken from the page.

§Barrier (rendezvous)

An operator bind with several demands does nothing until a readiness snapshot for every demand is present in its scope; that waiting point is the barrier. The report in this session waited at its barrier for the four vectors; each ceremony's evaluator waited for both the charter and the result.

§Bind (operator bind, emit bind)

What fires on readiness. An operator bind waits for the readiness of its activation knot and of every knot it demands (its barrier), gathers their snapshots into a scope, and then either runs a local pure action (release@1 here) or asks the world with an instruction, the scope and a result schema. It fires once per lane (the one-shot latch). An emit bind simply republishes a knot's readiness snapshot as a fact of a declared type, every time.

§Blueprint

The inner topology of a Cell as records: its listeners, its binds, the declared result path (which bind writes which type). For a reader seat the blueprint is one intake listener and one answering bind. Presented to the admission ceremony, checked, then materialised with qualified names.

§Cell

An isolated working space opened for one delegated task: it has its own listeners and binds (their names qualified cell@N::…), a Charter, a policy (what it may hear, what it may do, budgets), and a lifecycle: running → awaiting_assessment → ready_for_review → sealed (or archived, or failed). Content leaves a Cell only as its accepted export, after the person's review. Facts private to a Cell reach the Cell only; public facts reach the root first and then the Cells whose policy accepts them.

§Charter

The written brief of a Cell: a title, a purpose, the question, and criteria (each with a weight and a minimum grade). Proposed by the ceremony from the seat and the person's words, made canonical by the machine under a ref charter@N with a digest, and used to grade the result.

§Fact (domain.fact)

A tuple of kind domain.fact whose payload is {factType, data}. The person's inputs, the world's answers and the machine's protocol records are all facts; they differ by type and by who committed them. Reserved type families (sys., cell., charter., service., inference., bind.) may not be committed through the facts door.

§Formation boundary

Not coined here either — the specification's own name (HUID 00 §5) for the rule that information is computed once, on the machine's side, and every surface only ever presents it. Central to Part 6.

§Intention id (uid)

The correlation id a bind mints when it fires — <bindId>#<n> — carried by its outgoing request and echoed by the answer. Consumers match answers to requests by this id, never by adjacency in the log. It is also the emittedBy stamp on records a bind's intention sowed.

§Journal

The machine's own record of every register transition it made while propagating or answering a tuple — station, register, action, detail, the function and file that made it, and the after-image. Stored one document per tuple (journal/<offset>) and one per ingress wave (journal/wave-<watermark>). The vault's log documents are built from it.

§Knot (activation knot)

A listener with named slots: for each slot a collection rule says which fact type fills it (with optional where clauses on the fact's fields), which field is taken, and whether the newest value replaces (latest) or values accumulate (append); a condition says when the knot is ready. On readiness the knot commits a sys.knot.ready tuple carrying the snapshot of its slots, then (by default) clears them. Examples: press.facts.wanted (slots question, findings), cell@37::press.reader.gate (slots question, material, ask).

§Lane (key)

Facts travel on a lane named by their key. The session's own lane is loop-sem-1; listeners accumulate separately per lane. A null key is the ambient lane — used for registration records and for the sheet's pins, which no programme's listener hears.

§Ledger entry

The vector bind's release: press.<vector>.found {question, findings} — the question the person asked and the findings the attested Cell returned, released by a pure local action as a bind publication. The four ledger entries and the report are the study's results on the released list.

§Lens (Focus · Sheet · Log)

The three ways the workbench shows one session: Focus — the released list on the left, the figures index on the right, one figure or one release in the centre; Sheet — the living document; Log → — the debug board with every tuple, its trace and the stations. Switching a lens is navigation (a URL parameter), never a commit.

§Line of reasoning

This book's own name for what Part 2 describes: a chain, or a converging set of chains, of knot-and-bind pairs, each one's output being what a later one was waiting for. Not a term the machine's own specification uses — a reader's word for a pattern in the wiring, covered in full in 2.1.

§Minimal fragment

This book's name for the smallest complete knot-and-bind pair — one listener, one doer, nothing else — following the codebase's own comment calling an example of exactly this shape "the smallest figure that runs." Covered in Part 3.

§Offset

The position of a tuple in the log, counted from 0 and dense (no gaps). Offsets are the addresses by which everything refers to everything else: a charter is charter@32 because its proposal is tuple #32; a Cell is cell@37 because its seed is #37; the freshness stamp as of offset N on the surface means "everything up to position N−1 has been folded in".

§Policy and budget

The fixed terms of a Cell, declared by the planner before the Cell exists and copied unchanged into the package: mode trial, isolation subscribed (public facts on the same lane reach it if their type is in accepts), raw input denied, capabilities (inference — it may ask the world), budgets (max_records, max_emissions, max_inference_calls), and the publish pair (its candidate result type and its accepted-export type).

§Programme and vector

A study protocol written as records (YAML on the shelf, never code). The press-release programme declares four vectors — Facts of interest, Areas of interest, Relations, Form of facts — each a knot with a question slot and a return socket and a bind that releases the vector's ledger entry, and a report bind that waits for all four. The front door's chooser selects a programme by reading the intention; the loader sows it.

§Rail

Not coined here — the project's own word for one numbered entry in its standing checklist of design principles, checked on every later decision. 5.4 gathers every rail this book cites into one table.

§Re-presentation (represent)

The move by which a committed value re-enters a declared hearing without being retyped: a represent.requested fact names the source (a tuple by session and offset, or an export carried in the request) and the target hearing (type, field, where clauses); the represent controller answers with one fact of the target type, the value placed as it is, stamped represented with its provenance and correlated to the request. Used twice per vector: to carry the intention into the Cell as material, and to carry the accepted export back into the slot.

§Readiness (sys.knot.ready)

The tuple a knot commits when its condition holds: {knotId, understanding} where understanding is the snapshot of its slots. Readiness is what activates binds; it is committed to the log so the activation chain is fully recorded.

§Reading (projection, fold)

Information formed from the log by a fold — a function stepping over tuples with a small state — and served to the surface with the offset up to which it was folded (asOfOffset). Readings used by the workbench: work-queue@1 (figures and their knots), publications@1 (the released list), figure-history@1 (what reached each knot), cell-lifecycle@1, sheet@1, trace@1 (one tuple by address). Folds are stored as images and advanced at commit time; nothing is computed in the browser.

§Registration record

A tuple of kind sys.knot.defined (a listener) or sys.descriptor.defined (a bind) that registers a piece of topology. Registration precedes the facts that reach it: a listener never receives facts committed before it existed. Records carry a null key.

§Result and accepted export

Inside a Cell, the declared producer bind's publication is the Cell's result (recorded as cell.result, a public fact). After the person accepts, the machine emits the accepted export — a fact of the policy's accepted type carrying the result in an envelope that names the Cell, the charter, the assessment and the review by offset. This envelope is the only way content leaves a Cell.

§Return (the return socket)

A knot may declare, at registration, which of its slots is its return — the slot a delegated answer will fill (findings on the vector knots). When a Cell is opened from that slot, the machine sows a return figure at the root that waits for the Cell's accepted export by cell ref and, holding the declared address, republishes it as a request to carry the export into the slot.

§Ring, contour

"Ring" is this book's word for what the specification itself calls a contour — one layer of Part 6's radial structure (K0 through K5). The two words name the same thing; this book prefers "ring" in its own prose and gives "contour" wherever it quotes the specification directly.

§Seat

A row of a blueprint set on the shelf: the parameters of one kind of Cell a slot may open — title, gloss, questions (the Charter's criteria), threshold, what it publishes, and for a reader seat the instruction and schema its inner bind asks the world with. Press reader is the seat used in this session.

§Service request

The fact an operator bind commits to ask the world: {bindId, uid, instruction, scope, schema, emit}. emit.writes names the type the answer must have; emit.cell (instead) asks for a Cell to be seeded under a fixed policy. Requests are indexed by their uid so that answers can be verified.

§The log (the wave log)

The append-only sequence of tuples that is the session's single source of truth. Every gesture on the surface, every answer of the world and every movement of the machine becomes tuples in it; every reading shown on the surface is a fold over it and can be rebuilt from it. In this session the log has 239 tuples (#0–#238).

§The sheet and pins

The living document of a session: the intention as its head, then the rows the person pinned, in pin order. A pin is a fact sheet.pinned {ref} on the ambient lane (a figure, a release, any tuple, or a Cell); removal is sheet.unpinned. The sheet is a fold of these facts, rebuilt from the log on every refresh, never browser-private.

§The three roads

This book's plain-English name for the wave API's three roots (/service, /ingest/{type}, /projection/{contract}) — see Part 5 for the machine's own names and the complete lists behind each road.

§The world (controllers, the membrane)

Everything outside the machine that answers requests: the language model (through the Gemini controller), the deterministic ceremony discharge, the programme loader, the represent controller. A second reader of the log (the membrane) offers every tuple to each controller once; a controller that claims a tuple answers it with records that re-enter the log, attributed to the tuple they answer.

§Tuple

One entry of the log. Every tuple has a kind (one of four: domain.fact, sys.knot.defined, sys.descriptor.defined, sys.knot.ready), a key (the lane it travels on, or null), a payload, and an offset — its position in the log, assigned when it was appended. Tuples are never edited or removed; the study's whole history is the sequence of tuples.

§Watermark (as of offset)

The number of tuples committed — the position the next tuple will take. The surface shows it as as of offset N; the session store guards every commit with it (a commit is refused if the stored watermark is not the one the request loaded).