Human gate
Holds don’t “resolve themselves”. An operator must approve or reject.
Reason-first
Every item includes the system’s hold reason so operators can decide with context.
Signed decisions
Decisions are cryptographically attributed and recorded on the Clawchain audit trail.
Handling a request
The queue lists pending approvals (HOLD actions). Each item is an “approval card” that shows the action, who initiated it, and why it was paused — plus the operator decision controls.
Context
The raw action intent from the agent (often shown as the main action title), plus optionalAction and Context previews when present.
- Action: what the agent is trying to do.
- Context: blast radius / operational notes.
- Agent + category: who initiated it, and which area it maps to.
Violation detail
Why the system paused the action. In the detail view this appears as Reason— e.g. “Risk score > 0.7” or “Matches policy: Sensitive Data Access”.
You’ll also see supporting metadata like risk level, latency, and the judgment ID used to resolve the hold on-chain.
Decision actions
Operators resolve holds using one of two terminal outcomes. The decision is recorded, attributable, and becomes part of the immutable audit trail.
| Action | Result | What it means | Signing note |
|---|---|---|---|
| Approve | ALLOW | Manually overrides the hold and permits the action to proceed. | Requires an operator decision to be signed/attributed so the release is auditable on-chain. |
| Reject | BLOCK | Confirms denial. This terminates the action permanently. | The rejecting operator identity is recorded as part of the audit trail. |
Signing & security
Approval decisions are cryptographically attributed. The operator who approves or rejects is recorded on the Clawchain, so the organization has a provable chain of custody for every release and refusal.