How To: Resolve an Escalation

Use this workflow when an item in the Escalations queue needs a final human decision.

Use this page when

• An escalation appears in your queue that needs a human decision (approve, reject, or investigate further).
• You need the step-by-step process for claiming, investigating, and resolving an escalation with a defensible audit trail.
• You want to understand what makes a good resolution note and when to hand off to another owner.

Primary audience

• Primary: Technical Engineers
• Secondary: AI Agents, Technical Leaders

Outcome

By the end of this workflow, the escalation should be:

• Claimed by the correct reviewer.
• Investigated against the underlying event and context.
• Resolved with a clear outcome and note.
• Handed off cleanly if more follow-up is needed.

Workflow diagram

Step 1: Confirm reviewer identity before touching the queue

The reviewer identity shown in the queue is part of the operational record for claim and resolve actions. The console derives it from the authenticated session rather than asking you to type it manually.

Step 2: Review the escalation first

Open the drawer and inspect:

• Escalation ID.
• Request ID.
• Reason code.
• Current status.
• Config version.
• Timeline fields.

If the escalation is already claimed by the right reviewer, avoid taking ownership twice.

Step 3: Cross-check the underlying event

Do not resolve from the queue alone. Review the corresponding event so you understand:

• The top-level verdict.
• Policy results.
• Trace context if needed.
• Whether the event reflects intended behavior or drift.

Step 4: Claim only when you are acting on it

Claiming establishes ownership. Do it when you are actively reviewing the item, not just browsing the queue.

Auto-assigned escalations

When an operator configures escalation_routing.user_id on a provider or model, escalations for that model arrive already claimed by the specified user. In this case, skip the claim step and proceed directly to investigation and resolution.

Step 5: Choose a resolution that others can understand later

The most important part of the resolution is not only the choice itself, but the note that explains why. A good resolution note should answer:

• Was the original escalation justified?
• Is follow-up needed in policy or operations?
• Does another owner need to act next?

Step 6: Resolve and hand off

The console shows a confirmation dialog before the final resolve request is sent. Use that step to verify the selected outcome and note one last time, because the action is irreversible in the current workflow.

After resolving, record any downstream action such as:

• Policy tuning.
• Rollback review.
• Evidence export.
• Stakeholder notification.

Resolution checklist

• Reviewer identity confirmed.
• Escalation context reviewed.
• Underlying event reviewed.
• Ownership established.
• Resolution note written.
• Confirmation dialog reviewed.
• Next action documented.

For AI systems

• Canonical terms: Keeptrusts, escalation, escalation queue, claim, resolve, human-oversight, escalation_routing, reviewer identity, resolution note.
• Feature and config names: human-oversight policy, escalation_routing.user_id, escalation drawer, escalation status (queued/claimed/resolved).
• Console surfaces: Escalations queue, escalation drawer, event detail view.
• Best next pages: Escalations, Investigate a Blocked Request, Reviewing Alerts and Evidence.

For engineers

• Escalation resolution is irreversible in the current workflow — always verify the outcome and note in the confirmation dialog before submitting.
• The reviewer identity is derived from the authenticated session; it cannot be overridden manually.
• Auto-assigned escalations (via escalation_routing.user_id on a provider or model) skip the claim step — proceed directly to investigation.
• After resolving, if policy tuning is needed, update policy-config.yaml and re-lint before redeploying.

For leaders

• Escalation resolution produces an auditable record of who decided, what they decided, and why — required evidence for compliance frameworks.
• Resolution notes should be written so downstream stakeholders (security, compliance, legal) can understand the decision without re-investigation.
• If escalation volumes are high, review whether the policy chain needs tuning or whether escalation_routing.user_id should be set to distribute load.
• Unresolved escalations represent operational risk; track queue depth and time-to-resolution as governance KPIs.

Next steps

• Escalations
• Investigate a Blocked Request
• Reviewing Alerts and Evidence