> ## Documentation Index > Fetch the complete documentation index at: https://docs.sudont.xyz/llms.txt > Use this file to discover all available pages before exploring further. # Verdicts & Reason Codes > The four verdict variants the Judge emits and the canonical reason-code vocabulary the swarm consumes. ## Overview Every request that traverses Sudont terminates in a typed **verdict**. The verdict is the final output of [The Diamond](/architecture/the-diamond) — Constitution + Cortex + Cage collapsed into a single decision the agent loop can branch on. Four variants cover the full surface; reason codes qualify each one with a stable, machine-readable token. The verdict itself is defined by the `VerdictDecision` enum on the RPC event channel; the swarm observes the same value through the [ReAct error payload](/react-loop) on non-`Allow` outcomes, and through an EIP-191 attestation on `Allow`. *** ## The Four Verdicts ### Allow The Cage's simulated state diff matches the agent's declared [intent envelope](/concepts/intent-envelope), the Constitution accepts every recipient and target, and freshness is within tolerance. Sudont signs an approval attestation and forwards the original signed transaction to the upstream RPC. The agent records the artifact and continues; no remediation is required. ### Deny Surfaced to the swarm as **`BLOCK`**. The simulated outcome violates a Constitution rule, exceeds a policy bound (slippage, price impact), or pays an unauthorized recipient. Sudont never forwards the transaction to the network and emits a deterministic ReAct error carrying the `reason_code` and the violated rule. The agent must rewrite the transaction — fix the route, narrow the recipient, lower the size — before retrying. ### Interrogate The simulation surfaces ambiguity the Judge will not unilaterally resolve: amount slightly above delegated authority, recipient missing from a soft allowlist, or a state-freshness gap that needs operator confirmation. Sudont holds the request and returns an actionable challenge in the ReAct payload. The agent inspects `actionable_feedback`, applies the requested correction, and resubmits; a human operator can also clear the hold from the cage UI. ### Diagnose Reached only through `sudont_diagnoseRawTransaction`. The Judge runs the full simulate → evaluate → verdict pipeline but never forwards the result to network egress, regardless of outcome. Use this verdict to dry-run an unsigned candidate, validate a bundle ahead of submission, or replay a historical transaction against the current Constitution. The response is always the full ReAct envelope; no attestation is signed. *** ## Canonical Reason Codes Every non-`Allow` verdict carries a `reason_code` token from the `ReasonCode` vocabulary. The five codes below are the ones the agent loop branches on most often. All codes are stable and serde-renamed; agents should match on the string, not the discriminant. | Code | Fires when | Agent next step | | ------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------- | | `SUDONT_POLICY_DENY` | Constitution evaluation rejects the simulated outcome — exceeded price-impact ceiling, blocked program, or any first-order policy violation that is not specifically a recipient or target case. | Rewrite the transaction to satisfy the violated `rule_id`. Lower size, change route, or pick a different venue. | | `SUDONT_UNAUTHORIZED_RECIPIENT` | Simulated value flows into an address that is not in the Constitution's recipient allowlist — the canonical Mythos / trojan-swap signature. | Reroute to an approved vault or treasury. Do not retry with the same destination. | | `SUDONT_UNSUPPORTED_TARGET` | The transaction calls a program or contract outside the Constitution's program allowlist. The Cortex labels it as a `CUSTOM SVM PROGRAM CALL` or analogous EVM target. | Use only allowlisted programs. Adding a target requires an operator policy change, not an agent retry. | | `SUDONT_EGRESS_UNAVAILABLE` | The Judge granted `Allow` but the upstream RPC egress channel is missing, misconfigured, or unreachable. | Surface to the operator; the agent cannot recover this on its own. The transaction is held, not denied. | | `SUDONT_STALE_HEAD` | The freshness gate detects that the working-set state is older than the configured tolerance for the request mode (pending vs sealed). | Wait for the next hydration cycle and resubmit. Persistent staleness is an operator concern. | The full vocabulary — including `SUDONT_SLIPPAGE_EXCEEDED`, `SUDONT_PRICE_IMPACT_EXCEEDED`, `SUDONT_PRIVATE_ROUTE_REQUIRED`, `SUDONT_INTENT_PARSE_FAILED`, `SUDONT_INTENT_OUTCOME_MISMATCH`, `SUDONT_INSUFFICIENT_LIQUIDITY`, `SUDONT_UNKNOWN_STATE`, and `SUDONT_INTERNAL_SIMULATION_ERROR` — is enumerated in the [RPC method reference](/api-reference/rpc-methods). The five codes above cover the verdict-defining cases that every agent integration must handle. *** ## How Verdicts Compose with the Loop The verdict is the only contract between Sudont and the swarm. Everything else — the simulated state diff, the route table, the µs phase breakdown — is observability. The agent's branching logic should read exactly two fields: 1. The verdict variant (`Allow` / `Deny` / `Interrogate` / `Diagnose`). 2. The first `reason_code` in `data.sudont.violations`. For the full payload schema, the canonical violation order, and the recovery patterns for each reason code, see the [ReAct Error Payload](/react-loop) and the [Constitution Compiler](/policy) references. For the Cortex / Cage hot path that produces the verdict, see [The Diamond Architecture](/architecture/the-diamond).