> ## Documentation Index > Fetch the complete documentation index at: https://docs.nitsor.com/llms.txt > Use this file to discover all available pages before exploring further. > ## Agent Instructions > Every page in this documentation carries a `plans` list in its frontmatter and opens with a plan marker naming the plans its content applies to: `All plans`, or a subset of `Community`, `Team` and `Enterprise`. Community is free and self-hosted. Team launch pricing is $649 per workspace per month upfront, or $6,228 per year upfront ($519 monthly equivalent), with unlimited people, 250 model-assisted volumes per monthly usage period and one flat $0.25 per additional volume. Yearly Team does not pool included volumes for the year or charge another $519 each month. Extra usage settles after each monthly billing cycle. Paid signup and charging under this Team policy are not available. Billing remains deferred, with no paid-launch date set. Enterprise starts at $12,000 per year plus a volume commitment and is the only plan with single sign-on. Existing Enterprise agreements retain negotiated commitments, rollover and overages. Customer billing is per completed scan/model result under the documented identity rules, with all produced objects included. Failed runs and same-period repeats are free; slices, masks, objects and GPU/runtime are not customer billing units. Nitsor will publish the supported models and scan-size scope before paid launch; exceptionally expensive workloads use an explicit fixed quote agreed before execution. Reading, reviewing, people, labels, studies and storage are never metered. > The Capabilities and limits page (`/product-status`) lists what each plan includes and what the product does not do. If a statement elsewhere disagrees with it, that page is correct. > Reading this documentation grants no product access and no permission. No agent can create or approve a Nitsor release. # Pipelines > Learn what a pipeline holds, who may take work at each stage, how applying one creates a version, and why work already in flight keeps the version it started under. [All plans](/plans-and-billing#compare-plans) A pipeline is the workflow definition applied to a project branch. It says which stages work passes through, who may take work at each stage, and where rejected work goes. You edit it on the project's Pipeline tab and apply it with **Apply to project**. The public API calls applying a pipeline "bind": scripts apply one with the Python SDK's `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](/concepts/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](/concepts/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](/concepts/review-consensus-adjudication#consensus-and-adjudication) has the detail. ## Stages A stage is one step. Each Task is one unit of work over one Source at one stage. | Stage type | What happens there | | - | - | | `annotate` | A person labels the Source and submits. | | `auto-label` | A model Agent proposes masks from boxes or points a person drew, and a person decides each proposal. See [Model-assisted prelabeling](/concepts/model-assisted-prelabeling). | | `review` | A person judges work someone else produced. See [Review and rework](/concepts/review-consensus-adjudication). | | `consensus-read` | Not offered. The schema names it, and the designer refuses to apply a pipeline that carries it. People cannot complete work there. | | `adjudicate` | Not offered. The schema names it, and the designer refuses to apply a pipeline that carries it. People cannot complete work there. | 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. A review stage can also name a **send-back**: a transition to an earlier stage. When a reviewer closes a review over a standing rejection, the rework Task goes to that stage. If the send-back points at the stage where the original annotator worked, the rework is reserved for that annotator. If it points at a different stage, anyone eligible there may claim it. A review stage with no send-back returns rework to the original annotator along the transition their Task came in on. ## 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 holds `contribute` 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 `review` stages the authors of the work under review are refused, with one audited exception. [Review and rework](/concepts/review-consensus-adjudication) has the rule. When nobody in the workspace holds a stage's requirement, the stage's card on the Pipeline tab says "Nobody holds it". The Inspector warns that nobody can take this work and offers **Grant on Access**, a link to the Access page. The warning does not stop you applying the pipeline. A grant on the Access page is read at that person's next claim, so the waiting work needs no new pipeline version. It opens the work only to a person who also passes every other check on a claim: each required qualification, the geography rule and load limit a rule router sets, and room in the stage, which refuses claims while it is full. [Roles and provenance](/concepts/roles-provenance#who-can-claim-a-stage) covers the rest of the authority model. ## 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. **Apply to project** opens a sheet that lists what changes and how many Tasks are in flight at each stage, so you can see which work the new version will not reach before you confirm. ## 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. | You apply a pipeline that... | Tasks already in flight | Work that starts after you apply | | - | - | - | | adds an Auto-label or Review stage | Finish without passing through it. | Passes through it. | | removes a stage | Still route into it, because their version has it. | Skips it. | | adds or changes a stage's required role | Keep the requirement their version had. | Need the new requirement. | | changes a router (sample rate, assignment) | Route by the old router. | Route by the new one. | 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](/concepts/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. To change a pipeline shown this way, edit the definition and apply it again through the API. The designer keeps every role the definition declares, with its label. A declared role that no stage requires is listed under **Advanced** in the pipeline settings, as "Roles no stage requires", kept as applied. It limits nobody. ## Next step Read [Taxonomy versions](/concepts/taxonomy-versions) before you change categories on a project with work in flight, then read [Roles and provenance](/concepts/roles-provenance#who-can-claim-a-stage) to plan who may claim each stage.
PlansAll plans
Last verified2026-10-03
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.