Plan an integration

Planned — not available yet 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 for that vocabulary, Data boundary for the intended storage split, and 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 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, command-line interface, and Data model and contracts 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 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.

Outcome	Produce an evidence checklist for a future technical integration instead of assuming an API exists.
Availability	Planned — not available yet
Audience	ML engineers, Data engineers, Software engineers, Data scientists
Prerequisites	Know where source volumes and labels live today; Know which systems create, review, and consume them
Last verified	2026-08-23

Get started

Concepts

Guides

Reference

Begin with boundaries, not commands

Match the stages to the intended model

What is still unproved

Evidence required before integration

Examples in these docs

Common mistakes and limits

Next step

​Begin with boundaries, not commands

​Match the stages to the intended model

​What is still unproved

​Evidence required before integration

​Examples in these docs

​Common mistakes and limits

​Next step

Begin with boundaries, not commands

Match the stages to the intended model

What is still unproved

Evidence required before integration

Examples in these docs

Common mistakes and limits

Next step