Failure localization test for step granularity — if a step fails, can you pinpoint what went wrong without further investigation?

Why This Is a Rule

The competent stranger test (Competent stranger test for workflow steps — could someone complete this step with zero clarifying questions? If not, it is not yet atomic) tells you whether a step is clear enough to execute. The failure localization test tells you whether a step is granular enough to debug. A step can be perfectly executable and still too coarse: "Build and deploy the application" is clear enough to execute but if it fails, you have no idea whether the build failed, the tests failed, the deployment config was wrong, or the target server was down. You need further investigation to localize the failure.

The principle mirrors software engineering's approach to error handling: functions should be small enough that when they throw an error, the error message alone tells you what went wrong. A 500-line function that throws "processing failed" requires stepping through the code to find the failure point. A 10-line function that throws "parsing failed" localizes the problem immediately. The same logic applies to workflow steps.

The right granularity is the level where a failure report ("step 4 failed") gives you enough information to diagnose the cause without re-executing or investigating the step's internal operations. This is the Goldilocks zone: coarser steps hide failures inside compound operations; finer steps create unnecessary overhead for operations that never fail independently.

When This Fires

• When decomposing workflows and deciding how fine-grained to make each step
• When a workflow step fails and you realize you don't know which sub-operation caused the failure
• When reviewing workflow documentation that has steps spanning multiple distinct operations
• Complements Competent stranger test for workflow steps — could someone complete this step with zero clarifying questions? If not, it is not yet atomic (competent stranger test) with the failure-diagnostic perspective on granularity

Common Failure Mode

Compound steps that bundle distinct failure modes: "Review and approve the document." If this step fails, did the review find problems (expected, fixable) or did the approval process break (unexpected, systemic)? Two completely different failure modes are hidden inside one step, requiring investigation to distinguish them.

The Protocol

(1) For each workflow step, simulate failure: "If this step fails, what would I know?" (2) If the answer is "I'd know exactly what went wrong" → granularity is correct. (3) If the answer is "I'd need to investigate further" → the step bundles multiple failure modes. Decompose until each sub-step has a single, identifiable failure mode. (4) Apply the split test: can the step fail in two or more genuinely different ways? If yes, it's at least two steps. "Send email" has one failure mode (email doesn't send). "Draft and send email" has two (draft quality failure vs. sending failure). (5) Stop decomposing when further splits would separate operations that always succeed or fail together — there's no diagnostic value in splitting inseparable operations.