Run a Guided Differential Diagnosis

Tier: Core · Workflow area: Troubleshooting & diagnosis · ~30 minutes

This is the clinical method applied to infrastructure: enumerate the differential, design the test that splits the candidate list, run it, prune, repeat. The model contributes breadth (causes you did not consider) and discipline (tests chosen to discriminate, not confirm). You contribute ground truth, judgment and the hands on the keyboard.

When to use

• The stuck ticketsecond day, third engineer, or your third "certain" fix that changed nothing. Fixation is the disease; the differential is the cure.
• Intermittent problemssymptoms that come and go resist single-hypothesis troubleshooting; a differential tracks multiple live candidates across days without losing state.
• Multi-layer symptoms"slow app" where the cause could be endpoint, network, server or the app itself; the method forces layer-splitting tests early.

When NOT to use

• Known-error lookupsif the symptom matches a KB or known-error record, run that first; the differential is for genuine unknowns.
• Time-critical outagesduring a P1, run your incident playbook and the obvious reversals (rollback, failover); differential diagnosis is a between-incidents and hard-ticket tool.

The recipe

1. 1.

   Write the case statement. One tight paragraph: symptom, scope (who/how many), timeline (since when, any correlation with changes), and the facts already established. Rigor here pays through the whole session — include negative findings ("OWA works") which are usually the most discriminating facts you own.

2. 2.

   Open the differential.

   Copy

   Act as my differential-diagnosis partner on an IT infrastructure problem.
   
   CASE: Sales team (12 users, one office) report Teams calls dropping after
   2–3 minutes since Tuesday. Chat and file sync unaffected. Other teams in
   the same office are fine. No change requests logged for that floor.
   Established: wired users affected as well as Wi-Fi; one affected user
   worked fine from home yesterday.
   
   Rules of engagement:
   1. List ALL plausible causes first (aim for 6–10, grouped by layer:
      endpoint / LAN / WAN-firewall / service). For each: prior likelihood
      and what evidence we already have for or against.
   2. Then propose ONE next test — the test that best splits the remaining
      candidates. Tell me exactly what to run, what result supports which
      branch, and what it costs (time, user disruption).
   3. Wait for my result before proposing the next test. Update the candidate
      list with each result: state what is eliminated and why.
   4. Never declare a root cause while 2+ candidates remain unless the
      evidence is decisive. If I show fixation on one theory, say so.
   

   The "one test, then wait" rule is what makes this a method rather than a listicle — it stops the model from dumping a 12-step generic checklist and stops you from cherry-picking the steps you already believed in.

3. 3.

   Keep the elimination worksheet as you go. A four-column table in the ticket or a scratch file: candidate | status (live/eliminated) | evidence | test that decided it. The model tracks state in-conversation, but conversations get lost and colleagues cannot read your chat history; the worksheet is the durable artifact.

   Copy

   candidate                     | status     | evidence
   endpoint (client/driver)      | ELIMINATED | affected user fine from home; wired+wifi both hit
   Teams service regional issue  | ELIMINATED | other floors same tenant fine; no advisory
   floor switch QoS/config       | LIVE ★     | scope matches one access switch exactly
   firewall UDP timeout          | LIVE       | 2–3 min drop pattern is classic UDP-timeout shape
   DNS/DHCP scope on that VLAN   | LIVE       | untested
   

4. 4.

   Run each test for real, report results honestly. The discriminating test the model proposes will often be concrete, like:

   Copy

   # From an affected machine during a call: is media using UDP or falling back to TCP?
   Get-NetUDPEndpoint -OwningProcess (Get-Process ms-teams).Id |
     Select-Object LocalAddress, LocalPort
   Test-NetConnection worldaz.relay.teams.microsoft.com -Port 3478
   

   Report the actual output, including "the command errored" — a model told the truth iterates well; a model fed tidied results converges on fiction. Ambiguous results are normal: say "inconclusive because X" and let it redesign the test.

5. 5.

   Demand the closing argument, then verify it independently. When one candidate remains, have the model state the case: "Explain why the surviving hypothesis accounts for ALL observed facts, including the negatives. List any fact it does not explain." Any unexplained fact means the differential reopens. Then confirm the mechanism against vendor documentation (firewall UDP timeout defaults, switch QoS behavior) before you change anything — the differential tells you where the fault is; the vendor docs tell you what correct looks like.

6. 6.

   File the artifact. The completed worksheet plus the closing argument goes in the ticket. It is simultaneously your fix justification, your escalation note if you hand off, and — when the same symptom recurs next quarter — the KB seed that saves the whole session.

Make it yours

• Solo/lightweight versionfor a 30-minute stuck ticket, compress: "give me the 5-candidate differential and the single best splitting test" without the full session protocol. Even one round breaks most fixation.
• Team versionrun the conversation on a shared screen during a swarm; the model's neutral candidate list defuses the "it's definitely the network" vs "it's definitely the app" standoff better than any human moderator.
• Intermittent-issue versionadd: "design the observation that will catch the next occurrence (what to log, on which machines, triggered by what)" — for intermittents, the discriminating test is usually instrumentation you plant today and read next week.

Quality check

• Tests actually discriminatebefore running any proposed test, ask yourself which candidates each possible outcome would eliminate; a test whose every outcome leaves the list unchanged is busywork regardless of who proposed it.
• Least-invasive orderingread-only observation before restarts, restarts before config changes; and any state-changing test runs in a sandbox or maintenance window with rollback ready, never as an experiment on production because the chat suggested it.
• Negatives recordedeliminated candidates with their evidence are half the worksheet's value; "we proved it is not DNS" saves the next engineer a day.
• Model claims are not evidence"firewalls typically time out UDP at 120s" is a hypothesis about your firewall until you read the actual config; verify environmental claims against your own systems and docs.