Methodology
How troubleshooting guidance is selected, ordered and verified.
1. Identify the technical scope
Each record must describe one primary failure context: a symptom, component, error within a named subsystem, or repair command.
2. Prefer primary guidance
Microsoft Support and Microsoft Learn are preferred for Windows behavior and built-in tools. Hardware-vendor documentation belongs in device-specific records when the diagnosis requires it.
3. Order by disruption
Reversible checks come first. Driver replacement, service resets, network resets, recovery tools and system repair commands are placed later unless the symptom clearly requires them.
4. Preserve uncertainty and context
Error codes, Device Manager codes and stop codes are not detached from their subsystem. If a symptom has several possible causes, the page says so rather than manufacturing certainty.
5. Keep a stop condition
Guides state when the page is no longer the right troubleshooting path, reducing repeated irrelevant fixes.
6. Preserve release state
KB records keep release date, Windows version/build, documented known issues, later resolutions and review date together. Update guidance is not detached from the build it applies to.
7. Link by technical relationship
Related records are scored from shared component plus explicit technical contexts such as DHCP, DNS, proxy/VPN, driver, USB, GPU, Store, browser or recovery. Keyword resemblance alone does not create a recommendation.
8. Correlate evidence before assigning cause
Event IDs, reliability entries and storage health fields are treated as evidence with scope and limitations. A timestamp, source, stop code or repeated pattern can narrow the diagnosis; a single Critical label does not automatically identify the failed component.
9. Preserve the evidence chain
Service failures, app crashes, hangs, driver installs, storage events and stop errors are linked by timestamp and ownership: event → service/process/driver → component → recent change → dump or device evidence → safest next action. A downstream symptom is not treated as the original failure when an earlier dependency or hardware-path event explains it.
10. Separate observation from conclusion
High-value diagnostic records explicitly distinguish the observed fact, Windows evidence, likely subsystem, evidence still needed, safe next action and the point where vendor/IT/debugger handoff is more appropriate than another generic repair.