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.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 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.Planned model
From proposed change to planned release
Planned model, not a screen, command, public API, or available workflow.
Example state sequence
The following is conceptual, not a command or API example:- Register the source references used by a project.
- Create a branch for a focused proposal.
- Record one or more commits as work changes.
- Collect the required reviews and resolve contested items.
- Merge an approved proposal into the protected release line.
- 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.
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.
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”.
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, then compare this model with the guide to releasing a dataset. The product site describes the same model for a non-technical reader, without the contract detail, at 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 |
| Prerequisites | Read Product status |
| Last verified | 2026-08-23 |