# Programmatic access context > Product status, public API, command-line interface, and data-model contracts. > Estimated tokens: 13875 > 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. # 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. --- # 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). --- # Public HTTP API > Evaluate the implemented HTTP contract, its error vocabulary, and the authentication boundary that still limits production use. - Outcome: Identify the 16 implemented routes without mistaking an implemented contract for a production-ready public service. - Availability: Limited design-partner access - Audience: Software engineers, Data engineers, AI agents - Prerequisites: Read Product status; Work within an agreed design-partner environment - Last verified: 2026-08-18 - Source: https://nitsor.com/docs/reference/api **Status: Limited design-partner access.** The route contract and handlers below are implemented and tested. Public transport authentication is not production-ready. > **Authentication limitation:** current sessions accept an account identifier as the bearer credential, and some requests carry caller-declared principal data. Use this interface only inside an agreed design-partner environment. Do not treat it as an Internet-facing production authentication design. No request example is presented as runnable. A public copy-and-paste request example remains forbidden until an end-to-end test executes the same request against a supported public environment. ## Route inventory \[#route-inventory] The statuses below are the possibilities implemented by each current handler. Representative HTTP tests cover the shared success and failure mappings, but not every listed status is independently asserted for every route. No OpenAPI document is published. | Route | Purpose | Handler-implemented statuses | Current evidence | | --------------------------------------------- | -------------------------------------------------------------------------- | ---------------------------- | ------------------------------------------------------------ | | `GET /api/v1/decisions` | List recorded authorization decisions. | `200`, `400`, `404` | Registered handler and response contract | | `GET /api/v1/ledger` | List event-attribution records connected to decisions. | `200`, `400`, `404` | Registered handler and response contract | | `GET /api/v1/sources` | List a page of registered sources. | `200`, `400` | Registered handler, client coverage, and response contract | | `POST /api/v1/sources` | Register a source from object references. | `201`, `400`, `403`, `422` | Registered handler and request/response contracts | | `POST /api/v1/projects` | Create a project with an attributable principal and repeat-request key. | `201`, `400`, `403`, `404` | Registered handler and request/response contracts | | `GET /api/v1/projects` | List projects for the current account. | `200`, `400`, `404` | Registered handler, client coverage, and response contract | | `GET /api/v1/session` | Resolve the account associated with the current credential. | `200`, `401` | Registered handler, client coverage, and response contract | | `POST /api/v1/storage-connections` | Register an object-storage connection without accepting raw secret values. | `201`, `400`, `403` | Registered handler and request/response contracts | | `POST /api/v1/version-graph/branches` | Create an isolated branch from a known position. | `201`, `400`, `403` | Registered handler and request/response contracts | | `GET /api/v1/version-graph/branches` | List version-graph branches. | `200`, `400` | Registered handler and response contract | | `POST /api/v1/version-graph/commits` | Create a checkpoint-derived commit. | `201`, `400`, `403` | Registered handler and request/response contracts | | `POST /api/v1/version-graph/landmarks/delete` | Append a landmark-deletion event. | `200`, `400`, `403`, `409` | Registered handler and request/response contracts | | `POST /api/v1/version-graph/landmarks` | Append a landmark-upsert event. | `200`, `400`, `403`, `409` | Registered handler and request/response contracts | | `POST /api/v1/version-graph/merges` | Attempt a typed three-way merge. | `200`, `400`, `403` | Registered handler; no client currently exercises this route | | `GET /api/v1/version-graph/position` | Read a bounded page of the current landmark position. | `200`, `400` | Registered handler and response contract | | `POST /api/v1/version-graph/project-metadata` | Append a project-metadata update event. | `200`, `400`, `403`, `409` | Registered handler and request/response contracts | The source routes provide cursor-based listing and reference-based registration. They recognize several format depths, but they do not upload source bytes, make every format viewable, or prove a supported public service. ## Decisions, Ledger, and denials \[#decisions-ledger-and-denials] Authorization records both allowed and denied decisions. A denied request can return a `decisionId`, which connects the response to the corresponding Decision and Ledger evidence. That evidence does not repair the transport-authentication limitation above. A session identifies the account accepted by the current credential. It is not a published browser-session, refresh-token, or service-account contract. ## Issue-code vocabulary \[#issue-code-vocabulary] Clients can treat these 36 codes as the bounded issue vocabulary. A response may also carry a field path, remediation, missing permission scope, or decision identifier. | Code | Meaning | | ------------------------------------ | --------------------------------------------------------------------------- | | `ACCOUNT_NOT_FOUND` | The account accepted by the request could not be found. | | `API_ERROR` | A request reached the API but failed without a narrower public code. | | `API_UNREACHABLE` | The client could not reach the configured API origin. | | `AUTHORIZATION_DENIED` | The authenticated principal lacks the required authority. | | `AUTH_INVALID_TOKEN` | The current credential was rejected. | | `AUTH_REQUIRED` | The operation requires a stored credential. | | `CORRUPT_DICOM` | A referenced object could not be read as valid DICOM. | | `CORRUPT_VGI` | A referenced VGI descriptor could not be parsed. | | `DUPLICATE_SOP_INSTANCE_UID` | More than one object claimed the same DICOM instance identity. | | `GEOMETRY_INCONSISTENT` | Slice geometry did not describe one consistent volume. | | `GEOMETRY_OUT_OF_RANGE` | Valid geometry exceeds the range the viewer can display. | | `IDEMPOTENCY_CONFLICT` | A repeat-request key conflicts with an earlier request. | | `INVALID_ARGUMENT` | An input failed the command or request contract. | | `INVALID_JSON` | JSON input or output could not be parsed as required. | | `MISSING_SLICE` | The series evidence indicates a missing slice. | | `MIXED_FORMAT_FAMILIES` | One registration contains objects from more than one format family. | | `NO_VALID_DICOM_SLICES` | No referenced object produced a valid DICOM slice. | | `PROJECT_CREATE_FAILED` | Project creation failed without a narrower public code. | | `SERIES_IDENTITY_MISMATCH` | Referenced objects did not belong to one series identity. | | `SLICE_ORDER_INCONSISTENT` | Slice ordering could not be established consistently. | | `SOURCE_LIST_FAILED` | Listing registered sources failed. | | `SOURCE_REGISTER_FAILED` | Source registration failed without a narrower public code. | | `SOURCE_VERSION_AMBIGUOUS` | The referenced source version could not be resolved unambiguously. | | `STORAGE_CONNECTION_REGISTER_FAILED` | Storage-connection registration failed. | | `STORAGE_OBJECT_CHANGED_DURING_READ` | A referenced object changed while its registration evidence was being read. | | `STORAGE_OBJECT_NOT_FOUND` | A referenced storage object was absent. | | `STORAGE_OBJECT_TOO_LARGE` | A referenced object exceeded the accepted size boundary. | | `STORAGE_READ_FAILED` | Reading a referenced object failed. | | `UNEXPECTED_ERROR` | An unexpected failure crossed the public error boundary. | | `UNKNOWN_COMMAND` | The command-line parser did not recognize the command. | | `UNSUPPORTED_PIXEL_FORMAT` | The DICOM pixel format cannot be rendered. | | `UNSUPPORTED_TRANSFER_SYNTAX` | The DICOM transfer syntax is not supported. | | `UNSUPPORTED_VGI_SCENE` | The VGI scene cannot be rendered by the current viewer path. | | `UNRECOGNIZED_FORMAT` | No known source-format signature was found. | | `VERSION_GRAPH_OPERATION_FAILED` | A version-graph operation failed without a narrower public code. | | `VGI_VOL_MISMATCH` | The VGI descriptor and referenced VOL data do not agree. | ## Programmatic access today \[#programmatic-access-today] The HTTP contract and command-line client are the implemented programmatic surfaces. No public TypeScript or Python SDK, MCP server, webhook, or generated OpenAPI client is published. Their future shape remains open. ## Common mistakes and limits \[#common-mistakes-and-limits] - Registered routes do not make transport authentication production-ready. - A Zod contract (Zod is a TypeScript schema-validation library) is not an OpenAPI document. - A Decision record explains an authorization result; it does not authenticate the caller. - Route registration does not prove every route has client-level coverage. Merge is the explicit uncovered case today. ## Next step \[#next-step] Review the [Command-line interface](https://nitsor.com/docs/reference/cli) for the tested client surface or [Data model and contracts](https://nitsor.com/docs/reference/data-model) for the records these routes expose. --- # Command-line interface > See the five implemented commands, their tested guarantees, and the distribution boundary that prevents public installation instructions. - Outcome: Choose an implemented command and understand which installation and workflow commands do not exist yet. - Availability: Limited design-partner access - Audience: Software engineers, Data engineers, Platform engineers, AI agents - Prerequisites: Read the Public HTTP API authentication limitation; Work within an agreed design-partner environment - Last verified: 2026-08-23 - Source: https://nitsor.com/docs/reference/cli **Status: Limited design-partner access.** Five command families exist and have automated coverage. There is no published release pipeline, so this page does not offer a public installation command. The CLI uses the same request and response contracts described in [Public HTTP API](https://nitsor.com/docs/reference/api). Its current credential inherits that page's authentication limitation. ## Command inventory \[#command-inventory] | Command | What it does | Tested boundary | | ---------------------- | ------------------------------------------------------------------------------------ | ----------------------------------------------------------------------- | | `nitsor login` | Validates a credential against the session route and stores the accepted connection. | Invalid credentials fail; a rejected credential is not echoed to output | | `nitsor projects list` | Lists projects as a table or machine-readable JSON. | Authentication failure, table output, JSON output, and contract parsing | | `nitsor sources list` | Lists registered sources as a table or machine-readable JSON. | Authentication failure, table output, JSON output, and contract parsing | | `nitsor up` | Generates and starts the current self-host dependency stack after preflight checks. | Preflight, digest pins, private secrets, health waits, and repeat runs | | `nitsor version` | Prints the CLI version. | Literal command output | The source list identifies registered sources with status and viewability; JSON includes format, and the table includes file counts. This list does not make every recognized format viewable or production-supported. Login stores credentials in an owner-only file with mode `0600` on supported systems. Command failures use structured issue codes and non-zero exits. Machine-readable output goes to standard output; errors go to standard error. Tests verify that a rejected credential is not echoed to output. Because the current credential is an account identifier rather than a secret, successful command output can include that identifier. ## Distribution and installation \[#distribution-and-installation] **Installation is not a runnable instruction.** The installer logic verifies checksums in tests, but no release pipeline publishes the package and image targets it would download. A copy-and-paste install example would therefore describe an unavailable path and remains forbidden. An authorized design-partner evaluation must receive its build and setup instructions directly, together with the exact version and provenance being evaluated. ## Tested command sequence \[#tested-command-sequence] The following sequence is runnable only with a build, credential, and API origin supplied for an agreed design-partner environment. Process-level tests execute these exact command forms through the packaged CLI and the HTTP router. ```bash nitsor login --token --base-url --json nitsor projects list --json ``` Use a supplied credential in place of ``. The current credential design is an account identifier rather than production-grade authentication. Never paste a credential into logs, tickets, chat, or shared shell history. Separate process tests also execute `nitsor login --token `, `nitsor projects list`, and `nitsor sources list --json`. The `up` and `version` families remain inventory entries above, not runnable examples: their exact public invocations do not have the same process-level evidence, and no public distribution exists. ## Commands that are absent \[#commands-that-are-absent] There is no public command for project creation, storage registration, DICOM registration, branch or commit management, review, consensus, adjudication, release creation, export, upgrade, rollback, or general help. Their absence is deliberate documentation, not an implied alias. ## Common mistakes and limits \[#common-mistakes-and-limits] - JSON output makes automation easier; it does not make the authentication model production-ready. - `nitsor up` starts the dependency stack described in [Self-host mechanics](https://nitsor.com/docs/reference/self-host), not a complete Nitsor product. - A tested installer script is not a published distribution. - Shared contracts reduce drift, but they do not replace testing against a supported public environment. ## Next step \[#next-step] Read [Self-host mechanics](https://nitsor.com/docs/reference/self-host) before evaluating `nitsor up`, or return to [Integrations and public interfaces](https://nitsor.com/docs/reference/integrations) for the wider boundary. --- # Data model and contracts > Understand the replay-proven event, authorization, version, workflow, and prelabel contracts without assuming an operator product exists. - Outcome: Distinguish implemented backend contracts from planned operator surfaces and dataset-release behavior. - Availability: Limited design-partner access - Audience: ML engineers, Data engineers, Data scientists, Technical leaders, AI agents - Prerequisites: Read Version model; Read Roles and provenance - Last verified: 2026-08-23 - Source: https://nitsor.com/docs/reference/data-model **Status: Limited design-partner access.** The backend contracts in the first table are implemented and replay-tested. They do not yet form a supported operator product. ## Contract map \[#contract-map] | Contract | Implemented behavior | Boundary | | ----------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------ | | Event log | Events are the sole write path for governed project, version, workflow, role, and prelabel state. Derived records can be rebuilt by replay. | No complete operator surface is published. | | Decision and Ledger | Authorization writes allow and deny Decisions; attributable events link back through Ledger records. | Transport authentication remains a separate limitation. | | Checkpoints and commits | Commits derive from checkpointed event history and carry both a commit identity and a content root. The two identities are intentionally distinct. | Content identity currently covers landmark-scoped content; asset, instruction, and taxonomy roots are not yet populated. | | Branches | A branch points at history without copying the underlying source volume. | A branch name grants no permission. | | Typed merge | Three-way merge reports typed conflicts for existence, class, position, review state, note, or asset identity and can route unresolved conflicts to adjudication. | Merge has no public client coverage today. | | Router and workflow | One routing primitive handles assignment, review, consensus reading, gold checks, and adjudication eligibility. | The backend contract is not a published workflow editor. | | Task and Job | A Task is routed work for a person or runner. A Job is a bounded machine-compute request with model and provenance fields. | These are contracts, not a queue-monitoring product. | | Prelabel refusal | Risk-controlling calibration can end in a typed refusal before model invocation when the acceptable threshold set is empty. | The current inference path is a deterministic stub, not real model inference. | ## Event-sourced state \[#event-sourced-state] An event is an attributable fact about what was requested and accepted. Reducers fold those facts into current state. Replay tests compare rebuilt state with live derived records so a write that bypasses the log or a reducer that drifts becomes visible. Authorization happens before the governed event is appended. Both an allowed operation and a denial remain explainable: the Decision records the policy result, while the Ledger connects an accepted event to the acting principal and decision. ## Version and content identity \[#version-and-content-identity] A checkpoint turns a bounded event range into a stable position. A commit names that checkpointed history. Its `commitId` identifies the commit object; its `contentRoot` identifies the covered content. They are not interchangeable. Today those guarantees apply to **landmark-scoped content**. Roots reserved for assets, instructions, and taxonomy are not yet populated, so this page does not claim complete volumetric dataset identity. Branches are zero-copy references to history. Merge compares a base, the current branch, and the proposed branch. Non-overlapping changes can merge automatically; typed conflicts remain explicit and can require an authorized adjudication decision. ## Routing, review, and machine work \[#routing-review-and-machine-work] The Router evaluates eligibility and ordering rules for annotation, review, consensus, gold checks, and adjudication. Review outcomes and the decision that follows remain separate records. A machine Job carries its model family, inputs, execution mode, and provenance. The implemented prelabel contract can refuse work before inference when calibration cannot satisfy the declared risk bound. Successful output currently comes from a labeled deterministic stub; real model inference is planned. ## Planned target contracts \[#planned-target-contracts] The following concepts are **planned — not available yet**: | Target contract | Intended meaning | Missing evidence | | ----------------------- | --------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------- | | Taxonomy | Reusable labels plus geometry fields such as masks, 2D or 3D boxes, landmarks, classification, and regression fields. | No operator implementation or complete version root | | Dataset Release | One approved dataset state with a signed manifest and reconstruction evidence. | No release model, public manifest, or release command | | Real prelabel inference | A runner executes the recorded model contract and preserves measured provenance. | Current inference is a deterministic stub | ## Common mistakes and limits \[#common-mistakes-and-limits] - Replay-proven backend behavior does not imply a shipped screen or end-to-end operator journey. - A content root that covers landmarks does not yet identify every dataset asset and instruction. - A Task is not a machine Job. - A refusal is a valid terminal result, not a silent failure or automatic fallback. - An export is not automatically a Dataset Release. ## Next step \[#next-step] Read [Public HTTP API](https://nitsor.com/docs/reference/api) for the current transport surface or [Dataset release](https://nitsor.com/docs/guides/dataset-release) for the planned evidence lifecycle.