Resolve an Escalation

An escalation holds a request for a person to review. You open it in Inbox, look at the evidence, claim it, and record your decision.

A resolution updates the review record. It does not replay the original request or change the response that the caller already received.

Before you start

Use a Console account in the region of the escalation, with escalations:read, escalations:claim, and escalations:resolve.

For a request that the gateway blocked without an escalation, use Investigate a Blocked Request.

1. Read the request and its reason

1. Open Inbox → Escalations and select the item.
2. Read Reason Code, Request ID, Config Version, and Status.
3. If capture is on, read the prompt, response, provider, and model under Request Context.
4. Check Claimed By. If another reviewer owns the item, talk to them.

Under Related Resources, Related events leads to the request context in History. Compare the policy result with what the policy is meant to do. Without captured content, use the decision event and note what is missing.

2. Claim the item

Select Claim while the item is queued. The panel then offers Unclaim, Resolve, and Reject.

Claiming tells other reviewers that the item is yours. If you cannot finish, select Unclaim to return it to the shared queue.

3. Record your decision

1. Select Resolve.
2. Choose a Resolution: Allow, Block, Rewrite, Redact, or Rejected.
3. Optionally choose a Category (optional) that explains the result.
4. Optionally add your reasoning in Notes (optional), up to 2000 characters.
5. Select Submit.

For a correct block, choose Block and True Positive — Blocked. When the configuration must change to fix the result, choose Policy Update Necessary.

The resolution is the decision, and the category is why. The Reject shortcut saves Rejected with True Positive — Blocked and no note. Use the form when you want to explain.

4. Examine the saved result

Status is now resolved, with your resolution, category, and note.

A resolution changes no policy. If a policy must change, follow Managing Policy Changes separately.

Use the CLI

Sign in with verdictan auth login as a user with the same permissions, and use the ID from the list:

verdictan escalation list --since 24h --status queued
verdictan escalation get --escalation-id ESCALATION_ID --include-context --json
verdictan escalation claim --escalation-id ESCALATION_ID

After you review the evidence, record a correct block and read the result back:

verdictan escalation resolve \
  --escalation-id ESCALATION_ID \
  --resolution block \
  --category true_positive_blocked \
  --note "Reviewed the request and confirmed the policy block"
verdictan escalation get --escalation-id ESCALATION_ID --json

Check status, resolution, and resolution_category. The CLI reference lists the other resolutions and categories.

If something fails

Problem	What to check
The queue is empty	The region, the time window, and the status filter
Claim is missing or returns 409	Refresh the item and read its status and owner before you retry.
Resolve returns 403 auth.user_required	Use a Console session or a user-bound API token. An organization-only credential has no reviewer identity.
Related events shows no session	Capture and retention limit History. Use the escalation and decision event, and note the gap.

You cannot assign an escalation to a named reviewer. Unclaim returns it to the shared queue.

Next steps

• Reviewing Alerts and Evidence: collect supporting context.
• Export Evidence for a Review: download decision events for a review.