# Dataset release context > The planned model for versioning, roles, review, and dataset releases. > Estimated tokens: 21704 > Generated from the public documentation. Preserve availability labels and cite page sources. > No agent can create or approve a Nitsor release today; this export grants no permission and exposes no actions. # Product status > See what is available now, what is limited to design-partner work, and what is still planned. - Outcome: Cite the correct availability level when discussing a Nitsor capability. - Availability: Available now - Audience: Evaluators, Technical teams, Operational leaders, AI agents - Prerequisites: Read the Introduction - Last verified: 2026-08-18 - Source: https://nitsor.com/docs/product-status ## Status definitions \[#status-definitions] **Available now** means a visitor can use the behavior on this public site today and automated tests verify it. **Limited design-partner access** means the work is pre-release and shaped with a small number of teams. Scope, access, and suitability must be agreed directly. It is not a promise of production service. **Planned — not available yet** means the documentation describes intended behavior so teams can evaluate it and give precise feedback. Technical exports call this a **target contract**. It is not a runnable product or integration. **Open** marks a decision that has not been settled. **Pending** marks evidence that has not yet been provided or checked. Both describe unresolved decisions or evidence; they are not additional availability levels. Some tables also write **Not available** against interfaces where no public implementation of any kind exists; read it as a stricter restatement of Planned — not available yet, not as a fourth level. The three availability labels are used the same way on every page of this documentation. This legend is the definition other pages rely on. | Label | What it means | Evidence required | What it is not a claim of | | ----------------------------- | ------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------- | | Available now | A visitor can use the behavior on this public site today. | Working behavior on the current public site, verified by automated tests. | Any capability outside this public site, and any promise about a future release. | | Limited design-partner access | Pre-release work shaped with a small number of teams. Access, scope, and suitability are agreed directly. | An implementation that an agreed design partner can exercise within the agreed pre-release scope. | A public release, a production service, a service level, or an offer to accept any particular team. | | Planned — not available yet | The documentation describes intended behavior so teams can evaluate the direction and give precise feedback. | A written description only. Technical exports call this a target contract. | A runnable product, screen, command, public interface, or integration, even where the text uses present tense. | ### The four readiness states used on the marketing pages \[#the-four-readiness-states-used-on-the-marketing-pages] The home page carries one readiness band with four states, and it links here because this page defines them. They are a different vocabulary from the three availability labels above, on purpose, and neither one is a translation of the other. The availability label answers **who can reach a capability**. The readiness state answers **how far the work has got**. A capability can be built and reachable by nobody, which is why both exist. | State | What it means | | --------------- | -------------------------------------------------------------------------------------- | | Live today | You can use it right now, on this site. | | In build for v0 | Committed for the first release. The code exists. You cannot use it yet. | | After v0 | Named and sequenced, not started. A design partner needing it is what starts the work. | | Still open | A decision nobody has made yet. It is here so you can ask about it. | The summary table in the next section abbreviates these to **Live**, **In build**, **After v0** and **Open** to fit a narrow column. The four full names above are the definitions. **Where the two vocabularies disagree about the same capability, the availability level in the capability status matrix is correct.** That matrix is checked row by row against the code and carries a depth note for each one. A readiness state is a one-word summary and cannot carry a boundary. ## Available now \[#available-now] - Public marketing, planned-pricing, FAQ, contact, and draft legal pages. - Public documentation under `/docs`. - A contact form with input validation and safe email formatting covered by automated tests. Those tests do not prove live email delivery. ## Limited design-partner access \[#limited-design-partner-access] Nitsor is looking for teams with recurring industrial CT, medical CT, or MRI workflows who control their source storage and can evaluate the product with real constraints. Participation, scope, support, and production suitability must be agreed directly; this page does not promise acceptance or a service level. The implemented [Public HTTP API](https://nitsor.com/docs/reference/api), [command-line interface](https://nitsor.com/docs/reference/cli), and replay-tested [data model and contracts](https://nitsor.com/docs/reference/data-model) are available only inside an agreed design-partner environment. Their reference pages state the authentication, distribution, and product-readiness limits that still apply. Format depth is also narrow. Reference registration and browser rendering of supported uncompressed Part 10 slices exist; public-corpus, live-storage, and production evidence remain pending. VGI/VOL has a viewable registration path. MRD and TIFF/xtekct register as raw. NSI, REK, FLT, CB, and SBM register with explicit unsupported states. DICONDE, MetaImage, and NRRD remain planned. ## Planned — not available yet \[#planned--not-available-yet] The following areas are described so teams can review the direction, but they are not available as a released product: - complete project, branch, commit, review, agreement, final-decision, and release workflows; - source-data registration and data-location guarantees in a deployed product; - public SDK, Model Context Protocol (MCP), webhook, or agent integrations; - a supported self-hosted product, release pipeline, upgrade path, or rollback path; - enterprise identity, authorization, billing, compliance, or hosted inference. The tested [`nitsor up` mechanics](https://nitsor.com/docs/reference/self-host) start an incomplete dependency stack, not a supported Nitsor product. If you encounter a planned workflow example, read it only as a target contract rather than as proof of an available product. ## Readiness at a glance \[#readiness-at-a-glance] Twelve lines, in the four-state vocabulary the home page band uses. This is the readable summary. The capability status matrix below it is the register, and it governs. | Capability | State | What exists today | | ----------------------------------------------------- | -------- | -------------------------------------------------------------------------------------------- | | This website and the public documentation | Live | Including the contact form, which reports a clear error if delivery fails. | | Full-depth 3D viewer and editor | In build | Every editor screenshot on this site is a design mockup, labelled as one. | | Version graph, branch, semantic diff, three-way merge | In build | The spine. Nothing above it is meaningful without it. | | Dataset releases and frozen manifests | In build | Rebuilding a dataset outside Nitsor is the target. We have not demonstrated it. | | Routing, review, consensus, adjudication, gold tasks | In build | SAM 2.1 proposals and risk-controlling routing are the whole committed model scope. | | API, CLI, SDK, single-node self-host | In build | The specification defines these contracts. Nothing answers a request yet. | | Calibration, Certificates, auto-accept | In build | Enterprise tier. We have designed the independent verifier. Nobody has written it. | | DICOMweb, PACS and VNA adapters | After v0 | For v0 you bring industrial MRI and DICOM in through your own object storage. | | General agents and MCP | After v0 | v0 distinguishes humans, services and model executions. General agent principals come later. | | Which licence in the FSL/BSL family | Open | We also cannot publish before IP clearance, and that has not happened. | | Published packages and prices | Open | Seatless is settled. The numbers are not. | | Exact supported format list per release | Open | Round-trip tests decide this, not a marketing checklist. | ### Where this summary is rougher than the matrix \[#where-this-summary-is-rougher-than-the-matrix] Six of the twelve rows above compress a boundary that the matrix states exactly. Read the matrix for any of them before you rely on it. - **Full-depth 3D viewer and editor** reads as unreachable. It is not: the limited editor renders supported registered data for an agreed design partner. What no one can use is the full-depth viewer. - **API, CLI, SDK, single-node self-host** is four things in one row and they are not at the same stage. The HTTP API and the command-line interface are built and reachable inside an agreed design-partner environment, so "Nothing answers a request yet" is wrong for those two. No SDK package exists, and the self-host installer starts an incomplete dependency stack rather than a Nitsor product. - **Version graph, branch, semantic diff, three-way merge**, **Dataset releases and frozen manifests**, and **Routing, review, consensus, adjudication, gold tasks** read as "the code exists". For these three the matrix is stricter: an early backend description exists, there is no user interface, and no release can be created or approved. - **Calibration, Certificates, auto-accept** says it plainly in its own note and the matrix agrees. Nobody has written it. Two capabilities have no row in the summary at all and do have one in the matrix: **hosted workspace and sign-in**, and **hosted operation**. Both are marked Pending, meaning no deployed-operation evidence has been reviewed, so no reachable hosted service is claimed. ## Capability status matrix \[#capability-status-matrix] This is the canonical list of availability levels for Nitsor capabilities. Other pages link here rather than repeating it, so if a statement elsewhere disagrees with this table, this table is correct. Each row carries an availability label or an explicit pending-evidence marker, checked on 18 August 2026. Only the last row is **Available now**. The Depth column says how far the work has progressed in plain words. A capability that exists only as a backend record has no screen, command, or public interface a customer can use. | Capability | Status | Depth today | | ------------------------------------------------------ | ----------------------------- | ---------------------------------------------------------------------------------------------------------------------------- | | Hosted workspace and sign-in | Pending | Built; no deployed-operation evidence was reviewed, so no reachable hosted workspace is claimed. | | Account roles and permissions | Limited design-partner access | Built. | | Recorded authorization decisions and attribution | Limited design-partner access | Built as backend records. No screen presents them. | | Project record and event history | Limited design-partner access | Built as backend records. No screen presents them. | | Version model (branches, commits, merges) | Planned — not available yet | An early backend description exists. There is no user interface. | | Review, consensus, and adjudication workflow | Planned — not available yet | An early backend description exists. There is no user interface. | | Model-assisted prelabeling with calibrated uncertainty | Planned — not available yet | A description exists, including how the system declines a case it cannot support. No model runs. | | Medical-image (DICOM) series registration | Limited design-partner access | Supported uncompressed Part 10 slices can register and render in the browser within the limited editor. | | Volumetric viewer | Limited design-partner access | The limited editor renders supported registered data; the standalone demo still uses synthetic data. | | Public HTTP API | Limited design-partner access | Built. See [Public HTTP API](https://nitsor.com/docs/reference/api) for its authentication limitation. | | Command-line interface | Limited design-partner access | Five command families are built. | | TypeScript and Python SDKs | Planned — not available yet | No package exists. | | Dataset releases with signed manifests | Planned — not available yet | Described only. No release can be created or approved. | | Self-host installer | Planned — not available yet | The installer mechanics are tested, but no complete application package exists to install. | | Hosted operation | Pending | No deployed-operation evidence was reviewed; no running hosted service is claimed. | | Industrial (non-DICOM) file formats | Limited design-partner access | VGI/VOL is viewable; MRD and TIFF/xtekct are raw; five named families register as unsupported; other formats remain planned. | | Analytics and progress reporting | Planned — not available yet | Described only. | | Documentation and agent-readable exports | Available now | Published on this site and verified by automated tests. | ## What counts as evidence \[#what-counts-as-evidence] For these docs, “available” is limited to behavior a visitor can use on the current public site and that automated tests verify. A future release may add product capabilities. A roadmap statement or a sentence written in the present tense is not enough to call something available. | Counts as evidence | Does not count as evidence | | ----------------------------------------------------------- | ---------------------------------------------------- | | Working behavior on the current public site. | A roadmap statement or planned date. | | An automated test that verifies the named behavior. | A sentence written in the present tense. | | A recorded result tied to a specific version. | A demonstration that cannot be repeated. | | A limitation stated together with the capability it limits. | A capability described without its current boundary. | ## What the synthetic review measured Status: Synthetic review The fixed synthetic documentation review included 15 personas: 5 scored 9/10 and 10 scored 10/10. A frozen snapshot is a saved copy reviewed without later edits. These scores apply only to the first two frozen documentation snapshots. The current published documentation was not rescored. Pending: repeat this synthetic review with the current public documentation. This is documentation-clarity evidence only, not customer, product, domain, legal, security, or production validation. | Score | Personas | | ------------- | -------- | | 9/10 | 5 | | 10/10 | 10 | | Total reviews | 15 | This is documentation-clarity evidence only, not customer, product, domain, legal, security, or production validation. ## Next step \[#next-step] Return to the [Introduction](https://nitsor.com/docs/) or [contact the team](https://nitsor.com/contact) with the workflow you want to evaluate and the evidence you would need before adopting it. --- # Version model > Learn the intended relationship between projects, source references, dataset state, branches, commits, reviews, and releases. - Outcome: Use the version vocabulary consistently when describing a future Nitsor workflow. - Availability: Planned — not available yet - Audience: Technical program managers, ML and data teams, Reviewers, Researchers - Prerequisites: Read Product status - Last verified: 2026-08-23 - Source: https://nitsor.com/docs/concepts/version-model **Status: Planned — not available yet.** This model is a target contract: a precise description of the version history Nitsor is intended to provide. It is not a working API or workflow product today. ## Project \[#project] A project is the intended boundary for one related history of source references, labels, taxonomy, transformations, and review decisions. It should also define who may see or change that history. A project is not a storage bucket and not a temporary task queue. Those systems may contribute information, but they have different responsibilities. ## Dataset state \[#dataset-state] Dataset state means the versioned content needed to understand a candidate dataset: the referenced source objects, label state, taxonomy, declared transformations, and relevant decision evidence. Operational details such as who currently has a task open or how a queue is sorted may affect work, but they should not silently change the content identity of a release. ### Content identity and operational detail \[#content-identity-and-operational-detail] **Planned — not available yet.** The split below is the intended rule, not an implemented guarantee. Content identity means the set of facts that decide whether two releases are the same dataset. If something in the left column changes, the release is a different dataset and needs a new identity. Nothing in the right column may change that identity on its own. | Changes the identity of a release | Never changes the identity of a release | | --------------------------------------------------------------- | --------------------------------------------------------------------- | | Which source objects are referenced. | Who currently has a task open. | | The label state applied to those objects. | How a work queue is sorted or prioritised. | | The taxonomy version and what each label name means. | How many people worked on it, or how long it took. | | The transformations declared on the data. | Which screen, command, or interface was used to do the work. | | The decision evidence the policy requires the release to carry. | Comments, notifications, or activity indicators attached to the work. | ## Branch \[#branch] A branch is intended to isolate proposed changes from an accepted line of history. A person, team, model, or runner may work on a scoped branch. The branch name is descriptive; authority comes from permissions, not from the name. ## Commit \[#commit] A commit is intended to identify one content change and its history. It should make the earlier state, author, changed content, and relevant checks unambiguous. The evidence showing where the change came from is called **provenance**. A commit does not mean the change is approved. It may still require review, consensus, adjudication, or a protected merge decision. ## Review and decision \[#review-and-decision] A review records an assessment of a proposal. A decision records what happens because of the available evidence. Keeping these separate prevents a review status from masquerading as a geometry change. Read [Review, consensus, and adjudication](https://nitsor.com/docs/concepts/review-consensus-adjudication) for the intended decision rules. ## Release \[#release] A release is intended to name one approved dataset state together with the evidence needed to explain and reconstruct it. A release should not be inferred merely because work stopped or a batch was exported. The exact release record, signing, reconstruction, withdrawal, and compatibility behavior is still open. No executable public specification is available. ## What each object is and is not \[#what-each-object-is-and-is-not] **Planned — not available yet.** These are the intended definitions and the misreadings they are written to prevent. Nothing here describes an available screen, command, or interface. The containment is straightforward: a project holds branches, and a branch holds commits. Releases, taxonomy, and workflow belong to the project as a whole rather than to any one branch. | Object | Where it lives | What it is | What it is not | | -------- | ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------- | | Project | The outer boundary | One related history of source references, labels, taxonomy, transformations, and review decisions, together with who may see or change it. | A storage bucket, and not a temporary task queue. | | Branch | Inside a project | An isolated line for proposed changes, worked on by a person, team, model, or runner. | Permission by itself. The name is descriptive; authority comes from permissions. | | Commit | Inside a branch | One content change with an unambiguous earlier state, author, changed content, and relevant checks. | Approval. It may still need review, agreement, a final decision, or a protected merge. | | Taxonomy | Project scope | The controlled set of labels and what each one means for this project. | A free list of label names that anyone may extend in passing. | | Workflow | Project scope | The rules that route work and reviews across the project's branches. | A version of the data. A completed assignment is not a release. | | Release | Project scope | One approved dataset state together with the evidence needed to explain and reconstruct it. | Something to infer because work stopped or a batch was exported. | ## From proposed change to planned release Status: Planned model Dataset state leads to a branch or proposal, then a commit, review and decision, and finally a release. | Stage | Meaning | | ------------------- | ----------------------------------------------------------------------------------------------------------- | | Dataset state | Referenced source objects, label state, taxonomy, declared transformations, and relevant decision evidence. | | Branch or proposal | A focused proposed change isolated from accepted history. Authority still comes from permissions. | | Commit | One attributable content change with an unambiguous parent state. It is not approval. | | Review and decision | The assessment and what happens because of the evidence remain distinct. | | Release | One approved dataset state together with the evidence needed to explain and reconstruct it. | Planned model, not a screen, command, public API, or available workflow. ## Example state sequence \[#example-state-sequence] The following is conceptual, not a command or API example: 1. Register the source references used by a project. 2. Create a branch for a focused proposal. 3. Record one or more commits as work changes. 4. Collect the required reviews and resolve contested items. 5. Merge an approved proposal into the protected release line. 6. Create a release that names the accepted state and decision evidence. ## Recorded states for work, agreement, and conflict \[#recorded-states-for-work-agreement-and-conflict] Disagreement and conflict are first-class recorded states in this model, not error paths. A task nobody finished, two reviewers who disagree, and two edits that touch the same content are all expected outcomes with a name, rather than failures to be cleared away. **Planned — not available yet.** The three small state sets below are the planned model. Backend records exist for them, but no screen, command, or interface presents them, and no product moves work between these states today. A task is one assignment of work to one person or runner. | Task state | Meaning | | ---------- | ---------------------------------------------------- | | Queued | Waiting; nobody has taken it. | | Assigned | Taken by one person or runner, and not yet finished. | | Completed | Finished and handed back for whatever comes next. | An agreement round is one pass of collecting the reviews a policy requires for a single item. These states describe the round as a whole; the outcome of each individual review is a separate vocabulary, described in [Review, consensus, and adjudication](https://nitsor.com/docs/concepts/review-consensus-adjudication). | Agreement round state | Meaning | | --------------------- | ------------------------------------------------------------------------------ | | Open | Reviews are still being collected; the rule has not been applied yet. | | Agreed | The written agreement rule is satisfied by the eligible reviews. | | Disagreement | The rule is not satisfied and the difference is genuine, not a missing review. | | Adjudicated | An authorized final decision closed the round and recorded a reason. | A conflict occurs when two proposals change the same content and cannot both be kept. The disposition is the recorded answer to “which version wins, and who said so”. | Conflict disposition | Meaning | | -------------------- | ---------------------------------------------------------------------------------------- | | Take base | Keep the shared starting state that both proposals began from, and discard both changes. | | Take ours | Keep the version already on the line being merged into. | | Take theirs | Keep the version from the proposal being merged in. | | Custom | Record a different result that neither side proposed, together with who decided it. | Choosing a disposition is a decision with an author, not a silent cleanup step. Discarding a conflicting change without recording who chose that is exactly the outcome this model is meant to prevent. ## Common mistakes and limits \[#common-mistakes-and-limits] - A branch is not permission by itself. - A commit is not approval. - A completed assignment is not a release. - A release is not reproducible until reconstruction is proved against a released implementation. - This page does not define file formats, identifiers, schemas, or retention periods. ## Next step \[#next-step] Read [Roles and provenance](https://nitsor.com/docs/concepts/roles-provenance), then compare this model with the guide to [releasing a dataset](https://nitsor.com/docs/guides/dataset-release). --- # Roles and provenance > Learn how identity, permissions, authorship, review, approval, and change history are intended to remain distinct. - Outcome: Define the minimum role and provenance evidence your workflow would require. - Availability: Planned — not available yet - Audience: Program and operations teams, Reviewers and domain experts, Security and software teams - Prerequisites: Know who proposes, reviews, and approves changes today - Last verified: 2026-07-30 - Source: https://nitsor.com/docs/concepts/roles-provenance **Status: Planned — not available yet.** This page is a target contract: a precise description of the identity and permission model Nitsor is intended to provide. No such product system is available today. ## Identity, role, and permission \[#identity-role-and-permission] An identity answers “who or what is acting?” A role groups responsibilities such as annotator, reviewer, final decision-maker, or release approver. A permission answers whether that identity may perform a specific action in a specific project or area. These concepts should remain separate. A job title should not silently grant project-wide access, and a branch name should not grant permission. ## Workspace roles implemented today \[#workspace-roles-implemented-today] This table describes something narrower than the rest of the page: the permissions the account system implements today for administering a workspace — reading and updating account settings, managing members, handling billing, connecting storage, and configuring notifications. It is **not** a claim that the annotation-work authority model described further down exists. A member's workspace role is one of owner, admin, member, or billing. “Yes” means the role holds that permission; “No” means it does not. | Permission | Owner | Admin | Member | Billing | | ------------------- | ----- | ----- | ------ | ------- | | account:read | Yes | Yes | Yes | Yes | | account:update | Yes | Yes | No | No | | members:read | Yes | Yes | Yes | No | | members:write | Yes | Yes | No | No | | billing:read | Yes | Yes | No | Yes | | billing:write | Yes | No | No | Yes | | storage:read | Yes | Yes | Yes | No | | storage:write | Yes | Yes | No | No | | notifications:read | Yes | Yes | Yes | No | | notifications:write | Yes | Yes | No | No | | projects:write | Yes | Yes | No | No | Two details are worth reading carefully. An admin holds every permission except the ability to change billing, which stays with the owner and the billing role. A plain member can read but not change: they see account details, the member list, connected storage, and notification settings, and modify none of them. These roles govern workspace administration. They do not decide who may propose a label, review it, resolve a disagreement, or approve a release — that is a separate vocabulary, described next. ## Intended human roles \[#intended-human-roles] - **Annotator:** creates or corrects a specific piece of label work. - **Reviewer:** assesses a proposal against instructions and evidence. - **Domain expert:** provides specialist judgment, often in a limited scope. - **Final decision-maker (adjudicator):** resolves contested outcomes and records the reason. - **Release approver:** accepts a complete release candidate under an explicit policy. - **Project administrator:** manages membership and project configuration without automatically becoming the author or approver of content. One person may hold several roles, but a protected decision may require separation—for example, an approver who is not the proposal author. **Status: Planned — not available yet.** The following matrix describes the intended authority of each working role. No product enforces it today, and it is not the workspace table above. | Working role | Propose | Review | Adjudicate | Approve release | Configure the project | | --------------------- | ------- | ----------------------------------- | ---------- | --------------- | --------------------- | | Annotator | Yes | No | No | No | No | | Reviewer | No | Yes | No | No | No | | Domain expert | No | Yes, usually within a limited scope | No | No | No | | Adjudicator | No | No | Yes | No | No | | Release approver | No | No | No | Yes | No | | Project administrator | No | No | No | No | Yes | Read the “No” cells as “not by virtue of this role”. One person may hold several roles and then holds the union of their authority — with one intended exception: the author of a proposal is never its sole approver. Holding both the annotator and the release-approver role does not let someone approve their own work; a second, independent approver is required. ### Why the two tables stay separate \[#why-the-two-tables-stay-separate] Merging the workspace table into this one would produce a single grid that looks authoritative and is wrong. The two use different vocabularies for different questions: - The workspace table answers “who may administer this account?” — it is implemented, and its roles are owner, admin, member, and billing. - This matrix answers “who may decide the fate of a labelled change?” — it is planned, and its roles are annotator, reviewer, domain expert, adjudicator, release approver, and project administrator. A workspace admin is not therefore an adjudicator, and an adjudicator needs no billing permission. A merged table would invite exactly that misreading, and it would blur an implemented capability together with a planned one. ## Intended machine roles \[#intended-machine-roles] A model, automated runner, or agent should act under its own identity rather than borrow a person's account. Its permissions should be limited to the work it needs, expire when practical, and remain connected to a version and responsible operator. Machine-authored work should remain identifiable through review and merge. A machine suggestion is not a human approval. This is intended behavior, not an available agent integration. **Status: Planned — not available yet.** The comparison below states the intended differences between the two kinds of actor. No machine-identity system is available today. | Question | Human identity | Machine identity | | -------------------------- | ------------------------------------------------------------ | ------------------------------------------------------------------------------------------ | | Who is it? | A named person. | A model, automated runner, or agent, with its own identity rather than a borrowed account. | | What may it do? | Whatever its roles grant in a project. | Only the narrow set of actions its task needs. | | How long does it last? | As long as the person is a member. | Time-limited where practical, so an unused credential stops working. | | What version acted? | Not applicable; a person is not versioned. | The tool, model, or runner version is recorded with the work. | | Who is accountable? | The person, directly. | A named responsible operator, in addition to the machine identity itself. | | How is its output treated? | A proposal still needs review under the project's rule. | A proposal that stays identifiable as machine-authored through review and merge. | | Can it approve? | Yes, if the role grants it and the person is not the author. | No. A machine suggestion is never a human approval. | ## Provenance \[#provenance] **Provenance** means the evidence showing where a change came from and what happened to it. The useful minimum depends on the workflow, but may include: - authoring identity and role; - parent state and branch; - source references and taxonomy version; - tool, model, or runner version; - declared transformation; - timestamps and relevant checks; - review outcomes and decision reasons; - the identity that approved or rejected the change. Recording more fields does not automatically create trust. The system must make their meaning, integrity, and retrieval reliable. **Status: Planned — not available yet.** The table names the intended purpose and writer of each field. No product writes these records today. An auditor usually arrives with one question: given this value, who or what could have produced it? Each row exists to remove one way of answering “we cannot tell”. | Field | Why it exists | Who or what writes it | | ------------------------------- | ------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------- | | Authoring identity and role | Names the actor behind the change and the authority they held while making it. | The system, from the authenticated principal — never typed in by the author. | | Parent state and branch | Says which earlier state the change was made against, so it can be reconstructed. | The system, from the version record at the time of the change. | | Source references | Ties the change to the specific source data it interprets. | The system, from the project's registered source references. | | Taxonomy version | Fixes what each label name meant when the change was made, not what it means now. | The system, from the taxonomy in force for the project. | | Tool, model, or runner version | Distinguishes work produced by different versions of the same tool or model. | The tool or runner, reported under its own machine identity. | | Declared transformation | Records resampling, cropping, or conversion that changed the data before the change. | The process that performed it, declared rather than inferred. | | Timestamps and relevant checks | Orders events and records which automated checks ran and what they found. | The system. | | Review outcomes and reasons | Preserves the assessments, including disagreement, that led to the result. | Each reviewer, as an attributable record. | | Approving or rejecting identity | Names who accepted responsibility for the final decision, separately from the author. | The system, from the authenticated approver. | The pattern is that almost nothing is self-reported. Where a field is declared by a tool rather than observed by the system — the transformation row, for instance — that is itself worth knowing, because it is the field a misconfigured pipeline can get wrong without anyone noticing. ## Denials and failed actions \[#denials-and-failed-actions] The product direction is to retain meaningful authorization outcomes, including denials, so a later investigator can understand attempted actions and policy boundaries. Retention volume, privacy, and operational access need design and implementation evidence. ## Common mistakes and limits \[#common-mistakes-and-limits] - Authentication is not authorization. - Membership is not authorship. - An administrator is not automatically an approver. - A service account shared by several tools makes it harder to tell which tool acted. - An audit log is not useful if events cannot be connected to the content decision. - This page does not promise a particular identity provider, role schema, or compliance control. ## Next step \[#next-step] List the human and machine identities involved in one real workflow, then read [Review, consensus, and adjudication](https://nitsor.com/docs/concepts/review-consensus-adjudication) to define how their outcomes combine. --- # Review, consensus, and adjudication > Understand the intended decision model for independent reviews, agreement rules, conflicts, and accountable resolution. - Outcome: Describe a review policy without hiding disagreement or confusing task completion with acceptance. - Availability: Planned — not available yet - Audience: Reviewers, Domain experts, Program managers, Data scientists - Prerequisites: A written review instruction or quality rule; Named owners for escalation and final decisions - Last verified: 2026-08-23 - Source: https://nitsor.com/docs/concepts/review-consensus-adjudication **Status: Planned — not available yet.** This page is a target contract: a precise description of how reviews and disagreements are intended to work. No review-routing or decision system is available today. ## Review \[#review] A review is an assessment of a proposed change against a known instruction, recorded with the reviewer's identity. The intended record should distinguish outcomes such as accept, return for correction, abstain, or escalate, together with any required reason. A review is evidence. It does not by itself define the overall decision when a policy requires several reviews or another approval. **Status: Planned — not available yet, and the exact outcome names are an open decision.** The names used on this page — accept, return for correction, abstain, escalate — describe what a reviewer intends. Early implementation work records a shorter and differently shaped set: accept, correct, and reject. Those two vocabularies do not line up, and this page does not pretend they do. Which set survives, and whether “reject” means “return for correction” or something stronger, is unsettled. The last column concerns the total a rule counts against. If a rule says “two of three reviewers must accept”, it must also say which three: which reviews count toward the required total, and which are set aside. Deciding that is one of the hardest parts of writing the rule. | Reviewer outcome | Reason required? | What happens next | Effect on the required total | | --------------------- | ------------------------------------------------------------------ | ------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Accept | Usually not, unless policy asks for one. | The outcome is recorded and counts as acceptance evidence under the rule. | Counts toward the required total, and counts as agreement. | | Return for correction | Yes. A correction without a reason is guesswork for the author. | The proposal goes back to its author with the reason attached. | Counts toward the required total, but not as agreement. It is not acceptance. | | Abstain | Yes, so a later reader knows why judgement was withheld. | The reviewer is recorded as having withheld judgement. | Open. The written rule must say whether an abstention lowers the required total or counts against agreement — the two choices give different answers to the same reviews. | | Escalate | Yes. The escalation reason is what the decision-maker reads first. | The item routes to an authorized decision-maker for adjudication. | Open. The rule must say whether an escalated item still counts as awaiting agreement or has left the agreement process entirely. | The two rows marked Open are not oversights. They are the questions a written policy has to answer before any of this can be implemented, and a system that answers them silently is worse than one that refuses to guess. The states an item can be in — including outcomes that were never recorded at all — are set out separately below. ## Consensus \[#consensus] **Consensus** means that the required level of agreement has been reached under a written rule. Examples include unanimous agreement, a minimum threshold, or a required specialist review. The rule must say which reviews count, how abstentions behave, and what happens when the threshold is not met. The planned decision rule avoids silently converting “two of three tasks completed” into acceptance. Missing and ineligible outcomes remain visible. **Status: Planned — not available yet.** No system applies any of these rules today. The comparison is here so you can choose one deliberately for your own policy. | Rule | What it requires | How it treats a missing outcome | Its characteristic failure | | ------------------- | ---------------------------------------------------------- | -------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ | | Unanimous | Every eligible review accepts. | Nothing is decided until every required review exists. | Stalls. One unavailable reviewer holds the item indefinitely unless escalation is defined. | | Threshold | At least a stated number of eligible reviews accept. | The rule must say whether the missing outcome still counts in the total. | Quietly becomes majority voting, and a threshold met by two accepts out of two completed reviews looks the same as two out of three. | | Required specialist | A named qualification must be among the accepting reviews. | An absent specialist blocks the decision regardless of how many others accepted. | Reads as satisfied when a generalist reviewer's acceptance is miscounted as the specialist's. | ### Why “two of three completed” is not “two of three agreement” \[#why-two-of-three-completed-is-not-two-of-three-agreement] Three reviewers are assigned to one proposal. Two of them finish; the third records nothing. Of the two who finished, one accepts and one returns the work for correction. A progress view honestly reports two of three tasks completed. An agreement rule looking at the same item sees one acceptance, one return, and one missing outcome — one accept out of three, not two out of three. Under a threshold rule requiring two accepts, this proposal has not reached agreement, and it is not close: there is an unresolved disagreement and an absent reviewer. Reporting the completion figure as if it were the agreement figure is the single most consequential mistake in this area, because it converts a contested item into an accepted one without anyone deciding to do so. ## Adjudication \[#adjudication] **Adjudication** is a final, accountable decision about a contested item. The decision-maker should see the proposal, competing reviews, instructions, and change history. The decision should record a reason and make the next step clear. Adjudication is not an automatic average of shapes or scores. It is a decision made by an authorized person under a known rule. The evidence a reviewer needs in front of them is listed in [What a reviewer should see](https://nitsor.com/docs/guides/annotate-and-review#what-a-reviewer-should-see). ## Conflicting edits \[#conflicting-edits] When two proposals change overlapping content, a future implementation needs to detect the relevant conflict and route it according to policy. The correct unit of conflict, comparison method, and merge behavior require runnable product tests. This documentation does not claim automatic voxel-level conflict handling is available. ## How planned review outcomes differ Status: Planned decisions | State | Meaning under a written rule | | ----------- | ------------------------------------------------------------------------------------------- | | Accepted | Eligible acceptance evidence; it counts only under the written agreement rule. | | Returned | Sent back for correction with any reason required by policy; it is not acceptance. | | Abstained | Remains visible; the written rule defines whether it counts in the total. | | Missing | No outcome was recorded; completion or elapsed time cannot replace it. | | Ineligible | Recorded but excluded from eligible agreement under the written rule. | | Contested | Genuine disagreement remains unresolved and routes to an authorized decision-maker. | | Adjudicated | An authorized final decision records the result and reason; it is not an automatic average. | Planned meanings for review outcomes. No review-routing or decision system is available today, and release approval remains separate where policy requires it. ## Example policy questions \[#example-policy-questions] - Must reviewers be independent of the author? - Does a machine-authored proposal always require a human reviewer? - Which domain qualifications make a review eligible? - How many outcomes are required? - Can a reviewer abstain, and does that change how many reviews are required for a decision? - Which disagreements require adjudication? - Who may overturn or withdraw a decision? - How does a correction affect a previously released dataset? Use the worksheet below to answer them for one workflow. **Status: Planned — not available yet** — nothing here is configured in a product; the third column describes what happens in a team's process when the question is left open, which is the reason to answer it now. | Question | Your rule | Consequence if left unspecified | | --------------------------------------------------------------------------- | --------- | -------------------------------------------------------------------------------------------------------- | | Must reviewers be independent of the author? | | Authors end up reviewing their own work, and the review record stops being evidence of anything. | | Does a machine-authored proposal always require a human reviewer? | | Model output reaches a release without a person ever having accepted responsibility for it. | | Which domain qualifications make a review eligible? | | Every review counts equally, and a specialist judgement is diluted by reviewers who lack the background. | | How many outcomes are required? | | Whoever reports first defines the result, and the number varies from item to item. | | Can a reviewer abstain, and does that change how many reviews are required? | | Abstentions are counted inconsistently, so the same reviews produce different answers on different days. | | Which disagreements require adjudication? | | Disagreement is resolved by whoever is most persistent rather than by whoever is authorized. | | Who may overturn or withdraw a decision? | | A decision can be reversed without a record, and the history no longer explains the current state. | | How does a correction affect a previously released dataset? | | Consumers keep training on data known to be wrong, because no one is obliged to tell them it changed. | ## Common mistakes and limits \[#common-mistakes-and-limits] - More reviewers do not guarantee a better policy. - Consensus is not majority voting unless the policy says so. - A confidence score is not a review decision. - Automatically merging overlapping labels can erase important disagreement. - Synthetic persona evaluations of these docs are not domain-expert validation of the product model. ## Next step \[#next-step] Write the review and escalation rule for one representative structure, then use it while reading the guide to [releasing a dataset](https://nitsor.com/docs/guides/dataset-release). --- # Release a dataset > Walk through the intended evidence and decisions for turning source references and reviewed labels into an approved dataset release. - Outcome: Compare an existing release process with a precise, testable future contract. - Availability: Planned — not available yet - Audience: Technical program managers, Operations teams, ML and data teams, Reviewers and approvers - Prerequisites: A defined source set and label taxonomy; Named review and release owners; Read Version model and Product status - Last verified: 2026-08-23 - Source: https://nitsor.com/docs/guides/dataset-release **Status: Planned — not available yet.** This workflow is a target contract: a precise description teams can use to evaluate the product direction. A reference workflow is a clear example process that a team can compare with its own; it is not the only valid process. These are not instructions for an available Nitsor product. No public interface can create or approve a release today. ## The planned release path Status: Planned workflow 1. Define the release policy 2. Register the candidate source set 3. Establish the starting dataset state 4. Create focused proposal branches 5. Record content changes 6. Run checks and reviews 7. Resolve contested items 8. Approve and merge 9. Create the release record 10. Verify reconstruction and export Planned — not available yet. No public interface can create or approve a release today. ## Steps, evidence, and responsibility \[#steps-evidence-and-responsibility] **Planned — not available yet.** The table is the whole reference workflow: what each step does, the evidence it should leave behind, and the role accountable for producing that evidence. Every step is stated once, here, so this table is the checklist to copy. Roles are named by function; no product assigns them today. | Step | What happens | Expected evidence | Responsible role | | --------------------------------------- | --------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------- | | 1. Define the release policy | Write down the source scope, label definitions, checks, eligible reviewers, agreement rule, and approver. | A named policy version and a person accountable for it. | Release policy owner | | 2. Register the candidate source set | Identify the source objects and the metadata needed to interpret them. | Source identifiers, checksums or equivalent integrity records, relevant geometry and context, and access scope. | The engineer who registers the sources | | 3. Establish the starting dataset state | Name the accepted label state, taxonomy, transformations, and prior decisions that work begins from. | An unambiguous parent state. | Project administrator | | 4. Create focused proposal branches | Separate human corrections, label-definition changes, and machine proposals that need different reviews. | Branch purpose, author, permissions, and starting state. | Proposal author (annotator, domain expert, or machine runner) | | 5. Record content changes | Record commits that identify changed content and where each change came from. | Parent, author, change summary, source and taxonomy context, and the applicable tool or model version. | Proposal author | | 6. Run checks and reviews | Run repeatable automated checks, then gather the independent reviews the policy requires. | Check results, review outcomes, reviewer eligibility, and any reasons the policy requires. | Reviewers and domain experts | | 7. Resolve contested items | Route genuine disagreement or conflicting edits to an authorized final decision-maker. | Competing proposals, relevant instructions, the decision-maker, the decision, and the reason. | Final decision-maker (adjudicator) | | 8. Approve and merge | An authorized approver evaluates the complete evidence and merges the accepted proposal. | Policy evaluation, approving identity, accepted state, and any exceptions. | Release approver, who must not be the author of the proposal | | 9. Create the release record | Name one accepted state together with the contents and decisions the policy requires. | A stable release identifier and a complete record of its contents and decisions. | Release approver | | 10. Verify reconstruction and export | Rebuild the release somewhere else and check that the expected data and decision evidence are present. | A runnable acceptance result tied to the released product version. | A verifier independent of the team that produced the release | ### Notes on the harder steps \[#notes-on-the-harder-steps] - **Registering sources.** Record stable references and integrity evidence without confusing a reference with a backup. - **Branching.** The history should always identify who or what created each proposal. - **Committing.** A commit remains a proposal until policy requirements are satisfied. - **Reviewing.** Preserve missing, ineligible, returned, and escalated outcomes rather than collapsing them into a count. - **Resolving conflict.** Do not silently average labels, discard a review, or choose whichever change happened last. - **Creating the release record.** Exact signing and data-format behavior remain open. - **Verifying.** Record limitations rather than treating a successful download as full reconstruction. No such product proof is available today. ## Who owns each control point \[#who-owns-each-control-point] **Planned — not available yet.** A control point is a place in the lifecycle where someone decides something and the decision is recorded. Nitsor does not assign these responsibilities for you; your program does. The table names the four stages the steps above pass through, together with the failure that tends to appear when a stage has no named owner. | Lifecycle stage | Who is responsible | Anti-pattern when the responsibility is unspecified | | --------------- | --------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------- | | Project state | The team that decides which source references, labels, and definitions belong together. | Queue order and temporary assignments quietly decide what is in the dataset. | | Change state | Whoever proposes a change, plus the reviewers the program requires. | Proposed and accepted work become indistinguishable, so nobody can say what actually changed. | | Decision state | The named reviewers and the person accountable for resolving disagreement. | Elapsed time or a completed task queue is read as an approval that nobody actually gave. | | Release state | The approver named by the program for that release. | A release is described by where its files sit rather than by the content and evidence it contains. | ## Who may approve what \[#who-may-approve-what] **Planned — not available yet.** These are the separation rules this workflow assumes. No product enforces them today. | Rule | What it means | What happens if it is skipped | | --------------------------------------------------------- | -------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------- | | An approver evaluates the complete evidence | Approval is a judgement about the assembled record, not about the last change alone. | A release is approved without anyone having seen the checks, reviews, or contested outcomes. | | Author and approver are separate where policy requires it | The person who proposed a change is not the person who accepts it on behalf of the project. | Self-approval turns a proposal into a release with no independent judgement in the record. | | A machine-authored proposal is never approved by itself | Model or automated output always needs a human approval step; a confident suggestion is not an approval. | Model output enters an accepted release without any human accepting responsibility for it. | | Exceptions are recorded, not silent | Where the policy allows an exception, the exception and its reason belong in the release record. | A later reader cannot tell whether the policy was followed or quietly set aside. | | Approval is recorded as an act by a named identity | The approving identity is part of the evidence, alongside the accepted state. | Accountability for the release cannot be reconstructed afterwards. | ## What a download proves \[#what-a-download-proves] **Planned — not available yet.** The distinction below is the reason the last step exists. It applies to any release process, including one you run today without Nitsor. | A successful download proves | A successful download does not prove | | -------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------- | | Files were produced and transferred without an error being reported. | That the files match the state that was actually approved. | | The transfer path from the system to your environment works. | That the decision evidence — reviews, contested outcomes, approvals — travelled with the data. | | The archive can be opened and its file names inspected. | That labels, taxonomy version, and declared transformations are interpreted the same way in the new place. | | Something exists to hand to a colleague or an auditor. | That an independent team could rebuild the same dataset from it. | | The export step ran to completion. | That anything was released at all; an export is not automatically a release. | ## Recorded events behind these steps \[#recorded-events-behind-these-steps] The platform records a set of named events today, as backend records. **The event names in this table are implemented.** The mapping from those names to the workflow steps above is **planned — not available yet**, because the workflow itself is not available. There is no webhook layer: no Nitsor system sends these events to another system over the web. They are records, not notifications, and this table publishes no message contents. | Workflow step | Event names recorded today | Note | | ------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Before step 1 — project setup | `project.created` | Records that a project exists. | | 2. Register the candidate source set | `storage.connection_registered`, `dicom.series_registered` | Connecting a storage location, and registering a medical-image series held there. | | 4. Create focused proposal branches | `version_graph.branch_created` | Opening an isolated line for a proposal. | | 5. Record content changes | `version_graph.commit_checkpointed`, `version_graph.landmark_upserted`, `version_graph.landmark_deleted`, `version_graph.project_metadata_updated` | Saving a content change, adding or removing a marked point, and changing project details. | | 5. Record content changes (machine) | `prelabel.job_submitted`, `prelabel.job_running`, `prelabel.job_succeeded`, `prelabel.job_failed`, `prelabel.job_refused` | A model-assisted prelabeling request and its outcome, including the case where the system declines to answer. | | 6. Run checks and reviews | `workflow.definition_bound`, `workflow.tasks_routed`, `workflow.task_claimed`, `workflow.task_completed`, `workflow.review_recorded`, `workflow.gold_scored`, `workflow.lease_expired` | Attaching a task definition, sending work to people, claiming and finishing a task, recording a review, scoring work against a known-answer item, and releasing a task nobody finished. | | 7. Resolve contested items | `workflow.adjudication_recorded` | Recording a final decision on a contested item. | | 8. Approve and merge | `version_graph.branches_merged` | Combining an accepted proposal into the line it came from. | | 9. Create the release record | None | No release event name exists. | | 10. Verify reconstruction and export | None | No reconstruction or export event name exists. | A named event is not a workflow. These names show that the target contract has real records behind parts of it; they do not mean the release process above can be run. ## Common mistakes and limits \[#common-mistakes-and-limits] - Do not start with an undocumented release policy. - Do not treat model output as accepted label state. - Do not infer approval from silence or elapsed time. - Do not publish a release when required evidence is missing. - Do not claim reproducibility without an independent reconstruction test. - This workflow does not define a public release-record format, command, API, or service-level promise. ## Next step \[#next-step] Turn each expected-evidence item in the table above into an acceptance test for one representative release, then bring that checklist to [Design-partner onboarding](https://nitsor.com/docs/guides/design-partner-onboarding). --- # Glossary > Use plain-language definitions for the product and workflow terms that appear across Nitsor's public documentation. - Outcome: Understand a term without mistaking planned behavior for an available capability. - Availability: Available now - Audience: All readers, AI agents - Prerequisites: No prior Nitsor knowledge required - Last verified: 2026-08-23 - Source: https://nitsor.com/docs/reference/glossary ## Glossary terms and common misreadings \[#glossary-terms-and-common-misreadings] The first five rows distinguish public availability from unresolved decisions and evidence. The remaining rows define the product and data vocabulary used across these docs. | Term | Definition | Common misreading | | ----------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------- | | Available now | Behavior a visitor can use on the public site today and that automated tests verify. | It does not mean every Nitsor capability is available; the label applies only to the behavior carrying it. | | Limited design-partner access | Pre-release work with a small number of teams. Scope, access, and suitability must be agreed directly. | It is not public access or a promise of acceptance, production access, or service levels. | | Planned — not available yet | Intended behavior documented precisely enough to evaluate. Technical exports call this a target contract. | It is not a runnable capability. | | Open | A decision that has not been settled. | It is not an additional availability level and does not mean evidence is merely unchecked. | | Pending | Evidence that has not yet been provided or checked. | It is not an additional availability level and does not mean the decision itself is unsettled. | | Adjudication | A final, accountable decision that resolves contested reviews or proposals and records a reason. | It is not an automatic average or an unrecorded tie-break. | | Agent | Software that can choose and perform steps toward a goal. | An agent-readable file does not give an agent permission to act. | | Annotation | A label or structured interpretation associated with source data. | It is not the source data itself. | | Branch | In the target version model, an isolated line for proposed changes. | A branch name is not a permission. | | Checkpoint | In the target version model, a recorded position in the event history that later commits derive from. | It is not itself a commit or an approval. | | Commit | In the target version model, one attributable content change with a parent state. | It is not automatically approved. | | Consensus | The result of an explicit rule applied to eligible review outcomes. | It is not the same as most completed tasks. | | Content root | The identifier that fingerprints the content a commit covers, so identical content shares one root. Today it covers landmark-scoped content only. | It is not the commit identifier; the two are intentionally distinct. | | Control plane | The part of a system that records identities, source references, versions, rules, and decisions. | It is separate from source-image storage, though it may need authorized reads and temporary processing. | | Dataset state | The versioned source references, labels, taxonomy, declared transformations, and decision evidence needed to identify a candidate dataset. | It is more than a list of files or labels. | | Design partner | A team working directly with Nitsor on a focused pre-release evaluation. | The term does not promise acceptance, production access, or service levels. | | Gold check | In the intended review workflow, scoring submitted work against an item whose correct answer is already known. | Passing a gold check is not an approval or a release decision. | | Industrial CT / NDT | Computed-tomography workflows used to inspect manufactured objects without destroying them. This is Nitsor's initial commercial focus. | It does not mean every volumetric workflow is industrial CT. | | Landmark | A single marked point at a position in a volume, such as a tagged feature or defect location. | It is not a mask, box, or full segmentation; content identity currently covers landmarks only. | | Manifest | A structured list of the content and evidence belonging to a release. | No public Nitsor manifest format is available today. | | MCP (Model Context Protocol) | A standard for connecting AI applications to tools and information sources. | No public Nitsor MCP server is available today. | | Preflight | In the intended job model, a check that runs before a job starts and can refuse the job rather than let it run without its guarantee. | A refusal is a recorded outcome, not a crash. | | Principal | A human or machine identity that can receive limited permissions and be named as the actor behind an action. | An identity is not permission without an explicit grant. | | Provenance | Evidence showing where a change came from, including the relevant source, author, tool or model, earlier state, and decisions. | It is not just an author name or model label. | | Release | In the target model, one approved dataset state with the evidence needed to explain and reconstruct it. | An export is not automatically a release. | | Replay-tested | Verified by rebuilding state from the recorded event history and comparing the rebuilt result with the live one. | It is evidence about backend contracts, not about a public interface. | | Review | An attributable assessment of a proposed change against a known instruction. | It is not itself an approval or final decision. | | Runner | In the target model, a machine identity that can be assigned work and author proposals under its own name. | A runner cannot approve its own work. | | Source reference | An identifier for source data held in another system. | A reference is not a copy or backup. | | Surface | A general word for an interface a caller could reach, such as an API route, command, package, or webhook. | Naming a surface does not mean one is published. | | Target contract | A precise description of intended behavior, written so a team can evaluate and test against it before the capability exists. | It is not proof that the described capability is available. | | Taxonomy | The controlled set and meaning of labels used by a project. | It is not merely an uncontrolled list of label names. | | Volumetric data | Data sampled across three spatial dimensions, such as industrial CT, medical CT, or MRI volumes. | It is not limited to medical imaging. | | Voxel | One element of a three-dimensional volume, the volumetric equivalent of a pixel. | Voxel-level conflict handling is not an available capability. | | Webhook | An automatic message one system sends to another over the web when a specified event occurs. | No public Nitsor webhook is available today. | ## Common mistakes and limits \[#common-mistakes-and-limits] - Terms describe the intended model; they do not prove an implementation. - Similar words in another tool may carry different state or authority. - Legal, medical, security, and standards definitions may require domain-specific review beyond this glossary. ## Next step \[#next-step] Return to the [Introduction](https://nitsor.com/docs/) or use [documentation search](https://nitsor.com/docs/?q=glossary) to continue with the term in context.