> For the complete documentation index, see [llms.txt](https://docs.unitlab.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.unitlab.ai/documentation/workflows/review-rework-and-escalation.md).

# Review, rework, and escalation

Review should turn a quality decision into a clear next state. Rejected work needs an actionable reason and destination; specialist escalation needs an owner and return path.

### Before you make the change

* Define acceptance criteria and reviewer authority.
* Separate item-level correction from systemic policy or schema correction.
* Name the specialist or governance owner for escalated cases.

### Understand the product behavior

Review has both approve and reject edges. This allows a correction path to be designed before production starts.

A production workflow might be:

```
Project
├── Model → Annotate → Review
│                    ├── Accepted → Complete
│                    └── Rejected → Annotate
└── Difficult/low-confidence → Specialist Review
                               ├── Accepted → Complete
                               └── Rejected → Annotate
```

Here, Specialist Review is another stage of the released **Review** type with a specialist eligibility list, not a different stage type.

### Human review

Review stages require Approve and Reject outcomes. Approve follows the forward edge; Reject returns the item to the configured rework stage and can generate a rework notification. Workbench actions come from the item’s current stage rather than a fixed button set. Review should test the task’s quality policy, not merely confirm that an annotation exists.

### Workbench stage actions

Saving and moving through the workflow are separate actions. Saving appends annotation history inside the current stage. A stage action changes the item’s route.

The Workbench header builds available actions from the current item and can show:

* **Send to Review** or **Send to `<stage>`**;
* **Mark as Complete**;
* **Reject** as a danger action;
* **Restart Workflow** for a manager viewing a Complete item;
* item timeline.

Automated-stage items open read-only while the model or automation owns them. After a successful stage action, Unitlab saves dirty work, advances to the next item in the current queue/filter context, and returns to the project Datasets page with a Queue complete message when no work remains.

### Operate a quality decision

{% stepper %}
{% step %}

#### 1. Inspect the full task

Review the relevant frames, pages, panels, timeline, properties, relations, and source context.
{% endstep %}

{% step %}

#### 2. Make the decision

Accept, reject, or escalate against the published Instructions and ontology.
{% endstep %}

{% step %}

#### 3. Explain corrective work

Identify the instance, interval, page, field, or policy rule that needs attention.
{% endstep %}

{% step %}

#### 4. Route to the owner

Move the task to the configured rework or specialist stage.
{% endstep %}

{% step %}

#### 5. Re-review the correction

Confirm the specific defect and any related cohort risk are resolved.
{% endstep %}

{% step %}

#### 6. Escalate systemic gaps

Update Instructions, ontology, workflow, or training through controlled change.
{% endstep %}
{% endstepper %}

### Decisions that affect production

| Decision       | Production guidance                                                              |
| -------------- | -------------------------------------------------------------------------------- |
| Accept         | The work satisfies current policy and required values.                           |
| Reject         | The correction is understood and can return to an owner.                         |
| Escalate       | The decision exceeds the current role or policy and requires a named specialist. |
| Systemic issue | Inspect the affected cohort and control, not only the triggering item.           |

### Continue the operating flow

* Track repeated rejection reasons.
* Update calibration examples for recurring defects.
* Confirm queue state and ownership after every transition.