Work and quality
How Hypervibe defines the outcome you want, tracks each attempt at it, and keeps verification, acceptance and cost as separate facts.
On this page
This page explains how a piece of work is defined, tracked, checked and accepted, and why a passing check is not the same as acceptance.
A commission fixes the outcome before work starts #
You give Hypervibe a goal by commissioning a task. The commission states the objective, the source to start from, the recipe Reactor runs to build and check the result, the acceptance criteria, a budget, a time limit, the verifier and the receiver. The verifier is never the agent that produced the result, and the receiver, who is you when you work alone, accepts or rejects it.
Hypervibe seals the commission before any work is dispatched, and the agent doing the work cannot weaken its criteria. A change makes a new revision with a new id, and runs already under way keep the terms they started with.
Every part of the work keeps its own identity #
The change a run proposes is its candidate: one exact change at one revision. Every verdict and every decision names the candidate it applies to.
| Identity | Names | Kept apart because |
|---|---|---|
| Task | The outcome, its owner, inputs and acceptance contract | One task can need several runs |
| Run | One execution against pinned inputs and policy | A later run never rewrites an earlier candidate or verdict |
| Attempt | Each physical try at a step of a run | Retries never become new tasks |
| Job | One admitted Reactor execution, with its snapshot and receipt | A build is what you ask for; a job is what Reactor admits |
| Operation | One logical request for one version of an action, kept across retries and reconnection | Repeating it returns the original result; different content under the same id is refused |
Stopping and recovering work are separate acts #
Closing a view detaches; it never cancels. A cancellation is a request. The request, the reported interruption, the stopped execution and the released resources are four separate facts. A timeout is an unknown outcome, not a refusal, and any effect or spend whose outcome is unknown stays held until it is reconciled.
Reconnecting resumes watching the work; it never sends the request again. Before anything is resubmitted, Rocket! asks shared Work what happened to the original operation. A Rocket! session is its journal, so it survives the process that runs it. One check the first release must pass on a single person's machine kills a running session, then resumes the same session from its journal with exactly one attempt.
A verdict and a decision are different facts #
| Fact | Who records it | What it settles |
|---|---|---|
| Request (the commission) | You | What counts as done |
| Receipt | The owner that did the work, such as Reactor for a job | What ran, where, and with what result |
| Verdict | A verifier that is not the producer | Whether the exact candidate passed the pinned checks |
| Disposition | The named receiver | Whether the candidate is accepted |
A verdict is pass, fail, inconclusive or error, and Read a receipt defines each one. Error means verification never reached a result, so it says nothing about the candidate. Until a verdict exists the result reads not checked, never pass, and a pass alone reads awaiting acceptance.
The receiver then accepts or rejects the exact candidate. A rejection gives one reason: needs revision, incorrect, wrong target, insufficient evidence, not needed or other. Needs revision leads to a new revision of the commission.
In the first release, Reactor runs verification; Rocket!'s own evaluations, which run as Reactor jobs, come in later releases. An evaluation pins its cases, rubric, verifier and acceptance threshold before the candidate runs, and reserves its own budget first, so the work cannot spend what the check needs. A missing output, a timeout or a skipped evaluator makes the result inconclusive, never accepted.
Projects, requirements and defects will need no outside tracker #
In later releases, projects, product requirements, product capabilities, tasks and defects become native records, and outside trackers such as Linear and GitHub become optional connectors. The first release uses only the commission, its acceptance contract and the disposition.
- A task belongs to one project and at most one parent task, and containment never loops.
- Recording where work was discovered never adds a blocking dependency on its own.
- A claim gives one agent or person a task for a time. It reserves nothing: Reactor and Throttle still admit compute and inference themselves.
- A defect keeps every occurrence. Only a fixed resolution counts as a verified repair, and it needs passing evidence on the exact candidate plus the receiver's acceptance.
- Nothing closes because of a commit, a merge, an agent message or a passing build.
A product capability is judged per acceptance criterion on five separate facts: included in an approved scope, claimed as built, verified on the exact candidate, accepted by the receiver, and available where it is needed. None stands in for another.
Outcome evidence counts the whole cohort #
Quality is measured on a cohort: a set of tasks fixed before the run. For the first release, one person's cohort reports the accepted fraction, the cost per accepted outcome and the share of cost still unknown. Rejected, pending and unknown results stay in the cohort, so choosing easy tasks cannot raise the score, and a late rejection stays attached to the original outcome and its cost.
What the outcomes reveal becomes proposed work. Promoting a changed policy, skill or recipe is its own authorized operation, and a verdict alone promotes nothing.
Where to go next #
- Read a receipt for one run's verdict, disposition and cost.
- Context and evidence for provenance and cost attribution.
- Reactor for builds, jobs and verification.
- Rocket! for the agent that does the work.
- Standings for what Planned means.