A complex system enters service.
The LSAR has been delivered. The records have been reviewed. Contractual data requirements have been met. Thousands, perhaps tens of thousands, of structured records describe configuration items, failure modes, maintenance tasks, resources, skills, support equipment and spares.
Then the system starts to change.
Failures occur. Maintenance experience builds up. Tasks are revised. Parts become obsolete. Engineering changes are incorporated. Software is updated. Configurations diverge. Suppliers change. Operating conditions evolve.
The physical system keeps moving through its lifecycle. But somewhere along the way, the information describing how that system should be supported can stop moving with it.
The LSAR still exists.
The system it describes has moved on.
Software engineering identified this pattern decades ago. Meir Lehman's laws of software evolution, first set out in the 1970s, include the law of continuing change: a system used in a real-world environment must be continually adapted, or it becomes progressively less satisfactory. Lehman was describing programs, but the principle applies equally to the information that describes how a physical system is supported. An LSAR that is not continually adapted does not stay neutral. It steadily becomes less true.
An LSAR Is More Than a Collection of Records
It is easy to describe an LSAR as a database of information about parts, failure modes, maintenance tasks, personnel, skills, tools, test equipment, spares, facilities and support resources.
That description is correct. But it misses much of what gives the information its engineering value.
An LSAR is fundamentally about relationships.
A configuration item performs a function. That function can fail. A failure produces an effect. That failure behaviour may create a maintenance requirement. The requirement becomes a task. The task needs personnel, who need competencies and training. The task may also need tools, support equipment, technical information, facilities and spare parts.
The repair strategy shapes supply requirements. The maintenance concept shapes workforce and facilities. The configuration determines which analysis is still valid.
Change one element and several others may need to change with it.
This structure is deliberate. The LSAR tradition, rooted in the US MIL-STD-1388 series and carried into Australian practice through DEF(AUST) 5692, was designed as a relational data model, not a document set. More recent international specifications such as ASD S3000L take the same approach. The architecture assumes that records will be maintained as a connected whole.
The value of the LSAR therefore does not come simply from storing engineering records.
Its value comes from preserving the relationships between engineering and support decisions.
This Is a Systems Engineering Problem
Systems engineering establishes the relationships between operational need, requirements, functions, architecture, interfaces and the physical solution. Support analysis extends those relationships into the enabling systems needed to operate and sustain that solution.
The two information domains are not independent. The support solution exists because of decisions made within the product architecture. Change the design, and the consequences can propagate into reliability, failure modes, maintenance tasks, repair levels, spares, support equipment, technical information, training, facilities, workforce, software support and lifecycle cost. A single engineering change can affect several of these at once.
Maintaining the LSAR should therefore not be treated as a documentation activity happening downstream of engineering. It is part of maintaining the integrity of the overall lifecycle information model.
In that sense, LSAR integrity sits alongside configuration management, requirements traceability and interface management as a systems engineering concern.
How an LSAR Becomes an Archive
Few organisations deliberately decide to let their LSAR go out of date. The conditions develop naturally.
During acquisition, significant effort goes into developing support analysis information. There are contractual deliverables, reviews, milestones, data requirements, verification activities and acceptance criteria. Without anyone intending it, this can encourage the LSAR to be treated as something to be completed and delivered.
Then the system enters service, and responsibility starts to disperse.
Engineering changes may be managed in a PLM or configuration management environment. Maintenance execution moves into an EAM, ERP or CMMS. Supply information sits elsewhere. Technical publications have another repository. Operational failures are captured through FRACAS or another reporting system. Training has its own information environment. Software configuration may be managed separately again.
The LSAR remains. But the lifecycle information around it starts moving through other systems.
The result is not necessarily a poor database. It can be something more subtle:
a highly structured, internally consistent representation of the system at an earlier point in its lifecycle.
The System Does Not Stand Still
Entry into service does not freeze the engineering baseline. Throughout the operating life, configurations change, equipment is replaced, software evolves, failure behaviour becomes better understood, maintenance intervals are revised, suppliers disappear, parts become obsolete, operating profiles shift, facilities evolve and workforce structures change.
The support solution has to respond. So must the information model describing it.
Consider an asset physically operating at Configuration C, while important maintenance or support analysis still reflects Configuration A.
[Insert diagram: lsar-integrity-gap.jpg]
That is more than stale data. It creates engineering uncertainty:
- Are the existing failure modes still representative?
- Are the maintenance tasks still applicable?
- Are the inspection intervals still justified?
- Are the right spares being provisioned?
- Does the workforce still need the same competencies?
- Does the support equipment still match the installed configuration?
- Are the reliability and availability predictions still valid?
The physical configuration and its support configuration have started to diverge. That is a lifecycle engineering risk.
LSAR data models anticipated this. Records carry effectivity information, the usable-on and serial-number applicability that states which configurations a task, part or analysis applies to. Effectivity is the mechanism that lets a single LSAR describe Configuration A and Configuration C side by side. But effectivity only works if it is maintained. When a modification is embodied and effectivity is not updated, the LSAR does not just fall behind. It actively asserts that old analysis applies to equipment it no longer describes.
Configuration Changes Must Propagate
Consider a pump, hydraulic power unit, actuator or compressor that is modified after recurring failures. The modification successfully fixes the technical problem. But the engineering consequence does not necessarily stop at the modified component.
The change may alter failure modes, failure rates, inspection requirements, maintenance tasks, task intervals, spares, repair procedures, tooling, technical instructions, training, support equipment and reliability predictions.
The physical configuration may be updated correctly. The engineering change may be approved. The modification may be embodied across the fleet. But unless its consequences propagate through the support information, the organisation gradually creates two different systems:
One is the physical system that actually exists.
The other is the information system describing how that system is supposed to be supported.
Configuration management doctrine, as set out in standards such as ISO 10007, rests on four activities: identification, change control, status accounting and audit. Configuration status accounting, the continuous record of what configuration each item is actually in, is often the first casualty after entry into service. Without it, the organisation can no longer say with confidence which support information applies to which asset.
The gap between the two systems rarely appears suddenly. It develops quietly. Then one day it becomes operational.
Data Completeness Is Not Information Integrity
This distinction matters when LSAR quality is assessed.
Mandatory fields may be populated. Records may pass validation. The required relationships may technically exist. The database may meet contractual requirements.
Yet the information can still be wrong for the system currently being supported.
Completeness and integrity are not the same thing.
Data completeness asks:
Is the required information present?
Information integrity asks:
Does that information still correctly represent the configuration, relationships and operating context it applies to?
The information systems literature has long recognised that these are different dimensions. Richard Wang and Diane Strong's widely cited framework separated intrinsic data quality, such as accuracy and completeness, from contextual quality, such as relevance and timeliness for the task at hand. An LSAR can score perfectly on completeness while failing badly on timeliness and relevance. Most automated validation checks measure the first. The engineering risk lies in the second.
That second question is much harder to answer. It needs a continuing connection between engineering changes, operational evidence and the support baseline.
Operational Evidence Must Flow Back
Once a system enters service, the organisation gains something development could only estimate: actual behaviour. Actual failure modes and frequencies, repair durations, diagnostic effectiveness, spares demand, maintenance burden, workforce constraints and operating environments.
This evidence should be valuable to the LSAR, because it tests the assumptions the original support analysis was built on.
If a maintenance task consistently takes twice as long as predicted, something has been learned.
If an assumed failure mode rarely occurs while another dominates field experience, something has been learned.
If spares demand differs substantially from prediction, something has been learned.
If maintainers routinely need resources the original analysis didn't identify, something has been learned.
The lifecycle information should respond. The right loop is not:
Analyse → Deliver → Archive
It is:
Analyse → Implement → Operate → Observe → Validate → Update
That is what makes support analysis a lifecycle engineering activity, rather than an acquisition deliverable.
The LSAR Should Participate in the Digital Thread
Engineering organisations increasingly talk about the digital thread: maintaining traceable relationships between requirements, architecture, configuration, analysis, verification, operational evidence and engineering change.
Support information belongs inside that thread.
A design change should be traceable to its support consequences.
A changed failure mode should be traceable to affected maintenance tasks.
A maintenance change should expose its resource implications.
A changed repair policy should connect to supply, workforce, facilities and lifecycle cost.
Operational evidence should be able to challenge the engineering assumptions those decisions came from.
This does not mean every organisation needs one enormous database, or that every lifecycle discipline must use the same software. Different information systems can stay appropriate for different purposes. Exchange specifications such as the ASD S-Series were developed precisely so that LSA, provisioning, technical publications and in-service data could interoperate across tools.
The requirement is continuity of relationships. The organisation needs to know what information is authoritative, what depends on what, and what must be reconsidered when something changes.
That is the digital thread that matters.
This Is Not a Tooling Problem
It is tempting to treat fragmentation as a software problem. Buy a better LSAR tool. Implement a new ERP. Move to a modern PLM environment. Build interfaces between databases. Create dashboards. Digitise the records.
Technology can certainly help. But technology does not automatically create lifecycle integration.
A sophisticated digital platform can still become a sophisticated static archive. A perfectly integrated database can still contain relationships nobody is responsible for maintaining.
Digitisation improves the mechanism. It does not decide the governance. The more fundamental questions remain:
- Who owns the information?
- Who owns the relationships?
- Which changes trigger reassessment?
- How does operational evidence enter the engineering baseline?
- Who makes sure downstream support information stays aligned with the physical configuration?
Those are engineering and governance questions before they are software questions.
The Problem Extends Beyond Defence
LSAR is mainly Defence and aerospace terminology. Other industries organise similar information differently.
A mining operator may spread lifecycle information across SAP, engineering drawings, reliability systems, maintenance strategies and asset registers.
An energy company may combine EAM, asset integrity systems, document management and engineering databases.
A railway may manage configuration, maintenance, supply and operational information across several specialised platforms.
None of them needs an LSAR to experience the same problem. An organisation can have excellent individual information systems and still depend on people manually reconciling the relationships between them.
The terminology changes. The information continuity problem remains.
Bring the Question Back to Decisions
Lifecycle information is not maintained because databases deserve to be current. It is maintained because people need to make engineering decisions:
- What configuration are we supporting?
- What has changed?
- Which analyses are still valid?
- Which assumptions no longer hold?
- What downstream consequences does this engineering change create?
- Which maintenance requirements are affected?
- What does operational evidence tell us about the original prediction?
- What needs to change next?
An effective LSAR should help the organisation answer those questions. If it cannot, its value as a lifecycle engineering resource is already declining, however complete it looks in a data quality report.
The LSAR Should Be Living Engineering Information
If Integrated Product Support represents integrated lifecycle responsibility, the information behind it cannot fragment every time responsibility crosses an organisational boundary.
The LSAR was never meant to be valuable simply because it existed. Its purpose is to preserve structured engineering and support relationships, so that lifecycle decisions stay traceable as the system changes.
That means the important question after entry into service is not:
Do we still have the LSAR?
It is:
Does the LSAR still describe the system we are actually operating and supporting?
The physical system will keep evolving. So will the support system and the operating environment. The engineering information must evolve with them.
The real lifecycle challenge was never simply storing information.
It is maintaining continuity between the decisions that create it.
Aerion Engineering Advisory
Aerion Engineering Advisory helps organisations strengthen lifecycle information integrity across systems engineering, Integrated Product Support and asset sustainment.
Our approach connects configuration, RAM, FMEA/FMECA, maintenance analysis, LSAR, technical information, FRACAS and operational evidence, so that support information stays aligned with the system it is meant to represent.
The objective is not simply better data quality. It is preserving the engineering relationships needed to understand change, assess downstream consequences and make defensible lifecycle decisions throughout the life of the capability.
