Glossary

Every word the app's pages explain on hover, one line each with a link to the page that holds the detail, and the proposed new display names for the engine's own words.

One line for each term the window explains, grouped the way the pages group them. The words live in internal/canvas/static/glossary.mjs in four maps for the pages (MODEL_TERMS, SYSTEM_TERMS, SPEND_TERMS, ENGINE_TERMS) and GLOSSARY for the fields of a run's message. That file stays the source of the on-page tooltips and the "?" links; this page is a reading copy of it, so when the two differ the file is right. Where a term has no link its topic is not checked.

Renames are display only: the engine, wire formats and stored fields keep their names. The proposals are at the end.

01run message fields#

A run's message (a baton) carries these fields from node to node. See runs.

• ticket_id: the ticket this run is working on. See tickets.
• ticket_ids: every ticket in this run; more than one means a batch.
• batch_tickets: the id and title of each ticket in a batch.
• project_slug: the short name of the project the ticket belongs to. See harness-json.
• harness_launch: how the run was started: the branch, the workspace, the checks to run and the settings used. See launch.
• launched_from: where the run was started from: the chat, the card and the branch.
• ticket_context: the ticket as it was read: its title, description, column and comments.
• memory_context: what the project already remembers that bears on this ticket. See memory-and-search.
• search_notes: a note of what was searched for in memory and what was found.
• constraints: rules the work has to respect.
• research_challenge: risks and other ways of doing it, raised against the ticket before planning. See nodes.
• approach: how the planner means to do the work.
• review_acceptance_checks: the list of things that must be true for the work to count as done. See gates.
• operator_checks: things only the operator can check, like how it looks. Review never grades them.
• open_questions: things the planner could not settle and wants someone to look at.
• plan_brief: a short summary of the plan: the outcome, the steps and a title for each done-when item.
• doubts: things the worker is not sure about, and whether each was settled.
• changes: the files the worker changed and why.
• tests: the tests the worker added or ran.
• learnings: what the worker learned that is worth remembering next time.
• work_report: the worker's own account of what it did.
• workspace_handoff: the record of the workspace handed over for checking and review. See land-and-sync.
• checks_passed: whether every automatic check passed. See checks.
• check_run: each automatic check that ran, whether it passed and how long it took. See checks.
• accepted: whether the reviewer accepted the work.
• review_feedback: what the reviewer says about the work.
• needs_human: whether the reviewer wants the operator to look before it goes on.
• item_verdicts: for each done-when item, whether the reviewer found it met, with a note.
• human_decision: the operator's answer at the gate: approved, or sent back with a reason. See gates.
• scope_changes: done-when items dropped or moved to another ticket at the gate. See gates.
• landed: the commits made from the approved workspace. See land-and-sync.
• ticket_state: where the ticket ended up once the run closed it.
• missing: what evidence the closer found missing, in words, when it left the ticket open instead of completing it. See tickets.
• completion_evidence: the closer's summary of what was recorded as proof the ticket is done.
• headline: one short line saying what changed.

02the engine's words#

The engine's own words, with the display name the page uses or proposes. See runs and nodes.

• baton, shown as message: the set of fields a node passes on to the next. See runs.
• hop, shown as step count: how many cords a message has travelled since the run began; a run is sent to the operator when it passes the hop cap. See runs.
• envelope, shown as delivery: one message in transit, with its payload, the cord and node it is sent to, and its hop count.
• invocation, shown as round: one go of a node at its work; a node sent back runs again, as another invocation. See runs.
• topology revision, shown as plan version: which version of the run's layout of nodes and cords this was recorded against.
• patch revision, shown as board version: which version of the patch (the board's nodes and cords) a run was launched from.
• revision, shown as version: which saved version of a patch or its layout this is; a change makes a new one.
• inlet, shown as input: where a node takes messages in. See nodes.
• outlet, shown as output: where a node sends a message out; each outlet can feed a cord.
• cord, shown as link: a line from one node's outlet to another's inlet; messages travel along it.
• builtin, shown as smith step: a node smith runs itself (a gate, a router, a check, landing the work), not a model. See nodes.

03models page#

Tags, columns, levels and numbers on the models page. See models-and-presets.

• reasoning: thinks a problem through; plan asks for it by default, and the challenge step asks for it. See role tags.
• code: writes and changes code; work asks for it by default, and intake asks for it with fast.
• creative: writes and designs freely; no role asks for it by default.
• fast: answers quickly; intake asks for it with code, and close with cheap, by default.
• cheap: costs little per call; close asks for it, with fast, by default.
• long-context: reads a lot at once; no role asks for it by default.
• review: the review node, the review role, asking for review by default; it must differ from work.
• unknown tag: a tag smith does not know; the registry check refuses it, so a save with it is refused. See the registry.
• rank: how strongly the pool prefers this model; within a level's band the highest rank wins, except at a level that prefers the lowest.
• default rank: the rank the shipped pool gives this model; an override changes it in harness.json.
• override: harness.json's model_registry.override changes this model's rank or tags. See harness-json.
• model: the runtime that launches the model, and the model's id. See runtimes.
• tags: what the model is good for; a role is matched to a model carrying every tag it asks for.
• available (models page): whether this runtime's executable is on the path here; it says availability only, a launch does not check it.
• used by: which roles each level puts on this model.
• level: a preset, a rank band and effort the roles are matched at, its routes and its revise loops. See presets.
• quick, balanced, thorough, max: the shipped levels. Balanced is what a launch with no preset uses.
• intake, plan, work, close: the nodes whose roles get their own pick at each level.
• challenge: the step before the plan, any model from the pool with reasoning: off skips it, auto takes it when the pool has one.
• second review: a further review by a model other than review and work: off skips it, auto takes it when the pool has one.
• effort: the effort the level asks for; claude and codex take it, a runtime that takes none records it as not applied.
• PIN: the preset names this role's model; the pin wins over the level and the tags.
• off, auto, on: a route is skipped, is taken when the pool can serve it, or is required.
• can't be met: the launch resolver found no model for this level; a launch at it fails closed.
• pool: every model a launch can pick from: the shipped pool, trimmed and extended by harness.json.
• runs read: run journals the use was counted from; every run that moved in the window.
• no calls: no call to this model finished in the window.

04numbers from the journals#

Figures on the models, system and stats pages. A figure the runtime did not report reads "not reported" and is never counted as 0.

• calls: model calls that finished in the window.
• tokens: every token the calls read and wrote, cached context included.
• context read: tokens the calls read, cached context included.
• cached: the part of the context read that came from the cache.
• written: tokens the calls wrote.
• cached share: the cached part as a share of the context read; not reported when no call reported both.
• list price: what the runtimes say the calls would cost at list price; the subscription is what is billed.
• not reported: the runtime did not report this figure; it is left out, never counted as 0.
• run, ticket (spend table): the run, named for its board, and the ticket it worked on; a heading click sorts the table.
• window left, window: how much of each provider's usage window is used, as the runtime last reported it, and when it resets.

05system page#

The machine under live runs. See containment.

• live runs: runs going now and the nodes they have admitted.
• memory in use: the machine's memory in use, with the live runs' share of it in colour.
• memory, processes, cpu, cpu time, run time: what a node's unit holds now, against the limit its attempt was admitted with. cpu is counted in cores, and a unit at its quota is slowed, not killed.
• verdict: coping when the machine has room for another run; near a limit when any running node is at 80% or more of a limit; full when it has no room for another.
• near: at 80% or more of the memory, processes or run time an attempt was admitted with; past the limit it is killed.
• ran: what the node's finished attempts used, from the run's journal.
• not running: no attempt of this node is live.
• not contained: the node runs without a unit (uncontained development), so there is nothing to read.
• smith, the rest of the host: smith's share of the machine, and what the machine uses beyond it.
• live memory, live cpu, live processes: the figures of every running unit added up.
• host memory, available (system page), host cpus: the machine's totals; here available means memory.
• next run, room for another: what another run would be admitted with, and whether available memory holds it.
• disk, disk total, patch roots, work clones: what smith keeps on disk. See on-disk.
• core: the smith process serving the page, its version and the port.
• conductor: connected when this desk runs one. See conductor.
• discord: on when the bot is connected, off when it is switched off, has no token or is not set up. See discord.
• runtime: an agent cli that runs a node: ready, not installed, or can't start with the reason.
• search index, docs, skipped, failed, last run: what search can find, one source per kind of thing, with the documents indexed, left out, the sources that errored, and when each last ran. See memory-and-search.

available means memory on the system page and the executable being on the path on the models page, which is why the two maps are kept apart.

06proposed renames#

None of these is applied. The display name is the term itself unless a row says otherwise.