Inconsistent outputs despite consistent effort = missing input-output specifications — fix specs before fixing process
When a workflow produces inconsistent outputs despite consistent effort, diagnose missing or unstable input-output specifications before attempting to fix the process itself.
Why This Is a Rule
When a workflow produces inconsistent outputs, the instinct is to fix the process: add steps, add checks, tighten instructions. But if the root cause is unstable or missing input-output specifications, process fixes address symptoms while the underlying cause continues producing inconsistency. You can't process your way to consistent outputs if the inputs vary uncontrollably or the output standard is undefined.
This is the "garbage in, garbage out" principle elevated to a diagnostic rule. Inconsistent outputs with consistent effort is the signature symptom of specification problems. If the executor is doing the same thing each time but getting different results, the variation must be entering through the inputs (different starting conditions each time) or leaking through the outputs (different interpretation of "done" each time). Both are specification failures, not process failures.
The diagnostic priority matters because specification fixes and process fixes are different kinds of work with different costs. Process fixes add complexity (more steps, more checks, more overhead). Specification fixes add clarity (explicit inputs, explicit outputs) without adding steps. If the problem is specifications, process fixes make the workflow more complex without reducing inconsistency — you've made it harder to execute and still unreliable.
When This Fires
- When the same workflow produces noticeably different quality or format each time it runs
- When you or a team member is "doing everything right" but results keep varying
- When adding process steps hasn't improved output consistency
- Complements Define workflow inputs as precondition checklists — every piece of information, material, and state needed before step 1 can execute (input checklists) and Define workflow outputs as Definitions of Done with checkable acceptance criteria — not vague quality aspirations (output DoD) with the diagnostic trigger for when to apply them
Common Failure Mode
Process bloat from misdiagnosis: adding review steps, quality checkpoints, and approval gates to compensate for undefined inputs or vague output criteria. Each addition makes the workflow heavier without fixing the root cause. The workflow becomes slow, bureaucratic, and still inconsistent.
The Protocol
(1) When you notice inconsistent outputs, resist the urge to add process steps. Instead, diagnose: is this a specification problem or a process problem? (2) Check inputs: are the inputs to this workflow consistent and complete each time? Use Define workflow inputs as precondition checklists — every piece of information, material, and state needed before step 1 can execute's precondition checklist — if it doesn't exist, that's likely the root cause. (3) Check outputs: is there a clear, checkable Definition of Done? Use Define workflow outputs as Definitions of Done with checkable acceptance criteria — not vague quality aspirations's DoD framework — if it doesn't exist, that's likely the root cause. (4) If both input and output specifications exist and are complete, then the variation is in the process itself — now process fixes are appropriate. (5) Fix specifications first, then re-evaluate. Often, clarifying inputs and outputs eliminates the inconsistency without any process changes at all.