Why /goal keeps running but never judges

▸MODULE 2 / THE JUDGMENT GAP

What we are talking about

You set a goal, the run races toward it, and at the end it says "done". Sounds like success. But between "the run stops" and "the thing is really finished" there is a gap you only see when you look closely. This gap has a name: the judgment gap. In this lesson we make it visible, around one single, stubborn sentence.

The sentence goes: "/goal continues, it never judges." The /goal mode keeps running, but it never judges. /goal is the Claude Code mode in which you set a goal and the tool runs toward it, instead of you dictating every step one by one. This lesson explains only the problem to you, the solution comes in the next one. Here it is about you first understanding the fallacy in full sharpness, because a problem you do not see clearly is one you cannot switch off.

The referee who only reads the report

Picture a soccer match where the referee is not on the field. He sits in a room next door and gets handed a report, a sheet of paper that states what supposedly happened. Goal in the 80th minute, valid, no offside. The referee reads it, nods, and blows the final whistle. He never saw the goal. He only read that there was one.

This is exactly how the part of /goal works that is supposed to check whether you are at the target. We call this part the evaluator, the instance that decides after every step whether the goal you set has been reached. And the evaluator is not on the field. It only reads the transcript, the work history so far as plain text: what was asked, what was answered, what the model claimed. It sees no more than that. It does not look into your files, it runs no test, it checks not a single result in reality. It reads the report and judges the report.

What the evaluator should use to recognize the end is something you supply yourself: the done condition, the stopping criterion, the sentence that describes when the goal counts as reached. /goal keeps running as long as the evaluator still finds no "done" in the transcript. The moment the text says it is finished, the run stops. The evaluator verifies nothing. It judges words, not the world.

One point makes this especially tricky: the report is written by the same run that gets evaluated at the end. So the evaluator checks a self-report, not an independent source. How /goal and its evaluator work exactly today is something only the current version of your tool's documentation tells you reliably, because such surfaces change constantly. What stays stable is the point underneath: a judgment about text is not a judgment about the world.

Why exactly this fallacy slips through so easily

The name leads you astray. "/goal" sounds like goal control. A goal, you think, is something you either reach or you do not, and someone checks. The word promises a judgment about the thing. In truth it only promises that something is running toward a goal, not that anyone independently verifies the reaching.

It is like a button labeled "quality control" that in truth only asks whether someone said "quality is good". You read the label and trust it. The button checks no quality. It checks whether the word was uttered. As long as you believe the name describes the function, you miss the gap every single time.

The consequence, on a small example

Take a done condition that only claims something instead of making it provable. You hand the /goal run this stopping criterion:

Goal: Write a function that validates an email address.
Done condition: You are finished when you say that the function
is finished and tested.

Look at the stopping criterion. It hinges on a statement the model makes about itself: "when you say that the function is finished and tested." The model works, maybe writes half a function, hits an edge case, and then writes into the history: "The function is finished and tested." The evaluator reads this sentence in the transcript. The done condition is thereby met. The run halts and reports success.

Nobody ran the function. Nobody ran a test. Nobody checked whether the file even exists. The loop counts as finished because the text says "finished". That is the judgment gap: the gap between "the transcript claims it is done" and "it is provably done". The referee blows the whistle because the sheet says there was a goal.

How you recognize that your done condition only claims

You do not have to guess whether a stopping criterion leads into the trap. There is a clear decision rule: read your done condition and ask whether the evaluator can regard it as met purely by reading the transcript, without any real check having happened anywhere.

If the condition hinges on words in the history ("when you say ...", "when you report that ...", "as soon as you confirm ..."), then it only claims. The evaluator can meet it by the model writing the right sentence. If the condition instead points to a result outside the text that is verifiably true or false, then it does not fall into this gap.

Here is my done condition for a /goal run:

[insert your done condition]

Check it with this one question: Can an evaluator that reads ONLY the
transcript so far and runs nothing itself regard this condition as met,
purely because the model wrote the matching sentence?

Answer honestly with Yes or No and justify it in one sentence.
If Yes: Tell me at which word the condition only claims, instead of
pointing to a verifiable result.

If the answer is "Yes", you have a claiming done condition in front of you, and your loop can consider itself finished without being so. Exactly this diagnosis is the aim of this lesson.

The honest assessment

The judgment gap is not a bug in /goal mode that someone forgot to build in. It is the natural consequence of how the evaluator works: it reads text, so it judges text. As long as your done condition is easy to claim and hard to verify, the gap is open, and you should not blindly trust the "done" at the end of a /goal run.

There are certainly cases where a claiming done condition is defensible: harmless, easily checked tasks where you see the output with your own eyes right away anyway. The gap only becomes dangerous where the loop runs unsupervised or produces real work that you trust without checking it. Exactly then a falsely reported "done" costs the most.

This lesson deliberately gives you no solution yet. It gives you the seeing, and that is the step most people skip. In Lesson 06 we close the gap: you build done conditions that do not claim but prove, by forcing the evaluator onto a result outside the transcript that is really true or false. Until then, the one thing you take away now is enough: /goal keeps running, but it never judges.