Narrow by Elimination vs by Most-Likely-First Decision Tree

Why this matters

There are two ways to hunt a fault. You can work by elimination, splitting the system and ruling out half at a time until one suspect remains, or you can work by most-likely-first, going straight to the part that usually fails for this symptom and testing it. Both are correct in the right situation and slow in the wrong one. Most-likely-first is a sprint that wins when the prior is strong and the test is cheap; elimination is a search that wins when no single cause dominates or when a wrong guess is expensive to recover from. A tech who only ever guesses the common part gets burned on the uncommon fault; a tech who always bisects wastes time on faults that had an obvious answer. This article gives the rule for choosing.

Symptom presentation

The symptom is any fault with multiple candidate causes where you have to pick a search strategy. The candidates may be a known short list (a no-start has maybe five usual causes) or a sprawling fault space (an intermittent whole-system issue could be a dozen things). The choice of strategy is independent of the trade; it depends on the shape of the candidate list and the cost of a wrong move.

The signal you are reading is your own confidence distribution. Is one cause far more likely than the rest, or are several roughly equal? That single judgment routes the whole approach.

Quick checks before choosing a strategy

List the candidate causes for the confirmed symptom. You cannot pick a strategy without the list. Note roughly how the probability spreads across it: peaked on one cause, or flat across several.

Estimate the cost of being wrong. If guessing the likely part and being wrong costs five minutes and a reseated connector, the downside is small. If it costs a returned part, a drained system, or a torn-open wall, the downside is large.

Check whether a single test cleanly bisects the system. If there is a natural midpoint (a junction, a valve, a terminal block, a stage boundary) where one reading rules out everything upstream or downstream, elimination is cheap to run.

Isolation tree

Branch A: one cause dominates the probability and its test is cheap. Go most-likely-first. For a symptom with a textbook common failure (the part that fails on this model nine times out of ten), test that part first. Bisecting a system when the answer is almost certainly one known part wastes the customer's time on rigor that the odds do not require.

Branch B: probabilities are flat across several candidates. Use elimination. With no dominant suspect, guessing is a coin flip with several sides; bisecting the system rules out whole groups per test and converges faster than testing equal-odds candidates one at a time.

Branch C: the most-likely part is expensive to test or replace. Switch to elimination even if one cause is somewhat favored. When a wrong guess means a returned part or a destructive teardown, the cost of error outweighs the speed of the guess; eliminate the cheaper branches first so the expensive test is the only one left.

Branch D: a clean bisection point exists. Prefer elimination, because one well-placed test cuts the candidate list in half regardless of which side is more likely. A power-present check at a midpoint, a pressure reading at a manifold, a signal check at a board output each split the system in one move.

Branch E: the fault is intermittent. Most-likely-first usually fails because the part tests fine when the fault is absent. Use elimination of conditions and triggers rather than of components, or capture the fault before testing anything.

Branch F: you have strong history pointing at a recurring part. Treat history as a high prior and go most-likely-first on that part, but confirm it is actually failing this time rather than assuming the repeat. A part that failed twice can fail a third time, or the symptom can have migrated to a different cause.

Branch G: a guess already failed. Stop guessing and switch to elimination. One wrong most-likely-first attempt means your prior was off for this specific unit; continuing to guess the next-most-likely part is how a visit turns into a parts cannon. Bisect from here.

Confirming diagnosis

Whichever strategy you use, the diagnosis is confirmed the same way: a reading or observation that proves the specific cause, not a part swap that happened to coincide with the symptom clearing. Most-likely-first is especially prone to false confirmation, because swapping the common part can mask a different fault temporarily.

Re-test after the repair to confirm the symptom is gone and stays gone under the condition that triggered it. A most-likely-first fix that clears the fault only at rest, while the real fault appears under load, is not confirmed.

Record which strategy you used and the result. If a guess was wrong, that calibrates your priors for the next unit of the same model.

Next steps

When the strategy resolves to a confirmed cause, proceed to the repair tree for that component. When most-likely-first misses twice, commit fully to elimination and stop returning to the guess instinct mid-search; mixing the two leaves both half-done.

When elimination narrows to a single suspect, confirm it before condemning it, the same as you would a most-likely-first guess. The strategy chooses the path, not the standard of proof.

References

• ISO 13379-1 (Condition monitoring and diagnostics of machines; diagnostic reasoning and fault localization).
• ISO 14224 (Reliability data collection; failure-mode probability and prior-likelihood data).
• NFPA 70B (Standard for Electrical Equipment Maintenance; systematic versus targeted diagnostics).
• ASHRAE Handbook (HVAC Applications; equipment troubleshooting methodology).