> ## 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
> Nitsor is a pre-release product. Every page in this documentation carries an availability status in its frontmatter (`availability`) and, as the first element of its body, a link labelled `Available now`, `Limited design-partner access`, or `Planned - not available yet`. That label is binding: it says whether a reader can use the behaviour the page describes.
> A page written in the present tense is not a claim that the behaviour ships. Where the availability label says `Planned - not available yet`, the page describes a target contract and there is no runnable product, screen, command, or public interface behind it.
> Every readiness claim this documentation makes lives on the Product status page. If any statement elsewhere disagrees with the capability status matrix on that page, the matrix is correct.
> Reading this documentation grants no product access and no permission. No agent can create or approve a Nitsor release.

# Concepts

> Learn the vocabulary Nitsor uses for dataset state, boundaries, roles, review decisions, and model proposals before reading any workflow.

<a className="nit-availability" data-availability="target-contract" href="/product-status#status-definitions" aria-label="Planned — not available yet. Read the status definitions."><span aria-hidden="true" className="nit-availability__dot" />Planned — not available yet</a>

These five pages define the words the rest of the documentation depends on. Read them before a guide or a reference page, because a guide that uses those words loosely is a guide you cannot check.

**Status: mostly a target contract.** Four of the five concept pages describe intended behavior that is not available as a released product. The exception is the data boundary, where a limited design-partner implementation exists. Each page states its own boundary in its first paragraph.

## The five concepts

| Concept                                                                        | The question it answers                                                                    | Availability                  |
| ------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------ | ----------------------------- |
| [Version model](/concepts/version-model)                                       | What is versioned, and what does a branch, a commit, and a release each mean here?         | Planned — not available yet   |
| [Data boundary](/concepts/data-boundary)                                       | Where does image data live, and where does it travel when a model runs on it?              | Limited design-partner access |
| [Roles and provenance](/concepts/roles-provenance)                             | Who may act, and what record proves where a change came from?                              | Planned — not available yet   |
| [Review, consensus, and adjudication](/concepts/review-consensus-adjudication) | How is a disagreement recorded and resolved rather than averaged away?                     | Planned — not available yet   |
| [Model-assisted prelabeling](/concepts/model-assisted-prelabeling)             | What guarantee can a model proposal carry, and when does the system refuse to produce one? | Planned — not available yet   |

## How the concepts fit together

A **project** holds one related history. Within it, a **dataset state** names the source references, labels, taxonomy, and declared transformations that belong together. A **branch** isolates a proposal; a **commit** records one attributable content change; a **review** assesses that change; **consensus** and **adjudication** decide what happens to it; and a **release** names one approved dataset state together with the evidence needed to reconstruct it.

Two ideas cut across all of that. The **data boundary** says what Nitsor holds and what stays in your storage. **Provenance** says where each change came from, who or what made it, and which earlier version it changed.

## Common mistake

Do not read these definitions as a description of software you can open. They are a target contract: a precise statement of intended behavior, written so a team can test it before the capability exists. No screen, command, or public interface implements the complete model today.

## Next step

Read [Version model](/concepts/version-model) first, then pick the [guide](/guides) closest to the work you already do.

<table className="nit-page-details" aria-label="Page details">
  <tbody>
    <tr><th scope="row">Outcome</th><td>Use the same words the rest of this documentation uses, and know which of them describe planned behavior.</td></tr>
    <tr><th scope="row">Availability</th><td>Planned — not available yet</td></tr>
    <tr><th scope="row">Audience</th><td>Technical program managers, ML and data teams, Reviewers and domain experts, Researchers</td></tr>
    <tr><th scope="row">Prerequisites</th><td>Read Product status</td></tr>
    <tr><th scope="row">Last verified</th><td>2026-08-23</td></tr>
  </tbody>
</table>