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.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.
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
- Public marketing, planned-pricing, FAQ, contact, and draft legal pages.
- Public documentation at
docs.nitsor.com. - 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
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, command-line interface, and replay-tested data model and contracts are available only inside an agreed design-partner environment. Their reference pages state the 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
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.
nitsor up mechanics 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
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.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.
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.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.Synthetic review
What the synthetic review measured
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.
This is documentation-clarity evidence only, not customer, product, domain, legal, security, or production validation.
Next step
Return to the Introduction or contact the team with the workflow you want to evaluate and the evidence you would need before adopting it.| 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 |