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

# Plan an integration

> Turn a proposed dependency on Nitsor into an acceptance test, using the evidence gate that applies to every interface listed as planned.

<a className="nit-availability" data-availability="target-contract" href="/product-status#status-definitions" aria-label="Planned — not available yet. Read the status definitions."><span aria-hidden="true" className="nit-availability__dot" />Planned — not available yet</a>

**Status: Planned — not available yet.** This page remains a target contract because a complete supported integration is not available. The HTTP API, command-line interface, and replay-tested backend contracts have limited design-partner implementations; their reference pages state the authentication, distribution, and product-readiness boundaries. No public SDK, Model Context Protocol (MCP) server, webhook, agent-action surface, or supported self-hosted product is available.

This guide is written to be useful whether or not you ever adopt Nitsor. Its job is to turn "we might depend on this" into a written test that a working implementation either passes or fails.

## Begin with boundaries, not commands

Document the current path from source object to training or evaluation dataset. Include storage location, format, geometry conventions, label representation, taxonomy, transformations, model output, review decisions, and release destination.

Then identify which steps need a reference that cannot change, a named content version, an assigned task, or a human decision. These distinctions are more useful during evaluation than guessing what future API endpoints might look like.

The table below is a worksheet for describing the pipeline you already run. It does not describe Nitsor behavior and carries no availability claim: each row names one of the nine stages above so you can record what happens there and who controls it before any tool is involved.

| Stage                | What happens there                                                                                      | Who controls it in your current pipeline                        |
| -------------------- | ------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------- |
| Storage location     | Source objects are held somewhere durable and are read from that location.                              | The team that owns the storage system and its access rules.     |
| Format               | Bytes are written and read in a specific file or container format.                                      | Whoever chose the acquisition or export format, often a vendor. |
| Geometry conventions | Coordinates, voxel spacing, and orientation are fixed so a position means the same thing to every tool. | Usually the acquisition system; often nobody reviews it later.  |
| Label representation | An interpretation is stored as a mask, contour, box, key point, or structured value.                    | The annotation tool in use, which may not be the storage owner. |
| Taxonomy             | Label names are given a controlled set and an agreed meaning.                                           | The domain owner who defines what each label means.             |
| Transformations      | Resampling, cropping, normalization, or format conversion changes the data before use.                  | The engineer who wrote the processing step, often undocumented. |
| Model output         | A model produces a proposal, a score, or a derived measurement.                                         | The ML owner, together with whoever chose the model version.    |
| Review decisions     | A person accepts, corrects, returns, or escalates a proposal.                                           | The reviewer, under whatever instruction is written down.       |
| Release destination  | An approved set of data and labels leaves for training, evaluation, or an external consumer.            | The team that consumes the dataset and its approver, if named.  |

A stage with no named controller is the most useful finding here. It marks the point where provenance is already lost in your current process, independent of any tool you adopt later.

## Match the stages to the intended model

The target model separates source references from versioned dataset state. Branches hold proposals. Commits describe accepted content changes on a branch. Reviews and decisions remain attributable. A release identifies one approved dataset state.

See [Version model](/concepts/version-model) for that vocabulary, [Data boundary](/concepts/data-boundary) for the intended storage split, and [Model-assisted prelabeling](/concepts/model-assisted-prelabeling) for what a model proposal is allowed to claim.

## What is still unproved

Every row is an area an integration would depend on. Last checked: 2026-07-30. Owners are named by function because no individual owner is published.

| Area                                       | Status                        | Current evidence or unresolved boundary                                                                                                                                                                                                                         | Evidence owner by function                   |
| ------------------------------------------ | ----------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------- |
| Public documentation exports               | Available                     | 22 HTML pages, per-page Markdown, search, `llms.txt` and `llms-full.txt` are published at `docs.nitsor.com`, verified 24 August 2026. Agent discovery documents are published but name a non-canonical address; deployed cache and header evidence are Pending. | Public documentation and agent-export owner  |
| Public HTTP API and command-line interface | Limited design-partner access | Sixteen HTTP routes and five CLI command families are implemented with scoped agent-credential authentication; public distribution is not production-ready.                                                                                                     | Product integrations owner                   |
| SDK, MCP, webhook, and agent actions       | Not available                 | No public package, server, webhook, action surface, executable schema, credential setup, or compatibility policy exists.                                                                                                                                        | Product integrations owner                   |
| Identity and permissions                   | Open                          | Distinct human and machine identity, project-scoped permission, credential lifecycle, and protected-decision enforcement are not proved.                                                                                                                        | Identity and authorization owner             |
| Data-boundary proof                        | Open                          | Exact persisted and temporary data classes, network paths, retention, deletion, backup, and encryption behavior are not proved.                                                                                                                                 | Data platform and export-specification owner |
| Data format and spatial accuracy           | Open                          | No versioned input or output format, rule for preserving coordinates, spacing, and orientation, tolerance, round-trip test, or representative-volume result is published.                                                                                       | Data platform and export-specification owner |
| Failure, retry, and conflict behavior      | Open                          | Repeated requests, retries, partial failures, concurrent edits, conflict detection, and conflict resolution have no released contract or runnable test.                                                                                                         | Product integrations and versioning owner    |
| Deployment and self-hosting                | Open                          | No supported package, production architecture, installation path, region matrix, upgrade policy, or end-to-end deployment proof exists.                                                                                                                         | Platform operations and support owner        |
| Recovery, observability, and support       | Open                          | Product logs, metrics, alerts, backup and restore, recovery objectives, incident handling, and support commitments are unresolved.                                                                                                                              | Platform operations and support owner        |
| Export and reconstruction                  | Open                          | No released export schema, stable release record, re-import path, or independent reconstruction result exists.                                                                                                                                                  | Versioning and release-workflow owner        |

“Available” in this table applies only to the public documentation system. Limited design-partner access means the implementation can be evaluated only within agreed pre-release scope and is not a public production service. Not available means no usable public implementation exists. Planned — not available yet means the described product interface cannot be used today. Open means the implementation or decision is unresolved. Pending means an implementation exists but the named evidence has not been collected.

## Evidence required before integration

This is the canonical pre-integration acceptance gate for these docs. [Integrations and public interfaces](/reference/integrations) links here rather than keeping its own list. Ask for runnable proof of each item for every interface you plan to depend on:

| Evidence item                                    | Why it matters                                                                        | How to test it                                                                 |
| ------------------------------------------------ | ------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------ |
| A versioned released package or service          | Without a named version, nothing you test today describes what you run tomorrow.      | Obtain the same version twice and confirm it is identical.                     |
| Accepted formats and geometry preservation       | Volumetric data is unusable if coordinates, spacing, or orientation change silently.  | Round-trip a representative volume and compare spatial metadata exactly.       |
| Source registration and read permissions         | Integration depends on what the system may read and how that access is scoped.        | Register a source with the narrowest credential and observe what it can reach. |
| Identity and authorization boundaries            | Who can call what determines your security review, not the endpoint list.             | Attempt a denied request and confirm it is refused and recorded.               |
| Repeat and retry behavior, rate and error limits | Real clients retry; a duplicate that creates two records corrupts the history.        | Send the same request twice and compare the resulting records.                 |
| Event ordering and conflict behavior             | Concurrent writers are the normal case for annotation work.                           | Produce a deliberate conflict and check it is detected, not silently resolved. |
| Schema and compatibility policy                  | Breaking changes without a policy turn every upgrade into an incident.                | Ask for the written policy and the last change that exercised it.              |
| Examples tested against the release              | An example proven against a mock proves the mock.                                     | Run the published example against the released package or service.             |
| Export completeness and migration                | Data you cannot take out is data you have lost control of.                            | Export a project and rebuild your dataset from the export alone.               |
| Performance limits and failure recovery          | Volumetric workloads find limits quickly; recovery behavior decides the blast radius. | Ask for stated limits and a demonstrated recovery from a failure.              |
| Logs, metrics, and support boundaries            | Operating a dependency requires seeing into it and knowing who owns which failure.    | Review the operational signals and the written support boundary.               |
| Deployment and upgrade procedure                 | An integration you cannot upgrade safely will pin you to a vulnerable version.        | Walk one upgrade and one rollback, or obtain the documented, tested procedure. |

Documentation, type definitions, and mock examples are useful evidence, but they do not replace a test against a released package or service.

## Examples in these docs

The [Public HTTP API](/reference/api), [command-line interface](/reference/cli), and [Data model and contracts](/reference/data-model) pages include only current, bounded evidence. API request examples remain absent because no supported public environment executes them. CLI examples are limited to exact command forms exercised by process-level tests; they do not provide installation or production-credential instructions.

SDK, MCP, webhook, agent-action, and complete self-host examples remain absent because no usable public implementation exists. Planned workflow descriptions remain labelled **planned — not available yet**.

## Common mistakes and limits

* Do not infer a stable schema from a marketing sentence.
* Do not treat a generated Markdown export as an application API.
* Do not assume source data stays in place until a deployed data path and network trace prove it.
* Do not assume self-hosting from an open-source intention; require a versioned package, installation steps, upgrade steps, and an end-to-end test.
* A tested contact form is not evidence for product integrations.

## Next step

Read [Integrations and public interfaces](/reference/integrations) for the current list of surfaces and their boundaries, then turn your proposed dependency into a short acceptance test that can be run when a working implementation becomes available.

<table className="nit-page-details" aria-label="Page details">
  <tbody>
    <tr><th scope="row">Outcome</th><td>Produce an evidence checklist for a future technical integration instead of assuming an API exists.</td></tr>
    <tr><th scope="row">Availability</th><td>Planned — not available yet</td></tr>
    <tr><th scope="row">Audience</th><td>ML engineers, Data engineers, Software engineers, Data scientists</td></tr>
    <tr><th scope="row">Prerequisites</th><td>Know where source volumes and labels live today; Know which systems create, review, and consume them</td></tr>
    <tr><th scope="row">Last verified</th><td>2026-08-23</td></tr>
  </tbody>
</table>