Release a dataset

Planned — not available yet 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 — not available yet.

Define the release policy
Register the candidate source set
Establish the starting dataset state
Create focused proposal branches
Record content changes
Run checks and reviews
Resolve contested items
Approve and merge
Create the release record
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.

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

Get started

Concepts

Guides

Reference

The planned release path

Steps, evidence, and responsibility

Notes on the harder steps

Who owns each control point

Who may approve what

What a download proves

Recorded events behind these steps

Common mistakes and limits

Next step

​The planned release path

​Steps, evidence, and responsibility

​Notes on the harder steps

​Who owns each control point

​Who may approve what

​What a download proves

​Recorded events behind these steps

​Common mistakes and limits

​Next step

The planned release path

Steps, evidence, and responsibility

Notes on the harder steps

Who owns each control point

Who may approve what

What a download proves

Recorded events behind these steps

Common mistakes and limits

Next step