> ## 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.
# Version model
> Learn the intended relationship between projects, source references, dataset state, branches, commits, reviews, and releases.
Planned — not available yet
**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
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 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
**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
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
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
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](/concepts/review-consensus-adjudication) for the intended decision rules.
## 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
**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. |
Planned model
From proposed change to planned release
| Stage | What it holds |
| ------------------- | ----------------------------------------------------------------------------------------------------------- |
| 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
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
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](/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
* 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
Read [Roles and provenance](/concepts/roles-provenance), then compare this model with the guide to [releasing a dataset](/guides/dataset-release). The product site describes the same model for a non-technical reader, without the contract detail, at [Versioning](https://nitsor.com/versioning).
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