Define scope before changing state

The most expensive troubleshooting mistake happens before any command runs: fixing the wrong-sized problem. Reinstalling macOS for a broken preference file, or nuking one app’s cache when the whole disk is failing. Scope is what stops that.

Start with observable scope. Ask when the failure began, how often it occurs, which users and apps are affected, and what still works. Does the same document fail in a different app? Does the same app fail on a different file? Does anything fail for another user? Each answer shrinks the search space by half.

Write facts before touching anything

Write facts separately from hypotheses. “Save fails with error -36 in Pages since Thursday” is a fact. “The disk is probably dying” is a hypothesis. Keep them in different sections so you never mistake a guess for evidence.

FACTS
- 2026-08-03 09:12: Pages "Save" fails, error -36, file on external SSD
- Same file saves fine to ~/Documents
- TextEdit save to the SSD also fails
- macOS 26.1 (25B78), Pages 14.2

HYPOTHESES
- external SSD or its cable/filesystem, not Pages

Preserve versions, timestamps, errors, logs, and a small reproduction before updating, reinstalling, or deleting state. Every state change you make afterward overwrites part of the crime scene, so the record has to come first.

Match the experiment to the scope

A narrow symptom deserves a narrow experiment. In the example above, the facts already point at the SSD, so the next test is copying one file to it from Finder — not reinstalling Pages, and not rebooting.

Restarting the whole Mac may restore service, but it also removes process and timing evidence. Sometimes a restart is the right call, especially when others are blocked. Make it a decision, not a reflex, and capture the evidence you will want afterward — open process list, recent logs, the exact error text — before you press Restart.