Replay Safety
The replay-safe action contract is implemented and canary verified, while the live Standard contract remains the default compatibility route for existing integrations.
Current production boundary
The replay-safe action contract is implemented and was proved through a controlled synthetic production canary. It is not the default route for existing KU integrations and is not globally activated for the internal client population. The operational Standard contract, also called the Compatibility contract, remains the current route. Mixed compatibility/replay routing is not yet implemented.
SDK candidate verification is language-specific: Python, TypeScript, Go, and Java have their own executable evidence, while a Rust toolchain was unavailable on this host, so Rust remains source-reviewed and executable verification remains pending. Published SDK baselines remain distinct from replay-safe source candidates.
Capability status
| Capability | Status | Current boundary |
|---|---|---|
| Standard contract | Live | Operational route for existing KU integrations. |
| Replay-safe action contract | Canary verified | Implemented and proved through a controlled synthetic production canary; not the default or globally activated route. |
| Replay rollout and mixed routing | Partial | Global replay activation is gated by integration enrolment, and mixed compatibility/replay routing is not yet implemented. |
| SDK replay parity | Source candidate | Python, TypeScript/JavaScript, Go, Java, and Rust exist; replay parity and registry maturity vary by language. |
| Hardware key custody and external anchoring | Optional hardening | HSM/KMS custody and external transparency anchoring are not part of the current assurance. |
Exact operation binding
Each tenant and idempotency key binds the exact agent identity, action or tool, resource, normalized parameters, and risk class. The decision stores an immutable policy snapshot, including the evaluated policy ID and policy version. An exact retry replays that decision; a changed proposal conflicts instead of silently authorizing a different operation.
Activation epoch and delayed calls
The database-owned activation epoch fences newly admitted work after the closed cutover. SDKs may create hsr1:<epoch>:<uuid> only for generated keys when the caller omitted a key; explicit keys are never transformed. Raw or stale-epoch new keys terminate as expired without policy evaluation. Delayed pre-cutover calls must be drained, quarantined, or sent to destination reconciliation, never translated into the new namespace.
Approval, permit, and terminal replay
Approvals expire at the database deadline. An eligible operation receives one expiring single-use permit. A later retry after permit issuance returns terminal already_started; a completed operation is terminal too. Expired or malformed authority never enters the side-effect body.
Durable outcome receipt
Guard completion uses a caller-stable report ID and the same operation identity, permit token, and report payload on retry. Receipt validation requires received=true, receipt_event_id, receipt_hash, and a boolean duplicate marker. A malformed 2xx response is not success. An exact retry returns the original durable outcome receipt; conflicting content fails closed without rerunning the side effect.
Hash-chain scope
Policy decisions, approval transitions, permit issuance, and outcomes are hash-chained in append-only application evidence. The verifier checks sequence continuity, previous-hash linkage, and event hashes without re-executing the tool. The chain is tamper-evident at the application layer; it is not externally anchored, immune to a database superuser, or a transparency log.
Destination idempotency and reconciliation
HaltState authority does not make an external side effect exactly once. Destination idempotency remains separate and customer-owned. If a permit response is lost or an operation has a permit but no confirmed receipt, operators must perform reconciliation against the destination before any further action; a retry cannot obtain replacement authority.
Implementation notes
Keep the HaltState call as close as possible to the side effect. The agent may plan and draft freely, but the wrapper around the actual action should be the place where authority is checked. That wrapper should send only the context required for policy evaluation: safe identifiers, normalized amounts, action names, risk flags, schedule windows, and redaction status. Raw customer payloads and secrets should stay in the business system or protected operator tooling.
Operational evidence
For each action, preserve the decision, the worker outcome, the idempotency key, safe resource references, latency, proof status, and redaction status. This evidence supports incident response and control narratives because it shows what the system did at runtime rather than only describing what the policy document intended. HaltState supports alignment work; it is not a substitute for legal advice or a compliance certification.