# Design-partner onboarding context > Fit, prerequisites, onboarding questions, and the security evidence a partner asks for. > Estimated tokens: 12102 > 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. # Quickstart > Take one useful first action today, using only the parts of Nitsor that a visitor can actually reach. - Outcome: Leave with one focused, truthful action and the evidence you still need to ask for. - Availability: Available now - Audience: All readers, Evaluators, AI agents - Prerequisites: Read the Introduction - Last verified: 2026-08-23 - Source: https://nitsor.com/docs/quickstart Most quickstarts end with something running. This one cannot, because Nitsor is pre-release and there is no public sign-up, package, or sample workspace. What you can do in the next hour is decide whether the intended product fits a real decision your team already makes, and write down the evidence that would settle it. ## What you can reach today \[#what-you-can-reach-today] - These documentation pages, plus a clean Markdown copy of each one at the same address with `.md` added. - `/llms.txt`, `/llms-full.txt`, and four curated context bundles for AI tools. - Documentation search. - A [contact form](https://nitsor.com/contact) for product and design-partner questions. Nothing here requires an account, and nothing here grants product access. ## Pick your first action \[#pick-your-first-action] Find the row closest to your situation. Each row gives one page to read first and one action small enough to finish this week. | If you… | Read this first | First action | | -------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Annotate or review | [Annotate and review](https://nitsor.com/docs/guides/annotate-and-review) | Bring one instruction, one representative task, and the current rule for returning or escalating work. | | Run the program | [Release a dataset](https://nitsor.com/docs/guides/dataset-release) | Map one release decision from source selection through approval and note the evidence you cannot reconstruct today. | | Build integrations | [Plan an integration](https://nitsor.com/docs/guides/plan-an-integration), then [Integrations](https://nitsor.com/docs/reference/integrations) | Read the [public HTTP API](https://nitsor.com/docs/reference/api) and [command-line interface](https://nitsor.com/docs/reference/cli) contracts, then write the acceptance test a future package or service must pass. | | Model data or contracts | [Data model and contracts](https://nitsor.com/docs/reference/data-model) | Compare one of your own release records against the recorded contracts and mark what has no equivalent. | | Make the adoption decision | [Product status](https://nitsor.com/docs/product-status) | Define the smallest design-partner evaluation that could change your decision, separating conclusions that need a working product. | | Read this programmatically | `/llms.txt`, then the context bundles listed in [Integrations](https://nitsor.com/docs/reference/integrations) | Load the smallest bundle that covers your question and cite the page source recorded inside it. | Deployment and security requirements have their own evidence checklists in [Deployment and security](https://nitsor.com/docs/reference/deployment-and-security) and [Self-host mechanics](https://nitsor.com/docs/reference/self-host). ## If you get stuck \[#if-you-get-stuck] | Situation | What to do | | --------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------- | | You cannot tell whether a capability exists | Open [Product status](https://nitsor.com/docs/product-status) and read the capability status matrix rather than the prose. | | Search did not return the page you expected | Try a concrete noun from the [Glossary](https://nitsor.com/docs/reference/glossary), or use the sidebar. | | A documentation link is broken | Recover through the sidebar, record the page and the link, and do not substitute a private path. | | The contact form rejects your message | Use the exact [contact form validation](https://nitsor.com/docs/reference/integrations#contact-form-validation) constraints. | | An agent answered without a source or changed a label | Treat the answer as unsupported and require the source URL and the quoted availability label. | | You need legal, privacy, security, or compliance approval | Pause and involve the authorized owner; the public legal pages are drafts awaiting counsel review. | ## What to include in a useful question \[#what-to-include-in-a-useful-question] - your role and intended outcome; - the relevant workflow or decision; - the page you already read; - the availability or evidence point that remains unclear; - the smallest piece of working evidence or test that would answer it. The same limits apply here as in [Design-partner onboarding](https://nitsor.com/docs/guides/design-partner-onboarding). Do not send credentials, patient or customer scan data, storage locations, or confidential material through a public contact form. ## Common mistakes and limits \[#common-mistakes-and-limits] - A contact message is not an authorization to access systems or data. - A design-partner conversation is not a delivery commitment. - A complete documentation path is not proof that the product path exists. - Retrying does not turn an unavailable capability into an available one. - A context bundle is not a substitute for reading the cited source when making a high-stakes decision. ## Next step \[#next-step] Read [Product status](https://nitsor.com/docs/product-status), then record the exact evidence you would need before adopting the workflow you care about. If a focused design-partner evaluation is appropriate, continue to [Design-partner onboarding](https://nitsor.com/docs/guides/design-partner-onboarding). --- # 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. --- # Design-partner onboarding > Prepare a small, privacy-aware evaluation of Nitsor using one real volumetric-data workflow. - 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 - Source: https://nitsor.com/docs/guides/design-partner-onboarding **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 \[#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](https://nitsor.com/docs/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 \[#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 \[#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 \[#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 \[#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 \[#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 \[#next-step] Review [Product status](https://nitsor.com/docs/product-status), prepare the eight-item conversation outline above, and use the [contact form](https://nitsor.com/contact) without including sensitive material. --- # Deployment and security > Separate the public site's verified controls from planned product deployment, security, identity, compliance, and self-hosting capabilities. - Outcome: Build an evidence checklist without assuming a production deployment option exists. - Availability: Planned — not available yet - Audience: Software and security teams, CTOs, Heads of AI and Software, Operational decision-makers - Prerequisites: Read Product status; Identify your hosting, identity, and compliance requirements - Last verified: 2026-08-23 - Source: https://nitsor.com/docs/reference/deployment-and-security **Status: Planned — not available yet.** This page is a target contract: a precise description of the deployment and security evidence a future Nitsor product should provide. It also lists a few controls verified for the public site. ## Verified for the public site \[#verified-for-the-public-site] The public site configures browser security headers that limit which resources a page may load, how referral information is shared, whether browsers may guess file types, and whether another site may place Nitsor in a frame. A response header is a short instruction the website sends alongside each page to tell the browser how to treat it. **Available now.** The website sends each of the four headers below on public pages, and an automated test checks that they are present and correctly set. | Header | What it controls | How it is verified | | ------------------------- | --------------------------------------------------------------------------------------------------------- | ----------------------------------------------------- | | `Content-Security-Policy` | Which sources a browser is allowed to load content from, so injected third-party content is refused. | Automated test of the header sent by the public site. | | `Referrer-Policy` | How much information about the page you came from is passed on when you follow a link away from the site. | Automated test of the header sent by the public site. | | `X-Content-Type-Options` | Prevents the browser from guessing a file's type instead of trusting the type the site declared. | Automated test of the header sent by the public site. | | `X-Frame-Options` | Prevents another website from embedding Nitsor pages inside a frame on its own page. | Automated test of the header sent by the public site. | Automated documentation tests also check that public content comes from the public-site folder and scan for known private markers. These controls apply to the public site. They are not evidence for a future dashboard, product-data storage or processing, storage integration, identity system, or self-hosted deployment. ## Product deployment status \[#product-deployment-status] **Planned — not available yet.** Nothing in this table describes a service you can buy or run today. Each row records a commitment a production offering would have to publish, and the honest status of that commitment right now. | Deployment commitment | What a buyer would need to see | Current status | | --------------------- | ---------------------------------------------------------------------------------------------- | -------------- | | Hosting architecture | Where the service runs, how tenants are separated, and which components hold customer records. | Not published | | Regional availability | The regions a customer may choose and where records stay. | Not published | | Service levels | Availability, support response, and escalation commitments. | Not published | | Backup contract | Backup frequency, retention, restore procedure, and tested recovery times. | Not published | | Upgrade policy | Release cadence, notice periods, compatibility rules, and rollback. | Not published | | General availability | The date the product becomes generally purchasable and supported. | Not published | Nitsor is not operated as a hosted service you can sign up for today, and no self-hosting package, image, installer, deployment file, or upgrade path is published. An intention to be deployable or open does not satisfy an operational acceptance test. ## Identity and permissions \[#identity-and-permissions] The intended product requires separate human and machine identities, limited permissions, attributable actions, and protected decisions. No public sign-in setup, organization model, session behavior, or permission table is available today. A provider name in draft legal text would not make that provider a permanent architecture commitment. ## Security and compliance questions \[#security-and-compliance-questions] **Planned — not available yet.** Use this table as the list of asks for a future security review. The questions are ready to send; the answers are not published, so treat every current status below as an open item rather than a reassurance. | Area | Question to ask | Acceptable evidence | Current status | | --------------------------------- | ---------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------- | -------------- | | System and data-flow boundaries | Which components hold or move customer data, and where does each boundary sit? | A current architecture and data-flow description reviewed against the running system. | Not published | | Tenancy and authorization | How is one customer's data kept unreachable by another customer or an unauthorized user? | Isolation design plus tests that demonstrate a denied cross-tenant request. | Not published | | Credential and key handling | Where are secrets stored, who can read them, and how are they rotated? | A secret-management description and evidence of a completed rotation. | Not published | | Encryption | What is encrypted while travelling over a network and while stored? | Configuration evidence for both cases, with the key owner named. | Not published | | Integrity of history records | Can decision and version history be altered after the fact, and who could do it? | An append-only or tamper-evidence design plus an access list. | Not published | | Vulnerability and dependency care | How are known vulnerabilities in the product and its dependencies found and fixed? | A scanning and patching process with recent, dated results. | Not published | | Incident response | What happens when a security incident occurs, and when are customers told? | A written response plan with notification timelines and a rehearsal record. | Not published | | Backup, retention, and deletion | How is data backed up, how long is it kept, and how is deletion confirmed? | Retention and deletion policies plus a tested restore. | Not published | | Deployment and upgrade paths | How does a change reach production, and who approves it? | A change-control description and evidence that upgrades and rollbacks were run. | Not published | | Regulatory and customer controls | Which external regulations or customer-specific controls apply, and who signs off? | A mapping of applicable controls to product behavior, reviewed by your own counsel. | Not published | No certification, regulated-use approval, medical-device status, or compliance attestation is claimed. ## Self-hosting acceptance gate \[#self-hosting-acceptance-gate] **Planned — not available yet.** Self-hosting means running Nitsor on infrastructure your own team controls. Before calling any future option self-hostable, require all ten criteria below to pass. None of them passes today, so the honest reading of this table is that a self-host offering does not exist yet — not that it is nearly ready. | Criterion | What a pass requires | Current status | | -------------------------- | --------------------------------------------------------------------------------------- | ----------------- | | Versioned package | A named, numbered release you can obtain again later and pin to. | Not available yet | | Integrity verification | A way to confirm the package you received is exactly the one that was published. | Not available yet | | Dependency list | A complete list of every other component the product needs to run. | Not published | | Identity | A documented way to connect your own sign-in system and manage accounts over time. | Not available yet | | Secrets handling | Documented storage, access, and rotation of passwords, keys, and tokens. | Not published | | Storage and backup | Defined storage requirements plus backup and restore procedures you can test. | Not published | | Upgrade and rollback | Steps to move to a newer version and to return safely to the previous one. | Not available yet | | Logs and metrics | Operational signals sufficient to tell whether the system is healthy and why it is not. | Not published | | Licence | Settled terms stating what you may run, modify, and redistribute. | Not established | | End-to-end deployment test | A test that installs the product from scratch and proves a real workflow completes. | Not available yet | A draft configuration or a container that starts one dependency does not prove that the product can be self-hosted. Some low-level bootstrap mechanics are implemented and tested; [Self-host mechanics](https://nitsor.com/docs/reference/self-host) describes exactly what they do and do not start. ## Legal status \[#legal-status] The public terms, privacy, and cookie pages are drafts awaiting counsel review. They are not binding policies, a data-processing agreement, or procurement evidence. ## Common mistakes and limits \[#common-mistakes-and-limits] - Security headers do not protect a private file that was accidentally published. - Open-source intent is not a settled licence. - A local build is not a supported self-hosted deployment. - A simulated security review is not a penetration test or compliance audit. - A target identity model is not proof of tenant isolation. ## Next step \[#next-step] Turn your deployment and security requirements into pass/fail evidence requests, then include them in the charter described in [Design-partner onboarding](https://nitsor.com/docs/guides/design-partner-onboarding).