Glossary

The site uses its own words (brief, register, desk, statusgen, tombstone), sometimes before it stops to define them. This page defines them. Open it in a second tab and read the rest of the site alongside it.

This page is not the specification. Each entry is a short, reader-facing definition. Where a definition here and the referenced specification differ, the specification governs; a glossary is a map, not the territory.

The vocabulary is maintained in two places that are kept in step: the toolkit's own glossary and the public methodology glossary. A term is defined there and rendered here, so a correction lands once. The two sources were last reconciled entry by entry; where they disagreed, the disagreement is recorded below rather than quietly resolved.

Terms

bless: The single, pinned authority that can move an externally-authored item out of quarantine and into the work stream. If no such authority is configured, nobody can bless and everything from outside stays quarantined — the default is closed, not open.
board: The generated status page at the root of a repository. It is a single-writer artifact: nobody types it, and continuous integration recomputes it from the underlying workstream files and registers whenever a source changes. A branch never commits the board directly; its build instead lints the branch against the sources. See Lifecycle and statusgen.
brief: The unit of work: a self-contained scope-and-definition-of-done contract that one agent can execute without reading the rest of the plan. Its frontmatter, tables and verification rows carry the load-bearing facts; the prose only motivates. Outbound, we sometimes call it a work order. See Briefs.
capability vocabulary: A harness-neutral set of dispatch verbs — dispatch a worker, isolate a workspace, message an agent — that lets a brief describe what a harness must do without binding to any one harness's tool names. It is how the method stays portable across the agent runner a team already uses.
cell: One accountable unit — a lead plus its agent fleet — scoped either as its own repository or as its own directory tree. Cells are independent: a large organisation runs many of them, each carrying its own topology, and one cell may file issues into a repository it does not own but never modifies it. There is no global cross-cell registry, by design. See the public adoption guide.
claim: The signal that a brief already has an open branch against it. The priority queue drops claimed briefs so two sessions do not pick the same work; if the claim check itself cannot be read, the queue degrades to an unfiltered superset and says so rather than guessing.
desk: The generic name for a role window in the delivery pipeline — authoring work, dispatching it, reviewing pull requests, verifying merged work, and coordinating across the rest. An adopting team runs these as its own project-local skills. The desk vocabulary is how the method names its separated roles; the separation, not the naming, is the control. See Desk roles.
done: The lifecycle state after verified that additionally carries a recorded review verdict. A change on a risk-flagged path needs a review entry naming a person; a model's sign-off alone cannot close it. See Lifecycle.
drain: Working a queue — the post-merge verification queue, an open pull-request queue — continuously to empty, rather than sampling it once and walking away. An unwatched, undrained queue is how work rots half-finished.
evidence: The section of a brief filled in at implementation time: one row per verification item, each carrying the command, its exit code, the output or hash, the date, and who ran it. A non-implementer re-fills it on merged main to advance the work. See Lifecycle.
fan-out: The dispatch role that turns the priority queue into parallel worker agents, each implementing one brief in its own isolated workspace and opening a draft pull request.
gate: Whether a brief closes on a model's say-so or needs a named person. It is derived from risk, not chosen: all four risk answers — regulatory, customer, irreversible, sensitive-data — are recorded, and any yes forces a human gate. See Briefs.
implemented: The lifecycle state an implementer reaches when the work is finished and its evidence section is filled with its own run. Implementers stop here: verifying your own work is the narrator grading their own exam. See Lifecycle.
in-progress: The lifecycle state once a session owns a brief and is actively implementing it. See Lifecycle.
intake: The append-only register of raw ideas that are neither rejected nor yet scoped into a brief. An idea becomes work only when its disposition is flipped to scoped. See Registers.
next-up: The generated batch of briefs to pick next — weighted by priority and staleness, capped per workstream, and excluding briefs with an unresolved finding or an open claim. When the claim check is unavailable, the batch is an unfiltered superset and says so. Also called the priority queue.
pin: A line naming the exact released version, and hash, of a tool a repository depends on — so a reviewer sees a tool-source change in the diff instead of it happening silently underneath a workflow.
positive control: Proof that a check actually fails when the thing it guards is broken: break the guarded thing, run the check, confirm it goes red — required before trusting any clean report the check produces.
register: One of the append-only logs that sit alongside the workstreams as the system's memory. Entries are one file each and slug-identified; a withdrawal is a tombstone — the disposition is flipped and the file kept — never a deletion. See Registers. (This is the one term where the two source glossaries diverge — see the reconciliation note.)
review: The pre-merge quality pass on a working diff or an open pull request; the verdict is recorded, by an identity that did not author the change. It answers "well-built?" — a distinct question from verification's "works?", and neither substitutes for the other. See Lifecycle.
roster: The adopter configuration that decides who is trusted, which repositories they may write to, and which paths force a security review. It lives outside the work tree — never in a file a pull request could edit to admit itself.
statusgen: The reference implementation of the specifications: a single pinned program that generates the board from the workstream files and registers, lints a tree against the schemas, and exports the evidence bundle. It is the tool continuous integration runs — it is not the method itself, and a second conforming implementation would be legitimate. See statusgen.
stream: A named body of related briefs with its own README — frontmatter, a brief table, a critical path. Also called a workstream. An idea becomes a stream through a scoping document plus brief authoring. See Registers.
the-desk: The standing coordinator role: it watches the board, dispatches and adversarially verifies work, synthesises reviews, and keeps the registers honest — as opposed to the fan-out, review and verify windows, each of which runs its own loop over one slice of the pipeline. See Desk roles.
three-state instrument: Every check must report in three states, never two: checked-clean, checked-failed, or could-not-check. A result nobody obtained is never rounded up to a pass or down to a fail — "we could not look" is a distinct, recorded answer.
todo: The lifecycle state a brief starts in: authored, unclaimed, dependencies known. See Lifecycle.
tombstone: The withdrawal form for an append-only register entry: flip the entry's disposition to a withdrawn value and keep the file, never delete it. A deleted row is indistinguishable from one that never existed — precisely the property the registers exist to deny — so tombstoning is what makes "append-only" checkable rather than merely asserted. See Registers.
verified: The lifecycle state a non-implementer reaches by re-running the verification table on merged main and filling in the evidence — independent re-execution, the check that "works on my machine" survives contact with main. See Lifecycle.
verify: The post-merge role that drains the verification queue: a non-implementer runs each merged brief's checks, fills in the evidence, and advances the work from implemented, to verified, to done. Merging is not completion. See Lifecycle.
wave: A brief's position in the dependency graph: wave 0 has no dependencies; wave N depends only on briefs in strictly earlier waves. Waves are a projection of the dependency graph, not a hand-picked grouping. See Briefs.

Where the two sources disagree

The two glossaries this page is drawn from were reconciled entry by entry. They agree on almost everything; a handful of entries differ only in which document they point at, a consequence of one repository being published and the other not, and not a disagreement about any term.

One term diverges, and it is recorded here rather than silently merged:

The one divergence

register. The methodology specification names three append-only logs — findings, intake, and requirements. One operating repository instantiates only the first two, because it has no requirements register yet. The specification governs on the method; the operating tree's narrower reading is true of that tree and not of the method. The entry above states the shape both share and does not pick a side.

A vocabulary page that hides its own divergence is the same failure as a status board that hides a failing check. The reconciliation is dated at its source; if this note is older than the last edit to either source, treat it as could-not-check rather than as agreement.