If You Can’t Explain It to a Five-Year-Old

Root Cause Analysis Without the Magic: How Many Causes Can Exist, How Deep You Must Dig, and Why Simplicity Is the Test of Understanding

May 21, 2026

Root Cause Analysis Without the Magic: How Many Causes Can Exist, How Deep You Must Dig, and Why Simplicity Is the Test of Understanding

Taking the Mystery Out of How a Forensic Engineer Reaches a Conclusion

A five-year-old asks why the car crashed. You say the driver did not stop. The child asks why. You say the driver did not see the other car. The child asks why. You say a tree was blocking the view. The child asks why. You say nobody cut the tree back. The child asks why. You say the people responsible for the road did not do their job.

The child understood every answer. No jargon. No acronyms. No references to coefficient of friction, delta-V, principal direction of force, or barrier-equivalent velocity. Just a chain of causes, each one leading to the next, each one simple enough that a kindergartner could follow it and ask the next question. By the fifth “why,” the child has arrived at a root cause that a team of engineers, attorneys, and adjusters spent six months identifying.

This is not a coincidence. It is a diagnostic. If the forensic engineer cannot explain the root cause of a failure in terms that a non-technical person can follow—without simplifying the conclusion into inaccuracy but without burying it under technical complexity—the engineer does not yet fully understand the failure. Complexity in explanation almost always signals incompleteness in understanding. The engineer who resorts to jargon at trial is not demonstrating expertise. They are demonstrating that the causal chain has not been traced far enough, validated thoroughly enough, or understood deeply enough to be expressed in its simplest true form.

This principle has profound implications for how forensic conclusions are reached, how many root causes can coexist, and how attorneys should evaluate whether an expert’s conclusion is genuinely sound. What follows strips the magic out of root cause analysis and replaces it with a process that is rigorous, transparent, and—when done correctly—simple enough to explain to anyone.

What Root Cause Actually Means: Clearing the Fog

The term “root cause” is among the most misused phrases in forensic engineering and litigation. It is invoked as though it were a single, definitive answer—the one thing that caused the accident, the silver bullet that assigns blame, the conclusion that ends all debate. This understanding is wrong, and the misunderstanding leads to expert testimony that oversimplifies complex events, misleads triers of fact, and collapses under competent cross-examination.

A root cause is not the cause. It is a cause—the deepest cause in a specific causal chain that the investigation can identify and that a corrective action could address. This definition contains three critical qualifiers that most people miss.

The Deepest Cause in a Specific Chain

Every accident involves a chain of events. The root cause is not the proximate event—the final event that immediately preceded the harm—but the underlying condition that initiated or enabled the chain. The proximate cause of a collision may be that Vehicle A entered the intersection against a red light. The root cause may be that the driver was distracted by a cell phone. Or that the driver’s employer required them to answer calls while driving. Or that the traffic signal was obscured by overgrown vegetation. Or that the brake system had a pre-existing deficiency that prevented adequate deceleration. Each of these is a different root cause operating through a different causal chain, and each has different implications for liability.

The depth to which the engineer traces the chain is a judgment call guided by two constraints. First, the engineer must trace deep enough to identify a cause that is actionable—a condition that someone had the ability and responsibility to prevent. A root cause of “gravity exists” is technically accurate for every fall-from-height accident and technically useless for every investigation. Second, the engineer must trace only as deep as the evidence supports. A root cause that requires speculation about conditions not documented in the evidentiary record is not a root cause. It is a hypothesis.

The Investigation Can Identify

Root cause analysis is constrained by the available evidence. The investigation may be able to determine that the brake system was deficient but unable to determine whether the deficiency resulted from manufacturing error, improper maintenance, or owner abuse—because the physical evidence was destroyed before examination. In that case, the root cause of the brake deficiency is as deep as the investigation can go. The engineer reports the brake deficiency as the identified root cause and discloses the evidence limitation that prevents tracing deeper. This is honest analysis. Speculating beyond the evidence to assign a more specific cause is not.

A Corrective Action Could Address

This qualifier separates root cause analysis from academic exercise. A root cause is useful only if it identifies a condition that could have been prevented or corrected. The engineer asks: if this cause had been eliminated, would the accident have occurred? If the answer is no—if removing the cause breaks the chain—the cause is a root cause. If the answer is “the accident might still have occurred through an alternative chain”—the cause is a contributing factor, not a root cause. The distinction matters for liability allocation, and it matters for the clarity of the expert’s testimony.

How Many Root Causes Can Exist: The Answer Is Almost Always More Than One

This is where most forensic analyses go wrong, and where the five-year-old’s relentless questioning reveals what the expert’s methodology sometimes misses. An accident is rarely caused by a single failure. It is caused by the convergence of multiple failures—each one independently insufficient to produce the event, but collectively sufficient when they align in time and space. The forensic engineer who identifies only one root cause has either investigated only one causal chain or has arbitrarily stopped digging on the others.

A short note before the break. Inventor's Mind is free, and subscribing stays free — no payment, no upsell, just an email. The break exists for one reason: feedback. Subscriptions are the cleanest signal a writer gets about what landed and what did not. Page views measure traffic. Subscriptions measure trust.

I am moving the second half behind a free sub so the columns that earn the trust can be measured against the ones that did not, and the next column can be sharper than the last. Please stay with me — subscribe so I can tune in to what you need. Thank you for reading.

The Swiss Cheese Model and Forensic Reality

James Reason’s Swiss cheese model of accident causation remains the most useful conceptual framework for understanding how multiple root causes coexist. Every system has layers of defense—design safeguards, maintenance protocols, operator training, warning systems, regulatory requirements. Each layer has holes—deficiencies, omissions, or failures that allow a hazard to pass through. An accident occurs when the holes in multiple layers align simultaneously, creating a continuous path from hazard to harm.

Translated into forensic vehicle analysis: a driver runs a red light and collides with a vehicle in the intersection. The proximate cause is running the red light. But the investigation reveals that the driver was fatigued because their employer required a 16-hour shift in violation of company policy. The traffic signal had a short yellow phase that did not meet the MUTCD standard for the approach speed. The struck vehicle’s side-impact airbag did not deploy because of a known sensor deficiency that was the subject of a recall the owner never completed. The intersection lacked a protected left-turn phase that the traffic study recommended three years earlier.

How many root causes exist in this scenario? At least four, operating through four independent causal chains: employer negligence in scheduling, municipal negligence in signal timing, manufacturer defect in the airbag system, and owner negligence in recall compliance. Each one independently contributed to either the occurrence of the collision or the severity of the outcome. Eliminating any one of them might have prevented the accident or reduced the harm. The forensic engineer who reports only “the driver ran a red light” has identified the proximate cause and missed every root cause behind it.

Concurrent Root Causes vs. Contributing Factors

Not every condition present at the time of an accident is a root cause. The forensic engineer must distinguish between concurrent root causes—conditions that independently and necessarily contributed to the occurrence or severity of the event—and contributing factors—conditions that increased the probability or severity of the event without being independently sufficient to cause it.

The distinction is tested by the elimination question. If this condition had not existed, would the accident still have occurred in the same manner and with the same severity? If the answer is no, the condition is a root cause. If the answer is “yes, but it would have been less likely or less severe,” the condition is a contributing factor. Both are relevant to the investigation. Both should be reported. But they carry different analytical weight and different legal implications.

A wet road surface is a contributing factor in a loss-of-control accident. It increased the probability of the event by reducing available friction. But vehicles navigate wet roads successfully millions of times daily. The wet surface alone did not cause the accident. The driver’s excessive speed for the conditions, combined with the wet surface, produced the loss of control. The excessive speed is the root cause. The wet surface is a contributing factor. The forensic engineer who lists “wet road” as a root cause has confused a background condition with a causal agent.

Location-Specific Root Causes: The Intersection Problem

Certain locations accumulate accidents because multiple root causes are embedded in the location itself. An intersection with a documented history of collisions may exhibit a combination of geometric deficiencies—inadequate sight distance, substandard lane width, confusing lane alignment—compounded by operational deficiencies—signal timing that does not account for the approach speed, inadequate signage, missing pavement markings. Each deficiency is an independent root cause, and the location’s accident history is the cumulative result of multiple deficiencies enabling multiple accident types over time.

For the forensic engineer investigating a specific accident at such a location, the challenge is to identify which of the location’s multiple deficiencies actually contributed to the specific event—not to catalog every deficiency present. A sight-distance obstruction that is relevant to a left-turn collision may be irrelevant to a rear-end collision at the same intersection. The root cause analysis must be specific to the event, even when the location provides a menu of potential causes. The five-year-old’s why-chain for this specific accident leads to specific answers, not to a comprehensive infrastructure audit.

The Temporal Dimension: Root Causes That Existed Before the Event

Some root causes were established days, months, or years before the accident occurred. A design deficiency was embedded when the vehicle was engineered. A maintenance deficiency accumulated over thousands of miles of deferred service. An infrastructure deficiency persisted through budget cycles that never allocated repair funds. A regulatory deficiency existed since the standard was last revised.

These latent root causes are the most difficult to identify because they are not visible in the event itself. They require the engineer to look backward from the failure—tracing the causal chain past the moment of impact, past the pre-impact decisions, and into the system conditions that made the accident possible before anyone involved ever started their day. The five-year-old does this instinctively. Each “why” pushes further back in time. Why didn’t the brakes work? Because the brake lines were corroded. Why were they corroded? Because nobody inspected them. Why not? Because the maintenance schedule didn’t require it. Why not? Because the manufacturer’s recommended interval assumed a different operating environment. Each answer is earlier in time than the one before it, and each is a potential root cause at a different level of the system.

The Five-Year-Old Test: Why Simplicity Validates Understanding

The assertion that you do not truly understand something until you can explain it to a child is attributed to various scientists and educators, and its persistence across generations reflects a truth that the forensic engineering community would benefit from taking more seriously. The test is not about dumbing down the analysis. It is about verifying that the analysis has been carried to its logical completion.

Complexity as a Symptom of Incompleteness

When a forensic engineer cannot explain a conclusion simply, the barrier is almost never that the subject matter is too complex for simple language. The barrier is that the engineer has not yet traced the causal chain to a level where the links are self-evident. Consider two explanations of the same root cause.

Explanation A: “The accident was caused by a fatigue-initiated transgranular fracture in the lower control arm at a stress concentration arising from a geometric discontinuity at the stamping transition zone, which propagated under cyclic loading conditions until the remaining cross-section could not sustain the applied bending moment, resulting in catastrophic separation and consequent loss of directional control.”

Explanation B: “A metal arm that holds the wheel to the car had a weak spot where it was made. Every time the car hit a bump, that weak spot got a tiny crack, and the crack got a little bigger each time. After enough bumps, the arm broke, the wheel came loose, and the driver could not steer.”

Both explanations describe the same failure. Explanation A is technically precise and comprehensible to a metallurgist. Explanation B is technically accurate and comprehensible to everyone. The critical question is: which explanation demonstrates deeper understanding? The answer is B, because B required the engineer to identify the essential causal logic—weak spot, repeated loading, progressive growth, catastrophic failure, loss of control—and express each link in terms that reveal its physical inevitability. Explanation A describes the same chain in technical vocabulary that obscures the logic for anyone who does not already know what the words mean.

The five-year-old test does not replace technical analysis. It supplements it. The engineer must perform the fatigue fracture analysis, the stress calculation, the material characterization, and the failure mode identification. But the engineer must also be able to extract the essential causal narrative from that analysis and express it without the technical scaffolding. If the narrative collapses when the scaffolding is removed—if the engineer cannot explain why the part broke without referencing transgranular fracture mechanics—the engineer may be describing the failure without truly understanding the cause.

The Why Chain: A Child’s Instinct as Engineering Method

A child’s instinct to ask “why” repeatedly is, without exaggeration, the foundational methodology of root cause analysis. The formal technique is called the Five Whys, originally developed by Sakichi Toyoda as part of the Toyota Production System and subsequently adopted across engineering disciplines worldwide. The method is brutally simple: state the problem, ask why it occurred, take the answer, and ask why again. Repeat until you reach a cause that is actionable and fundamental.

The power of the method is that it defeats two of the most common failures in root cause analysis. First, it defeats premature stopping—the tendency to accept the first identified cause as the root cause without testing whether a deeper cause exists. The driver ran the red light. Why? Because the driver was distracted. Why? Because the driver was texting. Why? Because the company required the driver to respond to dispatches by text while driving. The first answer is a proximate event. The fourth answer is a root cause that identifies an actionable organizational failure. An engineer who stopped at “driver error” missed three layers of causation.

Second, the why-chain defeats complexity inflation—the tendency to make the analysis more complicated than the failure requires. When each link in the chain must be stated simply enough to prompt the next “why,” there is no room for unnecessary technical embellishment. The chain either connects logically from one link to the next or it does not. If the engineer cannot state a link simply, the link is either not understood well enough or it is not actually a link in the chain—it is a tangential observation that was included because it sounds technical rather than because it advances the causal narrative.

When the Test Fails: Genuinely Complex Causation

Intellectual honesty requires acknowledging that some failure mechanisms are genuinely difficult to simplify without losing essential accuracy. High-cycle fatigue in the presence of a corrosive environment, stress corrosion cracking under sustained tensile loads, hydrogen embrittlement of high-strength steels—these mechanisms involve interactions between multiple physical phenomena that do not reduce to a single simple chain. The five-year-old test does not require that every metallurgical mechanism be explainable to a child. It requires that the causal role of that mechanism in the accident be explainable to a child.

The metal part broke because the chemical in the environment weakened it over time. That is accurate. That is simple. That is the causal role of stress corrosion cracking expressed at the level the jury needs to understand. The mechanism—the electrochemical process, the crack growth rate equation, the threshold stress intensity factor—belongs in the expert’s report and the technical appendix. The cause—the environment weakened the part until it broke—belongs in the testimony. The five-year-old test applies to the cause, not to the mechanism. The distinction is essential.

Taking the Magic Out: How a Conclusion Actually Forms

There is a persistent mystique around forensic conclusions—a perception that the expert looks at the evidence, applies some mysterious proprietary analytical power, and produces a conclusion through a process that is opaque to non-engineers. This perception benefits experts who want to project authority and harms attorneys who need to evaluate whether the conclusion is sound. The reality is that forensic conclusions are not produced by magic, intuition, or genius. They are produced by a process that is entirely transparent, entirely auditable, and—when done correctly—entirely reproducible by any competent engineer working from the same evidence.

The process has five steps. Every forensic conclusion that has ever been reached by competent analysis followed these steps, whether the analyst articulated them or not. Understanding the process demystifies the conclusion and gives the attorney the ability to evaluate it independently.

Step 1: Observation — What Does the Evidence Show?

The process begins with observation uncontaminated by theory. What does the physical evidence look like? What do the photographs show? What do the measurements document? What do the data records contain? What do the witnesses describe? The engineer catalogs every available observation without attempting to explain any of them. This is the inventory phase. It is tedious, it is time-consuming, and it is the phase that shortcuts destroy.

The discipline of observation requires the engineer to separate what is observed from what is inferred. The observation is “the front bumper is displaced rearward 14 inches with symmetric crush across the full width.” The inference is “this was a full-frontal impact.” The observation is documented. The inference is tested in subsequent steps. An engineer who conflates observation with inference has contaminated the evidentiary foundation before the analysis has begun.

Step 2: Pattern Recognition — What Patterns Emerge from the Observations?

With the observations cataloged, the engineer examines them for patterns. Patterns are relationships between observations that suggest a common cause or a connected sequence. The crush pattern is symmetric and full-width. The airbags deployed. The skid marks are straight and parallel. The EDR shows constant deceleration before the trigger. These observations form a pattern consistent with a straight-line approach, full braking, and a centered frontal impact.

Pattern recognition is where experience matters most, but it is not magic. It is the accumulated ability to recognize which combinations of observations correspond to which physical events, built over years of analyzing failures and studying controlled test data. The NCAP crash test database is, in effect, a pattern library—a catalog of what specific vehicles look like after specific impact configurations at specific speeds. The experienced engineer’s internal pattern library is larger and more nuanced, but it is the same type of resource: observed damage patterns mapped to known physical events.

The discipline of pattern recognition requires the engineer to identify all patterns present in the data, not just the first one that forms a coherent narrative. If the crush pattern suggests a frontal impact but the paint transfer location suggests an oblique angle, both patterns must be documented. Selective pattern recognition—seeing the patterns that support a preferred conclusion and overlooking the ones that complicate it—is the most common analytical failure in forensic engineering.

Step 3: Hypothesis Generation — What Could Explain the Patterns?

The patterns suggest one or more hypotheses about what occurred. A hypothesis is a proposed explanation that accounts for the observed patterns and is consistent with established physical principles. The symmetric full-frontal crush pattern, combined with the straight parallel skid marks and the centered airbag deployment, is consistent with the hypothesis that Vehicle A was traveling straight and struck a fixed object or another vehicle head-on with full engagement.

The critical discipline at this step is generating multiple hypotheses, not just the most obvious one. Could the same pattern result from a different event sequence? Could the symmetric crush be the result of two separate oblique impacts that happened to produce a symmetric final pattern? Could the straight skid marks have been left by a different vehicle? The engineer who generates only one hypothesis has not yet begun the analysis. They have merely selected a conclusion and are about to look for evidence supporting it. The engineer who generates three or four hypotheses—including at least one that is unfavorable to the retaining party—has set the stage for genuine analytical testing.

Step 4: Hypothesis Testing — What Does the Evidence Eliminate?

This is where the conclusion forms, and it forms through elimination, not through confirmation. The engineer does not prove a hypothesis correct. The engineer proves alternative hypotheses incorrect, and the hypothesis that survives all available tests becomes the conclusion. This is the scientific method applied to forensic engineering, and it is the only process that produces conclusions defensible under Daubert.

Each hypothesis is tested against every available evidence source. The full-frontal impact hypothesis predicts specific crush depths, specific airbag deployment patterns, specific momentum exchange characteristics, and specific post-impact trajectories. If the evidence corroborates these predictions, the hypothesis survives the test. The oblique dual-impact hypothesis predicts different crush depths, different deployment patterns, and different trajectories. If the evidence contradicts these predictions—if the crush is symmetric when the dual-impact hypothesis predicts asymmetric damage, for example—the hypothesis fails the test and is eliminated.

The conclusion is not the hypothesis that the engineer likes best. It is the hypothesis that survived every test the evidence could apply. If two hypotheses survive all available tests—if the evidence cannot distinguish between them—the engineer must report both as possible conclusions and identify what additional evidence would be needed to resolve the ambiguity. This is not a failure of the analysis. It is an honest reflection of the evidence’s limitations.

Step 5: Validation — Does the Conclusion Survive the Simplicity Test?

The surviving hypothesis is now subjected to the final validation: can it be expressed as a simple causal chain where each link follows logically from the one before it? If the answer is yes, the conclusion is sound. If the answer is no—if the causal chain requires unexplained leaps, implausible coincidences, or mechanisms that cannot be simply articulated—the conclusion may still be correct, but it requires additional investigation to establish the missing links.

This is the five-year-old test applied as an engineering validation tool. The car crashed because the wheel came off. The wheel came off because the arm that holds it broke. The arm broke because it had a weak spot that cracked over time. The weak spot existed because of how the part was made. Each link is simple. Each link follows from the previous one. Each link is supported by specific physical evidence—the fractured arm, the fatigue striations on the fracture surface, the stress concentration at the stamping transition. The causal chain is complete, traceable, and defensible.

Compare this to a conclusion that cannot pass the simplicity test: “The accident was caused by a combination of factors including driver distraction, reduced friction, inadequate sight distance, and possible mechanical issues.” This is not a root cause analysis. It is a list of conditions that were present. It does not identify which conditions were causes and which were background. It does not establish causal chains. It does not distinguish root causes from contributing factors. It cannot be expressed as a why-chain because it does not trace any chain to its root. A five-year-old would respond to this explanation by asking, “But why did the car crash?”—and the expert would have no better answer to give.

The Attorney’s Audit: Evaluating Whether the Expert’s Root Cause Is Real

With the process demystified, the attorney now possesses the tools to evaluate any expert’s root cause conclusion without specialized engineering training. The evaluation is structured around five questions that map directly to the five-step process.

Question 1: Did the Expert Separate Observations from Inferences?

Read the expert’s report and identify every statement of fact. For each one, determine whether it is a direct observation—something measured, photographed, or recorded—or an inference drawn from an observation. If the report conflates the two—treating inferences as though they were observations—the analytical foundation is compromised. An observation is “the crush depth at the center of the bumper is 18 inches.” An inference is “the impact speed was approximately 40 mph.” The first is evidence. The second is a conclusion drawn from evidence through a calculation that involves assumptions. Both are valid, but they are not the same thing.

Question 2: Did the Expert Generate and Test Multiple Hypotheses?

This is the single most important question in the audit. If the expert’s report describes a single causal theory and presents evidence supporting it, the expert may have confirmed a hypothesis rather than testing one. Confirmation is not analysis. It is advocacy dressed in engineering clothing.

The audit looks for evidence of alternative hypotheses considered and eliminated. A thorough expert report will explicitly state: “Alternative causes considered include X, Y, and Z. Hypothesis X was eliminated because the evidence shows A. Hypothesis Y was eliminated because the physical evidence is inconsistent with B.” If the report does not discuss alternatives, the attorney should ask in deposition: “What alternative causes did you consider, and how did you eliminate them?” An expert who did not consider alternatives has not performed root cause analysis. They have performed narrative construction.

Question 3: Is the Causal Chain Complete and Traceable?

Map the expert’s stated root cause backward to the observed evidence. Each link in the chain should connect to the next through a stated physical principle or documented fact. If there is a gap—a point where the chain jumps from one event to another without an explained mechanism—the chain is incomplete. The gap may represent a cause that has not been identified, an assumption that has not been disclosed, or a link that the evidence does not support.

Apply the five-year-old test. Can the chain be expressed in simple language with each link following logically from the previous one? If a link requires a leap of inference that cannot be simply stated, the link needs additional analytical support. If the expert cannot provide it, the conclusion resting on that link is unsupported.

Question 4: Did the Expert Distinguish Root Causes from Contributing Factors?

Apply the elimination test to each condition the expert identified. If eliminating the condition would have prevented the accident, it is a root cause. If eliminating it would have reduced the probability or severity but not prevented the event, it is a contributing factor. If the expert’s report lumps all identified conditions together without distinguishing their causal roles, the analysis lacks the precision that liability determination requires.

Question 5: Can the Expert Explain the Conclusion Without Jargon?

Ask the expert to explain their root cause conclusion in two minutes using no technical terms. If the expert can do it and the explanation is accurate, the conclusion is well-understood and ready for trial. If the expert cannot do it—if the explanation requires jargon to hold together—the conclusion may need additional development before it can be presented to a jury. This is not a communication skills test. It is an understanding test. The expert who truly understands the failure can express it simply. The expert who is describing a failure they have characterized but not fully understood cannot.

The Honest Conclusion: What It Sounds Like When the Process Works

An honest forensic conclusion does not sound like a pronouncement from an authority. It sounds like a guided tour through a series of observations, logical inferences, tested alternatives, and a surviving explanation that the evidence cannot disprove. It sounds like a story that anyone can follow because the engineer has done the hard work of making it followable.

It sounds like this: “We examined the vehicle and found that the left front suspension arm was broken. The break happened at a specific spot where the manufacturing process created a thin area in the metal. Under a microscope, the fracture surface showed progressive cracking—the kind that develops over time from repeated stress, not from a single overload. The crack started at the thin spot, grew a little bit with every road vibration, and eventually the remaining metal was not strong enough to carry the wheel loads. The arm separated, the wheel shifted, and the driver lost steering control. We considered whether the break could have been caused by the impact itself rather than preceding it, and the evidence eliminates that possibility because the fracture surface shows thousands of loading cycles consistent with months of crack growth—not a single overload event. The root cause is a manufacturing deficiency that created a stress concentration, enabling a fatigue crack to initiate and propagate under normal service loads until the component failed.”

A five-year-old could follow that narrative. The arm broke because of a weak spot. The weak spot was there because of how it was made. It cracked over time. It broke, and the driver could not steer. A jury can follow it too—because it is true, it is complete, it is tested, and it is simple. No magic. No mystery. No jargon masquerading as expertise. Just the evidence, the logic, and the conclusion that the evidence requires.

The Pitfalls: Where Root Cause Analysis Fails

Stopping Too Early

The most common failure in forensic root cause analysis is stopping at the proximate cause and calling it the root cause. “The driver crossed the center line” is a proximate event, not a root cause. Why did the driver cross the center line? Were they asleep? Were they avoiding a road hazard? Did a mechanical failure alter the vehicle’s trajectory? Each answer leads to a different root cause with different liability implications. The engineer who stops at the proximate event has not performed root cause analysis. They have documented the accident without explaining it.

Digging Too Deep

The complementary failure is tracing the causal chain past the point where actionable causes reside into territory where the causes are systemic, societal, or philosophical. “The root cause is that the automotive industry prioritizes cost over safety” may be a legitimate policy critique, but it is not a forensic conclusion that assigns specific responsibility to a specific party in a specific case. The why-chain must stop at a cause that a specific entity had the specific ability and responsibility to prevent. When the chain extends past that point, it has left forensic engineering and entered editorial commentary.

Confusing Correlation with Causation

The fact that two conditions were simultaneously present does not mean one caused the other. The road was wet and the driver lost control. Did the wet road cause the loss of control, or did the driver’s excessive speed cause the loss of control on a road that happened to be wet? The driver was on the phone and ran a red light. Did the phone distraction cause the red-light violation, or would the driver have run the light regardless because they were unfamiliar with the intersection? The forensic engineer must establish the causal mechanism connecting the identified condition to the event, not merely document their co-occurrence. Correlation is the starting point for hypothesis generation. It is not evidence of causation.

Single-Cause Tunnel Vision

The pressure to deliver a clean, simple, single-cause conclusion is enormous. Attorneys want it because it simplifies liability arguments. Experts want it because it simplifies testimony. Juries want it because it simplifies deliberation. But physical reality does not always cooperate. When an accident has multiple root causes operating through independent chains, the expert who forces the analysis into a single cause has abandoned the evidence in favor of narrative convenience. Multiple root causes are harder to present, harder to litigate, and harder for juries to process—but when the evidence supports them, the expert’s obligation is to report them.

The Root Cause Is the Answer That Survives Every Question

A five-year-old’s relentless questioning is not a nuisance. It is the purest form of root cause analysis ever devised. Each “why” pushes past the superficial explanation to the next layer of causation. Each answer must be simple enough to be understood and specific enough to prompt the next question. When the questioning reaches a cause that is actionable, traceable, and supported by the evidence—and when no further “why” produces a deeper cause that the evidence supports—the root cause has been identified.

Multiple root causes can and frequently do coexist in the same event at the same location. The forensic engineer’s obligation is to identify every root cause that the evidence supports, distinguish root causes from contributing factors, and trace each causal chain to its actionable depth. Reporting only the most convenient cause or only the cause that favors the retaining party is not root cause analysis. It is cause selection, and it does not survive competent cross-examination.

The process of reaching a conclusion is not magic. It is observation, pattern recognition, hypothesis generation, hypothesis testing through elimination, and validation through the simplicity test. Every step is auditable. Every step is reproducible. Every step can be explained to a non-engineer in terms they can evaluate. The attorney who understands this process can evaluate whether their expert performed it rigorously, whether the opposing expert performed it at all, and whether the surviving conclusion is the one that the physical evidence actually requires.

If the expert cannot explain the root cause simply, the analysis is not finished. If the expert can explain it simply—if a five-year-old could follow the why-chain from the accident to the cause and nod at each link—the analysis is complete, the conclusion is sound, and the expert is ready for any question a courtroom can produce.

Because the hardest question a cross-examiner can ask is the same question the five-year-old asks: “But why?”

The Inventor's Mind Blog's Substack

Discussion about this post

Ready for more?