Failure Analysis¶
A retrospective engineering investigation that uses a failed physical item's evidence and service context to test explanations of how and why it failed.
Core Idea¶
Failure analysis is a retrospective engineering investigation of a physical item or structure that has failed or apparently failed. It relates the observed loss of function to physical traces, design or construction records, actual service conditions and competing mechanism hypotheses, then states what the evidence supports and what remains uncertain. NASA's component investigations and NIST's structural investigations show this evidence-to-explanation pattern in unlike settings.[ref-8f87fa046516][ref-ff51f833eb35][^ref-33f57c36aa6d]
Scope of Application¶
The method occurs in metallurgy, electronics, mechanical systems and structural investigations. NASA JPL's ASIC guide warns that an apparent chip failure may arise in neighboring circuitry or operating conditions. NASA Kennedy describes both mechanical and electrical component analyses; NTSB's I-35W bridge finding connects a failed structural member to design and loading history. This entry deliberately covers those physical-engineering settings, without claiming that software incident review cannot share the wider phrase.[ref-8f87fa046516][ref-33f57c36aa6d][^ref-e4e8db1ce1f0]
Clarity¶
Separate failure mode (how function was lost), physical mechanism (how damage arose) and enabling conditions (why it occurred in this design and service history). Do not infer a single root cause from a visible mark. FMEA is different: it prospectively enumerates possible modes and risks, while failure analysis starts from one observed case. The live FMEA prime currently carries “failure analysis” as an alias; this is a lexical collision requiring review, not a semantic duplicate.
Manages Complexity¶
Investigators use physical and documentary evidence to compare alternatives rather than read one signature as self-explanatory. Examinations may alter specimens, so preservation and discriminatory value must be considered together; there is no universal nondestructive-before-destructive rule. NIST describes combining both kinds of testing and quantifying uncertainty. Recommendations are outputs in some institutional settings; legal responsibility is a separate judgment.[ref-ff51f833eb35][ref-8f87fa046516][^ref-e4e8db1ce1f0]
Abstract Reasoning¶
Ask what was expected, what departed, which physical mechanisms could produce that departure, and what each predicts about the available traces and history. Test those predictions against other plausible explanations and report the inference at its supported confidence. In a complex system, an immediate broken element may have upstream design or load contributors; a technical finding should not silently become an unsupported blame judgment.[ref-8f87fa046516][ref-e4e8db1ce1f0][^ref-ff51f833eb35]
Knowledge Transfer¶
JPL's electronics case and NTSB's bridge case share observed departure → context and evidence → alternative mechanism/condition tests → bounded finding. Their tools, physics and institutional outputs differ. The proposed live parent is Diagnostic Method, a method of evidence-to-fault inference; FMEA, Fault Tree Analysis and Reverse Engineering are neighbors with different questions.
[^ref-8f87fa046516]: NASA Jet Propulsion Laboratory, “Appendix Four: Failure Analysis”, original ASIC documentation, opening definition, Major Tasks and Laboratory Work Flow. [^ref-e4e8db1ce1f0]: National Transportation Safety Board, “Collapse of I-35W Highway Bridge,” HWY07MH024, completed investigation, “What We Found.” [^ref-ff51f833eb35]: Tanya Brown-Giammanco, “NIST’s Investigations of Structural Disasters”, original NIST investigator account, evidence and alternative-hypothesis paragraphs. [^ref-33f57c36aa6d]: NASA Kennedy Space Center, “Material Analysis Laboratory Overview”, original facility Overview.
Relationships to Other Abstractions¶
Current abstraction Failure Analysis Domain-specific
Parents (1) — more general patterns this builds on
-
Failure Analysis is a kind of Diagnostic Method Domain-specific
Physical failure analysis specializes diagnostic evidence-to-fault inference to an already observed engineered-item failure.
Hierarchy path (1) — routes to 1 parentless root
- Failure Analysis → Diagnostic Method
Neighborhood in Abstraction Space¶
Failure Analysis sits in a sparse region of the domain-specific corpus (70th percentile for distinctiveness): few abstractions share its structure, so a faithful description tends to retrieve it precisely.
Family — Software & Systems Architecture (29 abstractions)
Nearest neighbors
- Reset (military) — 0.84
- Glitch Art — 0.84
- Engineering Critical Assessment — 0.84
- Function (engineering) — 0.84
- Aviation accident analysis — 0.83
Computed from structural-signature embeddings · 2026-10-08