Release and holds · Integrity Docs

Enforce requires its release checks to complete before returning customer content. Observe records review after relaying admitted traffic. A hold is an explicit unresolved outcome, not a suggestion to bypass Integrity.

Released, held, and uncertain#

State	Application response
Released	Consume the complete response. Execute tools only through the application’s authorized execution boundary.
Held	Stop the affected work; inspect the code and evidence. Do not retry automatically unless the body says automatic_retry_authorized: true (container_not_ready, review_capacity_exhausted); then wait retry_after_seconds and retry as the errors page describes.
Uncertain transport outcome	Read the original operation record with the same session and operation ID.
Closed session	Use its retained history for inspection; do not append more work to it.

What failure does not change#

In Enforce mode, an unavailable required review, exhausted budget, revoked authority, or unsupported request does not enable an unreviewed response. In Observe mode, review failure is recorded without retracting the provider response already delivered; authentication, admission, and upstream-routing checks still apply. The connection does not silently choose another provider, credential, model, or review engine.

Legacy observe/enforce classifier switches do not configure this session contract. The deployment's own enforcement_mode does; read it from the deployment's current capabilities and governing configuration.

Observe and enforce#

A deployment runs in one of two enforcement modes. A new deployment starts in Observe, and an unset mode means Observe.

Mode	What Integrity does	What your application sees
observe	Forwards the request to the provider as soon as the route is admitted and relays the provider's bytes to the client as they arrive. The review follows the completed relay and records the verdicts it reaches on that request, without the client waiting on it.	Nothing is blocked, altered, or delayed by the review. The response is exactly what the provider sent, streamed through. Each recorded verdict appears in Runs labelled as recorded, not enforced.
enforce	Reviews before release. Proposes an intervention and withholds the action when the judgment diverges.	A typed hold with its reasons; the action does not execute until a fresh allow. Non-streaming responses also carry x-triage-integrity-disposition: held, denied, or pending. Streamed responses are buffered until release checks finish.

In Observe mode the turn records two additional events. gateway.observe.forwarded is written once the relay completes and carries the mode, timing, upstream status, and the hold Enforce mode would have raised for the same request. judgment.review_unavailable is written when the observe review did not reach a verdict; the cause is the engine's own hold code, and the traffic the client already received is unaffected. Every event Enforce mode records (input review, proposals, per-proposal review, judgment.observed, release readiness, cost accounting) still lands on the run.

Observe mode is where you calibrate: the verdicts are real and inspectable, and a would-have-held step is never mistaken for one that was held. Switching a deployment to enforce changes whether the review runs before release and whether a divergent verdict withholds the action; the judgment itself is the same. Fleet tools such as Codex and Claude Code follow the same rule; see Connect your agent fleet.

The SDK session controls are different by construction. authorize, the reference client's evaluate in before_execution mode, and verify_permit are synchronous requests your harness makes before it executes anything, so they always wait for their verdict; the deployment's mode decides only whether a divergent verdict is recorded (judgment.observed, permit still issued) or withheld.

Respond to the specific hold#

For malformed input, correct the integration before starting new work. For a credential or readiness problem, restore the intended authorized connection. For an uncertain effect, reconcile the executor ledger and operation history. None of these situations justifies regenerating IDs and replaying the original action blindly.

See error handling and run inspection.