# Review queue

The queue (`/queue`) is the reviewer's main workspace. Every item in the queue is something the routing policy decided needed human eyes — either because confidence was below threshold, a risk flag fired, or the item was explicitly escalated.

## The view

Each row in the queue shows:

* **Project** — color-coded chip
* **Risk flags** — small badges (`pii`, `legal`, `high_value`, etc.)
* **Confidence** — numeric, with a low-confidence indicator
* **Age** — how long the item has been waiting
* **Input preview** — first \~120 chars of the original request
* **Status** — `queued`, `claimed` (someone is looking), or `escalated`

Filters: by project, by risk flag, by confidence band, by age. The default view is "everything I can act on, oldest first".

## Actions

| Action             | Effect                                                 | Captured as                               |
| ------------------ | ------------------------------------------------------ | ----------------------------------------- |
| **Approve**        | Ship the AI suggestion as-is                           | Decision (not a learning)                 |
| **Edit & approve** | Modify the suggestion, then approve                    | Decision + learning (`diff_kind: edit`)   |
| **Reject**         | Discard the suggestion; reason optional but encouraged | Decision + learning (`diff_kind: reject`) |
| **Escalate**       | Send to a senior reviewer                              | Item status → `escalated`                 |

Keyboard shortcuts: `a` approve, `e` edit, `r` reject, `s` escalate, `j`/`k` next/prev item.

## Item detail (`/items/:id`)

Opens when you click a row. Shows:

* Full input payload (formatted JSON)
* AI suggestion in a comparison pane (the "edit & approve" surface)
* Confidence and all risk flags
* Project guidelines (collapsible, scoped to this project)
* Decision history if the item was previously routed (e.g. escalated from another reviewer)
* Linked past learnings on similar inputs (if any)

## Assignment

By default, items sit in the project pool. Any reviewer in the project's `reviewer_pool` can pick them up. When a reviewer opens an item, a soft lock prevents two reviewers from acting on the same row simultaneously.

You can also explicitly assign items:

* Via the public API: `POST /api/public/items` with `assignee_id`
* From the queue UI: select rows → "Assign to..."

See `src/lib/assignments.ts`.

## SLAs and auto-escalation

Items older than the project's `max_queue_age_minutes` are automatically promoted to `escalate`. This protects against staffing gaps. The original confidence and flags are preserved; only the routing status changes.

## What never appears in the queue

* Auto-approved items (they went straight to webhook)
* Hard-rejected items (rejected by policy, never queued)
* Items in projects whose reviewer pool you're not in


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://hitl-01.gitbook.io/hitl-docs/features/queue.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.