Proof Packs: verifiable evidence for every agent decision.

Why logs are not enough

Agent systems often produce logs after an action has already happened. That is useful for debugging, but it is not enough for governance. A retail operator, security reviewer, or compliance team needs to know what the agent attempted, what authority was checked, what policy decided, whether human approval was required, whether the action executed, and whether sensitive data was redacted before evidence moved to a public or semi-public surface.

Proof Packs are HaltState's evidence bundle for that chain. They are designed to reconstruct the control path around a business action without exposing the full raw payload. A Proof Pack can include safe identifiers, a proof hash, action name, agent label, decision, normalized amount, currency, policy label, reason code, latency, execution outcome, redaction status, and signature or hash status. Internal storage can preserve richer evidence for protected operators, while public pages show only sanitized fields.

This distinction matters. The public live board should demonstrate that governance is operating, not reveal the data it governs. A proof hash can show continuity. A redaction status can show that customer data was intentionally excluded. A reason code can explain why a refund was denied without publishing the customer's history or private order record.

Proof Pack lifecycle

The lifecycle starts before execution. The worker submits a guarded action with an idempotency key and safe context. HaltState records the decision path. If the action is allowed, the worker performs the side effect and reports the outcome. If approval is required, the worker records pending state and does not execute. If the action is denied, the worker records denial and stops. If execution succeeds, the Proof Pack can connect the original decision to the post-action report.

For the retail refund agent, this means a low-risk refund produces an ALLOW decision, an execution record, a success report, and proof evidence. A medium-risk refund can produce APPROVAL_REQUIRED and no execution until a later approved retry. A high-risk or duplicate refund produces DENY and no execution. Those outcomes are materially different, and the Proof Pack preserves the difference.

Evidence should be durable, but publication should be selective. The public live board may show the agent name, action, decision, safe amount, currency, reason code, proof status, redaction status, latency, and hashed references. Protected operator tools can show ledger state, internal notes, and richer proof context. Customer names, emails, card data, raw order payloads, API keys, tenant secrets, raw policy IDs, and approval IDs should not be exposed publicly.

Governance use cases

Proof Packs support incident response by answering the basic timeline questions: when did the agent attempt the action, what did it ask to do, which guard decision was returned, did it execute, and what evidence was redacted? They support internal controls by showing that policy checks are happening at runtime, not only documented in a control spreadsheet. They support customer trust conversations by giving operators a precise explanation of why a refund, message, or data request was allowed, paused, or denied.

They also support governance alignment work. Teams mapping AI systems to frameworks such as NIST AI RMF, ISO/IEC 42001, SOC 2 control narratives, EU AI Act operational programs, or SB 53 / TFAIA-style transparency expectations need evidence that controls operate. HaltState can provide that operational evidence. It does not guarantee compliance by itself, and organizations should still review their legal obligations, retention policies, approval authority, and customer notice requirements.

A good Proof Pack is therefore both technical and practical. It is technical because it binds a decision to safe evidence and a hash. It is practical because an operator can use it to answer a real question during an audit, incident, support escalation, or executive review without exposing data that should stay private.

Teams should define a retention and access model before they scale the pattern. Public proof fields can be short-lived and sanitized. Protected Proof Packs may need longer retention for internal audits, dispute response, or incident review. Access should be role-based, and exports should preserve redaction rules. The strongest posture is to make the evidence useful enough for review while making accidental disclosure difficult by default.

For developers, the integration rule is straightforward: create proof after the guard decision and after the worker knows what happened. A policy allow without an execution report is incomplete evidence. A denial without a reason code is difficult to operate. A public feed row without redaction status is risky. A good Proof Pack ties those details together so the organization can explain agent behavior later.