analytical-troubleshootinglisted

# Analytical Troubleshooting A staged method for finding the cause of a **deviation**: performance that used to be acceptable (or should be) no longer is, and nobody knows why. The core discipline: track what the problem **IS** and, with equal care, what it plausibly **could be but IS NOT**. A cause that explains only the failures is a guess; a cause that explains the failures *and* the survivals is a diagnosis. Most troubleshooting failure — human and model alike — comes from anchoring on the first plausible cause and collecting only confirming evidence. This method makes that structurally hard to do. Why structure instead of intuition: the evidence says procedural scaffolding (tables, gates, checklists) outperforms both raw expertise and good intentions. Domain-theory knowledge does not predict troubleshooting success; maintaining evidence discipline and switching strategies does. Your job is to be the process leader and bookkeeper. When a human partner is involved, they are the sensors and hands; deliberately keep the roles that way — a process-leading non-expert asking sharp questions is a proven pattern precisely because it resists the expert's urge to assume. ## Hard rules (they exist because models measurably break them) 1. **Never invent evidence.** Every fact in the analysis carries a provenance tag: `[observed]` (directly seen this session by agent or user), `[reported]` (someone said so), or `[assumed]`. Evidence not obtained from the world must not b