Proof Packs: verifiable evidence for governed agent actions.

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, an integrity digest, action name, agent label, decision, normalized amount, currency, policy label, reason code, latency, execution outcome, redaction status, integrity metadata, and verification status. Internal storage can preserve richer evidence for protected operators, while public pages show only sanitized fields.

Signed Proof Pack integrity. The current signed path covers full canonical content with a digest and Ed25519 signature. Verification is tenant scoped, validates the signing material and content digest, and checks hash-chain continuity; database append-only controls prevent normal application updates and deletes to the signed event record.

Record-level assurance. Authenticated verification reports the integrity and verification material available for each stored record. The public local digest demo is illustrative and is not the authenticated Proof Pack signature verifier.

Current assurance boundary. These controls provide application and database-layer tamper evidence. They do not claim HSM or KMS key custody, external anchoring, immunity from a database superuser, or absolute immutability.

This distinction matters. The public live board should demonstrate that governance is operating, not reveal the data it governs. A proof hash supports integrity checks. 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. A signed Proof Pack can connect the original decision to the post-action report and its hash-chain history.

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 the signed integrity path binds a decision to safe evidence, a full-content digest, an Ed25519 signature, and a hash chain. 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.

Use the evidence in context