Troubleshoot Methodically and Separate Symptom from Root Cause

In the last chapter you learned to judge an output and decide whether it holds up. Sooner or later one will not: a total that is wrong, a confirmation that names the wrong person, a list that is missing names. This chapter gives you a calm, repeatable way to find out why, so you can fix the real problem instead of the first thing you notice. It is the difference between mopping up a leak and finding the crack that caused it.

See Why the Root Cause Matters More than the Symptom

When something goes wrong in a workflow, the first thing you meet is the symptom: the visible sign that something is off, like a thank-you note that thanks a donor for a gift they never made. The symptom is real and worth noticing, but it is not the problem itself. The root cause is the underlying reason the symptom appeared, the thing that, if you correct it, actually stops the symptom from coming back.

The temptation is always to treat the symptom and move on. You spot the wrong note, rewrite it by hand, send it, done. But if the reason the note was wrong is that the donor’s row in the spreadsheet was mistyped, then the next note built from that row will be wrong too, and so will the receipt, and the follow-up. You fixed what you saw and left what caused it. Troubleshooting is the discipline of pushing past the symptom to the cause, because only a fix at the cause holds.

Follow the Troubleshooting Method Step by Step

Once you accept that the cause matters more than the symptom, you need a reliable way to get from one to the other. Use these five steps in order. They work the same way whether the failing step is a person, a plain digital tool, or an AI assistant.

Step 1. Reproduce or characterize the failure. Start by trying to make the problem happen again, because a failure you can see on demand is far easier to study than one you are recalling from memory. Run the step again with the same input and watch what it produces. For most tools this works cleanly: the same wrong total appears every time. AI steps are different. An AI assistant is stochastic, meaning it can give a slightly different answer each time you run it, so the exact wrong output may not appear again. When you cannot reproduce a failure, characterize it instead: write down precisely what was wrong, with what input, and keep the evidence, such as a saved copy or a screenshot, so you can still study the failure even though you cannot summon it back.

Step 2. Isolate the failing step. Return to the workflow map from Part 1 and walk it, checking each step’s output against what went into it. The goal is to narrow a vague “the notes are wrong” down to a single step where good input went in and bad output came out. That step, not the whole workflow, is where your investigation belongs.

Step 3. Separate the symptom from its possible causes. With the failing step in hand, list the causes that could produce this symptom, then treat each one as a hypothesis to test rather than a conclusion to assume. A wrong thank-you note could come from a mistyped spreadsheet row, from a donor entered twice, or from the AI inventing a detail. Naming several candidates keeps you from locking onto the first one that comes to mind.

Step 4. Confirm the root cause with evidence. Test your hypotheses against something real, exactly as you evaluated outputs in the last chapter. Compare the failing step’s input to its trustworthy source: does the spreadsheet row match the original form? Does the total match the individual gifts? The cause you can back with a concrete mismatch is the root cause; the ones you cannot are set aside. Never settle on a cause you have only guessed at.

Step 5. Fix or escalate. Once you know the cause, decide who acts on it. If the fix is within your reach and your authority, make it at the cause, then re-run the step to confirm the symptom is gone. If it is not, escalate: hand the problem to the person who can resolve it, along with the evidence you gathered, so they do not have to start the investigation over. Escalating is not giving up, it is routing the fix to where it can actually be made.

Because the note is the symptom, not the cause. Fixing it makes this one note right, but if the cause is a mistyped row, the next note, receipt, and reminder built from that row will be wrong too. The steps feel slower on the first failure and save you from repeating the same fix on every failure after it.

Read Common Symptoms with a Diagnostic Table

As you troubleshoot more workflows, you will notice that the same symptoms tend to trace back to the same short list of causes. The table below pairs common symptoms with the causes worth checking first and the evidence that confirms them. Treat it as a starting point for Step 3, not a substitute for testing: the table tells you where to look, and Step 4 tells you whether you were right.

Watch the Method Work on a Real Failure

Let us run the whole method on the food drive from earlier, where one thank-you note thanked a Mr. Alvarez for a fifty-dollar gift he never made. That wrong note is the symptom. Here is the method finding the cause.

Step 1, reproduce or characterize. The note was drafted by the AI assistant, which is stochastic, so re-running it might produce a different note rather than repeat the same mistake. Instead of chasing an identical repeat, the volunteers characterize the failure: they save the exact wrong note and record its input, the spreadsheet row the assistant was given for Mr. Alvarez.

Step 2, isolate. Walking the map, they check each step’s output against its input: the form entry, then the spreadsheet row, then the AI draft. The form entry from Mr. Alvarez shows he pledged nothing that week; the spreadsheet row for him shows fifty dollars. Good input, wrong record: the failing step is the manual copy from form to spreadsheet, not the AI draft.

Step 3, separate symptom from causes. Before that isolation, three causes were plausible: the AI hallucinated the gift, Mr. Alvarez was entered twice, or his row was mistyped when copied over. Naming all three kept the team from blaming the AI on reflex.

Step 4, confirm with evidence. The direct comparison settles it: the form says zero, the row says fifty, and no second Alvarez entry exists. The root cause is a manual re-keying error, a volunteer who typed the wrong figure while copying the form into the sheet. The AI did exactly what it was asked; it wrote a warm note from a wrong number.

Step 5, fix or escalate. The volunteer who owns the spreadsheet can fix this directly: correct the row, then regenerate and re-check the note. But they also realize the same mistype could have hit other rows entered that day, which is a bigger problem than one note. That broader risk they escalate to the drive coordinator, with the evidence in hand, so someone with the authority can decide whether every row from that session needs a second check.

Notice what the method prevented. The obvious move, rewriting the one bad note, would have left the wrong fifty-dollar figure sitting in the spreadsheet, ready to reappear on the receipt and the year-end summary. By separating the symptom from the root cause, the team fixed the number once, at its source, and caught a risk they would otherwise have missed.

Let’s Recap!

• A symptom is the visible sign that something went wrong, while the root cause is the underlying reason it happened, and only a fix at the cause holds ;

• The troubleshooting method has five steps: reproduce or characterize the failure, isolate the failing step, separate the symptom from its possible causes, confirm the cause with evidence, then fix or escalate ;

• AI steps are stochastic, so when you cannot reproduce a failure exactly, characterize it instead by recording what went wrong and keeping the evidence ;

• Confirm a root cause by testing it against a real source, never by settling on the first cause that comes to mind ;

• Escalating hands a problem, with its evidence, to whoever can resolve it, and is a valid outcome rather than a failure.

You can now trace a failure to its true cause and decide whether to fix it or pass it on. The next chapter sharpens that final decision, giving you a clear way to choose between accepting, fixing, escalating, or overriding a result, and to turn a one-off fix into a change that keeps the problem from returning.