Test composability by replacing one sub-workflow without breaking others — forced changes to adjacent workflows mean interfaces are leaking

Why This Is a Rule

Composability means you can swap, rearrange, or replace parts without breaking the whole — and the test for composability is attempting exactly that. In software engineering, this is the Liskov Substitution Principle: if you can replace a component with a different implementation that satisfies the same interface, the system is properly composed. If replacement forces changes elsewhere, the components are coupled through their internals rather than their interfaces.

Applied to workflows: if your "research" sub-workflow can be replaced with a different research method (different tools, different steps, different process) without changing the "analysis" sub-workflow that follows it, the boundary between research and analysis is clean. If replacing the research method forces you to restructure the analysis workflow (because the analysis assumed a specific research output format, or relied on a specific intermediate artifact), the interface is leaking — the analysis workflow depends on research internals rather than research outputs.

Interface leaks in personal workflows produce the same problems as in software: brittleness (you can't change one part without breaking others), complexity (every change requires understanding the entire chain), and rigidity (improvements in one area are blocked by dependencies from other areas). Clean interfaces between sub-workflows enable independent improvement of each sub-workflow.

When This Fires

• When designing composed workflows from multiple sub-workflows
• When trying to improve one part of a workflow and finding it requires changes elsewhere
• When a workflow is brittle — small changes cascade through multiple steps
• Complements Preserve intermediate outputs as concrete artifacts at every workflow boundary — enables resumption, failure recovery, and reuse (artifact preservation at boundaries) with the diagnostic test for interface quality

Common Failure Mode

Implicit coupling: two sub-workflows that seem independent but share unstated assumptions about format, timing, naming conventions, or tool state. Replacing one reveals the hidden dependency when the other breaks. The coupling was invisible during normal operation and only surfaces during modification.

The Protocol

(1) For each boundary between sub-workflows, perform the substitution test: "Could I replace the upstream sub-workflow with a completely different process and still feed the downstream sub-workflow?" (2) If yes → the interface is clean. The boundary is defined by the output artifact, not the process that produces it. (3) If no → identify the leak: what does the downstream workflow assume about how the upstream workflow works? This assumption is coupling that should be eliminated. (4) Fix interface leaks by specifying the boundary contract explicitly: "Sub-workflow A produces [artifact with these properties]. Sub-workflow B accepts [artifact with these properties]." Neither should know or care about the other's internal steps. (5) Re-test after fixing: can you now substitute a different upstream process? If yes, the interface is now clean.