Data boundary

All plans Existing scans stay where they live and Nitsor reads them by reference. Uploads can go to connected customer storage, a Nitsor-managed bucket, or storage managed entirely by Nitsor. Hosted workspaces default to Nitsor storage for uploads; the owner can turn it off. On Team and Enterprise, Nitsor hosts the control plane. On Community, the Nitsor backend runs on your infrastructure: the Convex deployment, its operator dashboard and the Nitsor functions. The self-host stack does not include the Nitsor application. Bulk voxels never pass through the control plane in any storage mode.

​

Storage separation

​

Source volumes

A customer storage connection names the endpoint, bucket, region, addressing mode, prefix and an account-owned credential handle. Owners and admins submit or replace keys through the dashboard or personal authority. Nitsor encrypts the keys and never returns them in responses, events, logs or errors. Agent credentials cannot add or change keys or enable writing. A new customer connection is read-only. Nitsor keeps Source metadata, small labels such as landmarks, boxes and classifications, review history, audit events and Dataset Version manifests. It never keeps scan pixels or pixel-derived files for that connection, including viewer representations, thumbnails, mask voxels, model inputs or file copies. There is no fallback into Nitsor storage. Masks, stored viewer representations, uploads, model outputs and Dataset Version files carrying masks need write access. An owner or admin enables writing after the connection passes its checks. Uploads also require the separate Accept uploads setting, enabled by an owner or admin after the upload checks pass. They go to <write prefix>/nitsor-uploads/. See storage connection setup for the checks and setup steps. Registration (POST /api/v1/sources, client.sources.register in the Python SDK) reads what it needs to identify a volume and keeps a reference: A registered Source lists at most 512 objects. One registration carries one format family; mixing families is refused as MIXED_FORMAT_FAMILIES. Registration keeps hashes and references to your source objects; a checksum is not a backup. With write access, Nitsor writes viewer representations under <prefix>/nitsor/source-representations/ in the selected writable destination, as well as the mask chunks drawn in the editor. The connection’s previewObjectBytes field reports the bytes of those viewer representations.

​

Version and decision records

The control plane holds events, commits, hashes, references, Decisions, Ledger entries, Tasks, Datasets and Dataset Version manifests. It never holds a voxel. Nitsor stores annotations, answers and asset references in bounded chunks to stay within the control plane’s document limit.

​

Temporary processing

These paths read or write bytes across the boundary: Hosted model jobs use one run-plane class, managed-vendor, a GPU supplier arranged by Nitsor in region us running an image pinned by digest. Job inputs form temporary processing copies. They are deleted when the Job ends, within 24 hours at most. Hosted plans use this run plane only, and Nitsor runs no hosted compute for Community. Dataset Version downloads over self-serve customer connections need a signer that Nitsor sets up with you. A version with separate read and write connections needs a signer for each. The customer submits a dedicated download-only key through the dashboard; operator setup transfers it into the signer without anyone receiving the key by email or chat. Issued signer links can remain valid for up to one hour. Ordinary viewer links expire within 900 seconds. Viewing, masks, viewer representations and uploads do not use the download signer.

​

Exports

The export is the Dataset Version itself, a manifest with a SHA-256 per 16 MiB chunk, a stats block and a class index, which the Python reader, once the Python SDK is published, streams with every chunk verified. There is no other export route or re-import route.

Data boundary

​

What crosses the line, and what never does

Data class	Where it lives	How it is reached
Source volumes	Existing scans in customer storage; uploads in the selected customer or Nitsor-managed destination.	Registration reads headers and hashes once; the viewer reads slices by presigned range request.
Masks	A writable destination, under a content-addressed prefix.	Written through presigned links; the graph keeps the manifest hash.
Viewer representations	A writable destination, under <prefix>/nitsor/source-representations/.	Nitsor writes them for registered sources; the viewer reads ready ones through presigned links.
Dataset Version artifacts	Artifact storage hosted by Nitsor on Team and Enterprise; member objects stay in their selected storage destination. Mask-bearing files need write access. A Community deployment builds none today: its run plane is off, so a build is refused, and its stack does not run the data-plane Workers that serve reads.	A one-hour lease, checked by a data-plane Worker on every request.
Control-plane records	The Convex deployment, hosted by Nitsor on Team and Enterprise or by you on Community.	The public API and the Nitsor dashboard on Team and Enterprise. On Community, the operator reaches them through the Convex operator dashboard.
Job inputs during prelabeling	A GPU container on the managed run plane, region us, for Team and Enterprise Jobs.	Mounted by the run driver; capped by the image pin.

The control plane records references and decisions. Browsers, training readers and hosted model jobs read volume bytes from storage.

​

Data classes in detail

Export the scans and records you need before closing an account. Owner-directed deletion of Nitsor-managed uploads is separate from account and workspace record deletion and from the Dataset Version artifact grace period. See Retention and deletion. On Community, set STORAGE_PROVIDER=s3-compatible and S3_ENDPOINT together for Nitsor’s artifacts. Source volumes remain in the buckets registered through storage connections. The Community backend’s data volume is not a backup. Back up that volume and .env yourself.

​

What is published about this boundary

GET /api/v1/capabilities reports the topology and product version. Roles and provenance describes permission boundaries. Deployment and security covers deployment controls and operational limits. Enterprise deployment, security and procurement documentation are agreed with sales.

​

Format and modality scope

Source formats are recognized at registration by reading the object headers or extensions. Viewability is a registration fact: viewable sources render in the viewer and editor, raw sources are genuine acquisition data with no reconstructed image, and unsupported sources are recognized by name and not decoded. Files matching no known format are not sources at all. Uncompressed single-frame DICOM ultrasound is handled as a 2D image. Compressed transfer syntaxes are not supported. Ultrasound uses PixelSpacing or suitable Ultrasound Regions for calibration. An uncalibrated image has no physical scale. Register geometry-free images separately. NumberOfFrames must be 1: multi-frame cine and native 3D/4D ultrasound are not supported. Registration and viewing do not imply compatibility with every hosted model. DICONDE, MetaImage, NIfTI and NRRD are not recognized. The viewer decodes these raw slice encodings (raw-uint8, raw-int8, raw-uint16-le, raw-int16-le, raw-float32-le) and refuses a slice plane above 16,384 pixels on either axis.

​

Next step

Draw your current data path and mark each persistence, temporary-processing, and export boundary. Use that map during workspace setup, and read Register a source for the connection and registration steps.

Plans	All plans
Last verified	2026-09-30