Define the failure precisely
Separate the observed symptom, violated requirement, consequence, and conditions that reproduce it.
Diagnose before redesign
Mechanical Root-Cause Analysis That Separates Evidence from Assumption
I structure failure evidence, build competing hypotheses, use physics and targeted tests to discriminate among them, and develop corrective directions with defined verification.
Signals this work is needed
- A failure recurs despite multiple local changes.
- Field, production, and laboratory behavior do not agree.
- Symptoms vary with build, orientation, temperature, wear, or operator.
- A supplier and design team disagree on responsibility without controlled evidence.
- Performance margin is inadequate or unexplained.
What I evaluate
- Failure definition, frequency, severity, operating state, and detection method
- Configuration, lot, environment, duty, history, and changes correlated with the issue
- Loads, interfaces, energy paths, motion, contact, wear, thermal effects, and tolerance
- Failed versus known-good comparison and preservation of evidence
- Competing hypotheses and observations that would discriminate among them
- Corrective-action risk, containment, and verification requirements
Approach
A practical path from uncertainty to a buildable result.
Build the hypothesis tree
Develop plausible mechanisms across design, part variation, assembly, supplier process, test system, environment, and use.
Discriminate with evidence
Use bounding calculations, controlled comparisons, inspection, and targeted tests that can reject hypotheses.
Correct and verify
Develop the simplest robust corrective direction, then verify the mechanism and guard against coupled regressions.
Typical deliverables
- Failure statement and evidence timeline
- Hypothesis tree and discriminating-test plan
- Load, tolerance, motion, thermal, or wear calculations
- Failed/known-good comparison plan
- Corrective architecture concepts
- Verification, containment, and regression plan
Engineering considerations
- Correlation is useful evidence but not proof of mechanism.
- A failed part can be the victim rather than the cause.
- Containment and permanent correction are different decisions.
- Changed parts and undocumented rework can erase evidence.
- A correction should remove sensitivity, not merely retune a fragile condition.
A productive fit
- The failure can be defined and evidence can be preserved.
- Known-good or variant comparisons are available.
- Stakeholders will support discriminating tests and accept conclusions that challenge the current theory.
Usually not a fit
- Only a preferred conclusion is acceptable.
- Failed hardware and relevant history cannot be accessed.
- The request is for a compliance or legal determination outside the engineering analysis.
Questions
Practical details before the first review.
Can you work from limited failure data?
Yes, if uncertainty is explicit. I begin with the evidence available and identify the smallest observations or tests that would materially improve confidence.
How do you avoid random test-and-fix cycles?
Every test is tied to a hypothesis and a predicted discriminating outcome before it is run.
Does root cause always mean one cause?
No. A failure may require a design sensitivity, production variation, operating condition, and detection gap to align. The corrective strategy should address the controllable contributors.
Direct senior involvement
Turn the product decision into a clear next step.
Share a non-confidential summary, the current stage, and the outcome the team needs.
Discuss Your Project