Reviewed technical capability record

HaltState Runtime Control Catalogue

Stable control identifiers for reviewed checks and integrations covering action declaration, active-governance decisions, Standard contract approval retry and reporting, replay-safe authority, 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. The live Standard contract is the compatibility route for existing integrations. The replay-safe action contract is implemented and canary verified, but is not the default or globally activated route, and mixed compatibility/replay routing is not yet implemented. Signed Proof Pack records are tenant-verifiable when their stored integrity metadata and verification material are present. Customer integrations still enforce the returned authority and destination side effect. 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, Canada, European Union, Singapore
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: Australia, 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: Australia, 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 Standard contract approval retry

Look up Standard contract approval retries by tenant and idempotency key

Reuse the latest Standard contract 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 Standard contract control is an approval retry lookup, not the replay-safe action contract. The replay-safe contract is implemented and canary verified but is not the default route, and mixed compatibility/replay routing is not yet implemented. Standard contract customers must still serialize attempts and prevent duplicate side effects.
Last verified: 2026-08-20

HS-REPORT-001 Outcome reporting

Receive a Standard contract execution report

Accept an authenticated Standard contract 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: The Standard contract report remains compatibility reporting rather than a replay-safe durable receipt. Replay-safe outcome receipts are implemented and canary verified on the replay contract, which is not the default route for existing integrations.
Last verified: 2026-08-20

HS-EVID-001 Proof evidence

Create signed, tenant-verifiable Proof Pack evidence

The current signed Proof Pack integrity path uses a full-content digest, Ed25519 signature, tenant-scoped verification, hash-chain validation, and database append-only controls.

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: Native control
Integration point: ProofPackService.create_proof_pack
Evidence: /live/
Applicable public mappings: Australia, Canada, European Union, Singapore
Customer responsibility: Supply accurate redacted evidence, use authenticated tenant-scoped verification, inspect the assurance reported for each stored record, and retain records according to policy.
Limitations: Signed verification applies only when the stored record reports the current integrity metadata. Current assurance does not claim HSM/KMS custody, external anchoring, immunity from database superusers, absolute immutability, or legal certification.
Last verified: 2026-08-20

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: Australia
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: Canada
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: Australia, 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 compatibility 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