Define completion as binary observables (draft exists)…
Define workflow completion criteria as binary observables ('draft exists') rather than subjective evaluations ('draft is good') to create clear termination points that prevent recursive perfectionism.
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.