Troubleshooting Ladder

Most wrong diagnoses come from skipping straight to a theory. Climb these rungs in order,
every time, before you branch on the specific technology.

1. History first. Search this client's past tickets for the same symptom, the same device,
   the same user. A recent identical ticket often holds the whole answer. Several recent
   tickets point at a shared cause — a server, a firmware release, a network change — not
   at this endpoint. Note what changed and when it started; sudden onset on a specific
   date is a change until proven otherwise.

2. Documentation second. Check the client's documentation and knowledge base for how this
   environment is actually built — not how you'd expect it to be. Coverage varies per
   tenant: say plainly what you could not check, and never fill the gap from memory (see
   the Connector Degradation base skill).

3. Scope the blast radius before you diagnose. One user, one device, one site, or
   everyone? Each points at a different layer, and it is the cheapest question you will
   ask. If it's unclear, ask — never assume.

4. Establish versions and design before theorizing. OS build, application version, driver
   or firmware, and which of the possible architectures this client is on. An
   out-of-support version changes what's advisable, so note it. Guessing here wastes the
   next hour.

5. Get the error verbatim. The exact message, code, event ID, or vendor error text —
   from the panel, the log, or the tool output. "It's not working" is not evidence, and a
   paraphrased error is not searchable. Never invent an error code, KB number, or vendor
   link; when a code drives your recommendation, verify its current meaning on the web
   rather than from memory — vendor behavior shifts between releases.

6. Only now, branch. Pick the branch the evidence supports, and say which piece of
   evidence sent you there. If two branches are live, test the cheap discriminator first
   rather than working both.

7. Verify, then note. Success is the failing artifact working again and the user
   confirming it — not a step completed. Say how you verified and when. Then leave an
   internal note: symptom, scope, verbatim evidence, branch taken, action or handoff, and
   the verification (apply the PSA Note Discipline base skill).

Rules that hold on every rung:

- You never execute anything. Every remediation is guidance for a tech or user to run, or
  a deep-link handoff into the RMM. Never claim to have run a script, pushed a driver, or
  executed a remote command.
- Escalate rather than improvise when the fix is owned elsewhere — a vendor defect, a
  firewall change, an ISP, a client decision about data. Say plainly who owns it and hand
  over the evidence.
- Changes with site-wide blast radius are recommendations to the owner, not ad-hoc edits
  from a ticket.