---
title: "Reactor"
summary: "How Reactor will admit, run and receipt builds, verification and agent tool calls on registered resources, and why its verdict is never the same as acceptance."
standing: "planned"
release: "No public release yet"
verified: "2026-11-09"
---

# Reactor

How Reactor will admit, run and receipt builds, verification and agent tool calls on registered resources, and why its verdict is never the same as acceptance.

> Standing: Planned. An approved future concept. Not available to install or run. Release: No public release yet.
>
> Hypervibe has no public release yet. Until one exists, no page here is Qualified and nothing can be installed from these docs. Every page states its standing, so you can tell an approved plan from something you can run.
>
> This is the Markdown copy of https://hypervibe.app/docs/products/reactor/

> Hypervibe has no public release. Everything on this page is **Planned**: an approved design you cannot run yet.

Reactor is Hypervibe's access broker and executor for registered resources. It runs builds, verification and agent tool calls, and it owns how Hypervibe itself is installed, updated and rolled back on a machine, including the managed GraphLake engine on a Just me machine. Every execution is admitted first, held under a lease while it runs, and closed by a receipt. Reactor succeeds an earlier build tool, BuildCTL, whose name survives only as a historical source and executable name.

## Reactor executes, and other owners decide

Reactor runs what other owners decided and returns evidence that cannot be mistaken for a claim. It keeps no scheduler or reservation ledger of its own, holds no credential and never calls a model.

| Decision | Owner |
|---|---|
| What work exists, and its reservations | Shared Work, the one owner of tasks and runs |
| Which resources and grants exist | The [Hypervibe service](https://hypervibe.app/docs/products/platform/), the platform's system of record |
| What an agent may do | Policy and your approval of the exact effect, rechecked by Reactor where it runs |
| Credentials | Throttle, which issues short-lived leases |
| Whether a result is accepted | The named receiver |

In the first release, Reactor reaches builds through an adapter to BuildCTL's own reservation service, which keeps the reservations until shared Work takes them over.

## Every execution passes one admission path

A **build** is what you ask for. A **job** is one admitted execution, with its source snapshot, attempts and receipt. Every resource kind passes the same steps:

1. A request arrives.
2. The grant is checked where the effect will happen.
3. Capacity is reserved on the shared Work path.
4. A lease binds the attempt to one holder; its generation number and fence stop an earlier holder from acting.
5. The resource kind's adapter runs the work.
6. A receipt records the outcome.

The first release covers builds, verification and the agent's tool calls: reading, writing, editing and patching files, searching, and running a shell command. Each tool call is rechecked against the effect you approved and receipted, and a repeat of the same attempt runs nothing a second time. A shell command left running in the background does not survive a restart of Hypervibe: afterwards its status reads unknown, and it is never re-attached. Every receipt names its isolation; in the first release that is none, and you are told there is no sandbox. Later releases add deployments and browser sessions as resource kinds, each with its own lifecycle and cleanup.

## A job builds exactly the source it was given

Reactor captures an immutable snapshot of the source, including staged and unstaged changes, untracked files and ignored inputs you explicitly include. Build caches are partitioned by snapshot, so output from an earlier tree is never reused under a later receipt. Recipes are owned by the repository; the Hypervibe service never writes one. Commands start from a cleared environment, and a credential reaches them only as a lease. A build's evidence includes the digest of what it produced, and in later releases a deployment uses exactly the digest that was evaluated.

## A receipt binds every result to its job

A receipt names the job, attempt, lease generation, worker, source revision, profile image and exit code. Evidence you fetch must match that job and source, or it is refused. Measured resource use joins the run's receipt, and a cost nobody priced reads unknown, never zero.

| Job state | Means |
|---|---|
| Passed | The only state shown as a pass |
| Failed, Timed out, Rejected | Ended without success |
| Cancelled | Stopped on request |
| Held | An integrity error; the reservation stays until the worker reconciles |
| Lost | No receipt, so the effects are unknown |

Any other state, such as Queued or Running, is shown as Reactor sent it and is never treated as finished. A lost record, an expired lease or a cancel request is not evidence that work stopped, so Reactor holds the outcome as unknown and resubmits only after a witnessed cancellation. A cancel names the job and attempt, and its receipt says whether the job stopped, had already finished, or could not be confirmed.

## Verification is independent and is not acceptance

A verdict comes from a verifier that is not the producer, on the exact candidate, the change a run proposes, and the base it was made against. It is pass, fail, inconclusive or error. Without a verdict the result reads *not checked*, which is never a pass; a timeout reads inconclusive; a producer's rewrite of the candidate is refused. A pass alone reads *awaiting acceptance*. Reactor defines the form of the receiver's decision but never records one: only the receiver accepts or rejects. In later releases, evaluators also run as Reactor jobs with pinned cases.

## Workers are registered, and capacity is conserved

A **worker** is an execution endpoint tied to the machine or virtual machine it runs on, with its qualified recipes, release and concurrency. Registration is not admission: a registered worker can still be unusable. A worker and its machine are two identities over the same capacity, not two supplies. In every capacity domain, new demand plus existing reservations, unresolved holds and outside use must fit what is allocatable.

For example (synthetic), a 64 GiB host keeps 8 GiB for its own system and runs two virtual machines, each allowed up to 40 GiB. The host must not advertise 80 GiB; together the two can be guaranteed at most 56 GiB.

Placement applies hard limits first, such as authority, architecture, toolchain, isolation and budget, then ranks what is eligible. Fleet sets the placement policy, and Reactor places each job within it; later releases explain each placement and its exclusions. In the first release's team record, the evidence that a whole run works for a team, a member's verdict runs on an enrolled machine under that member's name, and revoking that machine's standing fences it, as [Fleet](https://hypervibe.app/docs/products/fleet/#grants-bound-fleet-and-revocation-fences) explains. The first release runs on Linux on x86-64 only. macOS and Windows are **Unavailable**: they are not part of the first release.

## Where to go next

- [Work and quality](https://hypervibe.app/docs/work/) for verdicts, dispositions and the work records.
- [Fleet](https://hypervibe.app/docs/products/fleet/) for registered machines and placement policy.
- [Throttle](https://hypervibe.app/docs/products/throttle/) for credential leases and cost.
- [Install](https://hypervibe.app/docs/start/install/) for how setup is planned to work.