Frequently asked questions
From getting started to sovereign classified deployments. Grouped by what buyers actually ask — with links to the evidence behind every answer.
Getting started
Is there a demo or trial?
Yes — a Guided Demo, by invitation during beta. It gives you a fully functional, pre-seeded instance with a complete realistic programme already modelled at L0–L5. You can interact with every feature: navigate the digital thread, run trade studies, generate reports, explore all 16 BOM views. The demo data resets daily per user so every session starts from a clean, consistent baseline. No credit card, no provisioning, no setup. Request demo access →
How quickly can I get from sign-up to first structured output?
Hours, not months. Upload your existing documents — requirements specs, SOW, ConOps, standards — and Clarity’s AI extraction pipeline builds an initial L0–L5 model from them. Most programmes have a draft L0 (stakeholder intent), L1 (architecture), and scope-matrix-driven report within a working day. No systems integrator, no SysML specialists, no infrastructure to provision.
What counts as a “product” in Clarity?
A product is a single system or subsystem under analysis. Each product gets its own L0–L12 analysis model, document library, and scope-matrix-driven reporting. Products live inside portfolios, which group related systems. A complex programme with multiple subsystems (e.g. platform, propulsion, avionics, C2) would have one portfolio and multiple products — each with its own traceable digital thread.
Do I need a systems integrator to deploy Clarity?
No. The SMB & Teams plan is hosted and requires no infrastructure. The Regulated plan (your cloud) uses a deployment script — no SI, no infrastructure project. The Sovereign plan includes implementation support for classified and air-gapped deployments where a hands-on engagement is appropriate. Compare plans →
How does pricing work?
Three tiers. SMB & Teams is per user per year (from US$500 · £300 · AU$750), hosted. Regulated is volume-priced for your cloud deployment with unlimited products and users above the minimum. Sovereign is an engagement — air-gapped, classified, and multi-classification environments require a conversation. Full pricing →
Integration & the 16 BOM views
How does Clarity compare to DOORS, Cameo, or Teamcenter?
DOORS covers requirements (one lifecycle layer). Cameo models architecture in SysML (one notation, no BOM). Teamcenter delivers 3 native BOM views — siloed, as-designed only, in separate data stores reconciled by spreadsheets. Clarity spans 13 lifecycle verticals with 16 BOM views on a single CI graph, three acquisition modes, and AI-native generation — at 10× less than the alternatives. From US$500 · £300 · AU$750 /user/year. No systems integrator, hours to first value. See the full competitor comparison →
Why does 16 BOM views matter? I thought one BOM was enough.
One BOM is as-designed. But engineering programmes span design, manufacturing, testing, deployment, operations, maintenance, and decommissioning — each with different stakeholders, different data, and different legal obligations. The eBOM your PLM manages is not the rBOM your MRO needs, the xBOM your ITAR office requires, or the deBOM your end-of-life disposal plan depends on. Every one of Clarity’s 16 views exists because programmes that lacked it had real failures — not because a product manager added it to a roadmap.
Can Clarity sit alongside my existing tools without replacing them?
Yes — this is Prong 1: Clarity as the Orchestrator. Your PLM keeps managing your eBOM. Your ERP keeps managing procurement. Your MRO keeps managing maintenance. Clarity sits above all of them, consuming their data via structured adapters, and delivers 16 BOM views, change management across 13 verticals, and a full decision evidence chain — from data those tools already hold but cannot connect. No rip-and-replace. The strangler pattern takes effect at your pace. How Clarity orchestrates your stack →
What is the xBOM (Export-Controlled BOM) and who needs it?
The xBOM is a first-class BOM view that applies ITAR, EAR, and NOFOR classification filters to the product structure — producing a BOM that is structurally identical to the eBOM but with controlled items redacted or flagged for export licensing. Any programme supplying to US, UK, or Australian defence with controlled components needs this. No other platform models it as a native view — everyone else maintains it as a separate spreadsheet. Discuss ITAR/EAR requirements →
Can Clarity connect change entities across GitHub, Jira, Teamcenter, and SAP into a single impact map?
Yes — this is Change Entity Orchestration. Clarity maps PRs, ECRs, ECNs, Issues, ERP change orders, and CVE scanner findings from GitHub, Teamcenter, Jira, SAP, and vulnerability scanners to their true CI-graph dependencies. A firmware PR that cascades to a hardware ECR to an ERP substitute approval — the full impact is visible before the change is approved, not three months after it has been built into out-of-configuration hardware. No other platform crosses tool boundaries and maps change entities to the CI graph that defines what they actually affect.
Can Clarity ingest MCAD, ECAD, and software PDM outputs directly?
Yes. Clarity ingests MCAD assembly exports (from SolidWorks, CATIA, Creo, NX), ECAD netlist and parts list exports, and software SBOMs and build manifests — treating them as L6 As-Designed configuration items in the Clarity CI graph. CAD tools keep managing CAD files; Clarity manages what they produce. Versions, variants, alternates, and substitutes become explicit graph relationships with qualification evidence attached — not parallel shadow trees or flat approved-parts lists. This eliminates the fundamental limitation of every PLM system: the single hierarchical MCAD assembly tree that cannot accommodate the real structure of engineering reality. Bulk items (fasteners, wire, O-rings) link directly to ERP via the pBOM — no phantom assemblies, no manual reconciliation. Software spans from compiled binary (L6) through deployed instance (L9) and in-service version (L10) in the same CI graph as hardware.
What is the pBOM and why does it matter?
The pBOM (Procurement BOM) is Clarity’s 16th BOM view — the only platform to model it natively. It represents contracted line items, approved vendor selections, and order state, connecting directly from the CI graph to your ERP procurement records. The pBOM resolves the shadow item problem: in PLM systems, bulk items (fasteners, wire, O-rings, consumables) that don’t fit the assembly tree structure become “phantom assemblies” — ghost nodes that exist only to satisfy the tree hierarchy. In Clarity, bulk items link directly to ERP via the pBOM as first-class CIs, eliminating the manual reconciliation that one engineer currently owns in a spreadsheet nobody else understands. No other platform models this relationship.
Our programme didn’t start at L0. Can we still use Clarity?
This is specifically what Clarity is designed for. Most programmes don’t start at L0 — they enter the digital thread wherever circumstances dictate: an inherited political decision at L5, a mandated COTS component that arrived before requirements were written, a field failure that demands a design change without a clean evidence chain. Legacy MBSE tools assume you already have L0 and progress sequentially. AUKUS is the canonical example: the September 2021 partnership announcement was an L5 political decision that selected an L2 option (nuclear submarines) before the L3 analysis, L4 baselines, or L0 ConOps were complete. Clarity imposes full structural discipline wherever your programme begins — building the evidence chain forward from the entry point and backwards through inherited constraints simultaneously. Lx Chain and non-linear entry →
Decisions & auditability
What is the Decision Truth Vector?
Every formal decision in Clarity carries a computed trustworthiness score at the moment it was made — derived from the structural evidence in the live programme model, not from a user-asserted status field. Three dimensions: formal traceability (explicit, reviewed links), structurally validated AI-inferred connections, and gap severity (what is missing and how much it matters). The result is a score that reflects how well-evidenced the decision was at the time it was taken. L4 baselines freeze the evidence state so the score can be recomputed for any past decision. Full explanation →
How does Clarity help with certification audits?
Certification evidence is generated from the live digital thread — not assembled from Word documents the night before submission. When an auditor asks “show me the evidence trail from requirement 3.2.1 to the decision that approved Option Alpha,” the answer in Clarity is a link — navigate it yourself. For any standard (ISO 13485, MIL-STD-973, STANAG, NQA-1), Clarity generates a structured evidence pack from the same live data the programme team works with. No curated subset, no retrospective assembly.
Can I reconstruct how a decision was made three years ago?
Yes — this is what L4 baselines are for. Baselines freeze the evidence state at a point in time. The Decision Truth Vector can be recomputed as it was at any past baseline — not just what was decided, but how defensible it was at the time, on what evidence, by whom, and what changed afterward. No other tool offers this. DOORS and Jama record link presence and absence; they cannot reconstruct past decision states or compute past trustworthiness scores.
How is this different from a traceability matrix in DOORS?
A DOORS traceability matrix records whether a link exists or does not — binary. It cannot compute trustworthiness, detect inferred evidence routes, score gap severity, or reconstruct a past decision state. It is link-counting. The Clarity Truth Vector is trust computation. Concretely: when a certification auditor asks “was this decision defensible when it was made?” — DOORS answers with a document assembled by the person who needs to pass the audit. Clarity answers with a structural proof.
Why is change management a child of L5 Decisions rather than a separate tool?
Because that is what change management structurally is. In Clarity, change management, baselines, release management, and configuration management are not separate tools bolted onto a PLM — they are structural children of L5 Decisions. Every change is traceable to the decision that authorised it. Every baseline exists because a decision froze it. Every configuration is what it is because of a set of formal, evidence-backed decisions. This means there is no reconciliation gap between “what was decided” and “what changed” — the decision IS the change authority, with the full evidence chain attached. No other platform models this relationship structurally; they connect change management to the BOM layer (at best) and leave the decision authority in a meeting-room document outside the tool.
Security & data sovereignty
Who holds the encryption keys?
You do. Every organisation’s data is encrypted at rest and in transit with keys in a KMS instance controlled entirely by that organisation — not Clarity, not the cloud provider’s default. Revoking your key immediately and permanently ends all data access. No support escalation, no recovery request, no vendor involvement required. This is structural sovereignty: not a contractual promise that Clarity won’t access your data, but a key architecture that makes access technically impossible.
Can Clarity employees access our programme data?
No. Because your organisation holds the encryption keys, no Clarity employee can access your programme data by technical means — for support, debugging, compliance, or any other reason. This is a key architecture property, not a policy statement. In practice, if you have an issue that would normally require vendor access to diagnose, Clarity’s support process works from logs and telemetry that contain no programme data.
What happens to our data if we stop using Clarity?
Your data is yours. All programme data is stored as open JSON with a fully documented schema — readable with any text editor, processable with any JSON library, with no Clarity licence required. Export everything at any time. Archive to S3 Glacier or any object store for long-term retention. There is no proprietary format, no data hostage, and no vendor lock-in at the data layer. For regulated programmes with 30–50 year lifetimes, this matters: no licence is required to read your 2040 programme data in 2065.
Is each organisation’s data logically isolated?
Yes, fully. Multi-tenant architecture means multiple organisations share serverless compute infrastructure — but share nothing else. No database row, no cache entry, no log line crosses a tenant boundary. Each organisation’s data has its own encryption key and its own logical data boundary. This is what allows multi-nation programmes to run on shared infrastructure without national data ever co-mingling.
Where is data hosted? What about data residency requirements?
The hosted SaaS plan uses Clarity’s AWS infrastructure. The Regulated plan deploys in your own cloud account in any AWS region — giving you full control over data residency. For sovereign or classified data residency requirements (GovCloud, UK Secret, AU Gov), the Sovereign plan deploys entirely within your boundary. Discuss your data residency requirements →
AI & model choice
Related: How Clarity’s AI works →
What AI models does Clarity use?
Clarity uses leading foundation models for hundreds of structured generation calls across every lifecycle layer. The specific model is a deployment configuration — the platform is model-agnostic by design. In the hosted SaaS plan, Clarity uses best-available commercial foundation models. In your own cloud or air-gapped environments, you choose the model. The platform produces schema-valid structured output regardless of which model runs, because the intelligence is in the platform — not the model.
Can we bring our own AI model?
Yes — this is a first-class capability. Deploy any foundation model, including cleared open-weight models, within your own deployment boundary. BYOM is particularly critical for classified environments where commercial AI services are not cleared. The model is interchangeable because Clarity’s intelligence lives in the structured knowledge model, the decision framework, and the schema validation layer — not in the LLM output stream. Swapping the model does not change the quality or structure of the output.
How does Clarity prevent AI hallucination?
Unlike bolt-on chatbots that generate unconstrained prose from documents, Clarity’s AI generates structured entities within the engineering model — bounded by the decision intelligence framework, the world model, and schema validation at every output. Every AI-generated entity is flagged as AI-generated, carries provenance, and can be reviewed, corrected, or rejected by a human before it enters the formal evidence chain. The AI accelerates construction of the model; the framework constrains what the AI can output.
Does Clarity learn from one organisation’s data to benefit another?
Clarity can learn efficiency patterns and structural insights across the fleet of programmes it serves — without any organisation’s programme data being exposed to another. Patterns that emerge from aggregate behaviour become available to all users; the data behind those patterns is never shared, never aggregated across tenant boundaries, and never used to train a model accessible outside your boundary. This is a patent-pending capability and a fundamental design property, not a setting.
Can Clarity operate where commercial cloud AI services are not available?
Yes. In classified environments — US C2S, UK Secret, Australian Protected — commercial AI API services are not cleared. Every competitor whose AI features depend on a hosted commercial API becomes non-functional in those environments. Clarity is unaffected: the BYOM architecture allows any cleared open-weight model to be deployed inside the classification boundary, and the platform operates with full AI capability at every classification level. Discuss classified AI deployment →
Compliance & standards
Which standards does Clarity support out of the box?
Thirty-nine built-in assessment overlays map to standards across defence (MIL-STD-973, MIL-STD-882, STANAG, TTCP), systems engineering (ISO 15288, ISO 10007), medical devices (ISO 13485), nuclear (NQA-1), cyber (NIST CSF, ISO 27001), supply chain (ISO 28000), automotive (ISO 26262), and rail (EN 50126). Domain packs extend coverage. Standards compliance is structural — embedded in the model as overlay dimensions, not maintained as separate documentation.
What is “active compliance mapping” and how is it different from a compliance document?
A compliance document is static — it reflects the programme state at the time it was written and drifts from reality immediately. Active compliance mapping embeds each standard as a structural dimension of the live engineering model. The compliance status of any requirement, architecture element, design decision, or analysis result is computed from the live model, not maintained in a separate document. When something changes in the programme, compliance status updates automatically. Certification evidence is always current because it is generated from data that is always current.
Can I switch from one standard to another without rebuilding my model?
Yes. Standards are overlay dimensions on the same underlying model — not separate data structures. Switching standards, stacking standards, or applying multiple standards simultaneously is a configuration change, not a rebuild. A programme that starts under ISO 15288 and later needs to demonstrate MIL-STD-973 compliance does not rebuild from scratch — it adds the overlay and generates the evidence from the model that already exists.
How many types of compliance reports can Clarity generate?
The scope matrix — 13 lifecycle layers × 39 overlay dimensions — produces a combinatorially unbounded number of report scopes. Any combination of layers and overlays can be selected to generate a report scoped exactly to the audit question being answered. At beta (L0–L5 active), the practical scope space is over 1020 possible configurations. The number of reports Clarity can generate is not a catalogue — it is every possible combination of layers and overlays your programme needs.
Deployment & sovereign environments
What deployment models are available?
Five models, from guided demo to fully air-gapped classified: Guided Demo (hosted, pre-seeded examples, invite-only, resets daily), Hosted SaaS (multi-tenant on Clarity’s AWS infrastructure), Your AWS (full data sovereignty, your cloud account), ATO Partner (government and classified, through an authorised partner), and Air-Gapped (multi-classification networks, fully disconnected). Compare deployment models →
Can Clarity run in a fully air-gapped environment?
Yes. Clarity is built entirely on serverless cloud services with no external dependencies at runtime — no outbound calls required for normal operation. In air-gapped deployments, all services run within the disconnected boundary. AI generation uses a locally deployed cleared model (BYOM). Cross-classification data exchange uses diode and airlock patterns that enforce policy-controlled transfer between networks. Specific classified deployment configurations are discussed under engagement. Start that conversation →
Questions about classified, multi-classification, or AUKUS deployments
Specific deployment configurations for classified environments — including GovCloud, AWS Secret, AWS Top Secret, multi-classification networks, cross-nation data exchange, and programme-specific ATO requirements — are discussed under engagement. These conversations involve deployment architecture, cleared model selection, and programme-specific security controls that are not appropriate for public documentation.
Contact us to discussCan different organisations in a joint programme share data across national boundaries?
Yes — this is a core capability for AUKUS and 14 Eyes programmes. Each participating nation operates its own Clarity instance, within its own data boundary, using its own encryption keys. Structured digital thread subsets are exchanged between instances through policy-governed airlocks: entity-level subsetting, classification-aware redaction, and full audit trail on both sides of every exchange. No shared database. No national data co-mingling. The detail of any specific programme exchange configuration is discussed under engagement. Discuss your programme →
Whole-life & closed-loop engineering
What lifecycle phases does Clarity cover?
The full L0–L12 digital thread spans stakeholder intent (L0), architecture (L1), options and trade studies (L2), analysis and scenarios (L3), baselines and change management (L4), formal decisions (L5), as-designed structure (L6), manufacturing and build (L7), test and V&V (L8), deployment and operations (L9), updates and patches (L10), maintenance and MRO (L11), and lifecycle closure and decommissioning (L12). The beta delivers L0–L5 (the full design plane). L6–L12 are architecturally defined, schema-complete, and visible in the UI — implementation follows.
How does a field failure connect back to the design model?
When an MRO event fires at L11 — a failure mode, a repair pattern, a field anomaly — Clarity traces it back through the operational and maintenance record to the design decision that produced the failing component. The originating L1 architecture element and L2 option surface as active risk, flagged for review. The requirement at L0 that specified that component is linked directly. No report, no email, no meeting required — the design team sees it when it happens. This is the closed loop that no other platform closes.
Does Clarity replace my PLM and MRO system, or work alongside them?
Both, depending on your situation. For large enterprises with sunk PLM investment, Clarity acts as the Orchestrator — consuming data from your PLM, ERP, and MRO via structured adapters and providing the connected view none of those tools can give you. For SMBs and Tier 2–4 suppliers who cannot afford legacy PLM, Clarity is the replacement — at 10× less. Over time, as the digital thread accumulates context that only Clarity holds, legacy tools naturally shrink from essential systems of record to data sources. The strangler pattern takes effect at your pace.
What happens to BOM data at end of life / decommissioning?
The deBOM (Decommissioning BOM) is a first-class view in Clarity — the only platform that models it natively. It tracks hazardous materials, disposal obligations, reuse candidates, and regulatory requirements at end of life. For programmes with nuclear, chemical, or HPAC components, this view is not optional. Combined with the open JSON format, programme data and decommissioning evidence remain readable and auditable indefinitely — with no licence and no vendor involvement required decades after the programme closes.
Still have a question?
For questions about specific programme requirements, classified deployments, AUKUS engagements, or anything not covered above — reach out directly.
hello@compliancewithclarity.comOne thread. 13 verticals. 16 BOMs. 25 USPs.
The only complete digital thread for regulated programmes, powered by the patent pending DeZolve Decision Intelligence Framework. Sovereign deployment under your own AWS account and encryption keys — at 10× less than the enterprise alternatives.