The problem you are accountable for
A platform enters service. Over the next three decades, the original design team rotates out. Contractors change. Suppliers are de-listed or acquired. The as-built configuration diverges from the design baseline — not through negligence, but because the mechanism for connecting design-time decisions to build-time reality has always been a document, not a record.
When the through-life support team asks why a subsystem was designed a particular way — what options were considered, what constraints applied, what the approval authority decided — the answer is a reconstruction from artefacts, not a retrieval from a record. The cost of that reconstruction, multiplied across a 30-year platform life and a hundred subsystems, is not a soft cost. Neither is the certification risk when the configuration state cannot be authoritatively established.
Three structural problems follow from this:
Configuration drift
Nobody knows exactly what was built.
When a supplier changes a component, when a modification is applied in the field, when a configuration item is substituted — does that change flow back to the authoritative design baseline? Or does it become a deviation that propagates silently until it surfaces as a certification or sustainment problem?
Sustainment cost
Most cost occurs after delivery.
Through-life support, maintenance planning, and modification programmes all depend on a trusted configuration baseline. When that baseline is uncertain, through-life costs escalate — not because of poor sustainment planning, but because the baseline the sustainment plan was built on is no longer reliable.
Sovereign knowledge loss
Engineering memory leaves with the people.
Australia repeatedly experiences workforce turnover, contractor churn, and the retirement of senior engineers who hold the institutional knowledge of why platforms were built the way they were. When that knowledge is not in a system — when it exists only in people's heads and email threads — it is not sovereign.
What Clarity provides
A trusted configuration baseline from design intent through to sustainment. Clarity records every design decision with its complete evidence chain — what options were considered, what constraints applied, what the approval authority decided, and why. That record is not a document. It is a structured entry in the programme model, traceable to the requirements that governed it and to the baselines that froze it.
When the through-life support team needs to understand why a subsystem was designed a particular way, the answer is a navigation through the live programme model — not a reconstruction from memory.
Configuration integrity from design through to build. Supplier BOMs are reconciled to your higher-level configuration model via Clarity — not to ICDs, spreadsheets, or an email trail. Discrepancies surface to the responsible engineer before they reach your governed baseline. Configuration modifications trigger a quality-gated review pipeline rather than propagating silently. The design baseline and the as-built reality remain connected — or the divergence is visible and attributed.
Engineering knowledge that outlasts the team. Every decision record in Clarity carries its rationale, its approval authority, and its evidence chain — permanently, without depending on the original team, the original tooling, or the original documents. The knowledge is in the programme model, not in the people. When engineers retire, the knowledge they held does not retire with them.
Sovereign by architecture. Clarity runs in your AWS account, encrypted with your KMS keys, in your AWS region. Clarity has zero access to your programme data. Air-gap capable for classified deployments. The programme’s engineering knowledge remains within your jurisdiction, in open structured format, in perpetuity.
The connection between design decisions and through-life cost
The most expensive problems in through-life support are the ones where nobody can answer why a design decision was made. Every time the answer is “we’ll need to get someone to reconstruct the original intent” — that is a cost. Multiplied across a platform life, across a hundred subsystems, across three or four modification programmes, it is a very large cost.
Clarity makes the 30-year question structurally answerable. Not because someone maintained a document — because the decision was recorded with its evidence chain when it was made.
The design decisions being made today about your platform will be questioned in 2040, in 2050, in 2060. The engineers making those decisions will not be available to explain them. Clarity ensures they do not need to be.
Designed for 14 Eyes compliance — by architecture, not by bolt-on
Clarity was not designed as a commercial platform and then hardened for defence. It was designed from first principles for the sovereignty and classification requirements of Five Eyes and 14 Eyes programmes.
The distinction matters. 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 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.
“Auditors read the documentation. Adversaries read the code.”
Clarity’s enforcement is in the architecture — independently verifiable without trusting vendor documentation.
Clarity’s three independent enforcement layers — IAM inline deny, S3 bucket policy, and schema-level classification enforcement — are not features. They are the architecture. Each is independently auditable by ASD or a DISP-qualified assessor without reading application source code. Any two could fail simultaneously and the third would still enforce the boundary. This is not achievable by adding security features to a legacy product. It requires building the product around the boundary from first principles — which is what Clarity did.
For classified programmes: AWS Australia air-gapped regions, no outbound connectivity required, customer-held KMS keys, zero Clarity access to programme data. The configuration record is sovereign by architecture — not by vendor promise.