The Rare vs Common Cause Bet: Decision Tree

Why this matters

Most faults have a common cause and a long tail of rare ones, and good diagnosis is partly a betting game: where do you spend your first move? Bet on the common cause every time and you are fast and usually right, until the rare fault burns you with a wrong part and a callback. Chase the exotic cause first and you waste the customer's time and money proving the obvious thing was not the problem after all. The phrase "when you hear hoofbeats, think horses, not zebras" is the rule, and the skill is knowing when a zebra is actually in the room. This tree gives you the signals that should shift your bet from common to rare.

Start here: lead with the common cause

The default is correct because it is usually correct. For any symptom, start with the cause that fails most often for that symptom on that kind of equipment, especially if its test is cheap.

If the common cause tests bad, you are done; the odds paid off and you fixed it fast. This is the outcome most of the time, and it is why you start here.

If the common cause tests good, the bet did not pay, but you have lost almost nothing because the test was cheap. Now genuinely consider the tail. Do not test the common cause a second time hoping for a different answer.

Signal one: the common cause was already tried

History overrides probability. If the usual suspect has already been replaced and the fault is back, the common cause has had its turn and lost.

If the record or the customer says the common part was recently replaced and it failed again, stop betting on it. Either it is being destroyed by an upstream cause or the real fault is elsewhere. The repeat failure is pointing you at the tail.

If there is no such history, the common cause is still the right opening bet.

Signal two: the symptom does not fit the common cause cleanly

A common cause produces a characteristic symptom pattern. When the actual symptom is off-pattern, that is evidence the common cause is not it.

If the symptom has an odd feature the common cause does not explain (wrong timing, an extra noise or smell, a condition dependency that does not fit), weight the rare causes higher. The mismatch is the tell.

If the symptom is textbook for the common cause, stay with the common bet; the clean match is real evidence.

Signal three: weigh the cost of a wrong bet

The right bet is not only about probability; it is about probability times the cost of being wrong. A cheap, reversible test on the common cause is worth taking even at modest odds. An expensive, irreversible commitment is not, even when the common cause is favored.

If confirming the common cause is cheap and reversible, take that bet first regardless of a slightly elevated rare-cause suspicion. The downside of a miss is tiny.

If acting on the common cause means an expensive part or a destructive teardown, do not bet on probability alone. Eliminate the rare causes that are cheaper to rule out first, so you are not committing big money to a guess.

Signal four: the pattern across multiple jobs

If you are seeing the same "common cause tested good" result across several recent jobs, the rare cause may not be rare in this batch. A bad lot of parts, an environmental factor, or a model-specific weakness can make a normally-rare cause locally common.

If several recent units show the same off-pattern symptom, treat the suspected rare cause as a working theory rather than a long shot. The cluster is data.

If this is an isolated case, judge it on its own signals without reading a pattern that is not there.

The decision

Bet common first, because horses outnumber zebras, and take that bet immediately when its test is cheap and the symptom fits. Shift toward the rare cause when the common cause already tested good, when it was already replaced and failed again, when the symptom does not match its pattern, when committing to it is expensive enough that the cost of a wrong bet outweighs the odds, or when a cluster of jobs says the rare cause is not rare right now. Never let "it is usually this" become "it must be this" after the test came back good. The discipline is to bet the odds at the start and to update honestly when the evidence says the long shot came in.

What to document

Record which cause you bet on first and why, that you confirmed or ruled it out with a test, and what shifted you toward a rarer cause if you went there. If you suspect a batch issue or a model-specific weakness, note it, because that is exactly the pattern that helps the shop catch a "rare" cause that is quietly becoming common. A record of which bets paid and which did not is how a tech's odds-reading gets sharper over time.

References

• Manufacturer service bulletins and failure-rate documentation (basis for common-versus-rare prior probabilities and known model weaknesses).
• Electronics Technicians Association International (ETA), probabilistic diagnostic methodology.
• See related: Narrow by Elimination vs by Most-Likely-First Decision Tree; The Obvious Cause Is Wrong Decision Tree; Parts Cannon vs Diagnosis: The Discipline.