Rule It Out

Something is wrong and eight things could be causing it. A list of checks is available and every one costs time you do not have much of. Run a check, read the answer, and whatever it eliminates crosses itself off. One of the checks is cheap, sounds like the obvious first move, and rules out nothing at all — every room runs it. The debrief compares what you spent against the cheapest route that actually existed, worked out by trying every order, and tells you whether your first move split the field or poked at a hunch. Five looks ship with it — the activity’s own, plus a control room, a workshop, an observatory and a winter market, drawn in the file itself with no images to load.

Open the activityDownload

Problem

People run the check that would confirm what they already suspect. The check that halves the field is almost always a different one, and it feels worse to run because it does not point at anything — it only removes possibilities. Nothing in normal troubleshooting training makes that trade-off visible, because there is no cost attached to asking.

Who it helps

Operations, service desk, quality and billing teams who diagnose faults, and anyone teaching troubleshooting or root-cause work rather than a fixed script.

In training

Make them say what a check will rule out before they run it. That single habit is the whole activity, and a room that starts doing it unprompted has got the point. When someone burns the budget on the reassurance question, do not move past it — ask what they expected it to eliminate. “Nothing, I just wanted to know” is the honest answer and it is worth hearing out loud.

Skills shown

Diagnostic sequencing, information-gain framing, exhaustive shortest-path search for scoring against a real optimum, budget-constrained decision design, in-browser editing with persistent export.