Science Education Systems · Article 86. Maya, Jia Jun, Hana and Ethan are fictional learners used to make the reasoning visible. This article owns one distinct scientific job: failure analysis—working backward from an unwanted outcome to reconstruct the causal chain, distinguish initiating events from contributing conditions, test competing root-cause explanations and design corrective actions. It does not replace anomaly detection, general causality or decision-making; it begins after something has gone wrong.
The 50-second parent route
A weak postmortem asks: “Who caused this?” A stronger scientific investigation asks: “What sequence of states, interactions, decisions, conditions and failed barriers allowed this outcome to occur?”
The route is:
failure → preserve evidence → define expected state → timeline → failure mode → initiating event → contributing conditions → mechanism → root-cause hypotheses → counterfactual checks → corrective action → monitoring → recurrence test
The fastest diagnostic is to ask whether the proposed “root cause” explains why the failure occurred here and now, why safeguards did not stop it, and what change would reduce recurrence. If the answer is merely “human error,” “carelessness,” “bad data” or “equipment problem,” the analysis has probably stopped too early.
This article extends How Scientific Anomaly Detection Works, How Scientific Causality Works, How Scientific Mechanisms Work and How Science Decision-Making Works.
1. Failure analysis begins with a defined failure
“It failed” is too vague. What expected function, tolerance, outcome, performance level or safety condition was not achieved? Scientific investigation needs a reference state before it can reconstruct deviation. The better the failure definition, the less likely the investigation is to chase irrelevant details.
2. A failure is an outcome, not yet a cause
A machine stopped. A bridge inspection found unexpected damage. An experiment produced inconsistent values. A learner repeatedly failed transfer questions. Those are observations. Failure analysis begins by describing them accurately before assigning causal meaning.
3. Maya’s first error is jumping to blame
She sees a wrong laboratory result and says the student was careless. Her repair is to ask what procedure, instrument, environment, instruction, timing and quality-control conditions shaped the event. Human action belongs in the system, but blame is not a substitute for mechanism.
4. Jia Jun’s first error is choosing the first plausible cause
He finds one broken component and stops. His repair is to ask whether the component failed before the system outcome, whether it could produce the observed pattern, and why it failed. The first damaged part may be consequence, contributor or initiator.
5. Hana’s first error is collecting everything without hierarchy
She gathers logs, photos, interviews and measurements but cannot distinguish central evidence from background noise. Her repair is to organise evidence by timeline, component, causal hypothesis and confidence.
6. Ethan’s first error is searching only backward
He reconstructs the past beautifully but proposes no prevention. His repair is to carry the analysis forward: which corrective action targets the causal pathway, which monitor will show whether it worked, and what new failure mode could the fix introduce?
7. Preserve evidence before changing the system
Repair can destroy clues. Rebooting can erase logs. Cleaning can remove residues. Moving parts can change fracture surfaces or alignment. In everyday educational contexts, rewriting a student’s work can erase the original error path. Preserve the pre-repair state sufficiently before intervention.
8. Evidence preservation is proportional to stakes
A classroom experiment needs simple photographs, notes and measurements. A safety-critical engineering incident requires formal procedures and qualified investigators. The general principle is stable: preserve enough reliable information to reconstruct what occurred without creating unnecessary risk.
9. Establish the expected state
What should the system have done? Use design requirements, prior successful runs, control groups, calibration records, manufacturer specifications, scientific models or established performance baselines. Failure is deviation from an expectation, so the expectation must itself be defensible.
10. Establish the actual state
What happened, not what people assume happened? Separate direct measurements, contemporaneous logs and physical evidence from later recollection and interpretation. Memory is useful but can be reconstructed after an event.
11. Build a timeline
Before failure.
first deviation.
warning signal.
intervention.
escalation.
final outcome.
Temporal ordering prevents downstream consequences from being mislabelled as upstream causes.
12. Time synchronisation matters
Two logs may use clocks that differ by minutes. If sequence determines causality, unsynchronised timestamps can reverse the apparent order. Scientific failure analysis therefore treats time metadata as measurement data that may itself require calibration.
13. Define the failure mode
A failure mode describes how a component or function failed: leak, fracture, overheating, loss of signal, incorrect classification, missing data, unstable output, delayed response, contamination or another observable mode. The mode narrows the mechanism search.
14. Failure mode is not root cause
“The sensor drifted” describes what happened to the sensor. Why did it drift? Ageing, temperature, calibration lapse, contamination, software interpretation or another condition may be involved. Failure analysis keeps asking causal questions until corrective action becomes meaningful.
15. Initiating event is not always the deepest cause
A sudden load, software command or operator action may start the final sequence. But the system may have been vulnerable because maintenance, design margin, training, monitoring or barriers were already weak. The initiating event explains when; deeper conditions explain why the event became a failure.
16. Contributing conditions matter
Humidity.
fatigue.
ambiguous instructions.
poor visibility.
high workload.
component ageing.
missing redundancy.
No single condition may be sufficient, but together they can make failure much more likely.
17. Root cause is often plural
Complex failures rarely arise from one isolated cause. There may be technical, procedural, organisational and environmental contributors. The useful question is not “What is the one true cause?” but “Which causal factors were necessary, enabling, amplifying or preventable?”
18. The “five whys” can begin inquiry but not finish it
Asking why repeatedly pushes analysis beyond the surface. But a single why-chain can force a branching system into one line and encourage hindsight. Use it as a prompt, then build a causal network and test each branch against evidence.
19. Fault trees organise alternative pathways
Start with an unwanted top event and map combinations of lower-level conditions that could produce it. AND relationships require several conditions together; OR relationships allow alternative routes. The value is conceptual: it exposes multiple pathways instead of one favourite story.
20. Fault trees need evidence, not decoration
A branch should correspond to a plausible mechanism and available evidence. Adding dozens of possibilities without discriminating them creates complexity without knowledge. Each branch should invite a question: what observation would support or weaken this path?
21. FMEA looks forward rather than backward
Failure Modes and Effects Analysis asks how components might fail, what effects would follow, and how those failures might be detected or mitigated. It is preventive. Post-failure analysis can feed FMEA by adding failure modes learned from reality.
22. Failure analysis and FMEA form a loop
Prediction before failure identifies vulnerabilities. Investigation after failure reveals which predictions were right, which were missing, and which barriers failed. The updated design then receives a new preventive analysis.
23. Barrier analysis asks what should have stopped the sequence
Physical guards.
software limits.
checklists.
training.
independent verification.
alerts.
Why did the barrier not exist, not trigger, not reach the operator, or not stop the hazard?
24. A failed barrier can be more informative than the initiating error
People and components will sometimes err. Resilient systems anticipate that. When one ordinary mistake causes catastrophic outcome, the deeper design question is why no independent layer contained it.
25. Redundancy is only useful when failures are sufficiently independent
Two sensors using the same vulnerable power supply can fail together. Two reviewers trained on the same wrong rubric can agree perfectly and still be wrong. Common-cause failure defeats superficial redundancy.
26. Common-cause failure is a systems problem
Shared supplier.
shared calibration.
shared software.
shared environmental exposure.
shared assumption.
When redundant channels share one hidden dependency, apparent safety can be misleading.
27. Near misses are valuable evidence
A failure almost happened but a barrier caught it. Near misses reveal weak pathways before catastrophic outcomes occur. Organisations that collect only major failures discard a large source of learning.
28. Success can hide vulnerability
A system may appear reliable because skilled operators repeatedly compensate for design weaknesses. If the compensation is invisible, management assumes the process is inherently safe. Failure analysis should ask what routine adaptations were keeping the system working.
29. Normalisation of deviance is dangerous
A procedure exceeds a limit slightly, nothing bad happens, and the deviation becomes normal. Repeated success under unsafe conditions can create false confidence. Monitoring should distinguish “we got away with it” from “the condition is safe.”
30. Human error is usually a starting label
Pressed wrong button.
missed step.
misread display.
Why was the action likely? Similar controls? Poor interface? Ambiguous procedure? Fatigue? Inadequate feedback? Failure analysis asks how the system shaped the action.
31. Human factors are mechanism, not excuse
Attention, workload, perception, memory and interface design affect performance predictably. A system that requires perfect memory under stress is designed around an unrealistic human model. Scientific analysis incorporates actual human capability.
32. Hindsight bias distorts postmortems
After the outcome is known, warning signs look obvious. Before the event, the same signs may have been weak, noisy or ambiguous. Investigators should reconstruct what information was available to each person at the time, not what became obvious later.
33. Outcome bias distorts judgement
The same decision may be judged harshly when the outcome is bad and generously when the outcome is good. Failure analysis should assess decision quality using information available before the result.
34. Counterfactual reasoning tests candidate causes
If this factor had been different, would the failure probably still have occurred? If yes, the factor may be peripheral. If changing it would break the causal chain plausibly, it becomes a stronger corrective target.
35. Counterfactuals should be realistic
“If nobody ever made mistakes, the failure would not occur” is true but useless. A corrective counterfactual should be achievable: clearer display, independent check, appropriate maintenance interval, better monitoring or redesigned process.
36. Mechanistic consistency matters
A proposed cause should produce the observed failure mode through a plausible mechanism. If the fracture pattern, temperature history, data trace or error sequence contradicts that mechanism, the hypothesis weakens.
37. Pattern matching can discriminate causes
Different failure mechanisms often leave different signatures. The scientific task is to compare predicted signature with observed evidence, while remaining aware that several mechanisms can overlap or alter one another.
38. Replication can reproduce a failure safely at small scale
When appropriate and non-hazardous, recreate the suspected conditions in a controlled environment. If the same failure mode returns, mechanistic support grows. Safety limits and domain-specific expertise determine what can be reproduced.
39. Simulation can test failure hypotheses
A model can ask whether the proposed sequence is physically or logically capable of producing the observed outcome. Simulation is particularly useful when full-scale reproduction would be expensive, destructive or unsafe.
40. Simulation is not evidence by itself
A model reproduces the failure because assumptions were tuned to do so. Another model might reproduce it too. Simulation should be constrained by independent measurements and used to generate new discriminating predictions.
41. Worked case: inconsistent classroom experiment
Three groups perform the same cooling experiment. One group reports a much faster temperature drop. A weak conclusion says they “did it wrong.” Failure analysis preserves the readings, checks starting temperature, liquid volume, container type, thermometer position, timing, room location and recording method, then reconstructs which difference could produce the observed curve.
42. The first damaged data point is not necessarily the first cause
Suppose the temperature curve begins diverging after five minutes. The cause may have existed earlier: a loose sensor, different starting mass or delayed timer. Timeline and mechanism together prevent the first visible deviation from being mistaken for the initiating condition.
43. Corrective action should target the pathway
If inconsistent thermometer placement caused the variation, “be more careful” is weak. A better corrective action standardises placement visibly, adds a simple setup check and records sensor position. The fix changes the system, not merely the motivational message.
44. Worked case: repeated data-entry error
A research team repeatedly records values in the wrong unit. Investigation finds two forms with different unit labels, a conversion step performed manually and no automated range check. The root cause is not simply “typing error”; the workflow creates multiple opportunities for predictable conversion mistakes.
45. Corrective action should avoid creating new failure modes
Automating unit conversion can reduce manual error. But if metadata is wrong, automation can propagate the wrong conversion consistently. Every fix changes the system and deserves verification.
46. Worked case: a learner’s repeated Science failure
The learner loses marks on “explain why” questions. Blaming weak memory may be wrong. Error reconstruction shows the learner identifies the correct concept but skips the intermediate causal step. The first weak link is mechanism construction, so more vocabulary memorisation will not address the failure.
47. Educational failure analysis separates symptom from cause
Low score is the outcome. Possible contributors include concept gaps, representation difficulty, question reading, retrieval failure, mechanism weakness, answer precision, time pressure and careless transcription. A diagnostic should identify which pathway produced the mark loss.
48. Primary 3: describe before explaining
What happened first? What happened next? Which observation was unexpected? Young learners should learn to preserve the event sequence before guessing why it happened.
49. Primary 4: compare successful and failed runs
What was different? Same materials? same quantities? same timing? same position? Comparing a normal run with a failed run is a powerful route to causal discrimination.
50. Primary 5: add barrier thinking
What should have prevented the error? A label? checklist? control setup? repeated measurement? Students begin seeing reliability as a property of systems, not individual perfection.
51. Primary 6: add competing root causes
Give three plausible explanations for the same failed experiment. Ask what evidence supports each and which new measurement would discriminate them. The learner moves from blame to hypothesis testing.
52. Secondary Science: add causal networks
Students can map initiating events, contributing conditions, failed controls, propagation and outcome. They can distinguish proximate from root causes and evaluate whether corrective actions target the true pathway.
53. Failure analysis and anomaly detection are different
Anomaly detection says: this observation differs from expectation. Failure analysis asks: what sequence generated the deviation, why did controls fail, and what should change? Detection opens the case; analysis reconstructs it.
54. Failure analysis and causality are different
Causal inference is general. Failure analysis applies causal reasoning to a specific adverse or unacceptable outcome, often using timeline, physical evidence, logs and barrier structure.
55. Failure analysis and mechanism are inseparable
Root-cause hypotheses must explain how one state produced the next. A label such as “overload” is incomplete until the propagation mechanism is linked to the actual observed failure mode.
56. Failure analysis and monitoring form a loop
After corrective action, monitoring asks whether warning signals decline, performance stabilises and recurrence disappears. Article 87 follows that forward-looking layer.
57. Failure analysis and engineering design form a loop
Failures reveal assumptions the design did not handle. Engineering then updates requirements, margins, interfaces, tests and barriers. Article 88 follows the design layer.
58. Corrective action should be testable
“Improve awareness” is difficult to verify. “Add an independent unit check and measure unit-entry error rate over the next production cycle” defines an observable intervention and outcome. Scientific correction includes a recurrence test.
59. Corrective action hierarchy matters
Eliminate the failure pathway where feasible. Redesign to make error less likely. Add detection and containment. Train and remind when human action remains necessary. Reliance on memory alone is usually weaker than changing the system.
60. Corrective action can be local or systemic
Replace one failed component.
Or change the maintenance process that allowed many similar components to age unnoticed.
The appropriate scope depends on whether the cause is isolated or shared.
61. Root-cause confidence should be graded
Confirmed by direct evidence.
strongly supported.
plausible.
uncertain.
rejected.
Investigations should not convert uncertainty into certainty merely because action is required.
62. Multiple causal paths can remain possible
Sometimes evidence cannot uniquely identify one root cause. The honest conclusion may preserve two plausible pathways and choose corrective actions that reduce risk under both.
63. Bayesian updating can support failure hypotheses
Start with plausible failure modes based on prior history. New evidence changes their relative credibility. A distinctive trace can strongly favour one pathway. The process formalises learning as investigation proceeds.
64. Data provenance is essential
Which sensor produced this reading? Was the record edited? Did software transform the value? Is the time stamp local or server time? Failure analysis can collapse if evidence lineage is uncertain.
65. Missing data should be treated as a clue
A log is absent exactly during the failure window. That may be random system loss, power interruption, storage saturation or another process. Missingness itself can be mechanistically relevant.
66. Correlated failures reveal shared causes
Several components fail at nearly the same time. Independent random failure becomes less plausible. Search for common environment, shared dependency, common software, shared supply or systemic stress.
67. Cascading failures require network thinking
One component fails, load transfers, another component exceeds tolerance, and the failure propagates. The root cause may involve both the first event and the architecture that allowed propagation.
68. Resilience asks whether the system can fail gracefully
Not every component can be made perfect. Resilient design detects problems early, isolates damage, preserves core function and supports recovery. Failure analysis should ask how the system behaved after the first fault, not only why the first fault happened.
69. Recovery is part of the failure story
How quickly was the problem detected? Was the system brought to a safe state? Was evidence preserved? Did communication reach the right people? Recovery performance can reveal strengths worth keeping.
70. Postmortems should identify what worked
A monitoring alarm succeeded. A teacher noticed a misconception early. A backup instrument preserved data. A reviewer caught the wrong unit. Understanding successful barriers prevents “fixing” the parts that already protected the system.
71. A no-blame culture is not a no-accountability culture
Scientific investigation should avoid premature personal blame because blame narrows evidence gathering. Accountability can still exist where duties were neglected. The sequence matters: understand the system and evidence first, then make proportionate judgments.
72. Independent review can reduce confirmation bias
The team that built a system may prefer explanations that preserve its assumptions. Independent investigators can challenge the favoured story, ask for missing evidence and test rival causal paths.
73. AI can accelerate failure reconstruction
AI can summarise logs, cluster similar incidents, compare timelines, search maintenance records and generate competing hypotheses. This is useful when evidence volume is large.
74. AI can also create a convincing false root cause
A language model can weave scattered facts into a coherent story even when timestamps or mechanisms do not support it. Investigators should require source-linked evidence for each causal step.
75. AI needs evidence provenance
If an AI summary says “sensor drift caused the failure,” the investigator should be able to inspect which records support drift, when drift began, and whether alternative causes were excluded. Untraceable conclusions should remain hypotheses.
76. AI can help generate counterfactual tests
Useful prompts include: “What evidence would be expected if Cause A were true but Cause B were false?”, “Which event in this timeline is consequence rather than cause?”, “What barrier should have interrupted this path?”, and “What corrective action would distinguish the hypotheses?”
77. AI incident databases need careful deduplication
Ten reports may describe one underlying event. Counting them as ten independent failures inflates prevalence. Provenance and entity resolution matter before pattern mining.
78. Independent-attempt task 1: build the timeline
Take a familiar failed experiment or learning task. Write only observable events in chronological order. Do not use causal words yet. Then mark the first deviation from expected state.
79. Independent-attempt task 2: build three cause trees
Create three different explanations capable of producing the same failure. For each, list the evidence that should exist if it is correct. The purpose is to prevent the first plausible story from becoming destiny.
80. Independent-attempt task 3: find the failed barrier
Ask what should have detected, prevented or contained the problem. If no barrier existed, that absence is part of the causal architecture. If one existed, explain why it did not function.
81. Independent-attempt task 4: design the recurrence test
Propose one corrective change. Define the monitoring signal that should improve if the proposed root cause is correct. If the signal does not change, the hypothesis or fix may be wrong.
82. Diagnostic error: single-cause story
The investigation has one arrow from “operator error” to “failure.” Repair by adding conditions, barriers, timing and mechanism. Complex failures usually need a network.
83. Diagnostic error: consequence labelled cause
A component overheats after another subsystem fails. The heat damage is visible, so the analyst calls it the cause. Timeline repair shows it occurred after the initiating event. Sequence protects causality.
84. Diagnostic error: corrective action too vague
“Be careful.” “Train more.” “Monitor closely.” These phrases may be part of a response but are difficult to test. Strong corrective action specifies which causal pathway changes and which measurable outcome should improve.
85. Diagnostic error: fixing the symptom only
Replace the broken part repeatedly without asking why it breaks. Symptom repair restores function; root-cause correction reduces recurrence. Both may be needed, but they are not the same job.
86. Diagnostic error: overconfidence
Evidence supports two plausible causes, yet the report declares one certain. Repair by grading confidence and listing discriminating evidence still missing. Scientific uncertainty can coexist with practical action.
87. The parent version of failure analysis
A child scores poorly. Do not begin with “didn’t study enough.” Preserve the marked paper. Identify where marks were lost. Reconstruct whether the first failure was reading, recall, representation, mechanism, calculation, precision or timing. Then target the earliest weak link that explains downstream errors.
88. The tutor version
Use one failed question as a trace. Ask the learner to reattempt without help. Compare original and new reasoning. Introduce one discriminating prompt at a time. The goal is to locate the failure transition, not to complete the answer for the learner.
89. The examination-performance version
After a practice paper, classify errors by mechanism rather than chapter alone. Two wrong questions from different topics may share the same underlying failure: unit conversion, variable confusion, skipped causal step or misread command word. Repairing the mechanism can improve several topics at once.
90. A compact failure-analysis checklist
- What exactly failed relative to what expectation?
- What evidence must be preserved before repair?
- What is the reliable timeline?
- What was the first observable deviation?
- What failure mode occurred?
- What initiating events are plausible?
- What contributing conditions increased vulnerability?
- Which barriers should have prevented or contained the event?
- Why did those barriers fail?
- What mechanism connects the candidate cause to the outcome?
- What rival causal paths remain?
- What counterfactual would break each path?
- Which evidence is direct, inferred or missing?
- What corrective action changes the pathway?
- What monitor will show whether recurrence risk falls?
91. Frequently asked questions
What is scientific failure analysis?
It is the structured reconstruction of an unwanted outcome to identify failure modes, causal pathways, contributing conditions, failed barriers and corrective actions using evidence rather than hindsight alone.
Is root cause always one thing?
No. Complex failures often arise from interacting technical, human, environmental and organisational factors.
Is human error a root cause?
Sometimes a human action is an important causal event, but strong analysis asks what system conditions made the action likely and why barriers did not contain it.
How is failure analysis different from anomaly detection?
Anomaly detection identifies that something deviates from expectation. Failure analysis reconstructs how and why the deviation became a failure and what should change.
How does failure analysis help PSLE Science?
It teaches students to preserve observations, compare successful and failed trials, identify changed conditions and distinguish evidence from explanation.
How does it deepen in Secondary Science?
Students can use causal networks, mechanisms, timelines, uncertainty, barrier analysis and corrective-action testing more explicitly.
92. Continue the Science Education Systems series
- How Scientific Mechanisms Work
- How Scientific Monitoring Works
- How Scientific Engineering Design Works
- How Scientific Anomaly Detection Works
Conclusion: Failure is evidence if the system is willing to learn from it
Maya sees the broken outcome.
Jia Jun builds the timeline.
Hana challenges the first root-cause story.
Ethan designs the corrective action and asks how they will know it worked.
Science needs all four.
Preserve the evidence.
define the failure.
reconstruct the sequence.
separate initiator from conditions.
find the failed barriers.
test competing mechanisms.
change the pathway.
monitor recurrence.
Then allow failure to become something more useful than blame: a map of where the system can be made stronger.
