The master database layer and final integration division of the AGL Failure Database. Division 25 is not another failure category — it is the controlled information architecture that connects every failure, investigation, evidence item, corrective action, reliability result and engineering lesson captured across Divisions 01–24. Its architecture: Failure Record → Evidence → Classification → RCA → Severity → Reliability → Corrective/Preventive Action → Knowledge → Related Records.
Key principle — Division 25 should not be viewed as merely an Excel register. It is the master information layer connecting the entire AGL Failure Management System: Divisions 01–20 supply the failure classification, Division 21 the root cause, Division 22 the severity & criticality, Division 23 the reliability & trends, and Division 24 the corrective action, preventive action & lessons learned. Division 25 binds all of it into one traceable Master Failure Record.
A unique identifier assigned to every failure, e.g. AGL-F-2026-0001. The exact numbering convention can be standardised separately, but every failure receives exactly one master record.
The Failure ID is the primary key linking RCA, evidence, maintenance, testing, corrective action, preventive action, reliability analysis, lessons learned and related failures into one traceable chain.
Records the equipment or system involved in the failure, plus identifying detail where appropriate.
Anchors the failure to a specific asset class and, where identified, a specific physical unit — enabling equipment-level and fleet-level reliability analysis.
Records the applicable airport/project information, subject to required access and confidentiality controls. The source framework explicitly qualifies this field with "if permitted."
Access restrictions and information-sharing permissions must be respected before airport/project identity is recorded or disclosed in any record, report or case study.
Records the date of failure, together with the surrounding time markers that establish the failure's timeline.
Provides the temporal foundation for Division 23 reliability analysis — MTBF, MTTR, downtime and repeat-failure interval all depend on this field being captured accurately.
Records the operating conditions at or around the time of failure — essential context for any failure that is intermittent, thermal, environmental or electrical in nature.
Particularly important when investigating intermittent failures, thermal failures, environmental failures, electrical failures and operational incidents — conditions that leave no physical trace.
Records what was observed when the failure was detected — kept strictly separate from root cause to prevent premature conclusions.
Symptom is the starting point of the investigation, not its conclusion. Example: "Runway light not operating" is a symptom — not yet an observation or a cause.
Records the first technical observations made during inspection or troubleshooting — the step between symptom and root cause.
Distinguishes three stages explicitly: Symptom ("Runway light not operating") → Initial observation ("Moisture observed inside fixture") → Root cause (to be established through RCA).
Links the failure record directly to Division 21. Captures the full causal chain from immediate cause through to root cause, with the evidence supporting the conclusion.
Example chain — Failure: fixture outage → Immediate cause: LED driver failure → Failure mechanism: thermal deterioration → Contributing factor: elevated operating temperature → Root cause: design/thermal issue, if supported by evidence.
Links directly to Division 24. Records what was actually done to restore the equipment or system to service.
Corrective action closes the immediate failure; it is distinct from, and a prerequisite to, preventive action, which addresses recurrence.
Records the action taken to prevent recurrence of the failure — the mechanism through which RCA findings feed back into standards, design and practice.
Completes the connection Failure → RCA → Preventive Action — without this link, RCA findings never change future outcomes.
Records the applicable technical/regulatory standards or requirements associated with the failure. The database records the specific applicable reference, not merely a body name.
A reference such as "ICAO Annex 14, Vol I" is required — a bare "ICAO" or "FAA" entry does not meet the intent of this field.
Links the failure to the relevant product/component record — LED fixture model, LED driver, isolation transformer, connector, cable, CCR, PAPI unit, sign.
Creates the connection to the AGL Product Encyclopedia / Product & Component Reliability system, enabling product-level failure-rate analysis.
Links relevant engineering drawings, with the drawing revision that was applicable at the time of failure explicitly identified.
Revision control matters: the record should identify the drawing revision used or applicable at the time of failure, not simply the current drawing.
Links applicable procedures — inspection, maintenance, testing, installation, alignment and emergency-response SOPs.
Allows the database to determine whether the failure exposed a procedure weakness or a procedural non-compliance — a key preventive-action trigger.
Links similar historical failures or engineering cases, so an engineer facing a new failure can immediately ask: have we seen this failure before?
The database should surface related records automatically rather than relying on an engineer's memory of past incidents.
Links the lessons captured in Division 24 — the mechanism through which knowledge from this specific failure is retained for future projects.
A failure record without a lessons-learned link is closed but not yet converted into reusable engineering knowledge.
Records supporting references used during the investigation — the source documents behind every conclusion in the record.
Every reference cited in the RCA or corrective/preventive action should trace back to a document listed here.
Every significant change to the failure record should be traceable — particularly important for technically controlled failure information.
Typical progression: Rev 0 — failure created → Rev 1 — RCA added → Rev 2 — corrective action added → Rev 3 — closure/effectiveness verification.
Stores photographs showing the failure condition, with metadata sufficient to establish provenance and context.
Recommended metadata: Failure ID, date, location, photographer, description, before/after status — without this, a photograph cannot be reliably linked back to its record.
Records measured technical values taken during investigation, retaining the original test record rather than only a summarized value where possible.
Where possible the original test record — not just a transcribed number — should be retained, preserving traceability back to the instrument and test conditions.
Stores detailed measurement information, always paired with the context needed to interpret the value correctly.
Every measurement should record value + unit + instrument + date + condition where applicable — a bare number is not sufficient evidence.
Links inspection records associated with the failure, helping establish whether the defect was already present before the failure occurred.
Answers a critical investigative question: was the defect already present before the failure, and if so, was it detectable at the time?
Links relevant maintenance history to the failure — essential for identifying repeat failures on the same asset.
Maintenance history is essential reliability evidence — it is the primary source for identifying repeat failures against Division 23's repeat-failure analysis.
Captures system-generated information, establishing sequence and timing — particularly important for intermittent or control-system failures.
Event logs can establish sequence and timing objectively, independent of what an operator recalls or reports — critical for control-system RCA.
Links relevant photometric information, particularly valuable for detecting degradation before complete failure.
Photometric trend data can reveal degradation well before a fixture fails outright — a leading indicator that a bare pass/fail test would miss.
Links formal test reports relevant to the failure, from factory acceptance through to functional and integration testing.
Formal test reports provide the documented, signed-off evidence trail that a bare reading in the field cannot substitute for.
Distinguished from general failure photographs — provides close-up evidence of the specific damage mechanism at the component level.
These close-up images become valuable evidence for future RCA and for product-level reliability analysis across similar components.
Stores the evidence specifically used to establish the root cause — the objective basis on which the RCA conclusion rests.
Critical principle: the RCA conclusion should be traceable to its supporting evidence — a root cause without linked evidence is an unsupported opinion.
Records evidence demonstrating what was actually repaired, distinct from what corrective action was merely planned or reported.
Repair evidence closes the gap between the corrective action recorded in the failure record and what was physically done in the field.
Confirms that the corrective action actually worked, completing the technical evidence chain from failure through to verified restoration.
Completes the chain: Failure Evidence → RCA Evidence → Repair Evidence → Post-Repair Evidence — a failure is not truly closed until this evidence exists.
Every failure receives a standardised classification, aligned with the category divisions established earlier in the Failure Database (01–20).
Standardized classification is the entry point for every statistical query — it must be applied consistently to be useful.
Assigns a standardised failure-mode tag describing how the equipment failed, enabling rapid searching and statistical analysis.
Failure-mode tags are what make it possible to answer "how many LED driver failures did we have this year" in seconds rather than by manual review.
Links to the RCA cause classification from Division 21, categorizing why the failure occurred at the systemic level.
Directly connects Division 25 records to Division 21's root-cause taxonomy, keeping cause classification consistent across the whole database.
Links to Division 22's severity classification, indicating how serious the failure was from an engineering standpoint.
Severity tagging supports prioritisation of both immediate response and longer-term reliability investment.
Records the safety impact of the failure, enabling rapid identification of safety-related failures across the whole database.
Safety-impact tagging must be applied independently of operational-impact and severity tagging — a low-severity failure can still carry meaningful safety risk.
Records the operational impact of the failure, supporting operational prioritisation alongside safety-impact tagging.
Feeds directly into downtime and repair-time prioritisation decisions made at the operational level.
Tags the environmental condition associated with the failure, allowing correlation between environmental conditions and failure occurrence.
Environmental correlation is one of the most powerful outputs of the intelligence layer — it can reveal seasonal or climate-driven failure patterns invisible in a single record.
Classifies repair duration into standardised bands, with exact time thresholds to be standardised separately.
Standardized repair-time bands make it possible to compare repair performance across equipment types and technicians without exact-duration noise.
Classifies system/equipment downtime resulting from the failure, always backed by the actual downtime value recorded elsewhere in the record.
The downtime tag must be backed by an actual downtime value — it is a classification of a measured quantity, not a standalone judgement.
Identifies whether the failure has occurred previously on the same or comparable equipment — directly linked to Division 23's repeat-failure analysis.
A failure tagged as chronic should automatically trigger a preventive-action review rather than another routine corrective action.
Classifies how easily the failure could have been detected before it became a full failure — particularly useful for identifying hidden reliability risks.
Failures tagged latent or intermittently detectable are the strongest candidates for inspection-checklist or testing-procedure revision.
Assigns a reliability classification to the failure, based on defined criteria rather than subjective judgement.
Defined criteria — not ad hoc judgement — keep this tag consistent and statistically meaningful across the whole failure population.
Links similar or connected failures, allowing engineers to identify patterns immediately rather than rediscovering them independently.
Example: Failure F-001 (LED driver failure) links to F-014 (same model), F-027 (same airport), F-041 (same batch) and F-063 (same root cause).
Links the appropriate troubleshooting guide from the Troubleshooting Atlas, converting the failure record into a practical engineering tool.
This is the link that turns a historical record into something a technician can actually use in the field the next time a similar fault appears.
Links the relevant maintenance SOP from the Maintenance Handbook, connecting the failure back to the procedure meant to prevent or catch it.
Allows an engineer reviewing a maintenance procedure to ask: what failures caused this procedure to be revised?
Links the inspection checklist that should detect the failure, creating a feedback mechanism between failures and inspection scope.
Creates the key feedback question: was the defect detectable through the existing inspection checklist — and if not, should the checklist change?
Links the test procedure capable of detecting or confirming the failure, from the Testing & Commissioning Manual.
Ensures every failure mode has at least one identified test capable of catching it before it reaches full failure.
Links the failure to a detailed engineering case study, transforming an individual failure record into reusable engineering knowledge.
The case study is the final output of the traceability chain — a complete, standalone narrative built entirely from linked record fields.
How the 48 fields work together as a single Master Failure Record, and how Division 25 binds Divisions 01–24 into one traceable system.
A mature Division 25 record moves through ten stages, each drawing on a specific group of fields:
Identify (Failure ID + Equipment + Location + Date) → Describe (Operating Conditions + Symptoms + Initial Observations) → Investigate (Evidence + Testing + Inspection + Maintenance History) → Diagnose (Failure Classification + Failure Mode + RCA) → Assess (Severity + Safety Impact + Operational Impact + Detectability) → Correct (Corrective Action + Repair + Retesting) → Prevent (Preventive Action + SOP/Design/Training/Product Improvement) → Learn (Lessons Learned + Case Study) → Analyse (Reliability Category + Repeat Occurrence + Related Failures) → Close (Post-Repair Evidence + Effectiveness + Revision History).
Division 25 establishes complete bidirectional traceability. Read forward, a single failure resolves into a full engineering chain:
The same links must also work in reverse, so that any node in the system can answer a practical engineering question:
From an SOP: Which failures caused this SOP to be revised?
From a product: What failures have occurred with this product?
From a component: What is its failure rate, repeat-failure history and RCA?
From a failure: What procedure should I use to troubleshoot and repair it?
The overall AGL Failure Knowledge System, expressed as one continuous chain:
Divisions 01–20 → Failure Classification
Division 21 → Root Cause
Division 22 → Severity & Criticality
Division 23 → Reliability & Trends
Division 24 → Corrective Action, Preventive Action & Lessons Learned
The 18 standardised tags (INT-31 to INT-48) that convert individual records into searchable engineering knowledge:
The fundamental purpose of Division 25 is to ensure that every AGL failure becomes a controlled, traceable, evidence-supported and reusable piece of engineering knowledge. It functions as the master information layer connecting the entire AGL Failure Management System, giving a complete architecture: what failed → why it failed → how serious it was → what the trend shows → what we did → what we learned → what we must do differently next time. That is a Failure Knowledge Base — an intelligence system, not simply a failure log.
Quick answers about the master failure record, evidence database and intelligence layer, as covered in Division 25 of the AGL Failure Database.
Division 25 is the master database layer and final integration division. It defines the 18-field Standard Failure Record, the 12-part Evidence Database and the 18-tag Intelligence Layer, 48 fields in total, connecting every failure, RCA, corrective action and reliability result across Divisions 01–24.
Failure ID, equipment/system, airport/project (if permitted), failure date, operating conditions, symptoms, initial observations, root cause analysis, corrective action, preventive action, applicable standards, related products, related drawings, related SOPs, related case studies, lessons learned, references and revision history.
Twelve evidence types: failure photographs, test readings, measurement records, inspection records, maintenance records, alarm and event logs, photometry records, test reports, damaged-component photographs, RCA evidence, repair evidence and post-repair test evidence.
It consists of 18 standardised tags (INT-31 to INT-48) that convert individual records into searchable engineering knowledge. They cover classification, failure mode, cause, severity, safety impact, operational impact, environmental condition, repair time, downtime, repeat occurrence, detectability and reliability category, plus links to related failures, troubleshooting, maintenance, inspection, testing and case studies.
Ten stages: identify, describe, investigate, diagnose, assess, correct, prevent, learn, analyse and close. Each draws on a specific group of fields, from failure ID, equipment, location and date at the start to the reliability analysis and closure at the end.
Read forward, a failure record resolves into a full chain of evidence, RCA, root cause, severity, corrective action, test report, preventive action, SOP revision, lessons learned and reliability trend. Read in reverse, an SOP can show which failures caused its revision, a product can show its failures, a component can show its failure rate and RCA, and a failure can point to the procedure for troubleshooting and repair.
Divisions 01–20 supply failure classification, Division 21 the root cause, Division 22 severity and criticality, Division 23 reliability and trends, and Division 24 corrective action, preventive action and lessons learned.
It ensures every AGL failure becomes a controlled, traceable, evidence-supported and reusable piece of engineering knowledge, answering what failed, why, how serious it was, what the trend shows, what was done, what was learned and what must be done differently next time.
A well-kept failure record proves what happened — but real failure intelligence comes from connecting records across divisions to spot patterns before they become recurring problems, not just archiving them for reference.
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.