# Evaluate Nitsor context

> Current status, data boundaries, integrations, deployment, and a first action.
> Estimated tokens: 17385
> Generated from the public documentation. Preserve availability labels and cite page sources.
> No agent can create or approve a Nitsor release today; this export grants no permission and exposes no actions.

# Introduction

> Understand what Nitsor is, what a visitor can use today, and where each part of this documentation answers a different question.

- Outcome: Choose a truthful next step without assuming a planned capability is already available.
- Availability: Available now
- Audience: Technical program managers, Annotators and reviewers, Technical teams, Researchers and leaders
- Prerequisites: No Nitsor account is required
- Last verified: 2026-08-23
- Source: https://nitsor.com/docs

Nitsor is a pre-release product for teams that need a dependable history of volumetric data, labels, reviews, and dataset-release decisions. These pages describe that product precisely and say, on every page, how much of it you can use today.

## What Nitsor is \[#what-nitsor-is]

Industrial computed tomography (CT) and non-destructive testing are the initial commercial focus. Magnetic resonance imaging (MRI) helps test whether the same ideas work in a different field.

The intended product keeps a clear record of how a dataset changes and how a release is approved. It is designed to complement the storage and annotation tools a team already uses. The full workflow describes planned behavior and is not available as a public service today.

## What is available now \[#what-is-available-now]

- This public marketing site and customer documentation.
- A contact path for product questions and design-partner conversations.
- A clear description of the planned product that teams can evaluate without assuming it is already available.

Read [Product status](https://nitsor.com/docs/product-status) before relying on any statement about workflows, integrations, deployment, software packages, command-line tools, or application programming interfaces (APIs).

## How these pages are arranged \[#how-these-pages-are-arranged]

Every page carries an availability label before its title. The label answers one question: can you use the behavior this page describes? Read [Product status](https://nitsor.com/docs/product-status) for the definition of each label.

| Section                                                  | What it answers                                                                     | Start with                                                             |
| -------------------------------------------------------- | ----------------------------------------------------------------------------------- | ---------------------------------------------------------------------- |
| [Quickstart](https://nitsor.com/docs/quickstart)         | What can I do in the next hour, given that this is pre-release?                     | The first-action table for your role.                                  |
| [Product status](https://nitsor.com/docs/product-status) | Which capability is built, which is reachable, and which is still an open decision? | The capability status matrix.                                          |
| [Concepts](https://nitsor.com/docs/concepts)             | What do the words mean, and how does the intended model fit together?               | Version model.                                                         |
| [Guides](https://nitsor.com/docs/guides)                 | How is one job meant to run from beginning to end?                                  | The guide closest to the work you already do.                          |
| [Reference](https://nitsor.com/docs/reference)           | What exactly exists, with its exact boundary?                                       | Integrations and public interfaces, then the interface you care about. |

## Choose your path \[#choose-your-path]

Each path orders the same documentation for a different job. Pick the one closest to your role; every path links back to shared concepts when it needs them.

- [Annotators and reviewers](https://nitsor.com/docs/guides/annotate-and-review): Learn the vocabulary and the intended review workflow. You do not need storage or API knowledge to judge whether the task model makes sense. Destination: Vocabulary and review basics.
- [Operations and program teams](https://nitsor.com/docs/guides/dataset-release): Follow what changed, which reviews happened, what counts as an approved release, and which evidence each step should leave behind. Destination: Change and release tracking.
- [ML, data, and software teams](https://nitsor.com/docs/guides/plan-an-integration): Evaluate the interfaces that exist and the evidence to demand before depending on one. No public SDK, command-line package, or self-hosted product is available now. Destination: Interfaces and acceptance tests.
- [Researchers and leaders](https://nitsor.com/docs/product-status): Separate the problem Nitsor addresses from the product behavior that still needs design-partner testing before you rely on it. Destination: Capability register and open decisions.

If a term is unfamiliar, open the [Glossary](https://nitsor.com/docs/reference/glossary).

## Common mistake \[#common-mistake]

Do not read a concrete workflow example as proof that you can run it today. Examples marked **planned — not available yet** explain intended behavior and do not contain runnable product instructions.

## Next step \[#next-step]

Read the [Quickstart](https://nitsor.com/docs/quickstart) for a first action, then [Product status](https://nitsor.com/docs/product-status) before you rely on any capability claim.

---

# Quickstart

> Take one useful first action today, using only the parts of Nitsor that a visitor can actually reach.

- Outcome: Leave with one focused, truthful action and the evidence you still need to ask for.
- Availability: Available now
- Audience: All readers, Evaluators, AI agents
- Prerequisites: Read the Introduction
- Last verified: 2026-08-23
- Source: https://nitsor.com/docs/quickstart

Most quickstarts end with something running. This one cannot, because Nitsor is pre-release and there is no public sign-up, package, or sample workspace. What you can do in the next hour is decide whether the intended product fits a real decision your team already makes, and write down the evidence that would settle it.

## What you can reach today \[#what-you-can-reach-today]

- These documentation pages, plus a clean Markdown copy of each one at the same address with `.md` added.
- `/llms.txt`, `/llms-full.txt`, and four curated context bundles for AI tools.
- Documentation search.
- A [contact form](https://nitsor.com/contact) for product and design-partner questions.

Nothing here requires an account, and nothing here grants product access.

## Pick your first action \[#pick-your-first-action]

Find the row closest to your situation. Each row gives one page to read first and one action small enough to finish this week.

| If you…                    | Read this first                                                                                                                                | First action                                                                                                                                                                                                           |
| -------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Annotate or review         | [Annotate and review](https://nitsor.com/docs/guides/annotate-and-review)                                                                      | Bring one instruction, one representative task, and the current rule for returning or escalating work.                                                                                                                 |
| Run the program            | [Release a dataset](https://nitsor.com/docs/guides/dataset-release)                                                                            | Map one release decision from source selection through approval and note the evidence you cannot reconstruct today.                                                                                                    |
| Build integrations         | [Plan an integration](https://nitsor.com/docs/guides/plan-an-integration), then [Integrations](https://nitsor.com/docs/reference/integrations) | Read the [public HTTP API](https://nitsor.com/docs/reference/api) and [command-line interface](https://nitsor.com/docs/reference/cli) contracts, then write the acceptance test a future package or service must pass. |
| Model data or contracts    | [Data model and contracts](https://nitsor.com/docs/reference/data-model)                                                                       | Compare one of your own release records against the recorded contracts and mark what has no equivalent.                                                                                                                |
| Make the adoption decision | [Product status](https://nitsor.com/docs/product-status)                                                                                       | Define the smallest design-partner evaluation that could change your decision, separating conclusions that need a working product.                                                                                     |
| Read this programmatically | `/llms.txt`, then the context bundles listed in [Integrations](https://nitsor.com/docs/reference/integrations)                                 | Load the smallest bundle that covers your question and cite the page source recorded inside it.                                                                                                                        |

Deployment and security requirements have their own evidence checklists in [Deployment and security](https://nitsor.com/docs/reference/deployment-and-security) and [Self-host mechanics](https://nitsor.com/docs/reference/self-host).

## If you get stuck \[#if-you-get-stuck]

| Situation                                                 | What to do                                                                                                                   |
| --------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------- |
| You cannot tell whether a capability exists               | Open [Product status](https://nitsor.com/docs/product-status) and read the capability status matrix rather than the prose.   |
| Search did not return the page you expected               | Try a concrete noun from the [Glossary](https://nitsor.com/docs/reference/glossary), or use the sidebar.                     |
| A documentation link is broken                            | Recover through the sidebar, record the page and the link, and do not substitute a private path.                             |
| The contact form rejects your message                     | Use the exact [contact form validation](https://nitsor.com/docs/reference/integrations#contact-form-validation) constraints. |
| An agent answered without a source or changed a label     | Treat the answer as unsupported and require the source URL and the quoted availability label.                                |
| You need legal, privacy, security, or compliance approval | Pause and involve the authorized owner; the public legal pages are drafts awaiting counsel review.                           |

## What to include in a useful question \[#what-to-include-in-a-useful-question]

- your role and intended outcome;
- the relevant workflow or decision;
- the page you already read;
- the availability or evidence point that remains unclear;
- the smallest piece of working evidence or test that would answer it.

The same limits apply here as in [Design-partner onboarding](https://nitsor.com/docs/guides/design-partner-onboarding). Do not send credentials, patient or customer scan data, storage locations, or confidential material through a public contact form.

## Common mistakes and limits \[#common-mistakes-and-limits]

- A contact message is not an authorization to access systems or data.
- A design-partner conversation is not a delivery commitment.
- A complete documentation path is not proof that the product path exists.
- Retrying does not turn an unavailable capability into an available one.
- A context bundle is not a substitute for reading the cited source when making a high-stakes decision.

## Next step \[#next-step]

Read [Product status](https://nitsor.com/docs/product-status), then record the exact evidence you would need before adopting the workflow you care about. If a focused design-partner evaluation is appropriate, continue to [Design-partner onboarding](https://nitsor.com/docs/guides/design-partner-onboarding).

---

# Product status

> See what is available now, what is limited to design-partner work, and what is still planned.

- Outcome: Cite the correct availability level when discussing a Nitsor capability.
- Availability: Available now
- Audience: Evaluators, Technical teams, Operational leaders, AI agents
- Prerequisites: Read the Introduction
- Last verified: 2026-08-18
- Source: https://nitsor.com/docs/product-status

## Status definitions \[#status-definitions]

**Available now** means a visitor can use the behavior on this public site today and automated tests verify it.

**Limited design-partner access** means the work is pre-release and shaped with a small number of teams. Scope, access, and suitability must be agreed directly. It is not a promise of production service.

**Planned — not available yet** means the documentation describes intended behavior so teams can evaluate it and give precise feedback. Technical exports call this a **target contract**. It is not a runnable product or integration.

**Open** marks a decision that has not been settled. **Pending** marks evidence that has not yet been provided or checked. Both describe unresolved decisions or evidence; they are not additional availability levels. Some tables also write **Not available** against interfaces where no public implementation of any kind exists; read it as a stricter restatement of Planned — not available yet, not as a fourth level.

The three availability labels are used the same way on every page of this documentation. This legend is the definition other pages rely on.

| Label                         | What it means                                                                                                | Evidence required                                                                                 | What it is not a claim of                                                                                      |
| ----------------------------- | ------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------- |
| Available now                 | A visitor can use the behavior on this public site today.                                                    | Working behavior on the current public site, verified by automated tests.                         | Any capability outside this public site, and any promise about a future release.                               |
| Limited design-partner access | Pre-release work shaped with a small number of teams. Access, scope, and suitability are agreed directly.    | An implementation that an agreed design partner can exercise within the agreed pre-release scope. | A public release, a production service, a service level, or an offer to accept any particular team.            |
| Planned — not available yet   | The documentation describes intended behavior so teams can evaluate the direction and give precise feedback. | A written description only. Technical exports call this a target contract.                        | A runnable product, screen, command, public interface, or integration, even where the text uses present tense. |

### The four readiness states used on the marketing pages \[#the-four-readiness-states-used-on-the-marketing-pages]

The home page carries one readiness band with four states, and it links here because this page defines them. They are a different vocabulary from the three availability labels above, on purpose, and neither one is a translation of the other. The availability label answers **who can reach a capability**. The readiness state answers **how far the work has got**. A capability can be built and reachable by nobody, which is why both exist.

| State           | What it means                                                                          |
| --------------- | -------------------------------------------------------------------------------------- |
| Live today      | You can use it right now, on this site.                                                |
| In build for v0 | Committed for the first release. The code exists. You cannot use it yet.               |
| After v0        | Named and sequenced, not started. A design partner needing it is what starts the work. |
| Still open      | A decision nobody has made yet. It is here so you can ask about it.                    |

The summary table in the next section abbreviates these to **Live**, **In build**, **After v0** and **Open** to fit a narrow column. The four full names above are the definitions.

**Where the two vocabularies disagree about the same capability, the availability level in the capability status matrix is correct.** That matrix is checked row by row against the code and carries a depth note for each one. A readiness state is a one-word summary and cannot carry a boundary.

## Available now \[#available-now]

- Public marketing, planned-pricing, FAQ, contact, and draft legal pages.
- Public documentation under `/docs`.
- A contact form with input validation and safe email formatting covered by automated tests. Those tests do not prove live email delivery.

## Limited design-partner access \[#limited-design-partner-access]

Nitsor is looking for teams with recurring industrial CT, medical CT, or MRI workflows who control their source storage and can evaluate the product with real constraints. Participation, scope, support, and production suitability must be agreed directly; this page does not promise acceptance or a service level.

The implemented [Public HTTP API](https://nitsor.com/docs/reference/api), [command-line interface](https://nitsor.com/docs/reference/cli), and replay-tested [data model and contracts](https://nitsor.com/docs/reference/data-model) are available only inside an agreed design-partner environment. Their reference pages state the authentication, distribution, and product-readiness limits that still apply.

Format depth is also narrow. 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. DICONDE, MetaImage, and NRRD remain planned.

## Planned — not available yet \[#planned--not-available-yet]

The following areas are described so teams can review the direction, but they are not available as a released product:

- complete project, branch, commit, review, agreement, final-decision, and release workflows;
- source-data registration and data-location guarantees in a deployed product;
- public SDK, Model Context Protocol (MCP), webhook, or agent integrations;
- a supported self-hosted product, release pipeline, upgrade path, or rollback path;
- enterprise identity, authorization, billing, compliance, or hosted inference.

The tested [`nitsor up` mechanics](https://nitsor.com/docs/reference/self-host) start an incomplete dependency stack, not a supported Nitsor product. If you encounter a planned workflow example, read it only as a target contract rather than as proof of an available product.

## Readiness at a glance \[#readiness-at-a-glance]

Twelve lines, in the four-state vocabulary the home page band uses. This is the readable summary. The capability status matrix below it is the register, and it governs.

| Capability                                            | State    | What exists today                                                                            |
| ----------------------------------------------------- | -------- | -------------------------------------------------------------------------------------------- |
| This website and the public documentation             | Live     | Including the contact form, which reports a clear error if delivery fails.                   |
| Full-depth 3D viewer and editor                       | In build | Every editor screenshot on this site is a design mockup, labelled as one.                    |
| Version graph, branch, semantic diff, three-way merge | In build | The spine. Nothing above it is meaningful without it.                                        |
| Dataset releases and frozen manifests                 | In build | Rebuilding a dataset outside Nitsor is the target. We have not demonstrated it.              |
| Routing, review, consensus, adjudication, gold tasks  | In build | SAM 2.1 proposals and risk-controlling routing are the whole committed model scope.          |
| API, CLI, SDK, single-node self-host                  | In build | The specification defines these contracts. Nothing answers a request yet.                    |
| Calibration, Certificates, auto-accept                | In build | Enterprise tier. We have designed the independent verifier. Nobody has written it.           |
| DICOMweb, PACS and VNA adapters                       | After v0 | For v0 you bring industrial MRI and DICOM in through your own object storage.                |
| General agents and MCP                                | After v0 | v0 distinguishes humans, services and model executions. General agent principals come later. |
| Which licence in the FSL/BSL family                   | Open     | We also cannot publish before IP clearance, and that has not happened.                       |
| Published packages and prices                         | Open     | Seatless is settled. The numbers are not.                                                    |
| Exact supported format list per release               | Open     | Round-trip tests decide this, not a marketing checklist.                                     |

### Where this summary is rougher than the matrix \[#where-this-summary-is-rougher-than-the-matrix]

Six of the twelve rows above compress a boundary that the matrix states exactly. Read the matrix for any of them before you rely on it.

- **Full-depth 3D viewer and editor** reads as unreachable. It is not: the limited editor renders supported registered data for an agreed design partner. What no one can use is the full-depth viewer.
- **API, CLI, SDK, single-node self-host** is four things in one row and they are not at the same stage. The HTTP API and the command-line interface are built and reachable inside an agreed design-partner environment, so "Nothing answers a request yet" is wrong for those two. No SDK package exists, and the self-host installer starts an incomplete dependency stack rather than a Nitsor product.
- **Version graph, branch, semantic diff, three-way merge**, **Dataset releases and frozen manifests**, and **Routing, review, consensus, adjudication, gold tasks** read as "the code exists". For these three the matrix is stricter: an early backend description exists, there is no user interface, and no release can be created or approved.
- **Calibration, Certificates, auto-accept** says it plainly in its own note and the matrix agrees. Nobody has written it.

Two capabilities have no row in the summary at all and do have one in the matrix: **hosted workspace and sign-in**, and **hosted operation**. Both are marked Pending, meaning no deployed-operation evidence has been reviewed, so no reachable hosted service is claimed.

## Capability status matrix \[#capability-status-matrix]

This is the canonical list of availability levels for Nitsor capabilities. Other pages link here rather than repeating it, so if a statement elsewhere disagrees with this table, this table is correct.

Each row carries an availability label or an explicit pending-evidence marker, checked on 18 August 2026. Only the last row is **Available now**. The Depth column says how far the work has progressed in plain words. A capability that exists only as a backend record has no screen, command, or public interface a customer can use.

| Capability                                             | Status                        | Depth today                                                                                                                  |
| ------------------------------------------------------ | ----------------------------- | ---------------------------------------------------------------------------------------------------------------------------- |
| Hosted workspace and sign-in                           | Pending                       | Built; no deployed-operation evidence was reviewed, so no reachable hosted workspace is claimed.                             |
| Account roles and permissions                          | Limited design-partner access | Built.                                                                                                                       |
| Recorded authorization decisions and attribution       | Limited design-partner access | Built as backend records. No screen presents them.                                                                           |
| Project record and event history                       | Limited design-partner access | Built as backend records. No screen presents them.                                                                           |
| Version model (branches, commits, merges)              | Planned — not available yet   | An early backend description exists. There is no user interface.                                                             |
| Review, consensus, and adjudication workflow           | Planned — not available yet   | An early backend description exists. There is no user interface.                                                             |
| Model-assisted prelabeling with calibrated uncertainty | Planned — not available yet   | A description exists, including how the system declines a case it cannot support. No model runs.                             |
| Medical-image (DICOM) series registration              | Limited design-partner access | Supported uncompressed Part 10 slices can register and render in the browser within the limited editor.                      |
| Volumetric viewer                                      | Limited design-partner access | The limited editor renders supported registered data; the standalone demo still uses synthetic data.                         |
| Public HTTP API                                        | Limited design-partner access | Built. See [Public HTTP API](https://nitsor.com/docs/reference/api) for its authentication limitation.                       |
| Command-line interface                                 | Limited design-partner access | Five command families are built.                                                                                             |
| TypeScript and Python SDKs                             | Planned — not available yet   | No package exists.                                                                                                           |
| Dataset releases with signed manifests                 | Planned — not available yet   | Described only. No release can be created or approved.                                                                       |
| Self-host installer                                    | Planned — not available yet   | The installer mechanics are tested, but no complete application package exists to install.                                   |
| Hosted operation                                       | Pending                       | No deployed-operation evidence was reviewed; no running hosted service is claimed.                                           |
| Industrial (non-DICOM) file formats                    | Limited design-partner access | VGI/VOL is viewable; MRD and TIFF/xtekct are raw; five named families register as unsupported; other formats remain planned. |
| Analytics and progress reporting                       | Planned — not available yet   | Described only.                                                                                                              |
| Documentation and agent-readable exports               | Available now                 | Published on this site and verified by automated tests.                                                                      |

## What counts as evidence \[#what-counts-as-evidence]

For these docs, “available” is limited to behavior a visitor can use on the current public site and that automated tests verify. A future release may add product capabilities. A roadmap statement or a sentence written in the present tense is not enough to call something available.

| Counts as evidence                                          | Does not count as evidence                           |
| ----------------------------------------------------------- | ---------------------------------------------------- |
| Working behavior on the current public site.                | A roadmap statement or planned date.                 |
| An automated test that verifies the named behavior.         | A sentence written in the present tense.             |
| A recorded result tied to a specific version.               | A demonstration that cannot be repeated.             |
| A limitation stated together with the capability it limits. | A capability described without its current boundary. |

## What the synthetic review measured

Status: Synthetic review

The fixed synthetic documentation review included 15 personas: 5 scored 9/10 and 10 scored 10/10.

A frozen snapshot is a saved copy reviewed without later edits. These scores apply only to the first two frozen documentation snapshots. The current published documentation was not rescored.

Pending: repeat this synthetic review with the current public documentation.

This is documentation-clarity evidence only, not customer, product, domain, legal, security, or production validation.

| Score         | Personas |
| ------------- | -------- |
| 9/10          | 5        |
| 10/10         | 10       |
| Total reviews | 15       |

This is documentation-clarity evidence only, not customer, product, domain, legal, security, or production validation.

## Next step \[#next-step]

Return to the [Introduction](https://nitsor.com/docs/) or [contact the team](https://nitsor.com/contact) with the workflow you want to evaluate and the evidence you would need before adopting it.

---

# Data boundary

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

- 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
- Source: https://nitsor.com/docs/concepts/data-boundary

**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 \[#intended-separation]

### Source volumes \[#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 \[#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 \[#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 \[#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.

## Where each data class is meant to live

Status: Planned boundary

| 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 \[#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 \[#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 \[#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 \[#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 \[#next-step]

Draw your current data path and mark each persistence, temporary-processing, and export boundary. Bring that map to [Design-partner onboarding](https://nitsor.com/docs/guides/design-partner-onboarding).

---

# Integrations and public interfaces

> See which public interfaces exist today and which APIs, tools, and product integrations are still planned.

- Outcome: Choose only an interface that is genuinely available and record acceptance tests for future dependencies.
- Availability: Available now
- Audience: ML engineers, Data engineers, Software engineers, AI agents
- Prerequisites: Read Product status
- Last verified: 2026-08-23
- Source: https://nitsor.com/docs/reference/integrations

Nitsor publishes a small set of public interfaces, and none of them is a product API. This page lists what exists today, states the boundary on each one, and shows how the documentation itself reaches an AI tool.

## Available public interfaces \[#available-public-interfaces]

The current public site provides:

- server-rendered marketing and customer-documentation pages;
- a public contact form;
- ordinary HTML links and a sitemap;
- per-page Markdown documentation exports;
- `/llms.txt` and `/llms-full.txt`;
- curated, read-only context bundles for agents;
- a documentation search endpoint used by the public docs interface.

These interfaces help people read about Nitsor and contact the team. They are not APIs for product data.

## Contact form \[#contact-form]

The form accepts a name, email, optional company, and message. Automated tests cover validation and safe email formatting. They do not prove live email delivery, a response time, spam resistance, or a customer-support service.

Do not submit secrets, credentials, sensitive scans, patient or customer data, storage URLs, or confidential strategy.

## Contact form validation \[#contact-form-validation]

Validation applies after leading and trailing whitespace is removed.

| Field   | Required | Exact validation                                       |
| ------- | -------- | ------------------------------------------------------ |
| Name    | Yes      | Trimmed; 1 to 120 characters.                          |
| Email   | Yes      | Trimmed; valid email address; 254 characters or fewer. |
| Company | No       | Trimmed; 120 characters or fewer.                      |
| Message | Yes      | Trimmed; 10 to 4,000 characters.                       |

## Agent-readable documentation \[#agent-readable-documentation]

Each documentation page links to a clean Markdown equivalent at the same address with `.md` added. `/llms.txt` lists every page with its availability label and an estimated size. `/llms-full.txt` combines the complete set.

Agents should cite the HTML source URL included in each export and preserve availability labels. Agent-readable documentation grants no permission. No agent can create or approve a Nitsor release today.

Each written page starts as a Markdown file stored with the website code. Markdown uses plain-text formatting markers. This project uses MDX, a form of Markdown that can also include reviewed components.

Fumadocs is the publishing system that turns those files into the pages you are reading. Tests compare each custom visual summary with the facts below.

## How one written source becomes six public outputs

Status: Verified documentation

Reviewed Markdown files supply each written page and machine-readable export.
Checked visual components summarize the same facts, and the renderer publishes the public outputs below.

| Public output                | Result                                |
| ---------------------------- | ------------------------------------- |
| Human-readable documentation | 22 HTML pages rendered by the website |
| Portable page content        | One Markdown export for each page     |
| Discovery                    | Documentation search                  |
| AI reading index             | llms.txt                              |
| Complete AI-readable export  | llms-full.txt                         |
| Focused reading sets         | Exactly four smaller context bundles  |

Agent-readable outputs expose no actions and grant no permission.

The export route is part of this site and does not require a Nitsor account.

**Pending — public origin:** a deployed public origin has not been verified. For command-line use, set `NITSOR_DOCS_ORIGIN` to the origin of the reviewed site you are reading, without a trailing slash.

### curl

```bash
curl --fail --show-error --silent --max-time 10 "$NITSOR_DOCS_ORIGIN/docs/index.md"
```

### Python

```python
import os
import urllib.request

origin = os.environ["NITSOR_DOCS_ORIGIN"].rstrip("/")

with urllib.request.urlopen(f"{origin}/docs/index.md", timeout=10) as page:
    print(page.read().decode())
```

### JavaScript

```js
const origin = process.env.NITSOR_DOCS_ORIGIN;

if (!origin) {
  throw new Error("Set NITSOR_DOCS_ORIGIN to the reviewed documentation origin.");
}

const page = await fetch(new URL("/docs/index.md", origin), {
  signal: AbortSignal.timeout(10_000),
});

if (!page.ok) {
  throw new Error(`Documentation request failed with HTTP ${page.status}.`);
}

console.log(await page.text());
```

Each example stops after ten seconds and treats an HTTP error as a failed request instead of printing the error page as documentation.

Reading these files grants no product access or permission.

## Context bundles \[#context-bundles]

A context bundle is a prepared set of related pages. It makes focused reading easier and grants no permission or product access. Start with `/llms.txt`, then choose the smallest bundle that covers your question.

| Bundle                                                                                    | What it covers                                                                          | Pages included                                                                                                        |
| ----------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------- |
| [Evaluate Nitsor](https://nitsor.com/docs/context/evaluate-nitsor.md)                     | Current status, data boundaries, integrations, deployment, and a first action.          | Introduction; Quickstart; Product status; Data boundary; Integrations and public interfaces; Deployment and security  |
| [Design-partner onboarding](https://nitsor.com/docs/context/design-partner-onboarding.md) | Fit, prerequisites, onboarding questions, and the security evidence a partner asks for. | Quickstart; Product status; Design-partner onboarding; Deployment and security                                        |
| [Dataset release](https://nitsor.com/docs/context/dataset-release.md)                     | The planned model for versioning, roles, review, and dataset releases.                  | Product status; Version model; Roles and provenance; Review, consensus, and adjudication; Release a dataset; Glossary |
| [Programmatic access](https://nitsor.com/docs/context/programmatic-access.md)             | Product status, public API, command-line interface, and data-model contracts.           | Product status; Integrations and public interfaces; Public HTTP API; Command-line interface; Data model and contracts |

Each bundle and each page in `/llms.txt` carries an estimated size. Those estimates are derived from the length of the text, not from any provider's billing, so treat them as a rough guide when choosing what to load.

## What the Markdown and HTML versions must agree on \[#what-the-markdown-and-html-versions-must-agree-on]

| Fact                | Must agree | May differ                         |
| ------------------- | ---------- | ---------------------------------- |
| Main topic          | Yes        | No                                 |
| Availability status | Yes        | No                                 |
| Prerequisites       | Yes        | No                                 |
| Limits              | Yes        | No                                 |
| Next steps          | Yes        | No                                 |
| Navigation controls | No         | Yes — they may appear only in HTML |

If the two versions make contradictory claims, do not rely on either claim; use [Product status](https://nitsor.com/docs/product-status) and contact the team with the page URL and exact wording.

## Programmatic and self-host surfaces \[#programmatic-and-self-host-surfaces]

Implemented contracts do not all have the same availability. The API, CLI, and backend data contracts require an agreed design-partner environment. The self-host page is a target contract that distinguishes tested bootstrap mechanics from a supported product. None of these pages provides a public installation or sign-in path.

| Surface                              | Availability                  | Current boundary                                                                                          | Reference                                                                |
| ------------------------------------ | ----------------------------- | --------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------ |
| Public HTTP API                      | Limited design-partner access | 16 implemented routes; transport authentication is not production-ready.                                  | [Public HTTP API](https://nitsor.com/docs/reference/api)                 |
| Command-line interface               | Limited design-partner access | Five tested command families; no published release pipeline or public installation command.               | [Command-line interface](https://nitsor.com/docs/reference/cli)          |
| Data model and contracts             | Limited design-partner access | Replay-tested backend contracts; no supported operator product, and some target contracts remain planned. | [Data model and contracts](https://nitsor.com/docs/reference/data-model) |
| Self-host mechanics                  | Planned — not available yet   | Tested `nitsor up` bootstrap mechanics start dependencies, not a complete supported Nitsor product.       | [Self-host mechanics](https://nitsor.com/docs/reference/self-host)       |
| SDK, MCP, webhook, and agent actions | Not available                 | No public package, server, webhook, or action surface is published.                                       | —                                                                        |

Before depending on a future interface, work through the canonical [pre-integration acceptance gate](https://nitsor.com/docs/guides/plan-an-integration#evidence-required-before-integration). Every item there — from a versioned release through export and migration behavior — applies to any interface listed as planned on this page.

## Search and machine consumption limits \[#search-and-machine-consumption-limits]

Search ranking is intended for this small documentation set, not as a general knowledge base. Token counts are estimates based on text size, not provider-specific billing measurements. Agent answers remain synthetic and must not be treated as product or customer validation.

## Common mistakes and limits \[#common-mistakes-and-limits]

- A `.md` documentation URL is not a product endpoint.
- A context bundle is not a tool permission.
- A description of a workflow is not an SDK example.
- Search visibility does not change product availability.
- Generated exports must not be copied into a private operational system without checking their public status and date.

## Next step \[#next-step]

If you need a product interface, write the smallest executable acceptance test it would have to pass, then bring it to [Design-partner onboarding](https://nitsor.com/docs/guides/design-partner-onboarding).

---

# Deployment and security

> Separate the public site's verified controls from planned product deployment, security, identity, compliance, and self-hosting capabilities.

- Outcome: Build an evidence checklist without assuming a production deployment option exists.
- Availability: Planned — not available yet
- Audience: Software and security teams, CTOs, Heads of AI and Software, Operational decision-makers
- Prerequisites: Read Product status; Identify your hosting, identity, and compliance requirements
- Last verified: 2026-08-23
- Source: https://nitsor.com/docs/reference/deployment-and-security

**Status: Planned — not available yet.** This page is a target contract: a precise description of the deployment and security evidence a future Nitsor product should provide. It also lists a few controls verified for the public site.

## Verified for the public site \[#verified-for-the-public-site]

The public site configures browser security headers that limit which resources a page may load, how referral information is shared, whether browsers may guess file types, and whether another site may place Nitsor in a frame. A response header is a short instruction the website sends alongside each page to tell the browser how to treat it.

**Available now.** The website sends each of the four headers below on public pages, and an automated test checks that they are present and correctly set.

| Header                    | What it controls                                                                                          | How it is verified                                    |
| ------------------------- | --------------------------------------------------------------------------------------------------------- | ----------------------------------------------------- |
| `Content-Security-Policy` | Which sources a browser is allowed to load content from, so injected third-party content is refused.      | Automated test of the header sent by the public site. |
| `Referrer-Policy`         | How much information about the page you came from is passed on when you follow a link away from the site. | Automated test of the header sent by the public site. |
| `X-Content-Type-Options`  | Prevents the browser from guessing a file's type instead of trusting the type the site declared.          | Automated test of the header sent by the public site. |
| `X-Frame-Options`         | Prevents another website from embedding Nitsor pages inside a frame on its own page.                      | Automated test of the header sent by the public site. |

Automated documentation tests also check that public content comes from the public-site folder and scan for known private markers.

These controls apply to the public site. They are not evidence for a future dashboard, product-data storage or processing, storage integration, identity system, or self-hosted deployment.

## Product deployment status \[#product-deployment-status]

**Planned — not available yet.** Nothing in this table describes a service you can buy or run today. Each row records a commitment a production offering would have to publish, and the honest status of that commitment right now.

| Deployment commitment | What a buyer would need to see                                                                 | Current status |
| --------------------- | ---------------------------------------------------------------------------------------------- | -------------- |
| Hosting architecture  | Where the service runs, how tenants are separated, and which components hold customer records. | Not published  |
| Regional availability | The regions a customer may choose and where records stay.                                      | Not published  |
| Service levels        | Availability, support response, and escalation commitments.                                    | Not published  |
| Backup contract       | Backup frequency, retention, restore procedure, and tested recovery times.                     | Not published  |
| Upgrade policy        | Release cadence, notice periods, compatibility rules, and rollback.                            | Not published  |
| General availability  | The date the product becomes generally purchasable and supported.                              | Not published  |

Nitsor is not operated as a hosted service you can sign up for today, and no self-hosting package, image, installer, deployment file, or upgrade path is published. An intention to be deployable or open does not satisfy an operational acceptance test.

## Identity and permissions \[#identity-and-permissions]

The intended product requires separate human and machine identities, limited permissions, attributable actions, and protected decisions. No public sign-in setup, organization model, session behavior, or permission table is available today.

A provider name in draft legal text would not make that provider a permanent architecture commitment.

## Security and compliance questions \[#security-and-compliance-questions]

**Planned — not available yet.** Use this table as the list of asks for a future security review. The questions are ready to send; the answers are not published, so treat every current status below as an open item rather than a reassurance.

| Area                              | Question to ask                                                                          | Acceptable evidence                                                                   | Current status |
| --------------------------------- | ---------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------- | -------------- |
| System and data-flow boundaries   | Which components hold or move customer data, and where does each boundary sit?           | A current architecture and data-flow description reviewed against the running system. | Not published  |
| Tenancy and authorization         | How is one customer's data kept unreachable by another customer or an unauthorized user? | Isolation design plus tests that demonstrate a denied cross-tenant request.           | Not published  |
| Credential and key handling       | Where are secrets stored, who can read them, and how are they rotated?                   | A secret-management description and evidence of a completed rotation.                 | Not published  |
| Encryption                        | What is encrypted while travelling over a network and while stored?                      | Configuration evidence for both cases, with the key owner named.                      | Not published  |
| Integrity of history records      | Can decision and version history be altered after the fact, and who could do it?         | An append-only or tamper-evidence design plus an access list.                         | Not published  |
| Vulnerability and dependency care | How are known vulnerabilities in the product and its dependencies found and fixed?       | A scanning and patching process with recent, dated results.                           | Not published  |
| Incident response                 | What happens when a security incident occurs, and when are customers told?               | A written response plan with notification timelines and a rehearsal record.           | Not published  |
| Backup, retention, and deletion   | How is data backed up, how long is it kept, and how is deletion confirmed?               | Retention and deletion policies plus a tested restore.                                | Not published  |
| Deployment and upgrade paths      | How does a change reach production, and who approves it?                                 | A change-control description and evidence that upgrades and rollbacks were run.       | Not published  |
| Regulatory and customer controls  | Which external regulations or customer-specific controls apply, and who signs off?       | A mapping of applicable controls to product behavior, reviewed by your own counsel.   | Not published  |

No certification, regulated-use approval, medical-device status, or compliance attestation is claimed.

## Self-hosting acceptance gate \[#self-hosting-acceptance-gate]

**Planned — not available yet.** Self-hosting means running Nitsor on infrastructure your own team controls. Before calling any future option self-hostable, require all ten criteria below to pass. None of them passes today, so the honest reading of this table is that a self-host offering does not exist yet — not that it is nearly ready.

| Criterion                  | What a pass requires                                                                    | Current status    |
| -------------------------- | --------------------------------------------------------------------------------------- | ----------------- |
| Versioned package          | A named, numbered release you can obtain again later and pin to.                        | Not available yet |
| Integrity verification     | A way to confirm the package you received is exactly the one that was published.        | Not available yet |
| Dependency list            | A complete list of every other component the product needs to run.                      | Not published     |
| Identity                   | A documented way to connect your own sign-in system and manage accounts over time.      | Not available yet |
| Secrets handling           | Documented storage, access, and rotation of passwords, keys, and tokens.                | Not published     |
| Storage and backup         | Defined storage requirements plus backup and restore procedures you can test.           | Not published     |
| Upgrade and rollback       | Steps to move to a newer version and to return safely to the previous one.              | Not available yet |
| Logs and metrics           | Operational signals sufficient to tell whether the system is healthy and why it is not. | Not published     |
| Licence                    | Settled terms stating what you may run, modify, and redistribute.                       | Not established   |
| End-to-end deployment test | A test that installs the product from scratch and proves a real workflow completes.     | Not available yet |

A draft configuration or a container that starts one dependency does not prove that the product can be self-hosted. Some low-level bootstrap mechanics are implemented and tested; [Self-host mechanics](https://nitsor.com/docs/reference/self-host) describes exactly what they do and do not start.

## Legal status \[#legal-status]

The public terms, privacy, and cookie pages are drafts awaiting counsel review. They are not binding policies, a data-processing agreement, or procurement evidence.

## Common mistakes and limits \[#common-mistakes-and-limits]

- Security headers do not protect a private file that was accidentally published.
- Open-source intent is not a settled licence.
- A local build is not a supported self-hosted deployment.
- A simulated security review is not a penetration test or compliance audit.
- A target identity model is not proof of tenant isolation.

## Next step \[#next-step]

Turn your deployment and security requirements into pass/fail evidence requests, then include them in the charter described in [Design-partner onboarding](https://nitsor.com/docs/guides/design-partner-onboarding).