The Physics of Root Cause

Most arguments in a failure review are not disagreements about facts. They are disagreements about vocabulary. One engineer says the root cause was "bearing wear," another says "oil starvation," a third says "the wrong torque spec on the pump bracket." All three can be true at once, because they sit at different depths in the same chain. Before anything else, fix the words.

The chain that every physical failure follows

Physics-of-failure practice, developed largely at the University of Maryland's CALCE group and codified in reliability standards, models any hardware failure as one directed chain: a design and process history creates a susceptibility, a life-cycle load acts on it, a mechanism converts load into accumulated damage, damage crosses a threshold, and a mode appears.¹ Root causing is walking that chain backwards from the only end you can see.

Judea Pearl's central organizing idea is that causal questions come in three kinds, and that each kind needs strictly more information than the one below it. No amount of data from a lower rung answers a question from a higher one.² Almost every bad root cause analysis is a rung confusion: someone answers a rung-three question with rung-one evidence.

The formal object underneath all three is a structural causal model: a set of variables, a directed acyclic graph over them, and one equation per variable expressing it as a function of its graph parents plus an independent noise term.

Two structural facts do most of the day-to-day work. A confounder is a common cause of both the suspected cause and the effect; it opens a non-causal path and makes correlation lie. A collider is a common effect of two variables; conditioning on it creates a spurious association between causes that were independent. Warranty data is riddled with colliders, because entering the database at all requires that something went wrong and that the customer complained.

Drawing the graph is not decoration. Once it exists, three questions have mechanical answers: which variables must be controlled for, which must not be, and whether the effect you want is computable from your data at all. Getting these wrong is how a careful team produces a confident number that means nothing.

The rule that decides whether a path carries information

A path between two variables is open unless something blocks it. The blocking rules are short, and they are the whole of d-separation.

• At a non-collider on the path, a chain link or a fork, conditioning on that variable blocks the path. Leaving it free keeps the path open.
• At a collider, where two arrowheads meet, the path is blocked by default. Conditioning on the collider, or on any descendant of it, opens the path.

Two variables are independent given a conditioning set when every path between them is blocked. This is why "control for everything you have" is bad practice rather than cautious practice: every extra variable you condition on risks being a collider or a descendant of one, and each of those manufactures association where there was none.

The back-door criterion

To estimate the effect of X on Y from observational data, find a set Z such that Z contains no descendant of X, and Z blocks every path from X to Y that starts with an arrow pointing into X. Those are the back-door paths, the ones that carry confounding. If such a Z exists and you measured it, the effect is identifiable.

Two practical corollaries for vehicle work. Conditioning on a descendant of the suspected cause is a common and expensive mistake: adjusting a supplier comparison for "measured contact resistance" when resistance is downstream of the supplier lot removes exactly the effect you were trying to measure. And conditioning on selection into the dataset is unavoidable in warranty analysis but is almost always conditioning on a collider, which is why the same comparison run on returned parts and on the full built population can point in opposite directions.

When no valid back-door set is available because a confounder was never measured, the effect is not identifiable from that data, and the honest response is to say so rather than to fit the model anyway. Sometimes a front-door route exists instead: if you measured a mediator that carries the entire effect and is itself unconfounded with the outcome, the effect can be recovered through it. In practice a physical intermediate quantity, the micro-motion amplitude, the film thickness, the local temperature, is often exactly such a mediator, which is another reason to instrument the mechanism rather than only the endpoints.

These are the methods that exist in every quality manual. They are structuring devices for human reasoning: they are cheap, they run in a conference room, and their output is a document. None of them contains any physics or any statistics. That is both their strength, since they apply to anything, and their weakness, since nothing in them can tell you that your answer is wrong.

5 Whys

Ask why repeatedly until you reach something actionable. Its virtue is that it forces a chain rather than a single label, and it costs nothing. Its documented weakness is severe: the answer depends heavily on who is in the room, it produces a single linear chain when real failures are trees, and it stops at the analyst's knowledge boundary rather than at the physics. Card's review in the patient-safety literature is the sharpest published critique, and its criticisms transfer directly to engineering: the method has no stopping rule, no test for sufficiency, and encourages a single-cause narrative.³

Use it as a warm-up to generate hypotheses, never as the analysis itself. The moment two different "whys" are defensible at the same step, you no longer have a chain, you have a graph, and you need a method that can hold a graph.

Ishikawa (fishbone) diagram

Organizes candidate causes into families. In manufacturing the classic six are machine, method, material, measurement, man, and environment; for a physical part it is usually more productive to reorganize the bones around load, geometry, material state, interface condition, and control, because those map onto quantities a physics model actually takes as inputs. The fishbone is a coverage tool: it is how you notice the branch nobody proposed. It has no mechanism for ranking or eliminating.

Fault tree analysis

Deductive and top-down. You state the undesired top event and decompose it through AND and OR gates until you reach basic events with known rates. Its real products are the minimal cut sets, the smallest combinations of basic events that are jointly sufficient for the top event, and a quantified top-event probability. The NRC's Fault Tree Handbook remains the definitive treatment.⁴

Fault trees are the classical method that most nearly behaves like a causal model, because gates encode sufficiency rather than mere association. Their limits: they are Boolean, so they struggle with continuous degradation and timing; they assume you enumerated the branches; and common-cause failures must be inserted by hand or the answer is optimistic by orders of magnitude.

FMEA, and its diagnostic cousins

FMEA is inductive and bottom-up: for each function, enumerate failure modes, their effects, their causes, and the controls. The AIAG-VDA harmonized handbook restructured it into seven steps and replaced the risk priority number with action priority, which removes the worst abuse of the old method, namely multiplying three ordinal scales and treating the product as a real number.⁵ Two variants matter here. FMEDA adds diagnostic coverage and is the safety-analysis workhorse. FMMEA, from the physics-of-failure community, replaces "cause" with an explicit failure mechanism and its governing model, which makes the analysis quantitative and, crucially, falsifiable.⁶

In root causing, a well-maintained DFMEA is your prior. It is the list of mechanisms the design team already believed were possible, with an implicit ranking. A failure mode that appears in the field and was never in the DFMEA is itself a finding.

Kepner-Tregoe problem analysis, and the "is / is not" boundary

The most underrated classical tool. You describe the problem along four dimensions, what, where, when, and extent, and for each you record both what is observed and the closest thing that could reasonably have been observed but is not. The difference between the is and the is-not columns is where the cause has to live, because a true cause must explain the boundary as well as the occurrence.

This is a genuinely powerful falsification engine and it costs nothing. If your hypothesis is "supplier B terminals," and supplier B parts also went into a model line with zero complaints, your hypothesis must explain that boundary or die. Most weak root cause candidates die here, fast.

8D and A3

Process wrappers rather than analysis methods. They matter because they enforce two things the technical methods forget: interim containment before the analysis is finished, and verification that the corrective action actually removed the effect. The discipline of D5 and D6, verify the corrective action and then verify it in production, is where a lot of otherwise correct analyses fail.

Barrier and change analysis

Two focused sub-methods. Change analysis asks what is different between the failing population and the last known good one, in build date, supplier lot, software calibration, plant, or process parameter, and it is often the single highest-yield first move on a field issue because manufacturing changes leave dated records. Barrier analysis asks which control was supposed to prevent this and why it did not act, which is how you find the detection root cause rather than just the technical one.

Before adding statistical machinery it is worth being concrete about how field data specifically misleads in a vehicle program. These are not abstract worries. Each one has sunk real investigations.

Censoring and the age problem

A warranty database contains failures that have happened, in a fleet whose units have wildly different ages and mileages. Comparing raw counts between build months compares different exposure. The minimum honest unit is a rate per unit exposure, and the standard model is the Weibull: a shape parameter below one indicates infant mortality, which points to manufacturing defects or damage during assembly; near one indicates random external causes; above one indicates a wear-out mechanism accumulating damage. The shape parameter is itself evidence about which class of mechanism you are looking for, before you have opened a single part.

Survivorship and the returned-parts filter

The parts you get to examine are the ones that failed, were noticed, were brought in, were replaced, and were actually shipped back rather than scrapped at the dealer. Every one of those is a filter. If severe failures destroy the evidence and mild ones do not, your returned-parts population is systematically biased towards the mild mechanism, and the analysis converges confidently on the wrong one.

No fault found

A large fraction of returned electronic and electrical components test good on the bench. The literature on this phenomenon in automotive and aerospace electronics is consistent: a substantial share of returns are no-fault-found, and the dominant underlying cause is intermittent behavior that is condition-dependent, that is, the fault exists only under a combination of temperature, vibration, humidity, and load that the bench test does not reproduce.⁷ A no-fault-found result is not evidence of no fault. It is evidence that your test did not span the condition space where the mechanism lives, which is itself a physics statement and a lead.

Base rates and the diagnostic trap

A DTC with a 95% true positive rate for a mechanism that occurs in 1 in 2000 vehicles, with a 3% false positive rate, gives a posterior of roughly 1.6% when the code sets. Codes are evidence, weighted by a likelihood ratio; they are not verdicts. Writing the likelihood ratio down explicitly for each piece of evidence, before you look at the answer, is one of the highest-value habits in this whole field.

These methods bring quantification and, in the causal branch, an explicit account of when a correlation can be read as an effect. They are strong exactly where the classical methods are weak, and blind exactly where physics is needed.

Granger causality

A time-series test: does the past of X improve prediction of Y beyond Y's own past? Formally, in a vector autoregression, X does not Granger-cause Y if the coefficients on lagged X are jointly zero.⁸ On a vehicle this is useful for ordering signals in a propagation chain, for example establishing that coolant inlet temperature leads module temperature rather than following it.

Its limits are strict and often ignored. It detects predictive precedence, not mechanism. Two signals driven by a common unmeasured cause with different lags will show Granger causality in the wrong direction. Sampling rate matters enormously: if the physical coupling is faster than your logging rate, the apparent direction can invert. Treat it as a filter that removes impossible orderings, not as a producer of causes.

Causal discovery from observational data

A family of algorithms that recover as much of the causal graph as the data can determine. Constraint-based methods such as PC start from a fully connected graph and delete edges whose endpoints are conditionally independent given some separating set, then orient what they can from collider patterns; the result is an equivalence class, not a unique graph.⁹ FCI extends this to allow latent confounders. Score-based methods search over graphs to maximize a penalized likelihood. Functional methods such as LiNGAM exploit non-Gaussianity to identify directions that conditional independence alone cannot.

These are genuinely powerful for generating structure over dozens of logged channels, and they fail in characteristic engineering ways: they assume acyclicity, but control loops are cyclic by design; they assume the sample is independent and identically distributed, but a drive cycle is not; and they orient edges from statistics alone, with no idea that heat flows from hot to cold. This is precisely where physics earns its place, as a set of hard constraints on which edges may exist and which orientations are permitted.

Bayesian networks for diagnosis

Once you have a graph and conditional probability tables, you can do proper diagnostic inference: enter the observed evidence, propagate, and read the posterior over candidate causes. This is the natural home for mixed evidence, because a Bayesian network is indifferent to whether a node is a DTC, a teardown observation, or a build record. It also handles the "explaining away" phenomenon correctly: strong evidence for one cause of a shared effect properly reduces belief in the alternative cause, which is a reasoning step humans do badly by hand.

Interventional and counterfactual analysis

The end state. With a structural model you can compute the effect of do(X = x) from observational data when the graph permits it, using the back-door criterion (condition on a set that blocks all confounding paths and contains no descendants of X) or the front-door criterion when a full mediator is measured. And you can compute the counterfactual quantities that root cause claims actually assert. Two are worth naming, because they map onto the necessity and sufficiency tests from Section 01.

Statistical process and signal methods that carry causal weight

Two more deserve mention because they are cheap and they discriminate. Difference-in-differences across a known change point, for example a process change on a dated build boundary, is a quasi-experiment and gives an effect estimate rather than a correlation, provided the parallel-trends assumption is defensible. And model-based residual analysis, the core of the fault detection and isolation tradition, is causal by construction: a residual is the difference between what a physical model predicts and what the sensor reports, so a structured residual set is designed so that each fault produces a distinct signature.¹¹ That belongs to the fourth level of physics and is the subject of Section 13.

Section 04 treated the Weibull shape parameter as a hint about the mechanism family. That works when one mechanism is running. In the field, two usually are, and the arithmetic of two mechanisms is not the arithmetic of one. Missing this is the most common quantitative error in warranty analysis, and it hides exactly the subpopulation you were looking for.

Two different situations that look identical in the data

Competing risks. Every unit is exposed to both mechanisms, and it fails when the first one gets there. The observed life is the minimum of two lives, so the reliability functions multiply.

The distinction is not academic, because the corrective actions are opposite. Competing risks means every unit will eventually meet both mechanisms, so a design change is needed. A mixture means a defined subpopulation carries a defect, so containment, traceability and a process fix are the right moves, and the units outside the subpopulation need nothing. Physics is what tells you which model applies: ask whether the mechanism requires a precondition that only some units have. Fretting needs micro-motion above a threshold, which only some routings produce, so it is a mixture. Thermal aging of an electrolyte happens in every cell, so it is a competing risk against everything else.

The bent probability plot, and the fit that hides it

On a Weibull probability plot a single mechanism is a straight line. Two mechanisms produce a bend, and the two slopes are the two shape parameters. What makes this dangerous is that fitting a single Weibull to bent data does not fail loudly: it returns a shape parameter somewhere between the two, an eta with no physical meaning, and a residual pattern nobody looks at. The reported result, a shape near one, then gets read as "random external causes" when what is actually present is a small infant-mortality subpopulation riding on a slow wear-out.¹⁹

The habit worth building: plot before you fit, look for the knee, and if it is there, split the data by any physically plausible grouping variable and see whether the two segments straighten out. When they do, you have found the subpopulation, and the grouping variable that split them is a lead on the cause.

Exposure, and why build-month comparisons lie

A build month from a year ago has had a year of exposure; last month's has had a month. Comparing raw claim counts, or even claim rates per vehicle, compares different amounts of opportunity. The standard fix is to compare at equal months in service, so each cohort contributes only the exposure that every cohort has, and to plot the cumulative claim rate against months in service rather than against calendar date. Everything before that transformation is noise shaped like a trend.

The same correction has a physics version that is stronger where you can get it. Months in service is a proxy for the stressor the mechanism actually consumes. If the mechanism integrates thermal cycles, compare cohorts at equal accumulated cycles; if it integrates sliding distance, compare at equal distance under load. Telematics duty-cycle histograms make this possible for a growing fraction of the fleet, and switching the horizontal axis from time to damage is often enough on its own to make a confounded comparison come apart cleanly.

Catching it early: the emerging-issue problem

By the time a rate looks alarming on a monthly chart, several months of build have shipped. What you want is a detector that fires on a sustained small shift rather than on a large one, which is exactly what a cumulative sum chart does: it accumulates the signed deviation from a reference rate and alarms when the running sum exceeds a decision interval.²⁰ Compared with a threshold on the monthly value, it trades a little delay on large jumps for a great deal of sensitivity to small persistent ones, which is the shape of nearly every real emerging defect.

The four levels in the next sections all assume something the previous sections never built: a model of the thing that broke. Not a simulation, and not a CAD assembly. A structured object that says what the parts are, how they are connected, what equation governs each connection, where each equation stops being true, which parameter each failure mechanism moves, and which of all those quantities you can actually see. Everything downstream is executable only because this object exists.

This section is about constructing it. It matters more than it looks, because the model decides what the investigation can conclude. A model with no interface between two parts cannot express a failure at that interface. A model whose equations carry no validity range will extrapolate across a regime change and return a confident wrong answer. A model that does not know which variables are measured cannot tell you whether a hypothesis is testable. Most stalled investigations are stalled on a modelling omission that nobody has noticed, because the omission is invisible: the model does not report what it left out.

Before designing anything automated it is worth watching a good failure analyst carefully, because what they do is not what the textbook order suggests, and the differences are the interesting part.

What the expert holds informally, a system has to hold explicitly. The object has five layers, each of which adds a specific capability and each of which has its own check. Skipping a layer does not produce an incomplete model, it produces a model that fails silently at a predictable place.

Decide what is inside the model, what enters as an input, and what is treated as environment. This sounds administrative and it is the single most common place an investigation is quietly doomed, because a cause outside the boundary cannot be found by anything done inside it. Case A turns on a converter calibration, which is outside any boundary drawn around "the bearing." Case D turns on a bracket revision, which is outside any boundary drawn around "the connector."

The test that catches this is cheap. Take the mechanism list from the DFMEA and the FMMEA, and for each mechanism ask whether the stressor it consumes is a variable inside the boundary or an input crossing it. If a mechanism's stressor is neither, the boundary is wrong. Widen it until every candidate mechanism has somewhere to come from, then stop. Boundaries that are too wide are merely expensive; boundaries that are too narrow are wrong.

Record three lists explicitly: inside, the things whose state the model computes; inputs, things that cross the boundary and are set elsewhere, including commands and calibrations; and environment, things that act on the system and are not controlled, such as ambient temperature, road profile, and duty cycle. Faults can live in all three, and a fault in the input list is usually a software or process cause, which is a category teams forget to include.

Now the graph. Nodes are elements that store or dissipate something; edges are ports through which power flows. The discipline that pays off here is refusing to draw a plain line between two blocks. Every connection carries a pair of variables whose product is power: an effort and a flow. Writing connections this way is the bond graph formalism, and it buys three things at once: one language for all physical domains, conservation that holds structurally rather than by inspection, and a natural place to put the interface elements where failures actually live.³²

Two rules make this layer do real work. First, every interface is a node, not a line. A bolted joint has a stiffness, a friction, a preload and a wear state; drawn as a line it has none of those and cannot fail. Second, every port is typed, so a mechanical port cannot be connected to a thermal one, and a missing or unpaired port is a detectable defect in the model rather than a silent gap. Almost every "we never modelled that coupling" story is a missing node at an interface or an untyped port that let two domains be conflated.

Each element gets a relation between its effort and flow, or between a state and its rate. What matters here is less the equation than the record around it. A usable equation record has seven fields, and the sixth is the one that decides whether the model can be trusted outside the condition it was written for.

A worked example from the thrust face. The film relation is written as a scaling law, its parameters are a geometry constant and a roughness, and its validity range is the whole point: it holds while the film ratio stays above roughly one and the flow stays laminar. Below that, the correct relation is a different one, an asperity contact model, and the two are not continuations of each other. A model that carries both relations and their ranges will switch; a model that carries only the first will report a film thickness of a fraction of a micrometre and imply everything is fine.

Where a relation does not exist in the literature for your specific material and geometry, there are two honest options and one dishonest one. You can measure it, which is expensive and correct. You can identify it from data with a method that produces an interpretable expression rather than a black box, which is the point of sparse regression approaches that select a short symbolic form out of a library of candidate terms.³³ The dishonest option is to fit a flexible model, report that it reproduces the data, and quietly use it outside the range of the data, which is the failure described in Section 16.

"Consistent with first principles" is easy to assert and easy to skip. Turned into six concrete checks it becomes a gate that can be run automatically, and the last two are the ones that catch real errors rather than typos.

1. Dimensional homogeneity. Every term in every equation has the same dimensions. Fully mechanical, and it catches missing factors, wrong exponents and unit-system mixups. Should never be done by eye.
2. Conservation closure. Power in equals power stored plus power dissipated, around every junction and over the whole graph. In bond-graph form this is guaranteed by construction for the true power domains; assert it explicitly for the thermal pseudo-bond.
3. Second law and sign definiteness. Every dissipative element must dissipate: the product of its effort and flow is non-negative, entropy production is non-negative, damping matrices are positive semi-definite. A sign error here produces a model that generates energy in some corner of the operating space, usually the corner you care about.
4. Reciprocity and symmetry. Stiffness and compliance matrices are symmetric; coupled transport coefficients obey Onsager reciprocity. Asymmetry that is not physically justified is a modelling error, not a discovery.
5. Limiting-case degeneration. Drive each parameter to zero and to infinity and check the model reduces to the simple case you already know. Film thickness to infinity should give pure viscous shear; contact force to zero should give zero friction; thermal resistance to zero should equalize temperatures. This catches structural errors that dimensional analysis cannot see.
6. Regime and lumping validity. Form the dimensionless groups and check that the regime you assumed is the regime you are in, and, critically, that the decomposition is legitimate. A lumped thermal node is only valid while the Biot number stays small; above roughly 0.1 the internal gradient matters and your single-node block is wrong no matter how good its equation is. This check validates layer 1, not layer 2, which is why it is the one most often missing.

That last point is worth stating plainly: first principles does not only validate your equations, it validates your block diagram. Whether a region can legitimately be one lump, whether two nodes can be treated as isothermal, whether a shaft can be rigid, are all decisions that a dimensionless group either permits or forbids. Teams routinely validate the equations and never validate the decomposition that the equations sit in.

Here is where the physics model stops being a simulation asset and becomes a diagnostic one. The move is small and it changes everything: a failure mechanism is a parameter of a constitutive equation drifting in a particular direction, at a rate governed by a rate law, driven by a stressor the model already computes.

Once faults are written that way, several things that were narrative become computable. Fault isolation becomes parameter estimation. The causal chain becomes a path through the model: stressor feeds rate law, rate law moves parameter, parameter propagates through the equations, propagation reaches an observable. The timeline check from Section 12 becomes an integration of the rate law along the measured duty cycle. And the health indicator for the prognostic in Section 28 is simply the parameter itself, or the closest observable proxy for it.

Finally, which of all these variables you can actually see. For each, record the signal name as it exists in the real database, the sample rate, the resolution and quantization, the filter and its cutoff, the storage policy including whether the buffer is rolling, the diagnostic debounce time if it feeds a monitor, and one field that is easy to forget: whether the variable sits inside a control loop, and if so which effort signal pairs with it.

This layer is what makes the difference between a model that can simulate the failure and a model that can diagnose it. A variable that exists in the equations but is sampled at one hertz through a low-pass filter, or is only stored in a buffer that wraps every two minutes, is for practical purposes not observable for a mechanism with a millisecond signature. Recording that fact in the model means the diagnosability analysis below will tell you so, rather than proposing a residual that cannot be computed on a real vehicle.

Now the payoff, and it is larger than most engineers expect. With the equation set and the observation map in hand, and with no parameter values at all, you can already compute which faults are detectable, which pairs are isolable, and which single extra sensor would break a specific tie. The reasoning uses only which variables appear in which equations, which is why it works at concept stage, on a napkin model, years before anyone has measured a coefficient.

The construction is short. Build the incidence matrix with equations as rows and unknown variables as columns, marking a one where a variable appears in an equation. A sensor is just another equation asserting that one variable equals a measurement, which moves that variable from unknown to known. A subset of equations has structural redundancy equal to the number of equations minus the number of distinct unknowns they contain; redundancy greater than zero means the subset says more than it needs to in order to determine its own unknowns, and that surplus is exactly what a residual is made of. A Dulmage-Mendelsohn decomposition splits the whole system into the under-determined, just-determined and over-determined parts, and all diagnostic information lives in the over-determined part. Everything else is simulation.²⁹

Within the over-determined part you enumerate the minimal structurally overdetermined sets: subsets with redundancy exactly one, none of whose proper subsets is itself overdetermined. Each of these yields one analytical redundancy relation, which is one residual, and the set of MSO sets a fault appears in is that fault's signature. Detectability and isolability then read straight off: a fault is detectable if it appears in at least one MSO set, and two faults are isolable if the sets they appear in differ. This is the fault signature matrix from Section 13, derived rather than assembled by hand.³⁰

The scale in that caption is worth dwelling on. The reference implementation of this approach, applied to an automotive engine air path, works on ninety-four equations with ninety unknowns, ten sensors and eleven faults, finds nearly four and a half thousand minimal overdetermined sets, filters them down to a couple of hundred that are numerically well behaved, and generates residual code from the selected ones.³⁰ No human is going to enumerate four thousand redundancy relations by hand or reason about their isolability. This is the part of the job that should have been automated a decade ago, and the tooling to do it exists and is open.

A complete model of a vehicle subsystem at the depth needed to express every mechanism is not buildable, and if it were it would not be worth it, because ninety percent of the detail would never be consulted. The expert's answer, from the third behaviour above, is to keep everything lumped and go deep in one place. To automate that you have to state the refinement trigger explicitly, because "go deep where it matters" is not an instruction a machine can follow.

Three triggers cover nearly all real cases, and they are checkable.

• An unexplained residual. A residual that does not return to zero under any admissible parameter set means the model is missing structure, not just a value. Refine the block that contributes most to that residual. This is the strongest trigger, because it is evidence-driven.
• An isolability tie you care about. If two candidate mechanisms sit in the same group in the signature matrix, refining the block that contains one of them may split it, and the structural analysis will tell you in advance whether it can. If refinement cannot split it, do not refine: add a sensor or design a test instead. This distinction saves a great deal of wasted modelling.
• A validity range violated. If the operating point leaves the range of an equation, that block needs a second relation for the other regime, plus the switching condition. This is refinement in a different direction, in condition space rather than in physical scale.

And one anti-trigger, worth writing down because it is the default behaviour of both thorough engineers and enthusiastic automation: do not refine because the detail exists. The presence of a CAD model at part level, or a supplier datasheet with forty parameters, is not a reason to represent any of it.

Everything above is a specification. It says what has to exist, what checks each part must pass, and what decides where to go deeper. That is exactly the shape of problem an agent system can attack, provided it is built around the checks rather than around the conversation.

The organizing principle comes first, because it decides everything else. The shared state is the model artifact, not the message history. Agents read and write a structured, versioned object: a graph of components and typed ports, a set of equation records, a fault dictionary, an observation map. They do not pass prose to each other. This matters for three reasons: every write can be gated by a verifier, the object can be inspected and corrected by a human at any point, and the system does not degrade as the conversation grows. Recent work on agentic systems for engineering design converges on the same idea, representing the design as a serializable state graph that bundles requirements, embodiments and executable physics models into nodes, with agents operating on the graph rather than on text.³⁴

Four design rules, and one uncomfortable finding

• Let code do what code can do. Dimensional analysis, unit conversion, symbolic manipulation, Dulmage-Mendelsohn decomposition, MSO enumeration, residual code generation: all of these are libraries with exact answers, and mature open implementations exist for the diagnosis-specific ones.³⁰ The language model's job is to read the documents, propose which relation belongs on which element, and explain itself. It should never be the thing computing an isolability matrix.
• Gate every write. A record that has not passed its verifier does not enter the artifact, and the check that admitted it is stored alongside it. This is what makes the model auditable a year later, when the question is not "is this right" but "why did we believe this."
• Give the orchestrator a budget and a trigger, not a goal. "Build the best model you can" produces the middle panel of Figure 7. "Refine only on an unexplained residual, a splittable isolability tie, or a violated validity range, and stop at N refinements" produces the right-hand panel.
• Run the red team on a different model, with an adversarial prompt. Its only job is to find what is missing, which is the one thing the generators cannot check themselves. Track its precision over closed cases; a red team whose flags are never real is theatre, and one whose flags are always real means the generators are too weak.

What the machine does better, and what it does not

Worth being precise, because it decides the division of labour. The machine is better at exhaustiveness, since it will not forget the fourteenth interface; at bookkeeping, since it will not lose a unit conversion or a provenance link; at combinatorics, since isolability over two hundred faults and ten sensors is not something a person can hold; and at consistency, since the same check runs the same way every time. It is worse, currently by a wide margin, at knowing that an entire mechanism class is absent from the dictionary; at knowing that a handbook coefficient does not apply to this supplier's material; and at deciding that the boundary is drawn wrongly, which requires knowing something about the organization rather than about the physics.

Notice that those three weaknesses are exactly the three human strengths that the expert section did not list, and the three human failure modes listed there are exactly the machine's strengths. That complementarity is real and it is the argument for the architecture in Figure 8, rather than for either extreme.

A build order you can actually run

1. Write the failure question in one sentence, in terms of a mode rather than a symptom.
2. Draw the load path and set the boundary. Test it against the DFMEA mechanism list: every mechanism must have a stressor that is inside or crosses the boundary.
3. Enumerate interfaces and make each one a node. Type every port.
4. Lump everything. Identify the suspect region from the mechanism list and the evidence, and only there go deeper.
5. Attach constitutive relations where a candidate mechanism lives, each with parameters, uncertainty, provenance and a validity range.
6. Run the six first-principle checks, including the lumping validity test, which audits step 4 rather than step 5.
7. Write the fault dictionary rows for the candidate mechanisms: parameter, direction, rate law, stressor, timescale.
8. Write the observation map for the signals that genuinely exist, with rates, filters and loop membership.
9. Run the structural analysis. If the pair you need to separate is not isolable, stop modelling: the decision in front of you is a sensor or a test, not more physics.
10. Only now fit parameters, build residuals from the selected MSO sets, and run them against data.
11. When a residual cannot be explained by any admissible parameter set, return to step 3. You are missing an edge, and the model has just told you so.

Everything above tells you how to organize hypotheses and how to weigh data. None of it tells you whether a proposed cause is physically capable of producing the observed failure. That is what physics contributes, and it contributes at four distinct depths. Confusing them is the most common technical failure in root cause work.

The four levels are not four schools of thought. They are four different questions, asked of the same failure, and a complete investigation asks all four. Each one can independently kill a hypothesis, and a hypothesis that survives all four is very hard to argue with.

The relationship between the levels runs in two directions at once, and keeping the two directions straight is the discipline. Causation runs downward and forward: fundamental processes produce field behavior, field behavior produces system-level effects, system-level effects produce signatures. Inference runs upward and backward: you observe signatures, and you climb.

This is the level of ratings, margins, and balances. It is deliberately crude, and its crudeness is the feature: an engineering-level check runs in minutes and eliminates whole families of hypotheses before anyone books simulation time.

The four checks worth running first, always

Energy budget. Can the proposed cause supply the energy that the observed damage represents? Melted copper, a fractured surface, a plastically deformed housing, and a vented cell all have a computable energy cost. If the candidate source cannot deliver it, the candidate is dead regardless of how well the timeline fits. This single check has more killing power than any other one-line calculation in failure analysis.

Force and moment balance. Where must the reaction go? Axial thrust in a transmission, clamp load in a joint, and preload in a bearing all have to be reacted somewhere, and the damage should appear at the reaction path. When it does not, either your load path model is wrong or there is a second load you have not accounted for.

Rating and derating. Compare the actual applied stressor, at its real duty cycle, against the component's rating at the real temperature. Most component ratings are quoted at a reference condition that no vehicle ever sees. A capacitor rated at 105 °C, a connector rated for a number of mating cycles, a bearing rated at a nominal L10 life: all need to be translated to the field condition before comparison means anything.

Dimensional analysis and scaling. Form the relevant dimensionless group and check whether the regime is what you assumed. A bearing that you believe is hydrodynamic is characterized by the ratio of film thickness to combined surface roughness. If that ratio is below about one, you are in boundary lubrication and the entire hydrodynamic argument is inapplicable. Regime errors are catastrophic and cheap to find.

Load-strength interference, the honest way to think about margin

A single-number safety factor hides the thing that matters. Both the applied load and the part's strength are distributions, and failure probability is the overlap between them. This reframing explains a phenomenon that confuses many programs: a design change that improves mean strength by a small amount can reduce field failures by an order of magnitude if it also reduces variance, and a process change that increases variance can cause failures without changing the mean at all. Most field failures are variance problems, not mean problems.

The engineering level tells you whether a quantity is large enough. The applied level tells you where it is large, and that is usually the discriminating information, because damage location is a fingerprint that hypotheses cannot fake.

Localization as evidence

Two hypotheses that predict the same magnitude almost never predict the same map. A gear tooth failing from bending fatigue cracks at the root fillet on the tension side; the same tooth failing from contact fatigue spalls below the pitch line. A winding failing from thermal overload degrades hottest-spot-first at the end turns; the same winding failing from partial discharge degrades at the slot exit where the field concentrates. When you can compute the field, the damage map becomes a likelihood function over hypotheses, and it is a very sharp one.

The models that matter for vehicle parts

• Structural. Finite element stress and modal analysis. The two questions that resolve most mechanical disputes: where is the stress concentration, and is there a resonance whose mode shape puts an antinode at the damage site.
• Tribological. The Reynolds equation for thin lubricating films, plus a contact model for when the film fails. This is the physics of every journal and thrust bearing, and the transition between regimes is the whole story.
• Thermal. Lumped resistance-capacitance networks for fast answers, conjugate heat transfer when the flow matters. The relevant output is rarely the mean temperature; it is the hot spot and the gradient, because gradients drive thermomechanical stress.
• Electromagnetic. Magnetic circuits for a first pass, finite element for saturation, harmonics, and localized demagnetizing field. The key output for a magnet problem is the field at the most exposed corner of the magnet, not the average.
• Electrochemical and transport. Porous-electrode models for cells, diffusion and migration for corrosion and dendrite growth. These are slow, strongly temperature-dependent, and highly local.

Regime transitions are where root causes hide

Nearly every dramatic field failure involves crossing a boundary between two physical regimes, because inside a regime the response is smooth and outside it the response changes character. Hydrodynamic to boundary lubrication. Laminar to turbulent. Reversible to irreversible magnetization. Elastic to plastic. Stable heat generation to thermal runaway. The design was validated inside one regime; the failure happened after something pushed the operating point across the line. Finding the crossing condition is very often the actual root cause statement.

This level supplies two things nothing else can: invariants, which are constraints a true explanation may never violate, and rate laws, which convert a stressor into a time to failure. Invariants are how you falsify. Rate laws are how you make the timeline close.

Invariants, and how to use them as falsifiers

Conservation of energy, mass, charge, and momentum, plus the second law, are not decorative. Each becomes a concrete test.

• Energy accounting. Sum the energy that entered the failure region over the event and compare it against the energy required to produce the observed damage: latent heat to melt the observed mass of copper, fracture surface energy times the crack area, enthalpy of the decomposition reactions in a vented cell. Discrepancies of an order of magnitude falsify a hypothesis outright.
• Mass and species balance. Corrosion products, wear debris, and vent gas composition are quantitative. If a hypothesis requires a reaction, the reactants must have been present in the required quantity, and the products should be findable.
• Entropy and irreversibility. Damage is irreversible entropy generation. This is more than a slogan: it justifies why damage accumulates monotonically and why some proposed "self-healing" explanations for intermittent behavior are non-starters, while others, such as re-formation of a lubricant film or reflow of an oxide, are legitimate because they have an external free-energy source.
• Kinetic feasibility. A thermally activated process at a given temperature has a rate. If the required rate is not achievable at the temperature the part actually saw, the mechanism did not run, no matter how good the metallurgy looks.

The rate laws you will actually use

Each is an empirical law with a first-principle justification, and each converts a stressor into life. Their real power in root causing is not prediction but acceleration factors: the ratio of life under two conditions, which lets you ask whether the field condition can produce failure in the observed time.

The first three levels describe the failure. This one describes your access to it. Diagnostic physics is the physics of the measurement chain: how a mechanism deep inside a part perturbs a quantity, how that perturbation propagates to a place where a sensor sits, what the sensor does to it, and whether what arrives is distinguishable from what a different mechanism would have produced.

This is the level that decides whether an investigation is even possible with the data you have, and it is the one most often skipped. A great deal of wasted effort in vehicle diagnostics consists of searching for a signature that physics says cannot be present in the recorded channel.

The observation model

Detectability, isolability, and the fault signature matrix

Model-based fault detection and isolation formalizes exactly this.¹¹ You design a set of residuals such that each one is sensitive to a known subset of faults and insensitive to the rest. Arrange faults as columns and residuals as rows, and mark which residual responds to which fault. Two properties fall straight out. A fault is detectable if its column is not all zeros. Two faults are isolable from each other if their columns differ. If two candidate mechanisms have identical columns, no amount of data from those residuals will ever separate them, and the only way forward is to add a residual, add a sensor, or create an operating condition where the columns diverge.

This is the formal version of what a good failure analyst does intuitively when designing a discriminating test. It is worth writing down explicitly, because the matrix immediately shows which test is worth running.

Condition-dependent observability, and why intermittents are hard

Detectability is not a property of a fault. It is a property of a fault under an operating condition. A cracked solder joint conducts fine until thermal expansion opens it; a fretted contact conducts fine until vibration in a particular frequency band separates the surfaces; a demagnetized magnet costs nothing measurable until the operating point demands full torque. This is the physical explanation for the no-fault-found phenomenon, and it converts a frustrating result into a testable hypothesis: name the condition under which the fault becomes observable, then create it.

The transfer path is part of the evidence

Between the mechanism and the sensor is a physical path with its own dynamics. A bearing defect excites a structure whose transfer function to the accelerometer mount has poles and zeros; if a defect frequency lands near a zero, the fault is invisible at that sensor and obvious at another. Order tracking exists because rotating-machinery signatures are locked to shaft angle rather than to time, and a fixed-frequency analysis smears them across bins under any speed variation. Sampling rate, anti-alias filtering, and the logging trigger all subtract information before you ever see it, and each subtraction is a hypothesis you can no longer test.

Detection thresholds are a decision, not a constant

A threshold trades missed detection against false alarms, and the physics sets the shape of that trade: the drift rate of the mechanism sets how long you must wait for separation, while noise and parameter uncertainty set the floor. In root causing, an unfired diagnostic is evidence only when you can show the mechanism would have crossed the threshold by now.

Almost every quantity you can measure on a modern vehicle sits inside a control loop. That single fact breaks several of the assumptions in the sections above, and it is the reason a mechanism that started twenty thousand miles ago produces a complaint that looks like it started last Tuesday.

What a loop does to a fault

A controller exists to hold a variable at a setpoint despite disturbances, and a developing fault is a disturbance. Integral action in particular will drive the steady-state error to zero for any slowly growing fault, which means the controlled variable, the one you would naturally look at, is the one place the fault is guaranteed not to appear. What moves instead is the control effort: the command, the duty cycle, the learned offset, the adaptation term. The fault is fully visible there, and completely invisible where everyone looks first.

This inverts the usual instinct. On an open-loop mechanical system you look at the output. Inside a loop you look at what the loop had to do to keep the output where it is. A useful shorthand: the error tells you the controller is working, the effort tells you what it is working against.

Saturation is the reveal, and it misdates everything

Compensation continues until the actuator, the calibration limit, or the adaptation clamp runs out of range. At that moment the controlled variable departs suddenly and the symptom appears. The customer reports a sudden onset, the diagnostic sets a code with a timestamp, and change analysis then goes looking for what changed around that date. It finds nothing, because nothing changed then: the mechanism started when the effort began drifting, which may be a year and many thousands of miles earlier.

This is a systematic, repeatable error and it has an equally systematic fix. Date the mechanism from the drift in the effort or in the learned value, never from the timestamp of the code. Adaptation memories are the cheapest clock on the vehicle for exactly this reason, and Section 15 treats that idea in general.

What the loop does to your inference tools

• Acyclicity is gone. Discovery algorithms that assume a directed acyclic graph will either fail to orient the loop edges or orient them arbitrarily. Either treat the loop as a single aggregated node, or work with the loop unrolled in time, where a command at step k affects a measurement at step k+1 and the graph becomes acyclic again.
• Granger direction inverts. Inside a well-tuned loop, the command anticipates the disturbance, so the command predicts the measurement and looks like its cause. It is not; it is the response to it. Any Granger result computed on closed-loop data must be interpreted with the loop in the model, not against it.
• Correlations get destroyed, not just distorted. A perfectly regulating loop makes the controlled variable independent of the disturbance, so the correlation between the true cause and the measured effect goes to zero. Absence of correlation inside a loop is expected and carries no information about absence of cause.
• Residuals must include the controller. A model-based residual built from the plant model alone will attribute the controller's compensation to model error. The residual has to be computed against the closed-loop model, or generated from a signal the loop does not close around.

Calibration and software as first-class causes

A calibration change is a clean intervention on a structural equation: it replaces one function with another and leaves the physics untouched. That makes a release history one of the most valuable causal datasets available in a vehicle program, because it is a series of dated, documented interventions on a large population, which is very close to an experiment. Case A turns on exactly this.

Three cautions. Releases usually bundle several changes, so the dated boundary identifies the bundle rather than the change. Adoption is gradual and voluntary in an over-the-air world, so the treated and untreated populations differ in ways that are themselves informative and confounding. And a software cause and a hardware cause are not alternatives: the common pattern is a calibration that moves the operating point to where a marginal hardware design stops being adequate, which is a conjunction with one fast-controllable term and one slow one, exactly as in Section 18.

A rate law read forwards predicts a life. Read backwards it dates an event, because damage is an integral and an integral remembers. This turns the part itself into a recording instrument, and it answers the question that decides many investigations: not what happened, but in what order.

Why order usually settles the argument

Two candidate causes are often both present and both plausible, and the evidence for each is equally good. What separates them is sequence. If the oxide layer runs across the fracture surface, the fracture happened before the oxidizing exposure. If wear debris is embedded in a bearing surface, the debris arrived while that surface was still being loaded. If a scratch stops where a corrosion pit begins, the scratch came first. These are not soft inferences; they are physical impossibilities in one direction.

The clocks available on a vehicle part

Superposition: reading order off the surface

When two features overlap, the one that is interrupted or covered came first. Practically this means photographing and mapping features before cleaning anything, because cleaning destroys precisely the superposition relationships that carry the order. The single most common irreversible mistake in failure analysis is a well-intentioned cleaning step performed before the part was mapped.

The same principle runs on the data side. A freeze frame is a snapshot of the operating point at the moment a monitor fired, and two codes with freeze frames give you an ordering plus the conditions at each point. Where high-rate logging exists, the ordering of the first departures across channels is a direct measurement of propagation direction, and it is far more trustworthy than any statistical precedence test, because it is a single event on a single unit rather than an average over a population.

Section 12 computes acceleration factors to two decimal places from an activation energy that is known, at best, to plus or minus a tenth of an electronvolt. That is not a reason to stop computing. It is a reason to carry the uncertainty through the calculation, because the answer to "does the timeline close" is often "it depends on a parameter nobody measured," and knowing which parameter is the most actionable output the screen can produce.

Propagating the uncertainty rather than hiding it

The mechanics are simple enough to do in a spreadsheet. Give every input a distribution rather than a value: a range for the activation energy from the literature, a range for the hot-spot temperature from the thermal model and the sensor placement, a range for the duty cycle from the telematics spread. Sample, evaluate the life model, and collect the outputs. What comes back is not a predicted life but a predicted life distribution, and the useful question becomes where the observed failure sits within it.

The three verdicts from Section 12 then get sharper. Instead of "predicted life is far longer than observed," you get "the observed life sits below the first percentile of what this mechanism can produce across the whole plausible parameter range," which is a falsification that survives an argument about parameter choices. And instead of a comfortable agreement, you sometimes get "the observed life is inside the predicted range, but so is a life ten times longer, so this test has no power," which is worth knowing before anyone presents it as corroboration.

Sensitivity: which unknown is actually in control

With the same samples you can ask how much of the output variance each input is responsible for. The cheap version ranks inputs by the swing in the output when each is moved across its range with the others held at nominal, drawn as a tornado. The rigorous version decomposes the variance itself and handles interactions, which matters here because life models are strongly multiplicative and inputs interact by construction.²¹

Either version produces the same actionable output: a ranked list of measurements worth making. If temperature dominates the tornado, instrument the hot spot rather than arguing about activation energies. If the activation energy dominates, run the accelerated test at two temperatures and fit it rather than taking it from a handbook. A sensitivity plot is a research plan, and it usually shows that one or two inputs carry nearly all of the doubt while the rest can be left alone.

Parameter uncertainty is not the only kind

Sampling parameters explores the space of answers within a model. It says nothing about whether the model form is right, and model-form error is usually the larger term. A one-dimensional thermal path model with a well-quantified conductivity is precisely wrong if the real heat path is three-dimensional. The formal frameworks separate these deliberately: verification asks whether the equations were solved correctly, validation asks whether they are the right equations against measurement, and uncertainty quantification carries the input distributions through.¹² A root cause argument that leans on a simulation should say which of the three it has evidence for, because most have only the first.

The practical guard against model-form error is a prediction the model was not tuned to make. If the thermal model was calibrated on steady-state temperatures, ask it to predict a transient, or a second location, or the sensor lag, and then go and measure that. A model that survives a prediction outside its calibration set is worth something in an argument; one that only reproduces its own fitting data is worth nothing.

Stating the verdict honestly

The output of all this is a sentence with a confidence and a falsifier attached, not a number. A defensible form: the mechanism is X; it accounts for the observed damage and, at the measured stressor levels, for the observed timing within the parameter uncertainty; the dominant remaining uncertainty is Y, which if it were at the far end of its range would extend the predicted life by a factor of Z; the finding would be overturned by observing W. Reviewers can argue with each clause, which is the point. A verdict nobody can argue with in detail is a verdict nobody can check.

An investigation is only as good as its evidence discipline. Two habits separate strong investigations from weak ones: classifying evidence by what it can and cannot establish, and assigning each item a weight before checking which hypothesis it favours.

The six kinds of evidence on a vehicle failure

Grading an item of evidence

Four questions, each of which independently reduces weight when the answer is unfavourable.

• Directness. Does it observe the mechanism, or something downstream of it? A fatigue striation count is direct. A DTC is three inferential steps removed.
• Independence. Does it add information, or does it repeat information you already counted? Ten vehicles from the same build lot are close to one piece of evidence, not ten. This is the single most common way investigations become overconfident.
• Discrimination. Does it separate the hypotheses, or is it equally likely under all of them? Evidence consistent with every candidate has a likelihood ratio of one and changes nothing, however impressive it looks in the report.
• Falsifiability. Was there a real chance of the opposite result? A test that could only ever have confirmed the hypothesis contributes nothing.

Weighing by likelihood ratio

The clean way to combine heterogeneous evidence is Bayes on the odds scale, where each independent item contributes a multiplicative likelihood ratio and the arithmetic is transparent enough to argue about in a review.

Here is the actual procedure, assembled from everything above. It is written as a loop rather than a sequence, because evidence changes the hypothesis set and the hypothesis set changes which evidence is worth collecting.

The hypothesis ledger

Keep one table, visible to everyone, with a row per candidate mechanism and these columns: prior plausibility and why; the predicted observables the mechanism requires; the observables it forbids; the evidence for and against, each with its likelihood ratio; the discriminating test that would separate it from the nearest rival; and current posterior. The ledger does three things that unstructured discussion does not. It makes forbidden observations explicit, so falsification is possible. It makes the next action obvious, since you run the test with the highest expected information. And it prevents the quiet disappearance of a hypothesis that nobody argued against but everybody stopped mentioning.

Necessity, sufficiency, and what "the" cause means

Real failures rarely have a single necessary and sufficient cause. The useful formalization is the INUS condition: a cause is typically an insufficient but necessary part of a condition that is itself unnecessary but sufficient for the effect. Fretting corrosion needs micro-motion and the absence of a protective film and low contact normal force; that conjunction is sufficient, none of its members is sufficient alone, and there are other sufficient conjunctions that produce an open circuit. So the question is never "what was the cause," it is "which member of the operative conjunction is both real here and controllable by us." That is a design and process decision as much as a physics one, and it is legitimate for two organizations to name different root causes for the same failure if they control different terms.

Designing a discriminating test

A test is worth running in proportion to how much it changes your posterior, which means the best test is the one where the surviving hypotheses predict the most different outcomes. Concretely: write the predicted outcome under each hypothesis, and if two rows are the same, the test is worthless for separating those two no matter how expensive or sophisticated it is. This is the fault signature matrix from Section 13 applied to laboratory work rather than to sensors.

Stopping rules

Stop climbing when three conditions hold at once: the mechanism is identified and quantitatively consistent with the observed timeline and damage; the earliest condition you have reached is inside someone's control; and you have separately identified why the existing controls did not detect it. Stopping earlier gives you a symptom-level fix. Stopping later drifts into organizational abstractions that no corrective action can address.

Verification: the only step that actually proves anything

The claim under test is counterfactual, so verification must be interventional. In descending order of strength: remove the condition on a population and observe the effect disappear; reintroduce it deliberately on a sample and observe the effect return, which is the single most convincing evidence available and is what 8D calls confirming the escape; reproduce the failure on a rig with the field stressor magnitudes measured rather than assumed; or, when none of those is possible, run the intervention in a validated simulation, which is a genuine do() operation whose credibility rests entirely on the model's validation record.

The analysis is finished when someone who was not in the room can read the statement, understand what happened, see why the alternatives were rejected, and know what would overturn it. Most reports fail at the second and fourth of those. Here is a structure that does not.

The slots

Eight, in this order. Each is one or two sentences. If a slot is empty, the investigation is not finished, and saying so is more useful than filling it with confident prose.

A worked statement, for Case A

Wording rules that matter more than they look

• Separate observation from interpretation, visibly. "The thrust face shows a polished band transitioning to circumferential scoring" is an observation. "The film collapsed" is an interpretation. Mixing them in one sentence makes the interpretation unchallengeable, which is convenient and wrong.
• Name the mechanism, never the part. "The connector failed" tells the reader nothing and blocks the next question. "Fretting corrosion of the tin plating at terminal 4" tells them what to go and control.
• Do not let a human or a supplier be the terminal cause. "Operator error" and "supplier quality escape" are places where investigations stop rather than answers. Ask what made the error possible and what the control was supposed to be, and put that in slot 7.
• Give magnitudes, not directions. "Higher temperature" is unfalsifiable. "Face temperature roughly 20 K above the value assumed in validation" can be checked and, if wrong, corrected.
• Write the confidence in the same voice as the finding. Hedging language scattered through the technical sections reads as weakness; a single explicit confidence clause at the end reads as rigour. Same information, very different reception, and the second one is also easier to revise later.
• Assume it will be read outside engineering. Field action, legal and supplier discussions all read this document. Speculation written as fact is the specific thing that causes trouble there, and slot 8 is where speculation belongs, labelled.

The four cases above are constructed. These three are not: each has a published, independently reviewed report, and each is instructive for a different reason. Read through the framework, they show what the four levels look like when the stakes are real and the analysis is adversarial.

The three families answer different questions and fail in different ways, so the practical question is never which is best but which combination covers your blind spots. This table compares them on the dimensions that decide that.

Which to reach for, given what you have

• One failed part, no fleet data. Forensic evidence plus levels 1 and 3. The energy budget and the damage morphology carry the case; statistics has nothing to work with.
• A fleet rate change with a clear date boundary. Change analysis first, then difference-in-differences on the boundary, then physics to explain why the change matters. The date boundary is a gift; use it before doing anything expensive.
• A fleet rate that is elevated with no boundary. This is the hardest case. Stratify by physics-derived exposure variables rather than by convenient categorical fields, then look for the subpopulation whose load distribution differs.
• Repeated no-fault-found. Go straight to level 4. Write down the activation conjunction, then build the combined-environment test. Do not collect more of the same bench data.
• Many logged channels and a vague symptom. Constrain the graph with physics, then run causal discovery inside the constraints, then confirm the surviving edges with a residual designed from the mechanism.
• A safety-relevant event. Fault tree for the sufficiency structure, event tree for propagation, physics for each basic event's rate, and barrier analysis for every control that did not act.

Put together, the three families form a pipeline in which each stage passes a smaller, better-justified set forward. The important architectural point is that physics enters twice, early as a constraint on structure and late as a counterfactual engine, and those are different jobs.

Reading the pipeline backwards

Most failed investigations can be described as entering this diagram at the wrong end. A team starts at TEST with a favourite hypothesis, books the rig, and gets a result that confirms it. The step they skipped is RANK, and its absence means nobody ever asked which rival the expensive test could not have separated. The answer is usually "most of them," and the investigation reopens six months later.

Several stages here are mechanical enough to hand to software, and several are not, and the line between them is sharper than it looks. Section 27 draws it.

Most of the work in an investigation is not insight. It is finding the relevant DFMEA lines, pulling the build records, normalizing evidence from six systems that disagree about part numbers, running the same four screens again, and keeping the arithmetic straight. That work is mechanical, it is where the calendar time goes, and it is automatable. The insight is not, and pretending otherwise is how automated root cause tools acquire their reputation.

The dividing line: what has a verifier

A step is safely automatable when a machine can check the answer without a human. That is a stronger condition than being able to produce an answer, and it is the only condition that matters, because an unverifiable generated claim in a causal chain is worse than no claim at all: it is fluent, it is plausible, and it propagates.

What an evidence record has to carry

The normalization layer is where most of the value is created, and its output format decides what the rest of the system can do. A record that is worth anything carries: the claim in one sentence; the class from Section 17; the source, specific enough to reopen; the observation date and the date the condition it describes obtained, which are different; the unit or population it applies to; the measurement and its uncertainty where there is one; and the hypotheses it bears on with a proposed likelihood ratio and a rationale. Records without a resolvable source are dropped rather than downweighted, because an unsourced claim in an evidence base is a slow-acting poison.

Two fields earn their keep out of proportion to their cost. Independence group: a tag shared by records that derive from the same underlying observation, so the ledger can refuse to multiply their likelihood ratios. And forbidden-by: which hypotheses this observation is inconsistent with, so falsification is a first-class operation rather than an afterthought.

Where a generated causal claim must not be trusted

• Any claim of the form "X caused Y" with no mechanism attached. A model will produce these fluently because they are the most common sentence shape in the training material. Require a named mechanism and a governing relation, or reject.
• Likelihood ratios that arrive already pointing at the leading hypothesis. Ask for the ratio before revealing which way the evidence points, exactly as you would with a person, then check that the numbers were not tuned to the conclusion.
• Confident interpolation across a regime boundary. Rate laws stop applying and mechanisms change; a model extrapolating an Arrhenius fit past a phase change will do so smoothly and wrongly. Make the valid range a required field on every rate law in the database.
• Summaries that quietly drop a hypothesis. The ledger, not the narrative, is the state of the investigation. If a hypothesis leaves, the record should say which evidence removed it.

Every case in this document ends with a detection finding, and every detection finding is a monitor specification waiting to be written. This section is how the one becomes the other, because a confirmed mechanism hands you almost everything a prognostic needs: the quantity that accumulates, the law that governs it, and the threshold that matters.

The mechanism picks the health indicator

A rate law is a statement about what integrates. Choose the health indicator to be that integral, or the closest observable proxy for it, and the rest of the prognostic falls out. Wear mechanisms integrate load times distance, so the indicator is a wear proxy such as clearance, endplay or a vibration order tied to clearance. Thermally activated aging integrates time at temperature, so the indicator is a resistance, a capacity, or a leakage that tracks the accumulated exposure. Fatigue integrates cycles weighted by amplitude, so the indicator is a Miner-style damage sum computed from a load histogram the vehicle already builds.

Four properties decide whether a candidate indicator is worth building, and they are worth checking before any modelling effort. It must be monotonic, since a quantity that recovers is measuring something other than accumulated damage. It must be observable early, well before the failure threshold, or the warning arrives too late to matter. It must be separable from unrelated operating conditions, or every hill climb produces an alert. And it must be cheap, meaning computable from signals the vehicle already has, because a monitor that needs a new sensor competes with the rest of the bill of materials and usually loses.

Three families, and when each is the right answer

• Model-based. A physics degradation model with online parameter estimation, usually a particle or Kalman filter. Best when the mechanism is known and instrumented, which is exactly the situation after a good root cause investigation. Extrapolates to conditions never seen in the training data, which is its decisive advantage.
• Data-driven. Learn the degradation trajectory from run-to-failure data. Best when the mechanism is complex or unknown but examples are plentiful. It cannot extrapolate past the conditions in the data, and it will fail silently rather than loudly when the fleet's usage distribution shifts.
• Hybrid. Physics supplies the structure and the constraints, data supplies the parameters and the residual terms the model does not capture. This is where most production work lands, and it inherits the extrapolation behaviour of the physics as long as the learned part stays a correction rather than the whole model.

What good looks like, quantitatively

Two properties matter more than point accuracy. The prognostic horizon is how far ahead the prediction first becomes and stays acceptably accurate, and it is the number that decides whether the monitor is useful: a warning that arrives two hundred miles before failure is not a warning, it is a notification. And convergence is whether the prediction tightens as the failure approaches rather than wandering; a monitor whose interval widens near the end is telling you the model form is wrong.

Both are more useful to a program than a mean absolute error, because both map onto decisions. The horizon sets whether parts can be pre-positioned and service scheduled; convergence sets whether a technician should believe the number when it finally becomes actionable.

Closing the loop from the four cases

• Thrust bearing. The indicator is axial clearance, and the cheap proxy is the axial-order content in structure-borne noise, or timing jitter on the crank position signal. The rate law is Archard, so the accumulator is a load-distance product the vehicle can compute from torque and speed it already logs.
• Magnet demagnetization. The indicator is magnet flux linkage, measured by a periodic coast-down back-EMF check. The mechanism has a threshold rather than a smooth rate, so the useful prognostic is not a remaining life but an exposure counter: time spent inside the joint temperature and current region that approaches the knee.
• Battery module. The indicator is per-cell direct-current resistance, trended over charge sessions, computed from existing current and voltage. This is the archetype of a free monitor, and Case C turns on the fact that it was not being computed.
• Connector. The indicator is the statistics of short resistance excursions during vibration, which needs a monitor fast enough to see them and a counter that survives ignition cycles. Note that the diagnostic requirement here is a sampling rate, not a sensor, which is the cheapest kind of requirement to meet and the easiest to omit.

When the failure has safety relevance, the investigation acquires a second audience with different vocabulary, a different evidence standard, and a clock. Engineers who have not worked in that space usually discover it late, which is expensive. This section is the translation layer.

The vocabulary, aligned to the chain in Section 01

Functional safety splits what this document has called a failure into three stages, and the split is useful rather than pedantic. A fault is the abnormal condition, the resistance rise, the demagnetized magnet, the cracked joint. An error is the resulting deviation in a computed or transmitted value. A failure is the loss of the intended function. A mechanism can produce a fault that never becomes an error, and an error that never becomes a failure, and the whole business of safety architecture is inserting detection and reaction between those stages.

The timing definitions follow from that. The fault tolerant time interval is the span from the fault occurring to the hazardous event, if nothing intervenes. Within it, the system must detect the fault and reach a safe state: the detection time plus the reaction time must fit inside the interval, with margin. This is the constraint that decides diagnostic design, and it is a physics constraint before it is a software one, because the interval is set by how fast the physical consequence develops.

What the safety argument needs that a root cause does not

An investigation answers what happened on these units. A safety argument answers what will happen across the population, which needs three things the investigation may not have produced. A rate for the mechanism, expressed per hour of operation, which requires the population and exposure work from Section 07 rather than a count of returns. A diagnostic coverage figure: what fraction of the ways this mechanism can express itself is detected in time, which is a level-4 question and is usually the weakest number in the whole argument. And a failure classification: whether the fault alone violates the safety goal, or only in combination with a second fault that has been sitting latent, since the two are treated very differently.

The practical consequence for the investigator is that "we found the mechanism" is the beginning of the safety conversation and not the end of it. Budget for the rate estimation and the coverage assessment as part of the investigation, because they will be requested, and because doing them late means doing them under time pressure.

The clock, and how it changes the work

In the United States, a manufacturer that determines a defect related to motor vehicle safety exists must furnish a defect information report to NHTSA within five working days of that determination, and then notify owners and remedy the defect.²⁶ Separately, the early warning reporting regulations require periodic submission of field data including claims, so the regulator is looking at a version of the same population data the investigation uses.²⁷

Two things follow, and both change how the technical work should be run rather than merely how it is reported.

• Evidence discipline becomes non-negotiable. Chain of custody on returned parts, dated records of what was known when, and a clear separation between observation and interpretation, all of which are good practice anyway and become essential when the file is read outside engineering. Section 19's wording rules exist largely for this.
• The population estimate is a live deliverable. Which units could carry the condition, on what basis, and with what confidence. This drives scope, and it is a traceability and stratification problem more than a physics one. Investigations that leave it until the mechanism is settled routinely find that the genealogy data needed to bound the population was never queryable in the first place.

Every case in this document contains a moment where the answer turned on data that either existed by luck or did not exist at all. Case C was solved by a voltage divergence nobody was mining; Case D was delayed by three bench tests that could not, in principle, reproduce the fault. Neither outcome was inevitable. Diagnosability is a design property, and it can be specified.

It is a structural question before it is a sensor question

Given a set of model equations and a set of candidate sensors, it is possible to determine which faults are detectable and which pairs are isolable, purely from the structure of which variables appear in which equations, before any numbers are known. The tools come out of the model-based diagnosis literature, where sensor placement is posed and solved as an optimization: find the cheapest sensor set that makes the required faults detectable and the required pairs isolable.²⁸ The practical value for a program is that this can be run at concept stage, on the same models the control team is already building, and it answers the question that otherwise gets answered five years later by a warranty problem.

What to specify, in rough order of value per dollar

• Log the quantity the rate law integrates, not just the state. If the mechanism consumes thermal cycles, count and bin them. If it consumes load times distance, accumulate that product. A counter is a few bytes and it converts every future investigation from inference to measurement. This is the single highest-return item on the list and it is almost always missing.
• Keep adaptation and learned values, with their history. They are the integral of everything the control loop absorbed, which per Section 14 is where a slowly developing fault actually lives. Store at least a coarse history rather than only the current value, and record when they were last reset.
• Make freeze frames sufficient to reconstruct the operating point. A code with a snapshot that omits temperature, load and the relevant command is a timestamp, not evidence. The test is whether a level-2 model could be run from the snapshot alone.
• Set debounce from the physics, not from convention. Case D fails because the excursion is shorter than the confirmation window. Every monitor's confirmation time should be justified against the time constant of the mechanism it is meant to catch, and where the mechanism is fast, count events rather than requiring persistence.
• Derive features from signals you already have. Per-cell resistance from existing current and voltage, an order-tracked band from an accelerometer already present for another function, a damage sum from a torque and speed history. These cost compute and calibration effort, not hardware, and they are where most of the achievable coverage actually lives.
• Keep build genealogy queryable, not merely archived. The population bounding question in Section 29 is a database question. If answering "which units received lot X through station Y in week Z" takes three weeks, that is three weeks added to every field investigation the program will ever run.
• Preserve a sample of the population, physically. Retained parts from known build points, stored unopened, are the only way to establish what the as-built condition was once the process has drifted. They cost warehouse space and they settle arguments that are otherwise unsettleable.

The DFMEA hook that makes this stick

None of the above happens because someone writes a guideline. It happens when the design analysis has a column that forces the question. Add one to the DFMEA next to the existing detection controls: for each failure mechanism, what observable would this produce in service, in which channel, at what magnitude, and under what operating condition. Most rows will come back empty on the first pass, and that emptiness is the deliverable: it is a ranked list of mechanisms the program has chosen to be blind to, visible while there is still time to change it.

The AIAG-VDA structure already has the right place for this, because the monitoring and system response supplement exists precisely to connect design analysis to in-service detection. Using it as a genuine diagnosability specification rather than a compliance artifact is a small change in habit with a large effect on how the next five years of field investigations go.

The investigation is a system, and it has its own failure modes. These are the ones that recur.

• Stopping at a symptom that happens to be actionable. "Replace the connector" closes the ticket and returns next quarter. The test is whether the named cause explains the boundary, the timing, and the damage morphology, or only the complaint.
• The single-cause reflex. Real mechanisms are conjunctions. A report that names one condition and does not list the others that had to be present simultaneously is hiding a choice it should be making explicitly.
• Treating a fitted model as a mechanism. A model that reproduces the data after its parameters were tuned to the data has demonstrated flexibility, not truth. The test is prediction on data the model was not fitted to, ideally at a different operating point.
• Counting correlated evidence as independent. Twenty vehicles from one build lot, or five channels that are all functions of the same underlying signal, are close to one item of evidence. Multiplying likelihood ratios across them manufactures certainty out of nothing.
• Confirmation search. Once a leading hypothesis exists, the natural next test is the one that would confirm it. The valuable test is the one that would break it. Ask what result would make you abandon the hypothesis, and if there is no such result, you are not doing an investigation.
• Using absence of a code as absence of a fault. Only valid after the detectability calculation in Section 13.
• Rebuilding the analysis around whatever data is convenient. The available channels shape the hypotheses considered, so mechanisms that are invisible in the logged data quietly stop being discussed. Generate the hypothesis list from physics and the DFMEA first, then ask what data would test each one, in that order.
• Skipping the detection root cause. Every escape has two answers: why it happened, and why nothing caught it. Reports that answer only the first leave the organization exactly as blind as before.
• Declaring closure without an intervention. If nothing was turned off and observed to stop, or turned on and observed to start, the claim remains a hypothesis with good supporting evidence. Say that in the report; it is an honest and defensible position, and it keeps the file open at the right level of confidence.

Everything above, compressed to what fits on one side of a card. Print it, or keep the tab open during the review. The value of a card is not that it teaches anything new, it is that it interrupts the two habits that cost the most: converging on the first plausible story, and running the expensive test before the cheap screen.

Terms as this document uses them. Several have looser everyday meanings, and the looseness is where a lot of failure-review disagreement actually lives.