Introduction

Troubleshooting failures are not necessarily caused by missing tools, lack of experience, or insufficient skill. They may instead be rooted in unverified assumptions. This article defines a pre-troubleshooting discipline designed to reduce diagnostic failure caused by unverified assumptions.

Its purpose is to make sure basic facts are checked before deeper troubleshooting begins. The checklist is meant to reduce wasted effort, misdirected analysis, and investigations that sound confident but are built on something unverified.

Scope

This checklist covers:

• Identification of unverified assumptions prior to troubleshooting.
• A minimal checklist to confirm basic facts before deeper analysis.
• Common situations where professionals skip verification and move too quickly.

This article does not cover:

• Step-by-step troubleshooting procedures.
• Tool usage, commands, or technical fixes.
• Root cause analysis methodologies.
• Decision-making after verified facts are established.

This checklist does not guarantee resolution. It does not claim to identify every possible cause, nor does it eliminate the need for further troubleshooting. Its role is to prevent time and effort from being wasted on reasoning built on false or unverified premises.

The System (How It Works)

Before starting to troubleshoot, perform an explicit assumption reset:

1. Separate what you know from what you assume
   Be clear about what you know for sure and what you only think is true.
   Example: You may assume it's true that power is being properly delivered to a desktop computer. Check it anyways to establish that as a fact.

2. Check before you trust
   Do not accept claims, precedent, probability, or authority without verifying them in the current situation.
   Example: Someone insists that an operating system boot issue is not due to a full hard drive. Check free hard drive space regardless.

3. Reason from confirmed facts
   Proceed only from things you have directly observed or verified.
   Example: You verify that a website loads internally but not externally. Continue from the confirmed fact that the application is running, and focus on other items such as DNS, firewall, or routing instead of treating it like an app failure.

The checklist enforces a single rule:

Reasoning may only proceed on verified facts.

Operational Definition: Assumptions

In this system, an assumption is:

Anything treated as true without being personally verified in the current situation.

This includes, but is not limited to:

• Something someone else says they already checked.
• Something you believe because it happened that way before.
• Something you assume because it usually works.
• Something you dismiss because it seems unlikely.
• Something you accept because the user sounds sure.
• Something you believe because you already concluded it earlier.

If verification did not occur by you while investigating it remains an assumption.

The Assumption Reset Rule

An assumption is anything treated as true without being verified in the current context, regardless of confidence, experience, or intent. Before troubleshooting, explicitly identify which facts you have verified and which beliefs you are assuming; proceed only on verified facts.

The Assumption Reset Checklist

1. Prove the physical layer
   Personally verify power, cabling, antennas, and any other physical connections before looking for other causes.
   Example: Confirm antennas are actually installed rather than assuming they are.

2. Check what is really being used
   Confirm the exact inputs in use, not what the user thinks or says they are using.
   Example: Observe credentials being entered instead of trusting what account the user says they used.

3. Confirm operating context
   Verify the system’s actual location, network, or setup instead of assuming the context is correct.
   Example: Verify the device is connected to the correct network.

4. Clear unknown state before deeper analysis
   Remove stale or unclear conditions before moving into more complicated troubleshooting.
   Example: Reboot the system to clear temporary issues.

5. Validate the entire chain
   Trace dependencies end-to-end; partial verification is insufficient.
   Example: Verify the full power path, not just the device.

What “Good” Looks Like

The system is working when:

• Troubleshooting starts from facts you have checked.
• Simple causes are ruled out quickly and confidently.
• Deeper analysis is delayed until justified.
• Rework and backtracking are reduced.

Get the facts right before getting fancy.

Common Failure Modes

This discipline is often skipped when:

• The checks feel too simple to matter.
• Someone credible claims it was already checked.
• The system was working fine before.
• Symptoms resemble a problem seen before.
• Something seems unlikely, so no one checks it.
• Time pressure pushes people to act fast.
• Escalation feels like the next obvious step.
• Confidence is treated like proof.

These shortcuts feel efficient in the moment, but they often cost more time later.

Tradeoffs & Limits

This system:

• Adds deliberate friction before action
• May feel slow or frustrating when time is tight.
• Does not guarantee resolution

It is designed to improve your starting point, not to guarantee speed or certainty.

What This Checklist Is Not

• It is not a step-by-step troubleshooting guide.
• It is not a diagnostic flowchart.
• It does not tell you the fix.
• It does not replace experience or skill.

If the issue remains after using the checklist, deeper troubleshooting is now justified because the basics were checked first.

When this Checklist is Complete

This checklist is complete when:

• Assumptions are clearly identified before troubleshooting begins.
• Verified facts are clearly distinguished from assumptions.
• Deeper troubleshooting begins only after the basics are verified.