> ## 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.

# Data boundary

> Understand the intended separation between source volumes, version and decision records, temporary processing, and exports.

<a className="nit-availability" data-availability="design-partner" href="/product-status#status-definitions" aria-label="Limited design-partner access. Read the status definitions."><span aria-hidden="true" className="nit-availability__dot" />Limited design-partner access</a>

**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.

<section aria-labelledby="docs-rich-data-boundary-map" aria-describedby="docs-rich-data-boundary-map-caption" className="nit-fig" role="figure">
  <div className="nit-fig__header">
    <p className="nit-fig__status">Planned boundary</p>
    <h2 className="nit-fig__title" id="docs-rich-data-boundary-map">Where each data class is meant to live</h2>
  </div>

  <div className="nit-fig__body">
    <svg aria-labelledby="data-boundary-title data-boundary-description" className="nit-fig__graphic nit-fig__graphic--md" role="img" viewBox="0 0 360 510"><title id="data-boundary-title">Intended Nitsor data boundary</title><desc id="data-boundary-description">Customer-controlled source volumes are distinguished from Nitsor reference, version, and decision records, declared temporary or derived processing, and complete export. This is intended behavior and not a deployed guarantee.</desc><g><rect className="nit-fig__box nit-fig__box--accent" height="78" rx="6" strokeWidth="2" width="320" x="20" y="12" /><text className="nit-fig__label nit-fig__label--sm" textAnchor="middle" x="180"><tspan x="180" y="43">Customer-controlled source volumes</tspan></text><text className="nit-fig__detail" textAnchor="middle" x="180" y="67">customer control</text></g><g aria-hidden="true" className="nit-fig__arrow"><line strokeWidth="2" x1="180" x2="180" y1="90" y2="118" /><path d="M 174 110 L 180 118 L 186 110" strokeWidth="2" /></g><g><rect className="nit-fig__box" height="78" rx="6" strokeWidth="2" width="320" x="20" y="132" /><text className="nit-fig__label nit-fig__label--sm" textAnchor="middle" x="180"><tspan x="180" y="155">Nitsor references, version, and</tspan><tspan x="180" y="172">decision records</tspan></text><text className="nit-fig__detail" textAnchor="middle" x="180" y="194">control records</text></g><g aria-hidden="true" className="nit-fig__arrow"><line strokeWidth="2" x1="180" x2="180" y1="210" y2="238" /><path d="M 174 230 L 180 238 L 186 230" strokeWidth="2" /></g><g><rect className="nit-fig__box" height="78" rx="6" strokeWidth="2" width="320" x="20" y="252" /><text className="nit-fig__label nit-fig__label--sm" textAnchor="middle" x="180"><tspan x="180" y="283">Declared temporary or derived processing</tspan></text><text className="nit-fig__detail" textAnchor="middle" x="180" y="307">must be declared</text></g><g aria-hidden="true" className="nit-fig__arrow"><line strokeWidth="2" x1="180" x2="180" y1="330" y2="358" /><path d="M 174 350 L 180 358 L 186 350" strokeWidth="2" /></g><g><rect className="nit-fig__box" height="78" rx="6" strokeWidth="2" width="320" x="20" y="372" /><text className="nit-fig__label nit-fig__label--sm" textAnchor="middle" x="180"><tspan x="180" y="403">Complete export</tspan></text><text className="nit-fig__detail" textAnchor="middle" x="180" y="427">intended exit path</text></g></svg>

    | 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.                                                                      |
  </div>

  <p className="nit-fig__caption" id="docs-rich-data-boundary-map-caption">Intended behavior only, not a deployed guarantee. Exact fields, locations, lifetimes, retention, and export behavior remain unproved.</p>
</section>

## 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](/guides/design-partner-onboarding).

<table className="nit-page-details" aria-label="Page details">
  <tbody>
    <tr><th scope="row">Outcome</th><td>Identify the storage and access claims that require evidence from a working product.</td></tr>
    <tr><th scope="row">Availability</th><td>Limited design-partner access</td></tr>
    <tr><th scope="row">Audience</th><td>Data engineers, ML engineers, Security and operations teams, Technical leaders</td></tr>
    <tr><th scope="row">Prerequisites</th><td>Know where your source volumes live today; Know which systems can read them</td></tr>
    <tr><th scope="row">Last verified</th><td>2026-08-23</td></tr>
  </tbody>
</table>