> 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/stages-and-routes.md).

# Stages and routes

A stage should represent a meaningful responsibility or automation boundary. A route should explain what decision moved the work and who owns it next.

### Before you make the change

* Write the normal path and every exception path in plain language.
* Name the human or service owner for each stage.
* Define entry criteria, valid actions, exit criteria, and observability.

![Workflow canvas with connected stages](https://292810646-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FGjVLUz4wthGkGlRKM6rM%2Fuploads%2FAjCMPQRpjcxTkfYgo8FQ%2Fworkflow-canvas.png?alt=media\&token=941ab2b3-7827-408e-978c-b7cf80252715)

*Use the canvas to make routes legible; a visually impressive graph is not useful if operators cannot explain why an item follows each edge.*

### Understand the product behavior

A new project receives the default workflow:

```
Project → Annotate → Review → Complete
```

The six stage types currently released in the editor are:

* **Project** — the single entry point;
* **Annotate** — human labeling;
* **Review** — human quality review with approve and reject routes;
* **Model** — automated inference on entry;
* **Archive** — terminal set-aside state;
* **Complete** — terminal successful state and release-readiness destination.

The released stage catalog contains Project, Annotate, Review, Model, Archive, and Complete. A team that needs specialist or expert review adds and names another Review stage, then configures its eligible reviewers and routing rules.

The canvas supports:

* adding stages;
* drawing connections;
* naming the workflow;
* binding the reusable workflow to a project;
* configuring eligible annotators or reviewers per human stage;
* allowing or preventing self-assignment;
* allowing manager override;
* hiding unassigned work where required;
* configuring whether the stage can be skipped;
* selecting a model, thresholds, generic type, queue scope, and class mappings for Model stages;
* accepted and rejected review branches;
* Save and Apply with impact validation;
* zoom, reset, and canvas navigation.

The workspace Workflows page displays reusable workflow cards and a Create Workflow action. Opening a project’s Workflows tab goes directly to the editor for that project’s active workflow.

In the full-page editor, users drag released stages from **Add Stages** onto the canvas, connect or remove edges, select a node to edit its configuration, and use one explicit **Save & Apply** action. The Project entry node embeds project progress. Stage names are editable except Project; duplicate display names are numbered consistently in both the canvas and Task Queue.

Replacing an active project workflow while items are in flight prompts with the number of items that would reset to Project. An unsaved-changes guard protects navigation away from the editor. Workflows can also be duplicated, archived, and restored.

### Rejection is a route, not a failure state

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.

### Build the operating state machine

{% stepper %}
{% step %}

#### 1. Place the project entry

Define how newly attached work becomes available.
{% endstep %}

{% step %}

#### 2. Add execution stages

Create human annotation, model, or other current stages according to responsibility.
{% endstep %}

{% step %}

#### 3. Add review

Define what the reviewer can accept, reject, return, or escalate.
{% endstep %}

{% step %}

#### 4. Connect every outcome

Draw explicit routes for success, rework, invalid data, failure, archive, specialist escalation, and completion.
{% endstep %}

{% step %}

#### 5. Test stage actions

Use each role to move representative tasks through every path.
{% endstep %}

{% step %}

#### 6. Save with impact awareness

Record the graph version and treatment of in-flight work.
{% endstep %}
{% endstepper %}

### Decisions that affect production

| Decision       | Production guidance                                                                         |
| -------------- | ------------------------------------------------------------------------------------------- |
| Stage boundary | Create a stage when responsibility, permission, automation, or acceptance criteria changes. |
| Route label    | Use outcome language the operator can interpret.                                            |
| Terminal state | Reserve completion or archive for explicitly accepted outcomes.                             |
| Exception      | Keep failed or escalated work observable and owned.                                         |

### Continue the operating flow

* Configure assignment and queue behavior.
* Exercise review and rework.
* Validate the graph before applying it to production volume.