# Reviewer handbook

For humans working the queue. Short, opinionated, read it once.

## Your job in one sentence

Decide quickly, decide correctly, and leave a paper trail clear enough that someone six months from now can understand why.

## The four actions

| Action             | When                                                                                                                   |
| ------------------ | ---------------------------------------------------------------------------------------------------------------------- |
| **Approve**        | The AI suggestion is correct and complete. Ship it as-is.                                                              |
| **Edit & approve** | The AI got it mostly right but you fixed something. The edit is captured as a learning.                                |
| **Reject**         | The AI got it wrong and there's no quick fix. Provide a reason.                                                        |
| **Escalate**       | This is above your authority — legal, large refund, ambiguous policy, unfamiliar pattern. Pushes to a senior reviewer. |

When in doubt between *edit* and *reject*: edit if the underlying intent was right, reject if the suggestion itself shouldn't have been generated.

## Read in this order

1. **Input** — what did the user/system actually ask for?
2. **Risk flags** — what did the pipeline pre-flag?
3. **Confidence** — high or low? Adjust your skepticism accordingly.
4. **AI suggestion** — only now look at what the AI proposed.

Looking at the suggestion first anchors you to it. Resist.

## Median decision time

Most items should take **under 30 seconds**. If you find yourself spending minutes:

* The item probably needs **escalation**, not a longer think
* The project's guidelines may be unclear → flag it to the project owner
* The threshold may be too loose → talk to whoever tunes the policy

Spending five minutes on one item means four other items waited five minutes for nothing.

## Reasons matter

When you reject or edit, the reason field is not bureaucracy. It is the training signal. Good reasons:

* "Suggestion offered a refund without checking order status"
* "Tone too casual for enterprise customer"
* "Cited policy section 3.2 which doesn't apply here"

Bad reasons:

* "Wrong"
* "No"
* ":("

Aim for one sentence that another reviewer or a model trainer could act on.

## When to escalate

Escalate without hesitation when:

* The item touches money above your tier's cap
* The item touches legal, medical, or regulatory territory
* The suggestion would be embarrassing if it went out wrong
* You genuinely don't know what the right answer is

Escalating is not a failure. Sitting on an item you shouldn't decide is.

## What you don't do

* You don't tune thresholds (project owners do)
* You don't change guidelines mid-shift (raise an issue)
* You don't rewrite AI suggestions from scratch — that's a reject + an out-of-band conversation about why the model is producing bad first drafts here
* You don't share your wallet credentials. Ever.

## Signing out

Click **Sign out** in the user menu. It disconnects the wallet and clears the session. If you walk away from the device without signing out, the session persists locally — treat it like any other authenticated browser tab.


---

# 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/guides/reviewer-handbook.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.