The problem you are accountable for
A platform enters service. The as-built configuration record is handed over — a set of documents, drawings, and software baselines that represent what was delivered. Within months, field modifications are applied. Components are substituted. Emergency repairs introduce workarounds. The configuration drifts.
Nobody is negligent. There is simply no mechanism connecting in-service changes back to an authoritative record in real time. The as-maintained configuration and the as-built baseline diverge — silently, continuously — until the divergence surfaces as a certification failure, an unplanned maintenance event, or a modification programme that cannot establish a reliable starting point.
Three structural problems follow:
Configuration drift
Nobody knows exactly what is fitted.
Field modifications, component substitutions, and emergency repairs accumulate without flowing back to the authoritative configuration record. When the next scheduled maintenance arrives, the maintenance team is working from a baseline that may not reflect the platform in front of them. Discrepancies surface at the worst possible time.
Maintenance cost escalation
The baseline the maintenance plan was built on is no longer reliable.
Maintenance schedules, modification programmes, and spares forecasts are built against a configuration baseline. When that baseline is uncertain, costs escalate — not from poor planning, but because the plan is executing against a platform that has silently diverged from the record it was planned against.
Sustainment knowledge loss
Institutional maintenance knowledge leaves with the people.
The engineers who know why a particular maintenance interval was set, why a component substitution was approved, which components are known to be failure-prone in this operating environment — they rotate out. The maintenance plan captures what to do. It does not capture why, and it does not capture what was rejected and why.
What Clarity provides
A live as-maintained configuration baseline — connected to the as-built record. When a modification is applied in the field, it is attributed and traceable in Clarity before it is closed out. When a component is substituted, the substitution carries its approval authority, its rationale, and its link to the configuration item it replaces. The drift between as-built and as-maintained does not disappear — it is visible, attributed, and governed. The maintenance team always knows what is actually fitted, not what the handover documentation said was fitted at delivery.
Modification traceability from intent to close-out. Every in-service modification carries its complete decision chain in Clarity: what was changed, what options were considered, what constraints applied, what the engineering authority approved, and why. When the next scheduled deep maintenance arrives, or when a platform review is required for an availability certification, the modification history is a navigable record — not a reconstruction from work orders, maintenance logs, and email archives.
Retention — maintenance knowledge that outlasts the team. Maintenance decisions, failure investigation conclusions, and modification rationale are structured entries in the programme model — permanently attributed to the engineering authority that made them, permanently connected to the configuration items they governed. When the original sustainment team rotates out, the knowledge they held is in the system, not in their heads. The maintenance plan captures what to do. Clarity captures why — and what was tried, rejected, or deferred.
Predictive maintenance enabled by accurate as-maintained configuration and digital twin telemetry. Digital twin models ingest telemetry from physical assets. Their predictive accuracy is bounded by the accuracy of the configuration model they represent. When the as-maintained record has drifted from what is actually fitted — through unattributed field modifications, component substitutions, or emergency repairs — the twin is predicting against a model that no longer matches the physical asset. Clarity provides the accurate as-maintained configuration record that makes digital twin telemetry actionable: the right telemetry, mapped to the right configuration, predicting failures in the platform that actually exists.
The connection between configuration accuracy and availability
The most expensive maintenance events are the ones nobody planned for. Behind most unplanned downtime is a configuration discrepancy — a component that was substituted without attribution, a modification that was applied without flowing through to the maintenance plan, a failure mode that was known on one platform but never recorded in a way that reached the maintainers of the next.
Clarity makes configuration accuracy a structural property of the sustainment programme — not a periodic reconciliation exercise.
The maintenance decisions being made today about your platform will be the starting assumptions for the modification programme in 2035, and the deep maintenance in 2045. Clarity ensures those decisions are recoverable at the moment they are needed — as a record, not a reconstruction.
Spares and logistics intelligence
A configuration-connected spares model. The as-maintained BOM and the spares BOM are a single query in Clarity. When a component substitution changes the as-maintained record, the spares forecast updates against the current configuration — not against the as-built baseline from delivery. Spares that are no longer fitted are visible. Components that have been substituted at higher frequency than forecast are visible. The logistics chain is planned against what is actually in service, not what was specified at delivery.
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 for sustainment. Legacy asset management and maintenance systems were designed for single-tenant, single-classification enterprise use. Their sovereignty claims are policy assertions layered on top of architectures never built for cross-classification, cross-jurisdiction, or air-gapped in-service operation. Every “secure” feature is a retrofit.
“Knowledge that is not in a system is not sovereign.”
The sustainment knowledge of a sovereign platform must be as sovereign as the platform itself.
Clarity’s three independent enforcement layers — IAM inline deny, S3 bucket policy, and schema-level classification enforcement — are each independently auditable by ASD or a DISP-qualified assessor without reading application source code. For classified in-service programmes: AWS Australia air-gapped regions, no outbound connectivity required, customer-held KMS keys, zero Clarity access to programme data.
The as-maintained configuration record of a sovereign defence platform belongs to the Commonwealth — by architecture, not by vendor promise.