client.workflow_definition.bind(...), which calls POST /api/v1/workflow/definition/bind. The pipeline lives in commit content, so applying one writes a commit, as Version model describes.
The Pipeline tab is part of the dashboard, which runs on Team and Enterprise. The Community self-host stack does not include the Nitsor dashboard. An Auto-label stage needs a hosted model run, which Community does not have; see Model-assisted prelabeling.
Nitsor has no consensus or adjudication stage. The designer does not offer them, because no dashboard screen or public route records a vote or a decision, so a disagreement could not be settled. A pipeline already applied with one still opens. The designer flags each such stage with “Nobody can finish work here yet” and will not apply the pipeline until you change the stage to Review or remove it. Review and rework has the detail.
Stages
A stage is one step. Each Task is one unit of work over one Source at one stage.
Only the designer refuses both stage types.
POST /api/v1/workflow/definition/bind refuses one case: a consensus-read stage when no transition leads to an adjudicate stage, which it answers with 400 and workflow_consensus_unsettleable. Any other definition that carries either stage, including one with only an adjudicate stage, passes this check but must still pass the other bind checks. A Task that reaches either stage still cannot be finished by a person, so do not bind one through the API.
Transitions and send-back
A transition moves work from one stage to the next. Each transition has a router, which decides:- whether work moves: always, for a sampled share, or when uncertainty is above a threshold. A sample below 100% is allowed only on a transition into a stage that judges work;
- to whom: into a queue anyone eligible can claim from, or assigned by rule to the eligible person with the lowest load, below a set maximum;
- for how long one lease lets a person hold a Task.
Who may take work at a stage
A stage can require a role, one or more qualifications, or both. A person may claim a Task there only if they hold the role and every qualification. A stage that requires neither asks for no role or qualification, so anyone who holdscontribute on the project passes that check.
- Roles and qualifications are granted on the project’s Access page (project Settings, then Access), by a workspace owner or admin. A grant belongs to the person across the whole workspace, not only that project, and takes effect at their next claim.
- A definition also declares a list of
roles. That list restricts nobody. Only a stage’s own required role limits who may claim there. - A model Agent holds no roles or qualifications, so it can work only at stages that require neither.
- At
reviewstages the authors of the work under review are refused, with one audited exception. Review and rework has the rule.
Versions
Every apply derives the pipeline’s version from its content: the SHA-256 of the canonical definition, without its label. Two consequences follow.- Applying the same content under a new label changes nothing and writes no commit.
- Applying any change to stages, transitions, routers or requirements creates a new version and a commit, listed on the Versions tab’s Commits and branches page.
Work in flight keeps its version
Each Task records the pipeline version it was created under, and it keeps that version. When the Task completes, it is routed by that version’s transitions. The Task it creates next, and any rework Task, inherit the same version. A claim is judged against the requirements in the Task’s own version. So a new version reaches only new work. A Source that entered under the old version finishes under it.
A role granted on the Access page is different: it is read at the moment of the claim, so waiting work needs no new version for it to count, though the claimant must still pass the other claim checks. Each Task also pins the Taxonomy version it was created under. Taxonomy versions describes what that means for category changes.
What the Pipeline designer edits
The designer on the Pipeline tab edits one linear chain: work enters, passes through each stage in order, and each review stage may send rejected work back to one earlier stage. The public API accepts other shapes. When the applied definition is one the designer cannot preserve, the Pipeline tab says “This pipeline cannot be edited here”, lists the stages and the reasons in plain words, keeps the definition’s JSON behind an “Applied definition (JSON)” disclosure, and replaces nothing. Work keeps moving through the pipeline as applied. The reasons it names today:- the stages branch or join, or do not form one chain;
- a router uses settings the designer cannot preserve;
- a stage sends work back to itself, or along more than one edge;
- stages use different or partial-minute times per Task;
- there is no single entry into annotation.
Next step
Read Taxonomy versions before you change categories on a project with work in flight, then read Roles and provenance to plan who may claim each stage.| Plans | All plans |
|---|---|
| Last verified | 2026-10-03 |