Reviewed technical capability record

HaltState Runtime Control Catalogue

Stable control identifiers for reviewed checks and integrations covering action declaration, active-governance decisions, approval retry lookup, best-effort outcome reporting, evidence handling, redaction, selected refund-worker failure handling, and external stop signals. Each applies only at the capability and integration boundary stated below.

Capability status matters. Native controls are implemented in HaltState. Demonstrated integrations are limited to the named workflow. Customer integrations require the customer's worker or system to enforce the boundary. These labels do not establish universal fail-closed behavior, verified evidence hashes, guaranteed replay protection, durable report attachment, or native rollback. This catalogue is not legal certification.

HS-IDENT-001 Agent attribution

Attribute a proposed action to a declared agent

Bind each guard request and evidence record to a stable agent label within the authenticated tenant context.

Enforcement point: Guard request ingestion and decision recording.
Decision outcomes: Not decision-bearing
Capability status: Native control
Integration point: /api/haltstate/sentinel/action/guard
Evidence: /haltstate/docs/guard-pattern
Applicable public mappings: Australia, European Union
Customer responsibility: Provide a trustworthy agent label and protect the tenant credentials that establish request scope.
Limitations: The agent label is caller-supplied attribution metadata, not cryptographic workload identity or proof of the human principal.
Last verified: 2026-07-26

HS-ACTION-001 Action declaration

Declare the business action before its side effect

Submit the intended action and bounded context to HaltState before the protected system is changed.

Enforcement point: Immediately before the customer-owned tool or business action executes.
Decision outcomes: Not decision-bearing
Capability status: Native control
Integration point: /api/haltstate/sentinel/action/guard
Evidence: /haltstate/docs/guard-pattern
Applicable public mappings: Australia, Canada, European Union, Singapore
Customer responsibility: Wrap every protected side effect and remove unguarded execution paths.
Limitations: The customer must place the guard call before every protected side effect and must not provide an unguarded bypass.
Last verified: 2026-07-26

HS-DECIDE-001 Pre-execution decision

Return a policy result under active governance

When the trial is active and policy loading succeeds, evaluate a declared action and return ALLOW, APPROVAL_REQUIRED, or DENY before execution.

Enforcement point: Between action declaration and the protected side effect.
Decision outcomes: ALLOW, APPROVAL_REQUIRED, DENY
Capability status: Native control
Integration point: /api/haltstate/sentinel/action/guard
Evidence: /live/ /haltstate/docs/guard-pattern
Applicable public mappings: Canada, Singapore
Customer responsibility: Treat the returned decision as authority, execute only an allowed or later-approved action, and monitor trial state and policy availability.
Limitations: Expired trials bypass governance and return allowed with governance inactive. A policy-load failure returns an empty policy set, and no matching policy defaults to ALLOW. Customers must not treat this control as fail-closed.
Last verified: 2026-07-26

HS-APPROVAL-001 Human approval

Hold a guarded action for human approval

Prevent execution while a selected action awaits an authorised decision.

Enforcement point: After an approval-required decision and before any customer-side execution.
Decision outcomes: APPROVAL_REQUIRED
Capability status: Native control
Integration point: /api/haltstate/sentinel/action/guard
Evidence: /haltstate/docs/approval-lifecycle /live/
Applicable public mappings: Canada, Singapore
Customer responsibility: Persist the pending operation and prevent execution until an authorised approval is returned.
Limitations: The customer worker must persist the pending business operation and retry only after an approved decision.
Last verified: 2026-07-26

HS-REPLAY-001 Approval retry lookup

Look up approval retries by tenant and idempotency key

Reuse the latest approval row found for a tenant and caller-provided idempotency key.

Enforcement point: Guard approval lookup before a new approval is created.
Decision outcomes: APPROVAL_REQUIRED
Capability status: Native control
Integration point: /api/haltstate/sentinel/action/guard
Evidence: /haltstate/docs/approval-lifecycle
Applicable public mappings: Canada
Customer responsibility: Choose a collision-resistant stable key, serialize attempts per operation, persist a customer ledger, verify action and agent binding, and make target execution idempotent.
Limitations: This is an approval retry lookup, not guaranteed replay protection. The database index is non-unique, lookup and insert are not atomic, and lookup is not bound to action or agent. Immediate ALLOW and DENY results are reevaluated; customers must serialize attempts and prevent duplicate side effects.
Last verified: 2026-07-26

HS-REPORT-001 Outcome reporting

Receive and best-effort record an execution report

Accept an authenticated guard report, attempt to update a matching approval context, write an action-log entry, and emit a runtime event.

Enforcement point: After allowed execution succeeds or fails.
Decision outcomes: Not decision-bearing
Capability status: Native control
Integration point: /api/haltstate/sentinel/action/guard/report
Evidence: /live/
Applicable public mappings: Australia, Canada, European Union, Singapore
Customer responsibility: Report the final execution result accurately, retain the operation-to-report binding in the customer ledger, and verify durable receipt when that matters.
Limitations: This is report receipt and best-effort recording, not proof that a guarded action was durably linked. Immediate ALLOW can have no approval row; the endpoint does not check whether its UPDATE matched a row; the idempotency key is not written to the action log; and event emission failures are ignored.
Last verified: 2026-07-26

HS-EVID-001 Proof evidence

Hash a redacted refund evidence document before proof storage

The refund worker computes SHA-256 over the canonicalized redacted in-memory evidence document and stores that digest beside a logical haltstate:// artifact URI in a Proof Pack.

Enforcement point: After the governed workflow has a final decision and before the demonstrated refund execution is recorded.
Decision outcomes: Not decision-bearing
Capability status: Demonstrated integration
Integration point: ProofPackService.create_proof_pack
Evidence: /live/
Applicable public mappings: Australia, Canada, European Union
Customer responsibility: Supply accurate redacted evidence, independently verify exported evidence when integrity assurance is required, and retain records according to policy.
Limitations: The artifact URI is logical and the verifier does not recompute the embedded action-evidence hash. The live page demonstrates Proof Pack integration only, not evidence integrity. This is not a digital signature, external timestamp, immutable store, or legal certification.
Last verified: 2026-07-26

HS-REDACT-001 Public evidence redaction

Expose a bounded sanitized refund projection

For allowlisted refund events, publish a fixed refund parameter and result subset while preserving the event action and status last_action labels.

Enforcement point: Public live-status and feed serialization.
Decision outcomes: Not decision-bearing
Capability status: Demonstrated integration
Integration point: /ops/api/live/status /ops/api/live/feed
Evidence: /live/
Applicable public mappings: No public mapping assigned
Customer responsibility: Use controlled non-sensitive action labels and review access control and redaction for private exports and customer-specific fields.
Limitations: The refund params and result fields use a bounded allowlist, but action and last_action are passed through from caller-controlled event and status data. Integrators must use controlled non-sensitive action labels. This does not establish redaction for private exports or arbitrary non-refund fields.
Last verified: 2026-07-26

HS-FAILCLOSED-001 Failure handling

Demonstrate no-execution handling for selected refund-worker failures

In the retail refund worker, avoid simulated execution after a guard transport or exception failure, an unrecognised guard status, or a Proof Pack exception before execution.

Enforcement point: Customer worker error path before execution.
Decision outcomes: ERROR
Capability status: Demonstrated integration
Integration point: core.haltstate.refund_agent.process_next_refund
Evidence: /haltstate/docs/refund-agent-example
Applicable public mappings: No public mapping assigned
Customer responsibility: Implement and test explicit failure handling, policy availability checks, recovery, and execution idempotency in every customer-owned high-risk worker.
Limitations: This is limited to the demonstrated retail refund worker transport, exception, unrecognised-status, and pre-execution evidence paths; it is not a universal fail-closed guarantee. It does not cover expired-trial governance bypass or policy-load empty/default-ALLOW paths. Guard-call exceptions mark ERROR; a Proof Pack exception stops before execution but can leave the row ALLOWED and requires operator recovery.
Last verified: 2026-07-26

HS-STOP-001 External stop signal

Receive an external kill-switch signal

Let a credentialed integrated agent poll for a tenant- or agent-scoped kill signal outside its own reasoning loop.

Enforcement point: Agent heartbeat or customer integration checkpoint.
Decision outcomes: KILL
Capability status: Customer integration required
Integration point: /api/haltstate/sentinel/heartbeat
Evidence: /haltstate/docs/typescript-sdk
Applicable public mappings: Canada, Singapore
Customer responsibility: Poll with tenant credentials, obey kill or pause status, and operate a tested pause, rollback, or recovery procedure appropriate to the protected system.
Limitations: Kill-switch activation uses a 3,600-second (one-hour) TTL. The heartbeat protocol returns OK, PAUSE, or KILL, returns OK on backend-check failure, and gives unauthenticated legacy polling only a status-only OK. The customer agent must poll and obey it; HaltState does not force termination, roll back completed actions, or return customer systems to a safe state.
Last verified: 2026-07-26

Use the catalogue in a real deployment review.

Map high-risk agent actions to control IDs, identify customer-owned integration work, and review the evidence links and stated limitations for each tested outcome.

Discuss governance readiness See the demonstrated live integration