AUKUS · Australia-First
Australia is the host nation and lead integrator for AUKUS Pillar 1. The industrial base being assembled — spanning Australian sovereign capability, United Kingdom naval design authority, and United States technology transfer — has never before needed to operate as a coordinated programme graph across three jurisdictions, three classification levels, and three sets of export control regulations simultaneously. The window to establish the right infrastructure is now. The decisions made in the first 18 months will determine the cost and schedule performance of the programme for the next 40 years.
The decision that started before the programme existed
On 15 September 2021, three nations committed to a 40-year nuclear-powered submarine programme before the requirements analysis was complete, the architecture trade studies had been run, or the option space had been formally evaluated. The most consequential decision in Australian defence acquisition history was made at the strategic level — and the technical chain was constructed around it afterwards.
This is not a failure of governance. It is the normal pattern for every major alliance programme. The political commitment precedes the evidence chain. The mission of programme infrastructure is to construct that evidence chain from the point of entry forward, and backward through the inherited constraints — simultaneously, with full structural discipline.
No existing PLM, ERP, or document management system was designed for this. Clarity was.
The three structural requirements AUKUS creates
AUKUS imposes three requirements on digital engineering infrastructure that determine whether a digital thread is sovereign-capable or sovereignty-theatre.
Time — 40 years
Decisions made today must be defensible to people not yet born.
The engineers designing the first submarine will not be available to explain their decisions in 2065. The programme infrastructure must hold those decisions with their complete evidence chains — without depending on institutional memory, the original tooling, or the original team.
Sovereignty — three jurisdictions
Data sovereignty is necessary. Knowledge sovereignty is required.
AUKUS requires shared decision traceability — not just data sharing. When an Australian supplier makes a design commitment affecting a UK prime's baseline, the decision record must be accessible to both parties under their respective classification controls, in their respective jurisdictions, auditable on both sides.
Classification — entity level
Document-level classification fails at the cross-domain boundary.
A single design record may contain both SECRET and OFFICIAL content. Classification must be enforced at the entity level — every requirement, decision, and baseline entry carrying its own classification claim, independently enforced and transferable at the right granularity.
Why legacy tools cannot meet this requirement
The honest explanation for why legacy enterprise systems cannot satisfy AUKUS’s structural requirements is not that they are old or badly designed. It is that they were designed for a different problem.
Teamcenter, DOORS, SAP, Maximo — these are products of the 1980s and 1990s. They were built to manage the data and information generated by engineering programmes in an era when programmes operated within a single national jurisdiction, security was a configuration layer applied after the architecture was designed, and “digital thread” meant connecting the CAD model to the bill of materials, not connecting decisions to evidence chains across sovereignty boundaries.
Their security architecture is a policy layer on top of a single-tenant relational database that was never designed to enforce sovereignty boundaries at the data level. Their classification model is document-level, not entity-level. Their exchange model is file transfer, not structured decision traceability.
Achieving genuine AUKUS sovereignty with legacy PLM or ERP requires:
- Separate instances per classification level — which creates the reconciliation problem across those instances
- Custom middleware to enforce cross-domain exchange policies — which adds attack surface and systems integrator dependency
- Policy documents that assert sovereignty — which auditors read, but which the code does not enforce
Rebuilding to genuine sovereign architecture requires discarding the product kernel — which is the entire product. No incumbent vendor is doing this.
Policies disconnected from architecture are promises, not guarantees. Auditors read the policy document. Adversaries read the code.
The AUKUS Digital Engineering Problem
The AUKUS agreement is structurally different from previous alliance programmes.
Previous alliance programmes shared information. AUKUS requires shared decision traceability. When an Australian supplier makes a design commitment that affects a UK prime’s baseline, the decision record must be accessible to both parties — under their respective classification controls, in their respective jurisdictions, without one party’s data crossing the other’s sovereignty boundary uninvited.
This is not a data-sharing problem. Legacy enterprise systems can share data. It is a decision-traceability-across-sovereignty-boundary problem. No legacy PLM, ERP, requirements database, or document management system was ever designed to hold that structure — because until AUKUS, no programme required it at this scale.
How Clarity works for AUKUS
Sovereign by design
Clarity runs in your AWS account, encrypted with your KMS keys, in your AWS region. For classified deployments: AWS Australia air-gapped regions, no outbound connectivity required. Clarity has zero access to your programme data under any operational circumstances — not to provide support, not to deploy updates.
This is verifiable: review the IAM policies in your AWS account. The verification does not require trusting the vendor’s documentation.
Three independent enforcement layers
Clarity enforces the sovereignty boundary at three layers, each independently auditable:
1. IAM inline deny — the execution roles used by Clarity’s processing functions carry an explicit IAM inline deny on write operations to the programme data. An inline deny cannot be overridden by any IAM policy that grants permissions — it is absolute. An application-layer vulnerability cannot bypass it.
2. S3 bucket policy — the programme data bucket carries an explicit deny on write operations from any role that is not explicitly authorised to write. This is enforced by S3, independently of IAM. An IAM misconfiguration cannot bypass it.
3. Schema-level classification enforcement — the programme data model enforces classification claims at the entity level, at write time. An entity cannot enter the programme record without a valid classification claim. This is enforced by the schema validation layer, independently of IAM and S3.
Any two of these layers could fail simultaneously and the third would still enforce the boundary. Each layer can be independently audited by an ASD-accredited assessor or DISP-qualified security architect without reading application source code.
Diode and Airlock for structured cross-boundary exchange
Clarity’s cross-boundary exchange operates through two controlled mechanisms:
The Diode allows structured digital thread content to flow from one programme graph to another in one direction, with write-back structurally impossible by IAM — not just by application logic. An Australian prime can receive design decisions from a US technology licensor via a Diode. The decisions enter the Australian programme graph with their evidence chains, classified at the entity level. The US licensor cannot receive any data back through the same channel.
The Airlock allows structured digital thread exchange in multiple directions across sovereignty boundaries, governed by a joint ownership policy that both parties must explicitly approve before any exchange occurs. Either party can suspend the exchange at any time, with suspension taking effect immediately. The policy infrastructure fails closed: if the policy enforcement mechanism is unavailable, no exchange occurs.
Every exchange — in either direction, through either mechanism — generates a CrossDomainTraceLink: a bilateral, immutable audit record stamped on both sides of the boundary simultaneously. Neither party can forge the existence of an exchange. Neither party can deny that an exchange occurred. The CrossDomainTraceLink records the specific entities exchanged, the classification at the time of exchange, the authorising parties, and the timestamp.
The exchange architecture operates on AWS SQS throughout — not EventBridge. SQS is available in AWS GovCloud and in AWS air-gapped regions. It does not require any outbound connectivity to Clarity’s infrastructure.
Entry at any lifecycle point
AUKUS entered the programme chain as a political commitment before the technical analysis existed — the mandate precedes the evidence chain. Clarity supports full structural discipline from any entry point, building the evidence chain forward from where the programme is and backward through the inherited constraints simultaneously.
Where the inherited chain exists only as political commitments or contract documents, Clarity provides the structure to capture it — with explicit provenance marking that makes the quality of the evidence transparent rather than hidden.
Legacy MBSE tools were built for the greenfield ideal: start at stakeholder requirements, proceed sequentially through design to disposal. That theoretical ideal describes almost no real programme of consequence. AUKUS is the most visible current example of how real programmes actually enter the lifecycle chain.
For Australia’s AUKUS industrial base
AUKUS Pillar 1 requires Australia to build a sovereign naval industrial base that does not yet exist at the required scale. The Tier 2 and Tier 3 suppliers entering that industrial base — the specialist manufacturers, precision engineering firms, and advanced materials suppliers who will form the backbone of the build-operate-sustain supply chain — are predominantly organisations that have never operated within a classified programme environment.
They do not have PLM. They have SharePoint, Excel, and email. The traceability and evidence requirements of a classified naval construction programme are beyond what their current tooling can produce.
There are two options for bringing these suppliers into the AUKUS digital engineering ecosystem: mandate that they acquire enterprise PLM (which will price many of them out of participation) or provide them with a digital thread platform that meets AUKUS requirements at a cost and complexity that an engineering SMB can absorb.
Clarity for the AUKUS industrial base:
- Same decision accountability infrastructure as the primes — same data model, same evidence chain structure, same classification enforcement
- Same-day deployment, no systems integrator, no infrastructure to manage
- Connected to the prime contractor’s Clarity deployment via CrossDomainTraceLink, with access controls set by the prime and enforced by architecture
- Priced for SMB participation — at a fraction of enterprise PLM licensing
The AUKUS industrial base requires that every participant in the supply chain can produce decision-traceable evidence at the level the programme demands. That is only achievable if the tooling is accessible to the full supply chain — not just to the Tier 1 primes who can absorb enterprise PLM costs.
Designed for 14 Eyes compliance — by architecture, not by bolt-on
Legacy PLM and document management systems were designed in the 1990s and 2000s for single-tenant, single-classification, single-jurisdiction enterprise use. Their sovereignty claims for AUKUS programmes are policy assertions layered on top of architectures that were never built for cross-classification, cross-jurisdiction, or air-gapped operation. Every “secure” feature is a bolt-on — middleware added decades after the product kernel was built, by vendors whose original architecture cannot be rebuilt to genuine sovereign compliance without discarding the product itself.
“Auditors read the documentation. Adversaries read the code.”
Clarity’s enforcement is in the architecture — independently verifiable without trusting vendor documentation.
Clarity was designed from first principles for Five Eyes and 14 Eyes programme requirements. The enforcement layers are not features. They are the architecture. The controls most frequently cited as gap items in legacy system ASD ISM assessments are addressed structurally:
| ASD ISM Control | Requirement | Clarity architecture |
|---|---|---|
| ISM-0109 | Separation of duties — no single user can perform a sensitive operation without a second independent control | Three independent enforcement layers; no single administrator can bypass all three |
| ISM-0141 | Audit logging — all access and mutations must be logged immutably | Every entity mutation generates an immutable CloudTrail event with author, timestamp, and rationale; the audit log cannot be modified by any user, including administrators |
| ISM-0428 | Cryptographic key management — encryption keys must be controlled by the system owner, not the vendor | Customer-held AWS KMS keys; Clarity holds no key material and cannot access it |
| ISM-1553 | Data sovereignty — sensitive data must be stored in Australian jurisdiction | All programme data in customer AWS account in ap-southeast-2 (Sydney) or AWS Australia air-gapped region; no data leaves Australian jurisdiction |
| ISM-1797 | Network separation — classified data must be handled on networks separated from lower classification environments | Air-gap deployment supported; no outbound connectivity required for programme data |
A full ASD ISM controls mapping — covering all applicable controls, with evidence references — is available to accreditation authorities, partner nation security assessors, and authorised ATO partners on request.
Starting point for AUKUS programme offices
The window to establish the right digital engineering infrastructure for AUKUS is now — before the first cross-domain exchange occurs, before the first classified design review, and before the programme has accumulated a decision record that cannot be retrospectively made traceable.
For prime contractors with existing PLM and ERP: Clarity sits above your existing systems as the connected intelligence layer. DOORS continues managing requirements. Teamcenter continues managing designs. SAP continues managing procurement. Clarity connects the decision layer above them and provides the sovereign exchange infrastructure for cross-boundary programme coordination.
For Tier 2–4 suppliers entering the AUKUS industrial base: Clarity replaces the spreadsheet and SharePoint infrastructure. Same-day deployment, no systems integrator, no infrastructure to manage. The first structured decision record is produced in hours.
For government programme offices: Clarity provides the oversight infrastructure that gives Australian programme authorities a structured view across the contractor ecosystem — with each contractor’s data held within their own sovereignty boundary and visible to the programme office only through the access controls each contractor has authorised.
"The AUKUS programme needs a digital thread that is sovereign by design, accessible to the full industrial base, and capable of carrying decision traceability across classification boundaries. That is what Clarity was built for."
Clarity is the product intelligence layer for sovereign defence programmes. Sovereign by design — running in your AWS account, with your encryption keys, in your jurisdiction.