Data boundary

Limited design-partner access Status: Limited registration paths; broader boundary planned. Source registration and limited rendering paths exist for design-partner evaluation. The storage, locality, temporary-processing, and export boundary described here remains a target contract, not a deployed guarantee.

Intended separation

Source volumes

The product direction is for source volumes to remain in storage controlled by the customer. Nitsor would refer to those objects and read only what an authorized workflow needs. A deployed implementation must prove that behavior with configuration, network, and storage evidence.

Version and decision records

The intended product would hold identity references, source-object references, checksums, selected metadata, label versions, label definitions, change history, and review or release events. These records are sometimes called the control plane because they describe and govern work without becoming the source-image store. Exact fields, retention, encryption, and regional behavior are still open.

Temporary processing

Viewing, validation, conversion, model inference, and export may require temporary copies, caches, or derived files. “Source data stays in place” does not mean no byte is ever read or processed. A future implementation must document where temporary data exists, for how long, and under whose control. Where a model runs decides where image data travels, so the two planned ways of running one differ on exactly that point:

On the planned managed run plane — compute that Nitsor arranges on your behalf — image data would travel to our GPU supplier in the European Union, stay there for the length of the job, and not be kept there afterwards.
With the planned bring-your-own compute classes (byo-cloud and pull-worker), the job runs on machines you already control, so image data would stay inside your own infrastructure.

Neither class is deployed today, and neither description has been demonstrated by a running system. Ask for the storage and network records listed below before relying on either.

Exports

The intended product should support a complete, usable export of customer-owned project state. Export completeness, format stability, and import into another system are not available or tested here.

Data class	Intended behavior
Customer-controlled source volumes	Remain in customer-controlled storage; authorized workflows may read what they need. Where a model runs would decide where image data travels.
Nitsor references, version, and decision records	Describe and govern work without becoming the source-volume store.
Declared temporary or derived processing	Viewing, validation, conversion, model inference, and export may create temporary copies, caches, or derived files that must be documented.
Complete export	Should provide a complete, usable export of customer-owned project state.

Intended behavior only, not a deployed guarantee. Exact fields, locations, lifetimes, retention, and export behavior remain unproved.

Data classes in detail

Planned — not available yet. The table restates the four zones above and adds the questions a deployed implementation would have to answer for each one. It is intended behavior, not a deployed guarantee, and the last column names what is genuinely unresolved rather than hiding it.

Data class	Where it is meant to live	Who controls it	Persistent or temporary	Open questions
Customer-controlled source volumes	Storage the customer already owns and administers.	The customer, including the permissions that decide what Nitsor may read.	Persistent, for as long as the customer keeps it.	Which reads an authorized workflow actually performs, and how a deployment proves it.
Nitsor references, version, and decision records	With Nitsor, describing and governing work without holding the source images.	Nitsor in a hosted deployment; the operator in a self-hosted one, once one exists.	Persistent, intended to last as long as the project’s history.	Exact fields, retention, deletion, encryption, key management, and regional behavior.
Declared temporary or derived processing	Wherever viewing, validation, conversion, model inference, or export runs.	Whichever system performs that step, and it must declare it rather than leave it implicit: the planned managed run plane (our EU GPU supplier, for the length of the job only) or planned bring-your-own compute (`byo-cloud`, `pull-worker`) on machines you control.	Temporary by intent, but only as temporary as an implementation proves.	Where each copy exists, how long it survives, who can reach it, and how deletion is confirmed.
Complete export	Delivered out to a destination the customer chooses.	The customer, once the export exists.	Persistent in the customer’s hands.	Completeness, format stability, and whether another system can import it without loss.

Evidence to request

Before relying on this boundary, ask for each item below and record what you receive. Every current status is Not published, because no deployed product exists to produce this evidence.

Evidence to request	What it would prove	Current status
A diagram tied to a released version	That the boundary describes a specific build, not an intention.	Not published
A list of persisted and temporary data classes	That every place data can rest has been named, including the temporary ones.	Not published
Storage and network records from a working deployment	Where bytes actually went, rather than where they were meant to go.	Not published
Permission and credential boundaries	Which identity can read what, and how narrow that access is.	Not published
Deletion, retention, backup, and recovery behavior	What happens to data over time, and what can be recovered after a failure.	Not published
Encryption and key-management details	How data is protected at rest and in transit, and who holds the keys.	Not published
An export and reconstruction test	That project state can leave the system and be rebuilt elsewhere.	Not published
A clear allocation of customer and provider responsibilities	Which obligations are yours and which are the provider’s, before something goes wrong.	Not published

Format and modality scope

Industrial CT/NDT is the initial commercial focus, while MRI is also important for testing the design. No public importer or viewer release exists. Treat format support, preservation of spatial information, multi-series behavior, and performance as unverified until runnable tests cover the exact product version being evaluated. The pre-release implementation has different depths by format. Reference registration and browser rendering of supported uncompressed Part 10 slices exist; public-corpus, live-storage, and production evidence remain pending. VGI/VOL has a viewable registration path. MRD and TIFF/xtekct register as raw. NSI, REK, FLT, CB, and SBM register with explicit unsupported states. These are limited implementation facts, not a public support promise.

Target format	Commonly used for	Current depth
DICOM	Medical imaging, including CT and MRI series.	Limited design-partner access. Supported uncompressed Part 10 slices can register and render in the browser; broader corpus and storage proof is pending.
DICONDE	Industrial inspection, using the DICOM structure for non-medical parts.	Planned — not available yet.
TIFF / Nikon xtekct	Reconstructed slices and Nikon projection data.	Limited design-partner access. Reference registration exists with a raw state; no browser image rendering is claimed.
VGI/VOL	Industrial CT volumes from inspection software.	Limited design-partner access. A viewable registration path exists; public-corpus, live-storage, and production evidence are pending.
MRD	Magnetic-resonance acquisition data.	Limited design-partner access. Reference registration exists with a raw state; no browser image rendering is claimed.
NSI	North Star Imaging legacy and HRVOL data.	Limited design-partner access. Registration records an explicit unsupported state.
REK / FLT / CB / SBM	Vendor and reconstructed-volume formats.	Limited design-partner access. Registration records an explicit unsupported state.
MetaImage	Volumes in research and imaging toolkits.	Planned — not available yet.
NRRD	Volumes in research and imaging toolkits.	Planned — not available yet.

Registration depth is not a support matrix. A raw source is recognized and registered without a rendered image. An unsupported source records the limitation instead of pretending it is viewable. DICONDE, MetaImage, and NRRD remain planned.

Common mistakes and limits

A reference in a database is not proof that bytes never moved elsewhere.
A checksum is not a backup.
Object-store ownership does not remove the need for least-privilege access.
A draft privacy policy awaiting legal review is not a data-processing agreement.
Robots rules and source-code path checks do not protect customer data in a deployed product.

Next step

Draw your current data path and mark each persistence, temporary-processing, and export boundary. Bring that map to Design-partner onboarding.

Outcome	Identify the storage and access claims that require evidence from a working product.
Availability	Limited design-partner access
Audience	Data engineers, ML engineers, Security and operations teams, Technical leaders
Prerequisites	Know where your source volumes live today; Know which systems can read them
Last verified	2026-08-23

Get started

Concepts

Guides

Reference

Intended separation

Source volumes

Version and decision records

Temporary processing

Exports

Where each data class is meant to live

Data classes in detail

Evidence to request

Format and modality scope

Common mistakes and limits

Next step

​Intended separation

​Source volumes

​Version and decision records

​Temporary processing

​Exports

​Where each data class is meant to live

​Data classes in detail

​Evidence to request

​Format and modality scope

​Common mistakes and limits

​Next step

Intended separation

Source volumes

Version and decision records

Temporary processing

Exports

Where each data class is meant to live

Data classes in detail

Evidence to request

Format and modality scope

Common mistakes and limits

Next step