The problem you are accountable for
Configuration managers in defence programmes are routinely given document management tools and asked to do configuration management with them. The tools track files and versions. They do not track configuration items, change authorities, baseline states, or effectivity. Every CM discipline — change control, baseline management, configuration status accounting — becomes a manual process enforced by the person, not the system.
Manual disciplines degrade under programme pressure. They are inconsistently applied by different people. They produce evidence that is difficult to reconstruct at audit time. And they place the CM officer in the position of being personally accountable for failures that the system was never designed to prevent.
Three structural problems follow:
Change control without traceability
PRs logged, ECRs approved, ECNs issued — across spreadsheets, email, and folders.
When an audit requires the full change history of a configuration item — every PR raised, every ECR decision, every ECN that touched the item — the evidence must be reconstructed from a dozen sources. The reconstruction takes weeks. The audit finding is the predictable result.
Configuration status accounting is a report, not a view
What is in which baseline? What changes are pending? What is approved but not yet incorporated?
Configuration status accounting in most CM environments is not a live view. It is a report generated by aggregating multiple spreadsheets. It is stale from the moment it is produced — and the accuracy of the next status report depends on whether everyone updated their spreadsheet.
Baseline integrity relies on the CM officer, not the system
Nothing prevents a change from reaching a governed baseline without an approved ECN.
The system does not enforce the control. The procedure does — until pressure, workload, or a workaround creates an exception. Document management systems were not designed to enforce baseline governance. They were designed to store documents.
What Clarity provides
CM workflows built into the data model — not layered on top of a document store. The PR → ECR → ECN change pipeline is a structured workflow in Clarity, not a document convention. A problem report is a first-class entity with a state machine. An engineering change request carries its analysis, its impact assessment, and its approval authority. An engineering change notice is not issued until the ECR has an authorised approval record. The system enforces the sequence — the CM officer does not need to.
Configuration status accounting as a live view. At any moment, the configuration status of any item — its current approved baseline, its change history, its pending changes, its effectivity — is a query over the programme model, not a report compiled from spreadsheets. The answer is current because the model is the source of truth, not a representation of it.
Baseline management with full effectivity. Versions, variants, alternates, and substitutes are managed as first-class relationships in the configuration model, not as naming conventions in a folder structure. Effectivity — which configuration applies to which serial number, which production lot, which modification state — is a structured attribute, not an annotation in a document.
Audit readiness as a permanent state. Every change applied to a governed baseline carries its full evidence chain at the moment it is applied: the PR that initiated it, the ECR analysis and approval, the ECN authority, the date, and the approving authority. When the audit asks for the change history of a configuration item, the answer is a retrieval — not a reconstruction exercise that takes three weeks.
Governance that protects the CM officer. When the system enforces the CM process, the CM officer is no longer personally accountable for failures caused by pressure to bypass the process. Clarity’s baseline governance is not a procedure. It is a constraint that the programme model enforces architecturally.
Configuration management as a founding discipline
The configuration management disciplines in Clarity were not added to satisfy a compliance checklist. They reflect the actual CM practice documented in major defence PLM deployments — 42 CM use cases across five CM activity domains, mapped to a data model designed to eliminate the class of failure where document management masquerades as configuration management.
The distinction matters. A document management system with CM procedures bolted on will always have a gap between the governed ideal and the daily reality. The gap lives wherever the procedure relies on a person instead of the system. Clarity was designed so that gap does not exist.
Designed for 14 Eyes compliance — by architecture, not by bolt-on
Clarity’s classification enforcement is structural. The CM record of a classified programme item carries its classification at the schema level — not as a document marking that depends on the CM officer remembering to apply it. Classification boundaries are enforced by IAM, S3 policy, and schema-level controls independently, so any two could fail and the third would still hold.
“The configuration record is only as sovereign as the system that holds it.”
Clarity runs in your AWS account, encrypted with your KMS keys. Zero Clarity access to programme data.
For classified programmes: air-gapped AWS Australia regions, customer-held KMS keys, no outbound connectivity required. The configuration record remains within the programme’s jurisdiction — permanently, without depending on the CM tool vendor’s access controls.