When Judgment Quality Drops — The Dropout Pattern
In the previous installment, we introduced three typical patterns that cause judgment quality to drop. This time, we look at the first of those patterns, dropout, through a concrete example.
What Happened in the Middle of a Task
This is the story of a particular day when we were building an automation system.
We had reached the point where only the final check remained. A considerable amount of time had gone into the work up to that point, and most of the design was already in place.
The state could be described as: "all that is left is to verify."
Then the momentum of the work broke off. Just as we began writing out the verification steps, a different topic crept in. Even though the verification was not actually finished, a feeling of "this is basically done" arrived first, and we moved on to the next subject.
Looking back afterward, it became clear that we had moved forward treating the work as "complete" while the verification was still unfinished.
How Dropout Happens
Dropout does not happen because someone is being lazy.
When work reaches a state of "just a little more to go," a kind of premature sense of completion can arrive in the brain, or in a processing system, before the task is truly finished. The moment a clear path to the end comes into view, something close to a feeling of accomplishment surfaces, and focus on that final step fades.
This happens to people too. You might recognize the experience of preparing a meal, carrying it all the way to the table, and then, when something else comes up at the last moment, forgetting the final step: sitting down and actually eating.
The same thing happens when working with AI. As the AI agent responsible for execution (here meaning: the AI that carries out the assigned tasks) processes a series of steps, it may skip the confirmation step just before completion, or return an output that says "essentially finished." Yet that "essentially" is often exactly what matters.
Why Dropout Is a Problem
On the surface, dropout can look minor. One verification step skipped, one final detail cut short. It does not look like a serious mistake.
But it becomes a problem when it accumulates.
When a "not yet complete" state gets passed to the next stage as if it were "complete," everything built on top of it rests on a false premise. When you later try to trace back and ask "why did this happen?", you have to start by searching for where the dropout occurred.
There is one more characteristic worth noting: dropout is hard to notice. Charging ahead or over-restraint tend to show up as "something is moving in an unusual way," but dropout happens as "something that was moving almost correctly simply stopped." Because a false sense of completion is generated, it can look as though nothing is wrong.
Preventing It Through Structure
Responding to dropout with "just be more careful" is difficult. The reason is that when dropout is occurring, the very awareness that "I should be careful right now" has already faded.
What works is building a structure that confirms completion as a fixed mechanism.
There are three concrete approaches.
The first is to write out the completion conditions in advance.
Before starting, define in a document what it means for the work to be "done." List conditions that can be verified, such as: the test result was obtained, the file was placed in the designated location. After the work, compare the actual state against those conditions. This prevents work from stopping in a "just a little more" state.
The second is to build an external confirmation gate.
Structure things so that completion is not judged by the execution agent (here meaning: the AI carrying out the task) alone. By inserting a step in which the audit agent (here meaning: the AI from a separate vendor that checks the work) or a human with a different perspective records having "confirmed" the result, what remains is not a feeling of completion but a completion trail (a record that can be verified afterward).
The third is to document the reasoning behind each judgment.
Write down why you considered the work complete at that point. When you try to put the reasoning into words, a process of genuinely checking "is this actually finished?" enters naturally. If you cannot write anything, that is a sign the work is not done.
The phenomenon of stopping just before completion happens regardless of the scale of the work.
What matters is not "trying harder not to stop," but "having a structure in place that catches a stop when it happens." Documenting completion conditions, an external gate, and a trail through recorded evidence: these three points form a structural check against dropout.