> ## 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. # Taxonomy versions > See what adding, renaming, recolouring, changing the kind of, removing and archiving a category each do to existing Tasks, annotations, Auto-label stages and exports. [All plans](/plans-and-billing#compare-plans) The Taxonomy says what a project's annotations may say: its categories, each with one geometry kind (`mask`, `box2d`, `box3d` or `landmark`), and its fields. On the Taxonomy page (project **Guidance** tab, then **Taxonomy**), the geometry kind is the **Annotation shape** of a category. Every saved change binds a new version; the API calls saving a Taxonomy "bind". The version is a hash of the canonical definition, so saving an unchanged Taxonomy writes nothing. The Taxonomy page 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. Nitsor refuses a Taxonomy change that removes or re-kinds a category an Auto-label stage uses; see [A guard for Auto-label categories](#a-guard-for-auto-label-categories). A Dataset Version records the Taxonomy version it was created under, with a class index of that version's category names. A raw read of the version graph carries neither; see [Exports and Taxonomy versions](#exports-and-taxonomy-versions). ## Four rules behind every change 1. **A Task keeps the Taxonomy version it was created under.** The pin is written once and never updated. The review Task that follows it and any rework Task inherit the same pin. A new Task takes the version bound when it is created. 2. **The editor draws a Task's categories from its pinned version.** When the project has moved on, the label list says: "This Task is pinned to a different Taxonomy than the project now carries." 3. **A commit is checked against the Task's pinned version,** not the branch's current one. The dashboard refuses an edit made under any other version. 4. **An annotation stores its category's id** (`classId`), not its name or colour. The id is the category's identity. On the Taxonomy page it is fixed once the category is saved. ## What each change does | Change | Tasks already created | Existing annotations | | - | - | - | | **Add** | Do not offer the new category; their pin predates it. New Tasks offer it. | Unaffected. | | **Rename** | Keep showing the old name. New Tasks show the new one. | Keep the same id, so they carry the new name wherever the current Taxonomy is read. A Dataset Version created before the rename keeps the old name in its class index. | | **Recolour** | Keep the old colour. New Tasks show the new one. | Unaffected. | | **Change kind** | Keep the old kind. New Tasks must draw the new kind: a `mask`, `box2d`, `box3d` or `landmark` annotation of any other kind is refused as `taxonomy_geometry_mismatch`. `stroke` and `polygon` annotations skip this check. | Not converted. A mask stays a mask. | | **Remove** | Keep the category and can still commit it. New Tasks refuse it as `taxonomy_unknown_category`. | Keep their `classId`, which the current Taxonomy no longer resolves. | | **Archive** | Keep the pin they had. Tasks under the new version stop offering the category for new labels. | Kept, and can still be edited. A new annotation in the category is refused as `taxonomy_category_archived`. | On the Taxonomy page, **Remove category** takes a category out of the draft, and the **Archived** option archives it. Name, Annotation shape and colour edit a category in place. ## Auto-label stages An Auto-label stage pairs categories by id: the category the model proposes masks on, and, for a prompt, the category a person draws boxes or points in. Adding, renaming and recolouring leave the pairing intact. Nitsor checks the pairing from both sides on each branch: * **Applying a pipeline** refuses a stage that names a category the bound Taxonomy does not have (`workflow_runner_category_unnamed`), or whose kind does not fit its role (`workflow_runner_category_geometry_mismatch`). A proposal category must be a mask category, and a prompt category must be the kind its prompt reads. * **Saving a Taxonomy** refuses removing a paired category or changing its kind; see [the guard](#a-guard-for-auto-label-categories). Archiving a paired category is allowed. The editor then leaves proposals in that category off the list and counts them separately. The id lock is a dashboard rule. Through `POST /api/v1/taxonomy/bind` a caller can change an id, and a changed id is a removal plus an addition, with the effects of both. ## A guard for Auto-label categories Nitsor refuses a Taxonomy bind that removes a category, or changes its geometry kind, while the pipeline bound on that branch pairs it in an Auto-label stage. Nothing is saved. The refusal names the stage and the category, for example: > Stage "auto-label" proposes on "Gland" (gland), so this Taxonomy cannot remove it. Archive the category instead, or take it out of that stage first. Through `POST /api/v1/taxonomy/bind` the refusal is a `409` with the code `taxonomy_category_runner_paired`. Archiving stays allowed, because an archived category keeps its id and kind. A category no stage pairs can still be removed. To remove a paired category, take it out of the Auto-label stage on the Pipeline tab and apply the pipeline first. ## Exports and Taxonomy versions Two reads return annotations, and they differ in what they say about the Taxonomy. * **A Dataset Version names its Taxonomy version.** It pins a commit and records the Taxonomy version bound at that commit as `taxonomyVersion`. `GET /api/v1/dataset-versions/{id}` returns it, and so does the manifest header. A class index sits beside the manifest: the `taxonomyVersion` plus a `{classId, name}` entry for each category that version defines. It carries no colour and no geometry kind. A Dataset Version is immutable, so a later rename leaves its names alone, and a Dataset Version created after the rename takes the new name. An annotation in it carries only its `classId`, which you resolve through the class index. A category removed before the version's commit is not in the index, so an annotation that still carries that id does not resolve there. When no Taxonomy was bound at that commit, the version has no `taxonomyVersion` and the index lists no classes. [Release a dataset](/guides/dataset-release) covers creating one. * **A raw version-graph read does not.** `GET /api/v1/version-graph/position` returns each annotation with its `classId` and no Taxonomy version, and nothing else in the response resolves that id. `GET /api/v1/taxonomy` does, but it reads the branch's current Taxonomy. So a renamed category resolves to its new name, a removed one does not resolve at all, and an archived one still resolves. Read the Taxonomy at the same time and keep its version with what you read. In both, an annotation keeps the geometry it was drawn with after a kind change. When a category's meaning changes, add a new category instead of renaming, as the next section says. ## Recommended practice * **Rename only to fix wording.** A rename keeps the id, so every existing annotation takes the new name wherever the current Taxonomy is read, and so does each Dataset Version you create afterwards. A Dataset Version created earlier keeps the old name. When the meaning changes, for example "Nodule" becoming "Solid nodule" with part-solid nodules split out, add a new category and archive the old one. * **Archive rather than remove.** Archive keeps old annotations resolvable and editable and stops new labels. Remove leaves ids that the current Taxonomy cannot resolve. * **Change the Auto-label stage first.** Before you archive, remove or re-kind a category an Auto-label stage uses, point the stage at another category and apply the pipeline. * **Expect in-flight work to keep the old categories.** A category you add today appears on Tasks created after the save. [Pipelines](/concepts/pipelines#work-in-flight-keeps-its-version) describes the same rule for pipeline versions. ## Next step Read [Pipelines](/concepts/pipelines) to see how the same pinning applies to stages, then [Version model](/concepts/version-model) for how Taxonomy versions sit in commit content.
PlansAll plans
Last verified2026-10-03
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.