> ## 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. # Design-partner onboarding > Prepare a small, privacy-aware evaluation of Nitsor using one real volumetric-data workflow. **Status: Limited design-partner access.** Nitsor is pre-release. An evaluation is shaped with a small number of teams and supervised by both sides. This does not mean general availability, guaranteed acceptance, or production support. ## Decide whether the fit is plausible The strongest starting point is a recurring volumetric-data workflow with a real release or quality decision that is hard to reconstruct today. Industrial CT and non-destructive testing are the initial commercial focus. MRI is an important scenario for testing whether the design works in another field. **Limited design-partner access.** Score your own situation against the five questions below before asking for a conversation. A candidate who cannot answer most of them usually does not yet have a decision small enough to evaluate. | Fit question | Why it matters | Can you answer it? | | --------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------ | | Where do source volumes and labels live? | Source volumes are meant to stay in your storage. Where a model runs would decide where image data travels — see [Data boundary](/concepts/data-boundary). | | | Who or what creates proposed labels? | Human and machine authorship are represented differently in the intended model. | | | Who reviews and resolves disagreement? | Without a named resolver, review outcomes cannot become a decision. | | | What makes a dataset acceptable for its next use? | This is the release decision the evaluation is built around. | | | Which evidence is missing or expensive to assemble later? | This is the gap an evaluation can actually measure. | | ## Prepare the first conversation Bring a privacy-safe description rather than source data. **Limited design-partner access.** Fill in the eight rows below before the first conversation. Every item can be written without disclosing data, credentials, or storage locations. | Item | Prepare | What to write down | Your notes | | ---- | ---------------------------------- | -------------------------------------------------------------------------------------------- | ---------- | | 1 | Modality and recurring task | The imaging type and the job your team repeats, in one sentence. | | | 2 | Formats and approximate scale | Representative file formats and a rough sense of volume, without exact figures if sensitive. | | | 3 | Current tools and handoffs | The systems the work passes through and where it changes hands. | | | 4 | Roles and external contributors | Who takes part, including vendors or contractors outside your organization. | | | 5 | Review, consensus, and escalation | How many reviews are required, what counts as agreement, and who breaks a tie. | | | 6 | Release or downstream decision | The decision this workflow feeds, and what a wrong one costs. | | | 7 | Security, legal, procurement gates | The approvals that must clear before any real data or system access is discussed. | | | 8 | Smallest worthwhile evidence | The one result that would change your mind about continuing. | | The public contact form is for descriptions of this kind and nothing more. | Safe to send | Never send | | -------------------------------------------------------------------- | ---------------------------------------------------------- | | Questions about the product, its status, and its intended workflow | Credentials, access tokens, or sign-in details | | The shape of your workflow: modality, roles, handoffs, and decisions | Patient, customer, or proprietary scan data | | Your role, intended outcome, and the pages you have already read | Storage locations, object-store paths, or system addresses | | The evidence or test that would settle your open question | Confidential strategy or contract material | ## Keep the evaluation small The first useful scope should test one complete decision, not every planned capability. For example: can the planned version model represent one batch, preserve the evidence showing where changes came from, handle one contested review, and describe a release candidate without depending on unavailable integrations? Agree which conclusions can come from documentation or made-up test data and which require a working product, real data, domain experts, or customer infrastructure. The split below is the one worth agreeing in writing before the evaluation starts. | What documentation and made-up test data can settle | What needs a working product and real data | | ---------------------------------------------------------------------------------- | ----------------------------------------------------------------------------- | | Whether the intended model can describe your workflow at all | Whether the product handles your real data volumes and formats | | Whether the vocabulary matches how your team already talks about the work | Whether your reviewers find the real interface usable | | Whether proposed, reviewed, and approved states map onto your decisions | Whether a real contested review reaches a defensible decision | | Whether the intended data boundary fits your storage and security responsibilities | Whether integration with your storage and identity systems actually works | | Which evidence you would need and cannot produce today | Whether that evidence can be reconstructed from a real release, months later | | Whether the plan is worth a pilot at all | Cost, reliability, performance, and suitability for regulated or customer use | ## Get permission before proceeding Before any data access or external coordination, identify who can approve each category below. Name a person, not a team. | Permission category | What it covers | Who must approve it | | ----------------------------------------- | ------------------------------------------------------------------------------ | ------------------- | | Disclosure of workflow details | Describing your process, tools, and roles to people outside your organization. | | | Use of made-up or de-identified test data | Creating or sharing stand-in data that resembles your real work. | | | Access to systems or storage | Any read or write against your own systems during an evaluation. | | | Identity and credential configuration | Creating accounts, issuing credentials, or connecting a sign-in system. | | | Legal and privacy terms | Agreements covering confidentiality, data handling, and processing. | | | Security review | Deciding whether the security evidence is sufficient to proceed. | | | Pilot success criteria | Setting what the evaluation must show, and who judges the result. | | The public contact route does not grant any of those permissions. Sending a message, or receiving a reply, changes nothing about who may authorize the rows above. ## What happens next Automated tests show that the public contact form validates a message and prepares it safely for email delivery. They do not promise delivery, response time, pilot acceptance, production support, or a live Nitsor workspace. If both sides choose to continue, the next step should be a written evaluation plan with owners, data boundaries, acceptance tests, and explicit non-goals. ## Common mistakes and limits * Starting with a broad platform migration instead of one decision. * Sending sensitive data before legal and security authority is clear. * Treating a roadmap discussion as a delivery commitment. * Using success with made-up test data as proof of production value. * Depending on an API, SDK, CLI, or self-host package that is not shipped. ## Next step Review [Product status](/product-status), prepare the eight-item conversation outline above, and use the [contact form](https://nitsor.com/contact) without including sensitive material.
OutcomeArrive at a first conversation with a focused problem, clear evidence needs, and the right permissions.
AvailabilityLimited design-partner access
AudienceTechnical program managers, Operations and technical teams, Researchers and leaders
PrerequisitesA recurring industrial CT, medical CT, or MRI workflow; Authority to discuss the workflow without sending sensitive data; An owner for technical and operational evaluation
Last verified2026-08-23