Mark workflow decision points with explicit if-then notation — make conditional logic visible instead of hiding it inside step descriptions

Why This Is a Rule

Most workflow documentation describes the happy path — the sequence of steps when everything goes as expected. But real workflows branch: "If the client approves, proceed to design; if they request changes, return to proposal revision." When these branches are buried inside step descriptions ("Complete proposal. Note: if revisions needed, see step 2"), the person following the workflow must parse prose to extract conditional logic — a cognitive tax that increases errors and slows execution.

Explicit decision-point notation (if-then-else structures, decision diamonds in flowcharts) externalizes the branching logic so it's visually distinct from sequential steps. This serves the same function as conditional statements in code: it makes the control flow structure visible at a glance rather than hidden inside narrative text. A workflow reader should be able to identify every decision point without reading every word — just as a programmer can scan for if/else blocks without reading every line.

The deeper principle is that workflow documentation is an interface, not a narrative. Like any interface, its primary obligation is to make structure visible. Sequential steps, decision points, loops, and termination conditions are structural elements that deserve distinct visual treatment.

When This Fires

• When documenting any workflow that contains conditional branches
• When following a documented workflow and realizing the branch logic is ambiguous
• When handing off a workflow to someone else and they ask "but what if...?"
• When reviewing existing workflow documentation for clarity and completeness

Common Failure Mode

Narrative-style documentation that embeds conditions inside step descriptions: "After receiving the report, review it. If there are issues, flag them. Otherwise continue." This reads like prose but functions as code — and prose is a terrible notation for code. The conditions are invisible to scanning, the branches are unmarked, and someone following at speed will miss the conditional entirely.

The Protocol

(1) For each step in a documented workflow, ask: "Does this step always lead to the same next step, or does it branch?" (2) If it branches → extract the branch into an explicit decision point: IF [condition], THEN [step A]; OTHERWISE [step B]. (3) Use visual distinction: bold the IF/THEN/OTHERWISE keywords, indent the branches, or use decision-diamond notation in flowcharts. The branching must be visually obvious, not buried in paragraph text. (4) Ensure every branch has an explicit path — no "figure it out" gaps. If you don't know what happens in a branch, that's a documentation gap to fill, not an edge case to ignore. (5) Test: can someone scan the workflow and identify every decision point without reading full step descriptions? If not, the decision points aren't marked clearly enough.