The Problem: Why Your Systems of Record Can’t Connect
PLM holds the product structure. ERP holds procurement and cost. MES holds manufacturing process records. cMRO holds maintenance and repair history. EAM holds asset lifecycle data.
Each is excellent at what it was built for.
Your systems of record
A system of understanding
Digital Threads
One connected model — from first requirement to final disposal, holding the reasoning your systems of record never could.
No combination of these systems holds the reasoning that produced their records: what decision was made, what options were evaluated, what constraints applied, who approved it, and why. That reasoning lives in email threads, meeting minutes, and the institutional memory of engineers who have since rotated off the programme.
“Your tools manage artefacts. Nobody manages the reasoning between them.”
Clarity is the structured layer above them all. Not replacing them — sitting above them. The decision record that connects their outputs and holds the reasoning between them.
That is not a gap that existing vendors will fill. It is a structural absence that requires a purpose-built layer above the existing stack.
Why now: defence programmes are becoming unnecessarily complex, supply chains are becoming more distributed, certification requirements continue to grow, and experienced engineers are retiring — while the systems managing engineering information remain fragmented across documents, databases and enterprise applications. The challenge is no longer collecting more data. It is preserving the engineering understanding behind it.
The Flawed Business Objects Your Tools Were Built Around
Each system of record is built around a business object that was never designed to carry a decision, its evidence, or the reasoning that connects it to the rest of the programme. It is the same structural gap in every tool:
“In 2006 and again in 2024, we tried mapping thousands of database tables across PLM and ERP systems. Same structural gap both times — there was no consistent way to connect information from one to the other. When a contract manufacturer changed, we had to ingest hundreds of thousands of documents from the old PLM to the new one. Engineering looked at what that would take and decided it was probably easier to just redo the CAD and start from scratch.”
The problem isn't reconciliation skill. It's that the tools were never designed to be reconciled.
| System of record | Its business object | The structural flaw | Clarity resolves it with |
|---|---|---|---|
| PLM (Product Lifecycle Management) | Hierarchical parts structure | Parts that belong to multiple assemblies have to be duplicated; every bill of materials is a separate tree that needs manual reconciliation | One connected graph where parts are nodes, and every bill of materials is a query — all views derive from the same data |
| Documents & requirements | The document file | The meaning and context live inside the documents; the decision that created them is not recorded anywhere | Documents become living views of the model; decisions are captured as tracked objects with their reasoning attached |
| ERP, MES, MRO, EAM (Finance, Manufacturing, Maintenance, Asset Management) | Cost records, work orders, maintenance records | The same physical thing is represented differently across multiple systems, reconciled by hand spreadsheets | Each becomes a data source feeding one unified model — one source of truth for every physical asset |
| All of them | The baseline as a frozen set of documents | The as-built system silently diverges from the as-designed system with no way to track what changed or why | The baseline is a snapshot of the connected model; drift is visible and traced to the specific change that caused it |
| None of them | No decision record | The reasoning behind every choice lives only in emails, meeting notes, and people’s heads — and it disappears when they leave | Every decision is captured with the options evaluated, evidence considered, who approved it, and why — immutable and traceable decades later |
The Solution: One Unified Schema
These systems cannot talk to each other because their data models are fundamentally incompatible. Clarity solves this with one unified schema — built from the ground up to capture what the legacy systems cannot: engineering decisions, their evidence, and their traceability across the full lifecycle.
Clarity Diodes ingest your PLM, ERP, MES, MRO, EAM, MBSE tools, ALM systems, document stores, and data warehouses — mapping them into this schema. One-way by design: your legacy systems remain the system of record; Clarity reads them and connects the reasoning they were never built to keep.
Clarity is not another of these systems. It holds the layer above all of them — the decision record and one connected model — and connects to them without replacing them. Over time they narrow from systems of record to data sources, decommissioned at your pace, never the vendor’s.
“Knowledge management stores information. Clarity structures reasoning.”
The objective is not finding documents. It is understanding how a decision was reached and whether it remains defensible.
What Clarity Does
1. Structures your existing programme documents into a connected product model.
Upload your Concept of Operations, your requirements pack, your design briefs, your supplier BOMs. Clarity reads them and extracts the structured entities — requirements, constraints, options, decisions, configuration items — with traceable links back to the source document. You do not migrate data. You do not restructure your files. Your documents stay where they are; the structured understanding layer is built on top.
2. Records every design decision with its evidence chain.
Every formal decision in a Clarity programme — a design authority approval, a baseline commitment, a trade study conclusion — carries a complete record: what options were evaluated, what evidence existed at the time, what the approval authority decided, and why. That record is not a document. It is a structured entry in the programme model, linked bidirectionally to the requirements it resolves and the baselines it freezes.
When the question arrives in 2040, the answer is a lookup — not a reconstruction.
3. Validates supplier configuration claims before they reach your baseline.
When a supplier delivers a BOM update, an interface control document, or a design modification, Clarity validates it against your design baseline before it is promoted to your source of truth. Contested claims surface to the responsible engineer. Configuration drift is visible before it becomes a certification problem.
4. Connects to your existing tools without replacing them.
Clarity sits above your PLM, ERP, and requirements management tools via policy-governed connectors. Your Teamcenter continues running. Your SAP continues running. Clarity reads their outputs, structures them into the understanding layer, and builds the decision record above them.
Together, this is where Clarity sits — above your systems of record, not instead of them:
The layer above — a system of understanding
Clarity
One connected model, from first requirement to final disposal — and it gets smarter the longer you use it.
Your systems of record — unchanged, more focused
Across the full lifecycle, that one connected model spans requirements, engineering decisions, product configurations, bills of material, supply chain changes, compliance evidence, manufacturing, sustainment, operational knowledge, digital twin, standards overlays, and risk & safety cases — every change remains connected, every decision remains explainable, every programme remains accountable.
Two Planes, One Connected Thread
A programme has two halves, and the thread has to cross both.
The decision plane · live today
What to build, and why
Intent, requirements, architecture and the design decisions that shape them — the reasoning at the front of the programme.
The implementation plane · active · connector-gated
How it was built and sustained
As-built, manufactured, sustained and disposed — the known configuration of the product across its whole service life.
Most tools stop at the boundary between them — the thread snaps where design hands off to build. Clarity holds both as one connected model, so a decision made at the front of the programme stays linked to the reality it produced decades later.
What Clarity Enables — The Overlay Groups
Clarity’s overlay groups — each a dimension of programme complexity — work together in one connected model:
Technical / Engineering
Design & Engineering
Design, manufacturing, operations and sustainment work from one connected model — each discipline's view stays consistent as the product evolves.
Configuration Management
Configuration Tracking
Configuration management and the audit trail are one always-current record — not a reconciliation spreadsheet you maintain each quarter.
Financial Management
Cost & Budget
Cost, budget, and financial performance tracked to every decision and component — cost breakdowns derived from the model, never maintained on the side.
Supply Chain
Supplier & Procurement
Procurement strategy, supplier risk, and supply availability visible across the full lifecycle — bring primes, suppliers and partner nations onto one shared understanding.
Resource Management
Schedule & Resources
Schedule, staffing, and resource constraints mapped to the model — see capacity and dependencies before you commit.
Quality Assurance
Test & Validation
Test coverage, validation status, and quality records linked to requirements and configuration — evidence of compliance built continuously, not reconstructed after delivery.
Risk & Compliance
Risk & Regulatory
Risk exposure, mitigation status, and regulatory compliance computed from the data — the audit trail and the evidence chain are one.
Security
Classification & Security
Classification, export control, and access controls embedded at the entity level — sovereign by architecture, not by policy statement.
Legal, Contractual & External Integration
Contracts & Boundaries
Contract obligations, cross-boundary terms, and integration points with external parties — capture the why behind each constraint and maintain it across the programme.
Each overlay lets every role — engineering, finance, supply chain, quality, sustainment — read the same underlying programme from its own perspective.
What Makes Clarity Structurally Different
Four things set Clarity apart from anything built on a legacy database — and each depends on the connected model above.
Bounded AI — engineering intelligence that cannot guess
Clarity builds a model-based representation of your programme, grounded in a world model and a lessons-learnt knowledge graph built from three decades of real programme delivery. That grounding is what makes the AI bounded: every output is constrained by how complex products actually behave, so it cannot invent a requirement, a part, or a decision the engineering would reject. Domain packs seed each sector’s standards, ontology and compliance from the first day.
“An AI that can hallucinate has no place in a certification decision. Clarity’s cannot.”
Bounded by a 30-year world model — not an open-ended chatbot on your documents.
Decision trust scoring — every decision carries a confidence score
Every decision is assigned a Decision Truth Vector (DTV) — a trustworthiness score computed from the evidence chain at the moment the decision is made, not reconstructed from memory after it fails. DeZolve is the decision intelligence framework at the core of every Clarity deployment.
A decision, with its evidence chain
DeZolve Decision Truth Vector (DTV)
Formal links, verified
AI-inferred links, scored separately
Gaps, surfaced not hidden
A trust score, computed at the moment of commit
Cached immutably — recomputable against today’s evidence to detect decision drift
The score is tied to the baseline that was frozen at the moment the decision was made — not just whether a link exists, but whether the decision was actually defensible against the evidence available at the time. Once computed, a DTV score is cached alongside the decision and stays readable with the same tooling and classification rules decades later — the 2040 answer is a lookup, not a reconstruction. If the underlying evidence changes afterward, Clarity can recompute the score against today’s state and surface the difference as a decision-drift signal, flagging exactly which past decisions are worth re-examining.
Multi-classification, cross-boundary exchange — the Diode and the Airlock
Sovereign programmes are multi-tenant, multi-classification and multi-nation by nature — a prime, its suppliers, and partner governments across the Five- and 14-Eyes community, each holding their own boundary. Clarity governs exchange across those boundaries structurally, not by policy alone — one-way by design, or two-way by joint approval. Across instances, only what a part is ever crosses; where and how it is used never does:
The Diode — one-way
Tenant A
US Licensor
ITAR
Tenant B
AU Prime
SECRET
Write-back structurally impossible by IAM — not application logic
The Airlock — joint-approved, two-way
Tenant A
AU Supplier
OFFICIAL
Tenant B
UK Prime
SECRET
Fails closed — suspension by either party takes effect immediately
At beta: cross-boundary data enters through the Clarity ingest bucket via policy-checked manual transfer — the model above is the architecture it hardens into. The productionised Diode and Airlock connectors, and full cross-classification federation, follow a pilot deployment.
Defence and engineering standards — DEF STAN, MIL-STD-31000, EIA-649 configuration management, MIL-STD-882 system safety, MIL-HDBK-516 airworthiness, S1000D, AS9100 and ISO 15288 among them — are handled the same way: as computed overlays on the one connected model, built to map, not maintained as a separate binder. (The IT-security landscape — NIST, IRAP, ISO 27001 — is covered by the 14-Eyes posture above.)
Sovereign by architecture — your keys, your cloud, your jurisdiction
Clarity is deployed in your AWS account, encrypted with keys you control, in the AWS region you specify. Clarity has zero access to your programme data. Air-gap capable for classified programmes. Your data — every entity, every decision, every configuration record — stays in your environment, in open structured format, remaining accessible and auditable across the full platform life, without Clarity or any vendor.
Built for Programmes Measured in Decades
Complex engineering systems routinely outlive the people who designed them. Forty years after a platform enters service, organisations must still be able to answer questions such as:
Why was this design approved?
Which evidence supported that decision?
Which configuration entered service?
What changed, when, and who authorised it?
Which downstream systems and suppliers were affected?
Was the decision defensible against the evidence available at the time?
Clarity preserves those answers as permanent programme knowledge.
Trace one asset from as-designed to as-operated
Every state below usually lives in a different system of record, owned by a different team. Clarity is the system of understanding above them, orchestrating one connected record from end to end.
The schema that makes this possible
One back-propagated CI object
A configuration item is a single node, not a copy in every system. As-built, as-tested and as-operated observations back-propagate onto it — the object carries its own history, and never overwrites the approved design.
The FK-diode
Structural references only ever point one way — a lower layer never reaches back up into a higher one — so the whole thread stays acyclic and auditable, from first intent to final disposal. Schema and writer version travel on each object, not on a shared database, so the model can evolve without a big-bang migration — old and new records coexist, each readable on its own terms.
Schema on read
Data is captured once as immutable JSON; the shape each consumer needs — a graph, an overlay, a report — is composed when it is read, not forced in at write. New lenses need no migration.
Cascade-derived views
Change one thing and the effect cascades through the model automatically — every dependent view regenerates, event by event. Nothing is left stale, nothing reconciled by hand.
Materialised views
Each layer is pre-aggregated into a single read model, so a query reads one object instead of thousands of scattered files — reads stay fast as the model grows.
Massive-scale query patterns
Query paths designed for fleet scale — tens to hundreds of millions of items — so a question can span the whole enterprise without re-traversing the raw graph each time.
The full data-schema walkthrough — cascade generation, provenance propagation and scaling patterns — is part of a technical briefing, under NDA.
One connected record, start to finish — because there was never a break to reconcile.
Designed for Submarine-Fleet Scale
Clarity is designed to scale to the largest sovereign programmes on earth — tens to hundreds of millions of items, and the full web of through-life relationships between them. A fleet’s configuration is not a list; it is a deeply connected model that keeps changing for decades, and the architecture is built for exactly that: event-driven, immutable, provenance on every write. Beta deployments run at small-to-medium decision-space scale; reaching full fleet scale is a deployment-tier step — offloading heavy processing to managed compute — not a re-architecture.
The detailed walkthrough — the AWS architecture, our data schema, and the scaling patterns behind it — is a technical briefing, under NDA.