Several explanations can fit the same observation
An ambiguous fault is one where the evidence fits more than one explanation. Do not try to list every possible cause. Pick the ones that could reasonably explain it. Then look for the evidence that could tell them apart.
Evidence helps most when each explanation predicts a different result. If two explanations both predict the same dashboard alarm, reading that alarm again tells you little. Comparing timing, which units are affected or a measurement from an independent source may tell you more.
Separate the variables before choosing a cause
Swipe sideways to follow the full diagram →
Keep rival explanations alive long enough to test them
Complex incidents often have evidence that fits several causes. Build an evidence matrix: a table with one row for each explanation. For each one, list the evidence for it, the evidence against it and one open question. A familiar failure deserves a look, but it does not go first automatically. Label each statement as a fact (something observed or measured), an inference (a conclusion you reasoned out) or an assumption (something not yet checked).
Choose checks that stay within approved boundaries. Before you check, write down what result would change your mind. Let the quality of the evidence set your confidence, not how many people repeat an opinion.
Maintain a decision record
Keep a timeline. For each observation, note where it came from and whether its clock might be wrong. For each decision, note what evidence you had at that time. Record the other explanations you considered and why you chose the next step. A missing log entry does not rule out an event if that source could not record it. A copy of the same dashboard view is not a second, independent confirmation.
When new evidence appears, update the explanation. Keep the earlier decision and its context in the record. Write the open question clearly enough that a specialist can take it over. Incomplete evidence and pressure to keep production running never expand what you are authorized to do. They never justify crossing a safety boundary.
Worked example: heat or a recent change?
Errors increase after a firmware update that was rolled out during the hottest week of the month. Either the new firmware or the heat could explain it.
Say you compare updated units in a hot area with units still on the old firmware in a cooler area. That comparison mixes two questions, so it cannot separate them. Compare groups that match in conditions and time window, and note any difference in how the groups were chosen. Even if errors cluster in the updated group, you may need more evidence before naming how the failure happens. Start by comparing what you can observe without changing anything. Any test that changes equipment or settings needs its own approval and stop criteria.
Optional references & further reading
Use current manufacturer instructions for the exact equipment and your site’s approved procedures. Course levels do not grant task authorization.