Design-partner onboarding

Limited design-partner access 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.
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
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, prepare the eight-item conversation outline above, and use the contact form without including sensitive material.

Outcome	Arrive at a first conversation with a focused problem, clear evidence needs, and the right permissions.
Availability	Limited design-partner access
Audience	Technical program managers, Operations and technical teams, Researchers and leaders
Prerequisites	A 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 verified	2026-08-23

Get started

Concepts

Guides

Reference

Decide whether the fit is plausible

Prepare the first conversation

Keep the evaluation small

Get permission before proceeding

What happens next

Common mistakes and limits

Next step

​Decide whether the fit is plausible

​Prepare the first conversation

​Keep the evaluation small

​Get permission before proceeding

​What happens next

​Common mistakes and limits

​Next step

Decide whether the fit is plausible

Prepare the first conversation

Keep the evaluation small

Get permission before proceeding

What happens next

Common mistakes and limits

Next step