Clarity for Prime Contractors

The layer above your existing tools

You have PLM. You have an ERP. You have MES on the shop floor. Your PLM vendor will tell you their platform manages configuration management. It does manage the product structure. What it cannot hold is the decision that produced that structure: what the design authority considered, what constraints applied, what was rejected and why, what the approval authority signed off.

When a certification question arrives and the answer requires understanding why a subsystem was configured the way it was — PLM returns a BOM entry. The reasoning behind it lives in a meeting minute from 2019 that is now somewhere in a document management system that three people who have since left the programme were responsible for maintaining.

Clarity holds the reasoning. Not instead of PLM — above it. The BOM entry in PLM connects to the decision record in Clarity. The decision record holds the options evaluated, the constraints that governed selection, the approval authority, and the traceability back to the requirement that specified the need.

None of your existing tools reconcile these. Clarity is the reconciliation layer — and it is a structural property of the programme model, not a quarterly exercise in spreadsheets.

“The challenge is not a lack of systems. It’s a lack of traceability between decisions and the evidence spread across those systems.”

Clarity provides the decision layer that sits above existing investments — without replacing them.

What Clarity does for primes

Supplier BOMs reconciled to your configuration model — not to ICDs, spreadsheets, or email. When a Tier 2 supplier delivers a BOM update or a design modification, Clarity reconciles it against your higher-level configuration model before it is promoted to your source of truth. Discrepancies surface to the responsible engineer with a source-weighted verdict. Configuration drift is visible before it becomes a certification problem or a sustainment cost.

Design baseline connected to the as-built record. The gap between the design authority’s baseline and what was actually built is the most expensive gap in through-life support. Clarity maintains the connection — every change to the as-built is traceable to the design decision that authorised it, or flagged as an unauthorised deviation. Versions, variants, alternates, and substitutes are all first-class objects in the Clarity configuration model, each carrying its own effectivity record — effectivity by serial, by date, by modification state, or by contract. When a platform leaves the production line with a known deviation, a concession, or an approved substitute fitted, the as-built record reflects that precisely — not as a note in a spreadsheet, but as a structured, queryable fact that follows the platform through its entire in-service life.

Subcontractor accountability without subcontractor access to your systems. Your Tier 2 and Tier 3 suppliers can produce and submit traceable evidence packs through Clarity without having access to your PLM or your classified environment. The classification boundary is enforced by architecture — not by process.

Each supplier sees only the work package assigned to them — the specific configuration items, interface requirements, and acceptance criteria that are theirs to deliver. Not the full programme model. Not another supplier’s scope. Not your internal decision records. Their Clarity workspace is scoped to their deliverable and nothing else.

Within that scope, the evidence submission process is structured but lightweight. A 12-person engineering firm delivering a hydraulic actuator sub-assembly produces the same structured, independently verifiable evidence pack as a tier 1 integrator — because Clarity generates the pack from the work they are already doing, not from a parallel documentation effort. The requirement is traced. The design decision is recorded. The test result is linked. The as-built configuration is confirmed. The submission is complete.

When the supplier submits, Clarity reconciles their deliverable against your configuration model automatically. Interface conformance is checked. Effectivity is validated. Any deviation surfaces to your responsible engineer with a structured verdict — not an email, not a spreadsheet flag, but a traceable configuration event that becomes part of the platform record. The supplier is accountable. Your system of record is clean. The audit trail is intact without either party having access to the other’s systems.

Decision records with their evidence chains. Every design authority decision is recorded in Clarity with the complete evidence chain that informed it — what options were evaluated, what constraints applied, what was decided and why. Those records survive workforce turnover, contractor rotation, and platform delivery. The 30-year question is answerable without the original team.

AUKUS requirements

AUKUS imposes specific configuration management requirements that no existing prime has fully addressed:

• Cross-classification exchange — design information flowing between UK primes, US primes, and Australian suppliers at different classification levels, with independently auditable boundary enforcement
• Sovereign knowledge retention — the engineering reasoning that supports through-life support of sovereign platforms must remain within Australian jurisdiction, outlasting the programme delivery team
• Industrial base visibility — the ADF and CASG need confidence that the AUKUS industrial base can produce and maintain configuration-managed deliverables at scale

Clarity addresses all three with architecture, not process. The Diode and Airlock connectors enforce cross-classification boundaries structurally. The programme model retains engineering reasoning within your jurisdiction. The supplier chain coordination layer gives CASG visibility into industrial base readiness.

One connected configuration model — not separate BOM trees

Your PLM holds the engineering BOM. Your ERP holds the procurement BOM. Your sustainment team holds a spares BOM. None of them match — and the reconciliation between them is a manual exercise that happens quarterly, if at all.

Clarity manages one connected configuration model. Every BOM view — engineering, manufacturing, as-built, sustainment, spares — is a query over the same source of truth. The as-built cannot diverge from the design baseline without an auditable record of the divergence. The spares BOM cannot drift from the as-maintained record.

Clarity supports sixteen configuration views from one CI graph — As-Designed, As-Built, As-Validated, As-Deployed, As-Operated, As-Updated, As-Disposed, and more — each generated as a live query against the same model, not a separately maintained tree. These are not export formats. They are the canonical lifecycle states of the Clarity data plane: L6 through L12. When a configuration item changes, every view that references it reflects that change immediately, with full traceability to the authorising decision. There is no batch export, no overnight sync, no reconciliation run. The sixteen-view capability is not a feature of the configuration module. It is a structural consequence of holding one model.

No PLM or ERP can do this. They manage separate trees in separate systems. Clarity holds the model above them from which every view derives. The reconciliation problem structurally disappears.

The reason legacy systems cannot solve this is architectural, not commercial. Every major PLM and ERP vendor — Teamcenter, Windchill, SAP, Oracle, ENOVIA — is built around the same foundational concept: the business object. A Material. An Item Revision. A CAD Document. An Item Master. These objects sound like neutral data containers. They are not. They encode the vendor’s assumptions about how your business should operate — which approvals must happen in which order, which fields must be populated before a status can change, which transitions are permitted. The business object is a workflow in disguise.

This creates five compounding failures. First, the business object is semantically overloaded — it collapses multiple real-world concepts into one database row. A part number, its procurement status, its engineering revision, its effectivity record, and its quality hold are stored as fields on the same object. When any one of those concepts needs to change independently, it cannot, because the object treats them as one thing.

Second, the business object cannot compose. You cannot take SAP’s Material and Teamcenter’s Item Revision and produce a clean integrated configuration item. You get a bolt-on middleware layer that inherits the problems of both and adds network latency on top.

Third, because the object never fits the real programme, every deployment requires customisation — fields added, statuses overridden, workflow logic extended. Each customisation makes the system harder to upgrade and harder to audit. The customisation is not optional. It is the inevitable symptom of the modelling failure.

Fourth, the data inside these objects is context-free and fragmented. Answering a question such as “which decisions depended on this supplier’s technical compliance statement” requires massive joins across tables whose foreign keys were never designed for that traversal. Most of the time, the honest answer from the system is that it cannot tell you.

Fifth, the complexity is economically reinforced. Every additional workflow, every additional business object field, every additional configuration option is a reason to keep the consulting firm on the premises. Simplification is structurally against the vendor’s interests. That is why legacy stacks never get simpler — and why the reconciliation problem has persisted for thirty years despite billions spent on PLM and ERP platforms that were each sold as the solution to it.

Sits above your existing tools

Clarity does not replace your PLM, ERP, or MES. It sits above them via Clarity’s Diode and Airlock Connectors — policy-governed, classification-aware connectors that control exactly what data crosses which boundary and in which direction. Your Teamcenter continues running. Your SAP continues running. Clarity reads their structured outputs, validates supplier submissions against the design baseline, and maintains the decision record and connected configuration model above them.

The Diode Connector enforces a one-way data flow — structured programme data moves from a classified or controlled environment into Clarity’s intelligence layer, with no return path that could carry sensitive data in the wrong direction. The Airlock Connector provides bilateral exchange with a structured hold point: data crossing the boundary is inspected, validated against the receiving environment’s classification policy, and released only on explicit authorisation. Both connectors maintain a bilateral audit trail — every data crossing is a traceable configuration event, not a file transfer. For AUKUS, Five Eyes, and ASD ISM programmes, this is not a feature. It is the architectural prerequisite for structured cross-classification exchange.

The integration model is the strangler pattern: Clarity becomes progressively more authoritative as it accumulates context that only it holds — the evidence chain behind every design decision, the single configuration model from which all BOM views derive, the audit record of every configuration change, the cross-supplier baseline integrity record.

Deployment options

All options: same platform, same data model, same classification enforcement architecture.