DEF(AUST) 5691 and 5692 emerged from the Defence logistics support environment.
ISO 55001 and ISO 55002 emerged from the broader world of asset management.
Their structures, terminology and application are different. But place them side by side and an important similarity appears.
Both are trying, in different ways, to maintain disciplined relationships between organisational objectives, engineering evidence, asset decisions, support arrangements and lifecycle performance.
Both depend on traceability.
And both run into a practical problem that no standard can solve simply by requiring more documentation:
the information may exist while the relationships between the pieces of information gradually disappear.
Different Frameworks, Similar Questions
Consider some basic lifecycle questions.
Why does this maintenance task exist?
Which failure mode, degradation mechanism or risk justified it?
Why is the interval 2,000 operating hours rather than 1,000 or 4,000?
Which configuration does the analysis apply to?
If that configuration changes, which support decisions need to be reconsidered?
What assumption underpins the spares holding?
Where does operational failure experience feed back into the engineering baseline?
How would someone reconstruct the rationale for today's maintenance strategy five years after the original decision?
In a mature Defence LSA environment, much of this rationale should be developed through the Logistic Support Analysis process and represented in the associated engineering and LSAR information.
In a mature asset management environment, equivalent reasoning should connect asset management objectives, risk, lifecycle planning, maintenance decisions and performance evaluation. ISO 55000 calls this line of sight.
The terminology differs. The underlying requirement does not:
The organisation needs to know not only what it decided, but why it decided it.
This is not a new idea. Design research has long distinguished between recording a decision and recording its rationale. Kunz and Rittel's Issue-Based Information Systems, developed in the early 1970s, were an early attempt to capture the issues, positions and arguments behind design choices. The persistent finding of that literature is sobering: the decision is usually recorded, while the reasoning is usually not.
It Is Not a Lack of Standards
Neither environment lacks structure.
DEF(AUST) 5691 sets out a structured approach to Logistic Support Analysis, providing the analytical basis for determining support requirements and evaluating supportability throughout system development.
DEF(AUST) 5692 provides the associated Logistic Support Analysis Record framework for capturing and managing structured logistics support information.
ISO 55001 sets requirements for an asset management system aligned with organisational objectives, and ISO 55002 gives guidance on applying them.
All provide mechanisms for disciplined lifecycle management. The difficulty appears when the resulting engineering knowledge is spread across many artefacts and information systems.
A Defence program may maintain a configuration baseline, requirements data, FMEA/FMECA, reliability and maintainability analysis, an LSAR, maintenance requirements, technical publications, supply support data, and FRACAS or other operational failure information.
A commercial asset operator may hold equivalent lifecycle knowledge across engineering or PLM systems, an EAM or CMMS, asset registers, maintenance strategies, risk assessments, reliability databases, technical documentation and operational performance systems.
Each repository may be controlled. Each artefact may be current. Each function may be meeting its responsibilities.
Yet the organisation can still struggle to answer a deceptively simple question:
How does this piece of information relate to everything that depends on it?
Organisational theorists James Walsh and Gerardo Ungson described organisational memory as knowledge distributed across "retention facilities": individuals, culture, procedures, structures and records. Their central insight was that storage is not the main problem. Retrieval is. An organisation can retain enormous amounts of information while losing the ability to find, connect and use it when a decision depends on it.
The Lifecycle Chain
Underneath the different terminology sits a common lifecycle logic.
An organisational need or capability requirement shapes the system or asset strategy. That drives requirements and architecture. The resulting configuration contains functions, failure modes, degradation mechanisms and risks.
Those characteristics drive support decisions: maintenance tasks and intervals, spares, workforce, support equipment, facilities, training, technical information and supply arrangements.
Execution then generates operational evidence. Failures occur. Maintenance is performed. Components are replaced. Operating conditions change. Actual repair times become known. Supply chain performance becomes measurable.
That evidence should then challenge the assumptions behind the original support solution. The lifecycle should therefore behave as a connected loop:
Need → Requirements → Configuration → Failure/Risk → Support Decision → Execution → Evidence → Engineering Feedback
[Insert diagram: lifecycle-knowledge-loop.jpg]
DEF(AUST) 5691/5692 and ISO 55001/55002 describe different parts of this lifecycle using different structures. But the engineering problem underneath them is remarkably similar.
The chain only creates value while its connections stay intact.
A Pump, Either Way
Consider a pump that must be replaced because the original unit is no longer available.
Engineering evaluates an alternative and confirms that it meets the necessary functional and interface requirements. The configuration is updated. The associated asset or support records are amended. From a configuration control perspective, the change is being managed.
But suppose the replacement pump uses different bearings. Its degradation behaviour is slightly different. Its vibration signature changes. Its expected failure characteristics are not identical to the original item.
In reliability terms, the failure distribution may have changed. A different bearing design may shift the Weibull shape and scale parameters, changing both when wear-out begins and how quickly it progresses. Condition monitoring thresholds calibrated to the old vibration signature may now produce false alarms, or miss real degradation.
The engineering change now raises a series of lifecycle questions:
- Does the existing FMEA/FMECA remain valid?
- Does the existing maintenance task still address the relevant failure mechanism?
- Is the 2,000-hour interval still justified?
- Does condition monitoring need different limits or interpretation?
- Does the spares strategy need to change?
- Does the technician need different diagnostic information?
- Do technical publications need amending?
- Does the reliability model still represent the installed configuration?
Updating the part number is necessary. But it does not answer those questions.
The lifecycle requirement is broader:
the change must propagate through everything whose validity depended on the previous configuration.
That is where traceability becomes more than record keeping.
Organisations Own the Boxes
Most organisations are reasonably good at assigning ownership of information.
Engineering owns engineering information. Configuration management owns the controlled baseline. Reliability owns reliability analysis. Maintenance owns the maintenance program. Supply owns provisioning and inventory. Technical publications owns technical documentation. Asset management owns asset strategy. ILS or IPS may own supportability analysis and the associated logistics information.
These ownership boundaries are necessary. But lifecycle knowledge does not live only inside them. Its value often lies in the relationships between them.
A failure mode justifies a maintenance task.
A maintenance task creates a workforce requirement.
A repair strategy creates a spares requirement.
A configuration change affects the validity of reliability analysis.
An operational failure challenges an engineering assumption.
A changed operating profile affects the maintenance strategy.
These are not simply records. They are relationships.
Who Owns the Arrows?
This leads to a harder question.
Who owns the arrows between the boxes?
Who makes sure a configuration change triggers review of the maintenance analysis that depended on the previous configuration?
Who makes sure recurring field failures challenge the FMECA, rather than simply accumulating in a failure database?
Who makes sure a changed maintenance interval is reflected in planning, technical documentation, supply demand and lifecycle cost?
Who notices that an approved reliability analysis describes a configuration that is no longer installed?
Who decides which downstream information becomes suspect when an upstream assumption changes?
These responsibilities often sit across organisational boundaries, which makes them easy to dilute. One function assumes another will update the information. A change notification is issued. A document is revised. A database is updated. Individual configuration items stay controlled.
Yet the engineering rationale connecting them gradually fragments.
Requirements management already has a technical answer to part of this problem. Many requirements tools support suspect links: when an upstream requirement changes, every downstream item traced to it is automatically flagged for review. The same principle, applied across the whole lifecycle chain, would mark the FMECA, the maintenance task, the interval and the provisioning decision as suspect the moment the pump's configuration changed. Few organisations apply it that far.
This is not necessarily a documentation problem. It is an interface governance problem.
Configuration Control Is Necessary, but the Knowledge Graph Is Larger
Configuration management is essential to technical integrity. But lifecycle traceability goes beyond knowing which configuration is current. The organisation also needs to understand which decisions, analyses and assumptions depend on that configuration.
If an item changes, the important question is not only:
What record must be updated?
It is also:
What engineering reasoning must now be reconsidered?
That distinction grows more important as lifecycle information is spread across digital systems.
PLM may know the configuration.
The LSAR may know the support requirements.
The CMMS may know the maintenance tasks.
FRACAS may know the observed failures.
The supply system may know inventory and demand.
Each system can hold correct information. The lifecycle problem is maintaining the semantic relationship between them.
Digital engineering policy has begun to name this. The US Department of Defense's 2018 Digital Engineering Strategy describes an authoritative digital thread: a connected flow of data linking an asset's information across its lifecycle. The concept is sound, but a thread of data is not the same as a thread of reasoning. Linking a part number in PLM to a task in the CMMS is valuable. Recording why that task exists, and what would make it invalid, is what preserves engineering judgement.
In effect, the organisation needs to preserve a knowledge thread, not simply a collection of compliant databases.
Why This Matters to Availability
This fragmentation eventually becomes operational.
A system fails. Diagnosis takes 40 minutes. The physical repair takes 90 minutes. But returning the capability to service needs engineering information:
- Which configuration is installed?
- Which maintenance instruction applies?
- Has this failure occurred before?
- Is the existing repair approved for this configuration?
- Which spare is valid?
- Has the technical documentation incorporated the latest change?
The asset waits while the organisation reconstructs information that technically already exists.
The problem is not necessarily missing data. It is the difficulty of connecting the data quickly enough to support a decision.
This is one reason availability problems can become coordination problems. A technically mature organisation can hold vast amounts of controlled lifecycle information and still suffer long recovery times, because the relationships between engineering, maintenance, supply and configuration information are hard to navigate.
The cost compounds over time through workforce turnover. Ikujiro Nonaka distinguished between explicit knowledge, which can be written down, and tacit knowledge, which lives in people's experience and judgement. Much of the reasoning that connects lifecycle records is tacit. It sits with the engineer who remembers why the interval was set, or the planner who knows which configuration a task really applies to. When those people move on, the records remain. The connections often leave with them.
Compliance Is Not the Same as Connected Knowledge
Standards provide essential structure. They set expectations, define processes, create common information requirements, and provide mechanisms for governance and assurance.
But compliance alone cannot guarantee that engineering knowledge stays connected through decades of configuration change, operational learning and staff turnover. That takes deliberate lifecycle information architecture and governance. Organisations need to understand:
- what information is authoritative;
- which relationships must stay traceable;
- what downstream information depends on an upstream decision;
- which events should trigger reassessment;
- who owns those relationships; and
- how operational evidence closes the loop with engineering.
This is not an argument against standards. It is an argument for completing what the standards are trying to achieve.
The Standard Is the Foundation
DEF(AUST) 5691/5692 and ISO 55001/55002 provide different frameworks for different environments. There is little value in asking which is superior.
The more useful observation is that both ultimately depend on an organisation's ability to preserve engineering and lifecycle knowledge as assets, configurations and operating conditions change.
A compliant artefact matters. A controlled record matters. An approved analysis matters.
But lifecycle performance depends on something larger:
whether the organisation can still reconstruct the reasoning connecting them.
That changes the question engineering and asset leaders should ask. Not simply:
Who owns this artefact?
But:
Who owns the relationship between this artefact and everything that depends on it?
Lifecycle knowledge rarely disappears because nobody recorded it.
It disappears when the connections between the records are lost.
Aerion Engineering Advisory
Aerion Engineering Advisory helps organisations strengthen the engineering and information relationships that support lifecycle decision-making.
Our approach connects systems engineering, RAM, FMEA/FMECA, Integrated Product Support, LSAR, configuration management, maintenance analysis and operational evidence. We help organisations preserve traceability between engineering rationale, support decisions and real-world asset performance as systems evolve throughout their lifecycle.
