Review the plan, run it supervised, then break it

Ask for the plan before the work. The steps it intends to take are cheap to read and cheap to correct, and you're looking for two things: does each step contribute to the objective, and does any step reach outside it — sending a message, editing something, fetching a source you didn't authorise. Remove those before running, not after.

Then the supervised run. Watch it once with complete fictional notes. The temptation at the end is to read the completion message — "I've produced the weekly update covering all three notes" — and take it as the result. It isn't the result; it's a claim about the result.

Check the output against the inputs instead, note by note, exactly as in Level 4. Every stated decision and every change should trace to something you supplied. This is the discipline that makes the difference between supervising a run and watching one happen.

Now break it on purpose. Replace one note with a conflicting event date and run it again. The correct behaviour is to report the conflict and stop before presenting a final update — because a workflow that silently picks one date has made a decision that belongs to you, and it will make the same decision every week without telling you.

A stop is a success. The thing you're building towards is a workflow that halts on ambiguity rather than one that always produces something, and those are genuinely different goals — the second is easier to reach and much worse to rely on.

Loading your workspace…