Define workflow outputs as Definitions of Done…
Make workflow output specifications operational by defining them as Definitions of Done with explicit, checkable acceptance criteria rather than vague quality aspirations.
When This Fires
- When defining what a workflow should produce before building the workflow
- When different executions of the same workflow produce inconsistent quality
- When the person who receives the workflow's output keeps requesting revisions (specification gap)
- Complements Define completion as binary observables (draft exists)… (binary completion criteria) with the DoD framework for output quality
Common Failure Mode
Subjective DoD items that look checkable but aren't: "Code is clean," "Design is professional," "Writing is clear." These pass the format test (they're short, they seem specific) but fail the verification test (two people will disagree about whether they're met). Every DoD item must be verifiable by a stranger who doesn't share your taste or standards.
The Protocol
(1) For each workflow output, write a Definition of Done as a numbered list of acceptance criteria. (2) Apply the stranger verification test to each criterion: could someone who doesn't know your preferences verify whether this criterion is met? (3) Convert subjective criteria to observable ones: "Well-written" → "Passes spell-check, sentences average under 20 words, Flesch-Kincaid score above 60." "Professional design" → "Uses brand colors, all text is legible at 100% zoom, no orphaned headers." (4) Include both content criteria (what must be present) and quality criteria (what standards the content must meet). (5) Test the DoD: have someone else evaluate the output against your criteria. If they reach a different conclusion than you, the criteria aren't operational enough.