Define completion as binary observables (draft exists) not subjective evaluations (draft is good) — clear termination prevents perfectionism spirals

Why This Is a Rule

Subjective completion criteria ("the draft is good enough," "the design feels right," "the code is clean") create infinite loops because they have no observable termination point. "Good enough" is a moving target — every improvement shifts the standard upward, and the evaluator (you) is inside the loop with no external reference point. This is the perfectionism spiral: each revision reveals new imperfections, each improvement raises the bar, and "done" recedes endlessly.

Binary observable criteria ("the draft exists and has been spell-checked," "all tests pass," "the proposal has been sent") have a clear, verifiable termination point. Either the observable condition is true or it isn't. There's no ambiguity, no sliding standard, and no recursive evaluation. The moment the condition is met, the step is done — regardless of how the executor feels about the quality.

This doesn't mean quality doesn't matter. It means quality evaluation belongs in a separate, subsequent step with its own binary criteria ("reviewer approved" or "three rounds of revision completed, whichever comes first"). Separating production from evaluation prevents the production step from becoming an infinite perfectionism loop by giving the evaluative judgment its own bounded container.

When This Fires

• When defining "done" for any workflow step, especially creative or judgment-heavy ones
• When a workflow step keeps expanding because the completion criteria are subjective
• When someone (or future-you) can't tell whether a step has been completed by inspecting the output
• When perfectionism prevents task completion despite adequate output quality

Common Failure Mode

Criteria that sound binary but are actually subjective: "The report is complete" (complete by whose standard?), "the data is clean" (how clean?), "the code works" (works for which cases?). Each of these invites interpretation, and interpretation invites endless refinement. True binary observables are verifiable by anyone: "the report has sections 1-5 and a summary," "zero null values in required columns," "all 47 test cases pass."

The Protocol

(1) For each workflow step, write the completion criterion. (2) Apply the stranger verification test: could a stranger determine whether this criterion is met by inspecting the output alone, without asking for your opinion? (3) If no → the criterion is subjective. Rewrite it as a binary observable. Convert "good" to "reviewed," "clean" to "passes linter," "complete" to "contains sections A, B, C." (4) If the step genuinely requires quality judgment, create two sub-steps: "Produce [binary: output exists]" then "Evaluate [binary: reviewer approved OR revision count = 3, whichever first]." (5) The completion criterion must be in the documentation, not in your head. If someone else can't determine whether the step is done, the criterion isn't observable enough.