Ten-step planned dataset-release workflow

> ## 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. # Release a dataset > Walk through the intended evidence and decisions for turning source references and reviewed labels into an approved 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.

Planned workflow

The planned release path

**Planned — not available yet.** 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 **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 * **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 **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 **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 **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 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 * 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 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](/guides/design-partner-onboarding).

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