Glossary · Hypervibe Docs

The words Hypervibe uses, each with one meaning, and the historical names that still point to something real.

This page defines the words you meet in these docs and in the product, each with one meaning on every surface, and maps historical names to current ones. The words describe a product that is still Planned.

Each product word has one meaning #

Hypervibe is the platform, the fully managed agentic factory. Lanes, Rocket!, Throttle and Reactor are its components, and Products describes each one.

Word	Meaning
action	One operation in the command registry, with a stable identity shared by the command line, the composer, the Commands list and agent tools.
agent team	A versioned set of agent roles offered to a task, such as builder, critic and verifier, with their tools, model requirements and delegation limits.
build	What a person asks Reactor to run, such as compiling and testing exact source.
candidate	The exact change a run proposes, pinned to one revision; every verdict and decision names its candidate.
capability catalogue	Throttle's versioned record of what each model accepts, how its output may be replayed and what it costs, for every provider Throttle supports. It fails closed: a model it does not list is refused. It is not the capability registry, which holds extension packages.
command	What a surface sends to change something, with an operation id that a retry reuses so the effect is not repeated.
Commands	The searchable list of actions you can take where you are; searching selects an action and never runs it.
commission	What a Rocket! task must achieve and the terms it runs under, including its objective, source, recipe, budget, receiver and verifier; a revision is a new commission with a new id.
coordinator	The one lane each workspace names to receive its needs. A need travels from a lane to its coordinator, then to the fleet admin, the one such lane for the whole site.
decision	A question with two to four options that a lane's owner answers from any surface.
deployment profile	A planned way to set Hypervibe up, such as one person on one machine or a self-hosted team server. Setup pages call it a profile for short. Each one qualifies separately, with its own evidence.
device	A signed-in client with its own key, such as a laptop, a phone or a browser.
disposition	The receiver's decision on a result: accepted, or rejected with a reason. Until one exists, the result reads awaiting acceptance.
Fleet	The privileged operations workspace: a built-in Lanes workspace whose agents manage machines, placement and repair under explicit, revocable grants; it keeps no store of its own, and each action lands as another owner's record with a receipt.
grant	Permission for a subject to act with a capability at a scope. Only a grant authorizes, and it is checked again where the effect happens.
GraphLake	The derived evidence layer that joins lineage, context, work, cost and outcomes for queries, planned as a managed engine in the first release. Owners publish facts and keep control of money, grants and work; GraphLake projects those facts, states its coverage and authorizes nothing.
hold	Money reserved for a request before it settles. A hold is not spend, and spend whose outcome is unknown stays held until it is reconciled.
host	What runs on a machine and reports its liveness, such as the Lanes host that serves the directory of lanes, terminals and uploads.
`hyper`, `!hyper`	The planned command-line program, and its prefix inside a trusted Rocket! or Lanes composer. See Commands.
Hypervibe service	The platform's system of record: identity, configuration, grants, secret references, the capability registry and the inventory. It runs no work, installs nothing and never holds a credential value.
job	One admitted Reactor execution, with its snapshot, attempts and receipt.
lane	One addressable work seat, running an agent or a shell. Closing its view detaches and does not stop the work, and the lane outlives the processes behind it.
lease	A time-limited right for one holder, such as a credential value lent to one process for a stated purpose, or a job attempt held by one worker. A newer lease fences out an earlier holder.
machine	A computer. Fleet enrolls machines.
machine team	A group of machines with shared eligibility and reservation rules. Fleet manages machine teams, and Reactor places work on them.
managed file	A file in a workspace's repositories that the Platform inventories in one mode: canonical (written by people), projection (generated) or observed (not yet adopted).
model lane	Throttle's routing set for one model inside a pool.
organization	Holds teams of people. Organization roles decide what a member may change in the Platform.
paid route	Throttle's metered path for a pool's requests. It is used only for a model that has a list price, and a setting decides whether it is allowed.
Platform	Hypervibe's area of the web app, where identity and configuration live.
pool	A set of provider accounts that Throttle routes independently of every other pool. Pools are never added together.
profile	The settings that apply at one scope, built from layers: default, organization, team, you and this device. A later layer wins, but a preference never widens a policy.
projection	A managed file generated from Hypervibe's own records, such as settings, profiles and instructions. A hand edit shows as drift and is never silently overwritten.
queue lane	Reactor's scheduling key for jobs.
receipt	The durable record of a command's outcome: pending, done, not done or not confirmed yet. It is never a synonym for success, and it names its owner when that matters, such as a job receipt from Reactor.
receiver	Who accepts or rejects a result. When you work alone, that is you.
recipe	The repository's own steps that Reactor runs to build and check exact source; a commission names the recipe its verifier runs. A workspace recipe is a different record, which requests a workspace's source, tools, services and checks.
result	What a commission delivered: the candidate with its verdict, evidence, limitations and cost. Unknown cost reads Unknown, never $0.
run	One execution against pinned inputs and policy. Starting a workflow creates a run.
run receipt	The one document that shows a commissioned run's attempts, verdict, disposition and full cost. It joins records other owners keep and owns none of them. See Read a receipt.
secret reference	The name of a secret and who holds its value, never the value itself. Throttle holds every credential value.
session	Rocket!'s resumable journal of one agent's work: an append-only journal and its index. After a kill, it resumes as the same session.
setting	One configurable value, kept as a record with an owner, a scope and a revision. Its key starts with the owning component, such as `lanes.` or `reactor.`.
shared Work	The one owner of tasks, runs, attempts, dependencies and claims. Every executor uses it, and no component keeps a second task queue.
single-person record, team record	The two records the first release needs: evidence that a whole run works on clean machines for one person, and for a team. See Releases.
standing	How far a subject has come: Qualified, Preview, Planned, Unavailable, Unknown or Deprecated. See Standings.
task	An outcome with an owner, inputs and an acceptance contract. It may take several runs.
team	A group of people in an organization.
verdict	The result of an independent check of one candidate: pass, fail, inconclusive or error. It comes from a verifier other than the producer and is never acceptance.
verifier	Who checks a candidate independently and returns the verdict. A verifier is never the candidate's producer.
worker	Reactor's host for jobs, never a Lanes host.
workflow	A named, versioned way to reach an outcome, such as code, research or verify, with inputs, a plan, an output and a verifier.
workspace	The governed container of lanes, repositories and identities, with its mandate and effective profile. It can span directories and machines.

Similar words are always qualified #

A bare lane is always the Lanes work seat. Reactor's scheduling key is a queue lane and Throttle's routing set is a model lane, and neither is ever shortened to lane. A bare team is always people; a machine team belongs to Fleet and an agent team to Rocket!. A machine is a computer, a host is what runs on it, a device is a signed-in client and a worker is Reactor's host for jobs; none stands in for another. A session is Rocket!'s journal, never the lane that shows it and never a sign-in.

Four records stay separate #

The design never merges these into one status, and none implies the next.

Record	Comes from	What it says
Request	You or an agent, through any surface, with an operation id	What was asked for
Receipt	The owner of the effect	What the owner did with the request
Verdict	A verifier other than the producer	Whether one candidate passed an independent check
Disposition	The receiver	Whether the result is accepted or rejected

A receipt is not a verdict, and a pass alone reads awaiting acceptance. Cost that nobody measured reads Unknown, never zero.

Historical names point to current ones #

These names appear in older material and in some interfaces kept for compatibility. A name that was only ever proposed and then rejected never becomes an alias, even if an earlier draft used it.

Earlier name	Current name	What still uses it
BuildCTL, `buildctl`	Reactor	Older material; the `buildctl` program may continue as a compatibility entry point to the same commands
`hv`, `hypervibe`	`hyper`	Planned compatibility names that enter the same command system
Studio, Studio host	Lanes; the host	Existing Studio interfaces, kept as compatibility contracts
board	workspace	Some key-map identifiers keep the word as code
paid lane, paid overflow	paid route	Configuration keys keep the word overflow
`.hypervibe/`, `~/.throttle` and other per-tool folders	`.hyper/` in a repository, `~/.hyper/` on a machine	The earlier tools that still read them. Setup in the first release moves nothing out of them; a later release plans to move each once, with a receipt, when Hypervibe replaces the tool that reads it

Where to go next #

Products describes each component and what it owns.
Commands shows how actions, commands and the !hyper prefix fit together.
Receipts explains how to read a receipt, a verdict and a disposition.
Standings explains what each standing word requires.
Architecture shows who owns each decision.