
In the last chapter you learned to trace a failure back to its root cause. Finding the cause, though, is not the end of the story. You still have to decide what to do about it, and the right move is not always to fix it yourself. This chapter gives you a simple frame for that decision, then shows you how to go one step further: turning a single fix into a change that stops the same problem from coming back.
Every time you evaluate an output or trace a failure, you arrive at the same fork: what do you actually do with what you found? Four choices cover almost every case. Read them as a set, because the skill is picking the right one, not defaulting to the same one every time.
Accept means the output passes your checks, or the problem is too small to matter, so you use it as it is and move on. Accepting is a real decision, not a lack of one: you looked, you judged it trustworthy, and you can say why.
Fix means the problem is real and correcting it is within your reach and your authority. You repair it at the root cause, the way you learned in the last chapter, then re-check the step to confirm the symptom is gone. Fix is the right call when you both know the correct answer and are allowed to change it.
Escalate means the problem is real but sits beyond your reach, your authority, or your certainty. You hand it, along with the evidence you gathered, to whoever can resolve it. Escalating is not giving up, it is routing the problem to the person who can actually settle it.
Override means the output is wrong or unfit and you cannot repair it in time, but you can supply the right result yourself. You set the output aside and use your own judgment instead. This is the move for the AI suggestion you know is off: rather than accept it or wait for a fix, you overrule it and do it correctly by hand.
The table below lines up the four so you can choose quickly.
Decision | Use it when | What you do |
Accept | The output passes your checks, or the issue is too small to matter | Use the output as is and move on |
Fix | The problem is real, and correcting it is within your reach and authority | Correct it at the root cause, then re-check the step |
Escalate | The problem is real but beyond your authority, reach, or certainty | Hand it, with your evidence, to whoever can resolve it |
Override | The output is wrong or unfit and you cannot repair it, but you can supply the right result | Set the output aside and use your own judgment instead |
The hardest call is usually the line between fixing something yourself and passing it on. When both feel possible, escalate rather than fix if any of these is true:
the fix touches data, tools, or decisions you do not own or control ;
the problem may be bigger than the single case in front of you, so it needs someone with a wider view ;
you are not certain what the correct result should be, and cannot verify it on your own ;
being wrong would be costly, for someone’s money, safety, or trust.
Isn’t escalating just passing my work to someone else so I don’t have to deal with it?
No. Escalating well is more work, not less: you still do the investigation, gather the evidence, and hand over a clear picture of the problem. What you are routing is the decision or the authority to act, not the effort. A problem escalated with no evidence is just a complaint.
Fixing the case in front of you solves today’s problem. It does nothing about tomorrow’s, when the same weak step fails again in a new way. A preventive workflow improvement is a change to the workflow itself that lowers the chance the same failure returns. Instead of only repairing the output, you go back to the fragility point you learned to spot in Part 1 and remove or guard it.
The most useful preventive changes follow a short list of patterns. Reach for whichever one targets the root cause you found:
remove the fragile step: replace a manual re-keying step with a direct connection, so the copying error simply cannot happen ;
guard the handoff: add a quick check or confirmation where one tool passes work to the next ;
create a single source of truth: keep one master copy instead of several, so versions cannot drift apart ;
assign an owner: make each step someone’s clear responsibility, so nothing falls through the gap between people ;
add a freshness rule: date or refresh the data so a stale figure is caught before it is used ;
keep a human in the loop: have a person review high-stakes AI output before it goes out the door.
Return to the food drive, where the last chapter traced the wrong thank-you note back to a mistyped spreadsheet row for Mr. Alvarez. The cause is known. Now watch all four decisions appear as the volunteers finish the job.
The notes that passed every check need nothing done to them; the team accepts them and moves on. Mr. Alvarez’s row is a clear, in-reach repair, so the spreadsheet owner fixes it at the source, corrects the figure, then regenerates and re-checks his note. The worry that other rows from that same session might also be mistyped is bigger than one note and needs the coordinator’s authority to review the whole batch, so the team escalates it, evidence in hand. And when the AI assistant, asked to total the day’s gifts, returns a figure the volunteers know is off after counting by hand, they do not wait for a fix or accept the number; they override it and use their hand-checked total for the summary.
That handles today. To stop the mistype from ever happening again, the team makes a preventive improvement: they connect the sign-up form directly to the spreadsheet so entries flow across automatically, removing the manual copy step that caused the whole problem. They also add a quick reconciliation check, comparing the batch of notes against the form, before any notes go out. One afternoon’s fix becomes a change that protects every drive after it.
Every evaluation or diagnosis ends in one of four decisions: accept, fix, escalate, or override, and the skill is choosing the right one rather than defaulting to a favorite ;
Fix repairs the workflow at its cause, while override leaves the output aside and substitutes your own answer for this one instance ;
Escalate when the fix is beyond your authority, reach, or certainty, or when the stakes or scope are too large to settle alone, and always hand over the evidence ;
A preventive workflow improvement changes the workflow so the same failure is less likely to return, by removing or guarding a fragility point from Part 1 ;
Match the size of a preventive change to the size of the risk, since a fix that costs more than the failure it prevents is not worth making.
You now have the full method: map a workflow, judge its outputs, trace failures to their cause, decide what to do, and prevent the problem from returning. In the final chapter you will watch the whole method run end to end on a complete case, then take a turn applying it yourself.