The analytical backbone of the entire AGL Failure Database. Divisions 01–20 classify what failed and where; Division 21 determines why it failed, how the cause was established, and whether the corrective action actually eliminated it — covering 18 root-cause categories and 9 RCA methods, from evidence collection through to verified closure.
Core logic — Failure → Evidence → Cause → Root Cause → Corrective Action → Verification → Prevention. One failure can have multiple contributing factors but should ultimately have a technically verified root cause wherever sufficient evidence exists.
Diagnostic principle — Do not stop at "what failed?" Establish "why did it fail?", verify the answer with objective evidence, eliminate the cause, and prove that the corrective action prevented recurrence. Recording "Root Cause: LED driver failure" only restates what failed — it is not a root cause.
The failure originates primarily from an electrical condition or electrical-system characteristic.
The failure is primarily caused by mechanical loading, movement, damage, wear or structural condition.
The failure originates primarily from optical performance, optical components or optical alignment.
The failure is primarily caused by excessive, abnormal or inadequately controlled temperature.
The failure is primarily caused by environmental exposure or environmental conditions.
The failure originates from incorrect, inadequate or defective installation.
The failure originates from maintenance activity, maintenance workmanship, maintenance omission or incorrect maintenance decision.
The failure is caused by a weakness or deficiency in system, equipment, component or installation design.
A design root cause should normally require supporting technical evidence, not merely the fact that a component failed.
The failure originates from the manufacturing process.
The failure is primarily attributable to material properties, material degradation or unsuitable material selection.
A specific component is established as the primary source of failure.
Component failure describes what failed. Component root cause means the investigation has established that the component itself was the primary causal source.
Human action, error, decision or omission is established as a contributing or primary cause.
Human root cause should not automatically mean "technician error." The surrounding system conditions should also be examined.
The applicable procedure itself is missing, inadequate, incorrect, unclear or unsuitable.
Human root cause: person did not correctly perform the required process. Procedural root cause: the process/instruction itself was inadequate or unavailable.
Incorrect, incomplete, unavailable or outdated documentation contributes directly to the failure.
Software logic, programming, configuration or software behaviour is established as a root cause.
Failure of communication between equipment, controllers, networks or monitoring systems is established as a root cause.
The operating condition, operating practice or operational event is established as the primary cause.
The root cause cannot yet be established with sufficient evidence. This category is important because the database should not force a false root cause. Use "Unknown/Pending" when investigation is still underway.
Once sufficient evidence is obtained, update the RCA classification. Never force-fit a root cause the evidence does not yet support.
Used to progressively investigate why the failure occurred.
The final answer must be supported by evidence — not simply the fifth answer.
Also known as Ishikawa/cause-and-effect analysis. Used to identify possible causes across multiple categories.
When several potential causes exist and the team needs to systematically organize them before verification.
Works from the top-level failure downward to possible causal events.
Runway lighting outage → OR:
Then each branch can be further decomposed.
Analyzes how a component/system can fail and the effects of each failure mode. This can connect directly with the Failure Database and eventually support FMEA/FMECA-style reliability analysis.
Establishes the root cause using objective evidence.
RCA should be evidence-based rather than assumption-based.
Reconstructs the sequence of events before, during and after the failure.
This can reveal causal relationships that are missed when looking only at the final failure.
Identifies factors that did not independently cause the failure but increased its likelihood or severity.
Primary root cause: connector defect
Contributing factors:
Root Cause + Contributing Factors + Failure Mechanism = Complete RCA
Confirms that the proposed root cause actually explains the failure.
If the identified root cause is removed, does the failure mechanism disappear or materially reduce? If not, the RCA may be incomplete or incorrect.
Confirms that corrective action has actually eliminated or controlled the root cause.
Repeated connector failures caused by a sealing problem — Corrective action: improved sealing method → Verification: inspection + test → Monitoring: subsequent failure trend → Effectiveness: no recurrence over defined monitoring period.
Master workflow, data structure, status classification, RCA quality levels and cross-division linkage that apply across all 27 Division 21 root-cause and RCA-method topics.
Every Division 21 case should progress through the following twelve-step workflow, from identification through to lessons learned:
Lessons learned should feed back into SOPs, inspection checklists, maintenance plans, the Product Encyclopedia, training, design/specification and supplier evaluation.
This distinction is mandatory in the database — recording only the immediate cause is not an acceptable substitute for a root cause.
Failure: Runway edge light failed.
Immediate cause: LED driver failed.
Failure mechanism: Driver electronics overheated and failed.
Contributing factors: High ambient temperature; restricted heat dissipation.
Root cause: Product thermal design weakness.
Corrective action: Driver/product design improvement.
Verification: Monitor modified units for recurrence.
This structure is far stronger than simply recording "Root Cause: LED driver failure", because that only describes what failed, not why it failed.
| Status | Meaning |
|---|---|
| Open | RCA not started/completed |
| Under Investigation | Evidence collection underway |
| Cause Suspected | Preliminary cause identified |
| Cause Identified | Root cause technically established |
| Verification Pending | Root cause requires verification |
| Corrective Action Open | Corrective action being implemented |
| Effectiveness Pending | Implemented, effectiveness not yet established |
| Closed | RCA and corrective-action verification completed |
| Reopened | Failure recurred or RCA proved inadequate |
Level 1 — Suspected: evidence suggests a possible cause but is insufficient
Level 2 — Probable: multiple pieces of evidence support the cause
Level 3 — Verified: testing/inspection/evidence confirms the cause
Level 4 — Demonstrated: the failure mechanism has been reproduced or conclusively established
Particularly useful for tracking confidence on Unknown/Pending Root Cause cases as evidence accumulates.
Every RCA case should have a structured record containing at minimum:
Failure Identification
Failure Description
Investigation
RCA Classification
Verification
Corrective Action
Prevention
Closure
Division 21 functions as the analytical layer over the entire Failure Database. One failure can carry several linked classifications without duplicating the failure record — for example:
The most valuable part of Division 21 is the feedback loop that turns the Failure Database into a continuous reliability-improvement system rather than a simple failure record:
Divisions 01–20 classify what failed and where the failure occurred. Division 21 determines why the failure occurred, how the cause was established, and whether the corrective action actually eliminated the cause. It should never be used to force a root cause where evidence is insufficient — the Unknown/Pending category and the RCA confidence levels exist precisely to keep the database evidence-based rather than assumption-based, while still tracking every case through to a verified, closed corrective action.
Quick answers about root cause analysis in the AGL Failure Database, as covered in Division 21.
Division 21 is the analytical backbone of the database. It contains 27 published topics: 18 root-cause categories (RC-01 to RC-18) and 9 RCA methods (RM-01 to RM-09). It establishes why every failure occurred, how the cause was verified and whether corrective action eliminated it.
Electrical, mechanical, optical, thermal, environmental, installation, maintenance, design, manufacturing, material, component, human, procedural, documentation, software, communication and operational root causes, plus an Unknown / Pending root-cause category.
5-Why analysis, fishbone analysis, fault-tree analysis, failure-mode analysis, evidence analysis, timeline reconstruction, contributing-factor analysis, root-cause verification and corrective-action verification.
The distinction is mandatory: recording only the immediate cause is not an acceptable substitute for a root cause. For a runway edge light failure, the immediate cause is that the LED driver failed, the mechanism is driver electronics overheating, the contributing factors are high ambient temperature and restricted heat dissipation, and the root cause is a product thermal design weakness. Recording “LED driver failure” alone only describes what failed, not why.
Every case progresses through twelve steps: failure identification, failure classification, immediate cause, failure mechanism, contributing factors, root cause, RCA method, root-cause verification, corrective action, corrective-action verification, preventive action and lessons learned. Lessons learned should feed back into SOPs, inspections and related documents.
Status runs from Open through Under Investigation, Cause Suspected, Cause Identified, Verification Pending, Corrective Action Open and Effectiveness Pending to Closed, with Reopened used when the failure recurred or the RCA proved inadequate. Confidence has four levels: Suspected, Probable, Verified and Demonstrated, which is useful for tracking Unknown/Pending cases as evidence accumulates.
Division 21 should never be used to force a root cause where evidence is insufficient. The Unknown/Pending category and the RCA confidence levels exist to keep the database evidence-based rather than assumption-based.
Divisions 01–20 classify what failed and where. Division 21 determines why it failed, how the cause was established and whether corrective action eliminated it. One failure can carry several linked classifications without duplicating the failure record.
A root cause analysis is only as strong as the investigation behind it — real competence means understanding failure mechanisms well enough to trace symptom to cause with evidence, not just settle on the most convenient explanation.
Take that knowledge further with Precision AGL Academy.
Learn how to connect:
Develop structured knowledge across AGL fundamentals, components, electrical systems, testing, photometry, troubleshooting, maintenance and commissioning.
Find the failure. Understand the cause. Build the engineering skill.
Please read before relying on any content on this page or on any record downloaded from it.