This report describes the architecture, research context, and operating principles behind Halo-2.0. Private prompt templates, routing weights, security controls, and implementation-specific thresholds are intentionally omitted.
Executive finding
Autonomous systems should not ask users to infer success from motion. A spinner, animated status line, or confident final paragraph can communicate that activity occurred, but it cannot establish what changed, whether the action succeeded, which version of a file was inspected, or whether the delivered artifact satisfies the original request. Halo-2.0 treats a receipt as the smallest structured unit that connects a claim to runtime reality. Receipts are not decorative logs. They are the evidence substrate from which task completion, verification, replay, and user trust are computed.
The architecture described in the Oscerra specification is intentionally severe: the model proposes state transitions, while the runtime records, rejects, normalizes, pauses, repairs, or accepts them. Once accepted, the receipt becomes truth. The finalizer checks the model’s closing story against the task ledger, original mission, workspace state, receipts, open verification gaps, and outcome coverage. This design turns the agent from a narrator of work into a participant in a court of record. The model may explain; the runtime must prove.
This report develops that idea into a product principle. A good autonomous interface should be quiet while work is occurring and exact when work is complete. It should show users the artifacts, state changes, tests, sources, and unresolved limits that matter—without dumping raw telemetry or performing “progress theater.” The receipt system therefore has two audiences: machines need structured evidence for governance, while people need a concise, legible account of what happened.
Completion is not a sentence the model writes. It is a state the runtime can reconstruct from evidence.
The difference between narrative and evidence
A language model is optimized to produce a coherent continuation. Coherence is useful, but it can blur the distinction between an intended action, an attempted action, and a successful action. “I updated the configuration” may mean the model planned a patch, emitted a tool call, received a partial failure, or actually changed the file. Without an external record, the user and the next model see the same sentence in every case. Receipt-grounded systems separate these states.
A receipt records the operation that crossed the runtime boundary. For a terminal command it includes the command identity, working directory, timing, exit status, output reference, and discovered artifacts. For a file mutation it includes the target path, before and after digests, applied change, validation result, and snapshot. For a browser action it can include the target, resulting state, screenshot, and extracted observation. For research it can include the query, source URL, extraction time, and claim coverage. The receipt does not have to expose every field to the user, but the runtime must retain enough to audit the claim.
This distinction is common in mature technical systems. SLSA provenance describes an attestation that a build platform produced artifacts through a defined build process.2 The in-toto framework defines verifiable claims about how software was produced, and OpenTelemetry traces operations as spans with timestamps, attributes, events, and causal links.34 Halo applies a related intuition to agent work: the output is more trustworthy when the path that produced it is structured and inspectable.
Activity is not the same as decision-grade evidence
Receipt structure increases both inspectability and the value of the record for downstream decisions.
Mission contracts make receipts meaningful
Evidence is meaningful only relative to a claim. A passing test does not prove that the user received the requested artifact; a generated file does not prove that it builds; a browser screenshot does not prove that the correct route was deployed. Halo therefore begins with a mission packet and delivery contract. The packet records the original request, input and output paths, repository identity, allowed operations, verification expectations, and user-visible goal. The contract defines what completion must deliver.
Every later receipt can be evaluated against that contract. A terminal command may establish repository state. A read receipt may cover the file that controls the target behavior. A patch receipt may satisfy one task. A build receipt may verify structural correctness. A screenshot may verify visual behavior. The system does not treat these as interchangeable. It asks which requirement each receipt supports and whether any requirement remains uncovered.
This prevents evidence accumulation from becoming another form of theater. A session can generate hundreds of logs without proving the requested outcome. The contract lets the runtime prefer a small number of decisive receipts over a large volume of activity. It also gives the user a stable frame for the final explanation: what was requested, what was changed, how it was checked, and what remains uncertain.
Completion is a chain of admissible gates
Each layer narrows the gap between the user’s request and a verified final claim.
The task ledger is an evidence index
Halo’s task state machine distinguishes pending, ready, active, concluded, done, blocked, failed, rewritten, and deleted work. The distinction between concluded and done is especially important. A model may believe a task is complete, but settlement can wait for verification. To move a task to done, the agent submits evidence. The runtime can inspect whether that evidence cites receipts, manifest rows, file paths, or other non-vacuous proof.
The task ledger therefore serves as an index into the receipt graph. Each task knows what evidence settled it, and each receipt can be traced back to the action that produced it. If a task is rewritten, the ledger preserves that structural change. If a task is blocked, the reason and evidence remain visible. If the final answer claims that all work is complete, the finalizer can compare that claim with the ledger rather than trusting the model’s summary.
This also improves handoffs and compaction. Another model does not need to infer progress from a conversation. It can inspect the current tasks, their status, and their evidence. A user can see a concise task history without reading terminal output. The same structure powers replay, evaluation, and recovery after failure. Receipts become useful not because they are stored, but because they are connected to the units of work the user cares about.
Terminal receipts: from output to governed evidence
Terminal output is one of the noisiest parts of an engineering agent session. A command may emit thousands of lines, mix warnings with success, produce artifacts in several directories, or continue as a background job. Halo records terminal metadata separately from the model’s interpretation: command, directory, environment, start and end time, exit code, output log, and artifact paths. Large outputs receive preview blocks and a reference to the full log so the live context remains usable.
The system classifies output families such as code read, text read, directory listing, search result, test log, and build log. That classification determines what reflection is required. A test log should preserve failing tests and summary counts; a directory listing should preserve relevant paths; a code read should preserve ranges and file identity. The receipt is shaped around the evidence semantics of the operation rather than treating every stdout string alike.
Background work receives its own lifecycle. Starting a server or long build is not evidence of success. The runtime records the job identifier, observation events, completion state, and final output. A model that launches a command and immediately claims completion can be contradicted by the still-running job. This is a simple example of the core law: runtime state outranks model narrative.
Read receipts and exact coverage
Reading a file is an action with evidence consequences. A model may cite code it never actually saw, or it may read only the first portion of a file and assume the rest is irrelevant. Halo’s read-coverage layer infers read intent, merges intervals, detects overlap, and tracks exact digests. The forward-read registry can identify whether a current action was already covered, whether a read was superseded, and which output should be reflected.
This allows the runtime to ask a more precise question than “did the agent use the read tool?” It can ask whether the necessary bytes were seen. A patch that modifies a function should be supported by coverage of that function and its relevant surrounding context. A claim that a configuration key is absent should be supported by an appropriate search scope. A later file change invalidates stale coverage for the current version, while retaining the old receipt for comparison.
Read receipts also make compaction safer. The model can forget the raw file contents while the system remembers that lines 120–190 of digest D were inspected and supported decision X. If the decision is revisited, the exact source can be rehydrated. This is more reliable than preserving a paraphrase with no address back to the underlying code.
Mutation receipts: a change must have a before and after
A mutation receipt begins before the edit. The runtime captures the target state, path, digest, and often a snapshot. It then applies the patch through a governed mutation engine, validates syntax or structure where possible, and records the resulting digest and diff. If the patch fails partially, the receipt says so. If indentation recovery or fuzzy matching was used, that fact can be surfaced for additional verification. The model cannot convert a failed patch into a successful one by describing its intention.
Execution shadow and patch verification provide another boundary. A proposed change can be parsed or tested in a shadow context before it is accepted. The verification result becomes part of the receipt. This is particularly important for broad rewrites, generated files, and replacements where the textual patch may apply but break the program. The receipt therefore describes not only that bytes changed, but whether the mutation passed the relevant structural checks.
Snapshots make the evidence temporal. A final answer can link to the file as it existed at the turn that produced the claim, rather than a mutable path that may later change. This prevents a user from opening “the file” after several more turns and seeing a different state than the one the agent described. Temporal integrity turns receipts into stable references rather than ephemeral logs.
Reflection gates stop evidence from being skipped
A fast agent can be dangerously fluent. It may read a large error log, form an immediate guess, and queue mutations before it has extracted the decisive facts. Halo’s reflection gate can pause subsequent tool calls when a raw output requires governed interpretation. The model must identify what the output establishes, what remains uncertain, and which evidence should be retained. Only then can the queue continue.
This gate is not a demand for verbose chain-of-thought. The reflection can be compact and structured. Its purpose is to transform an unbounded payload into operational memory: failing target, relevant lines, likely cause, affected files, and next discriminating action. The full log remains available. What changes is that the next decision is grounded in an explicit receipt rather than a transient impression.
Reflection also creates a review point for multi-model routing. A specialist can return findings without mutating; a judge can compare several reflected outputs; the overseer can decide which evidence is sufficient to act. Because the reflections cite receipts, the system can transfer understanding across models without transferring every raw token.
Verification receipts
Verification is not one generic “check.” Different missions require different evidence. A code change may need syntax validation, targeted tests, a full build, and runtime behavior. A visual change may need screenshots at several breakpoints and confirmation that text is not cropped. A research report may need source coverage and citation checks. A generated document may need file existence, page count, and visual inspection. Halo’s delivery contract defines the required verification modes so the agent cannot satisfy a visual task with a build log alone.
Each verification operation produces its own receipt. The system can distinguish a test that passed before the mutation from a test that passed afterward, a subset from a full suite, and a warning from a failure. It can also record unavailable checks. If the environment lacks a browser or dependency, the final answer should disclose the gap rather than imply complete verification. Evidence quality includes honest limits.
Verification receipts can settle tasks or reveal new ones. A failed responsive screenshot may reopen a concluded interface task. A build failure may add a dependency repair task. This keeps the plan responsive to reality. Progress is not a one-way animation toward 100%; it is a state machine whose transitions are justified by evidence.
finish_run as a closeout court
The finalizer is where receipt-grounded autonomy becomes visible. Before Halo can close a mission, finish_run compares the proposed final narrative with the original request, task ledger, delivery contract, workspace state, receipt evidence, open verification gaps, and outcome coverage. It can reject closeout if tasks remain unsettled, evidence is weak, artifacts are missing, or the story overstates what happened. Finalization is a solo control operation rather than one more tool call in a batch.
This design solves a common agent problem: the model’s desire to be helpful can turn into premature closure. A model may reach a plausible answer and stop even though a file was not written, a test was not run, or the requested link was not produced. The finalizer has no need to preserve conversational optimism. It checks the record. If completion is not admissible, it returns the mission to execution with specific gaps.
When closeout succeeds, the final response can be concise because the evidence already exists. It can name the delivered artifacts, summarize material changes, cite verification, and disclose residual limits. The user does not need a transcript of every action. They need a readable receipt bundle connected to the actual outcome.
A receipt graph survives the model
Models may change or context may compact, while causal state remains addressable.
Receipts as provenance, not surveillance
The language of logging can suggest exhaustive surveillance, but Halo’s goal is narrower. A receipt should capture what is necessary to reconstruct and evaluate a state transition. It should not retain every hidden model token, private thought, or irrelevant environment detail. The architecture follows the same economy as provenance systems: identify the subject, activity, inputs, outputs, actor, time, and supporting metadata needed for trust.
W3C PROV defines provenance around entities, activities, and agents involved in producing a thing, while in-toto attestations bind claims to software subjects and predicate schemas. Halo’s receipt graph has a similar shape without claiming formal compliance: artifacts and file states are entities, tool calls are activities, models and runtime components are agents, and task evidence connects them. The similarity is useful because it suggests mature design patterns for causal links, versioning, and verification.
Privacy controls remain essential. Receipts can contain command output, paths, or source material that should not be exposed broadly. The user interface can render a concise public view while retaining restricted evidence for the session. Sharing a final artifact does not automatically share the entire agent trace. A trustworthy system must make proof available without turning proof into uncontrolled disclosure.
The user interface: quiet during work, exact at completion
Progress theater appears when an interface tries to reassure the user without possessing meaningful state. It adds animated steps, optimistic percentages, or model monologues that are weakly connected to the actual runtime. Halo instead derives interface events from the task ledger and receipts. A task becomes active because the runtime focused it. A file appears because it was created. A test result appears because the command completed. The UI can remain minimal because every visible state has a source.
The ideal completion view is layered. At the top: the outcome in ordinary language. Beneath it: delivered artifacts and the most important verification. Deeper inspection can reveal changed files, command receipts, screenshots, sources, and unresolved gaps. This allows a non-technical user to understand success while giving an engineer enough detail to audit it. The interface does not force everyone to read raw logs, and it does not hide the logs when they matter.
Receipts also improve interruption. If a session stops, the UI can show what completed, what was attempted, what failed, and what remains pending. The user receives a partial but truthful outcome instead of a frozen spinner. Autonomy becomes less risky because work is continuously convertible into an inspectable state.
Metrics for receipt quality
A receipt system should be evaluated on decision value, not storage volume. Useful metrics include claim coverage—the fraction of final claims supported by identifiable evidence; artifact reachability—the fraction of delivered outputs that can be opened; temporal correctness—whether links resolve to the state described; verification specificity—whether the check matches the requirement; and replayability—whether another model or human can reconstruct the task state from the record.
Noise is also measured. A system that stores every token may have perfect retention but poor usability. Halo can track how often users expand raw logs, how often agents reread evidence that already exists, and how many receipts are cited by no task or final claim. Unused evidence may still be valuable for audit, but persistent patterns reveal where the receipt schema is too verbose or the interface is surfacing the wrong level.
The strongest metric is recovery cost. After a model handoff, compaction, or interrupted session, how much work must be repeated before the next actor can proceed safely? Good receipts reduce that cost. They convert completed work into durable state rather than ephemeral model memory.
Failure modes and adversarial cases
Receipts can create false confidence if the schema records activity but not meaning. An exit code of zero does not prove the correct command was run. A screenshot does not prove the correct URL or breakpoint. A file digest proves identity but not quality. A test receipt can be misleading if the test suite does not cover the requested behavior. Halo therefore relates receipts to contracts, tasks, and coverage rather than treating their mere presence as proof.
Another risk is evidence laundering: a model cites a receipt whose content does not support the claim. The finalizer and adversarial reviewer can inspect the relationship between evidence and task. For high-risk operations, a different model may review the receipt. The system can also require exact references—output IDs, manifest rows, file ranges—instead of accepting vague phrases such as “tests passed.”
Receipts can become stale, duplicated, or inconsistent across stores. Atomic flushes, snapshots, digests, and memory coordination reduce this risk. A closeout should not proceed if the task ledger says done but the workspace snapshot predates the mutation, or if a receipt references a missing log. The record must be coherent enough to withstand disagreement among its own components.
Design principles
The first principle is that receipts should be generated by the runtime, not authored by the model. The model may annotate or interpret them, but it should not be able to fabricate the exit code, file digest, or screenshot reference. Second, receipts should be typed around the semantics of the action. Third, they should be addressable so compaction and model routing can cite them. Fourth, they should be minimal enough for routine use but expandable to full evidence.
The fifth principle is that completion evidence must be relative to the user’s contract. Sixth, temporal state must be explicit. Seventh, missing verification should remain visible. Eighth, the interface should summarize without severing the link to source evidence. Ninth, privacy and sharing boundaries should apply separately to artifacts and traces. Tenth, the finalizer should be empowered to reject a persuasive but unsupported ending.
Together these principles define a different relationship between models and software. The model is no longer the sole author of the session history. It is an actor whose proposals are mediated by a system of record. That constraint does not make the model less autonomous; it makes autonomy durable enough to trust.
A minimal receipt schema for autonomous work
A practical receipt does not need to expose every internal event. It needs a stable identity, the action family, the responsible runtime actor, the inputs that materially shaped the action, the output or state transition produced, and the verification status at the time it was recorded. For a shell command, this can include the normalized command, working directory, start and completion time, exit status, output reference, and artifact changes. For a file mutation, it can include the target path, pre-change and post-change digests, the applied edit family, validation results, and the snapshot from which the change can be reconstructed.
The schema should distinguish observations from assertions. “The command returned exit code zero” is an observation. “The application is correct” is an assertion that may require several observations and a contract-aware judgment. Mixing those categories produces brittle audit trails because later readers cannot tell whether a statement came from the runtime or from a model’s interpretation. Halo keeps typed runtime facts addressable, then allows task settlement and finalization to build higher-level conclusions over them.
Receipts should also express incompleteness. A browser run may prove that a page rendered at one viewport while leaving keyboard navigation untested. A unit test may validate a function while leaving integration behavior unresolved. A file may have been created but not opened from the final delivery path. Explicit coverage fields let the runtime say what the evidence supports and what it does not. This is more useful than a binary “verified” badge because it makes the next verification action computable.
| Field | Purpose | Example |
|---|---|---|
| Subject | The artifact or state being discussed. | src/router.ts at digest 9b… |
| Activity | The accepted runtime transition. | Patch applied, test executed, browser inspected. |
| Evidence | Addressable output supporting the claim. | Receipt V-7, screenshot B-3, log L-12. |
| Coverage | What the evidence does and does not establish. | Desktop route verified; mobile orientation pending. |
| Disposition | How the task state changed. | Concluded, settled, blocked, or returned for repair. |
Receipts enable safer delegation and recovery
A routed agent system can move responsibility between models only if completed work is independent of the model that performed it. Receipts provide that independence. The incoming model does not need to trust a prose handoff that says “the migration is done.” It can inspect the relevant mutation receipt, the current workspace digest, the targeted tests, and any unresolved coverage. This reduces the amount of historical conversation that must be carried into the new context and makes delegation less vulnerable to confident but inaccurate summaries.
The same property improves recovery after failure. If a process crashes, a provider times out, or a user returns days later, the session can be reconstructed from durable task state and evidence. The runtime knows which actions were admitted, which side effects occurred, and where the last coherent snapshot lives. It can avoid repeating expensive work and can distinguish an interrupted action from a completed one. Recovery becomes a state-reconciliation problem rather than an exercise in guessing what the previous model meant.
Receipts therefore connect the three reports in this series. Dynamic routing depends on portable responsibility; memory compaction depends on references that remain valid after prose is removed; and trustworthy completion depends on a final narrative that can be checked against the world. The receipt layer is the shared substrate. It allows cognition to be transient while the consequences of cognition remain durable, inspectable, and correctable.
Conclusion
“Receipts beat progress theater” is not an argument against beautiful interfaces or helpful progress. It is an argument that those experiences should be downstream of truth. The runtime should know which task is active, which action occurred, which artifact changed, and which verification passed before the interface animates certainty. When the evidence is weak, the product should communicate uncertainty rather than decorate it.
Halo-2.0 operationalizes this through mission contracts, task settlement, typed tool receipts, read coverage, snapshots, reflection gates, verification records, and a finalizer that checks the closing story against the actual workspace. These mechanisms turn long autonomous sessions into inspectable chains of state transitions. They also make model routing and memory compaction safer because the essential truth lives outside any one model’s context.
The ultimate product goal is simple: the user should be able to leave, return, and understand what happened without trusting a performance. A finished output should arrive with enough evidence to use it, enough history to audit it, and enough honesty to know what remains. That is the difference between an agent that looks busy and a system that can be held accountable for work.