{"slug":"stage-gated-workflow","meta":{"title":"Stage-Gated Workflow","slug":"stage-gated-workflow","kind":"topology","summary":"A record cannot advance to the next stage until stated conditions are met, and the interface says exactly which condition is blocking it.","problem":"A process has rules — no job starts without insurance on file, no invoice sends without approval — and the rules live in people's heads. They are enforced by whoever notices, which means they are enforced inconsistently and discovered late.","family":["workflow","act"],"data_shape":["record"],"principles":["orientation","consistency","surface-dont-bury"],"interaction":["decision"],"density":"low","complexity":"high","status":"stable","visibility":"public","use_when":["Real conditions must hold before work proceeds, and the cost of proceeding wrongly is high.","The same conditions apply to every record, so they can be stated once.","People currently enforce the rules by memory and vigilance."],"avoid_when":["The rules are advisory. A gate that gets overridden constantly is worse than a warning.","The conditions differ every time, so no gate can be stated.","Speed matters more than correctness here, and a blocked record costs more than a wrong one."],"alternatives":[{"slug":"checklist-workflow","when":"The items must be tracked but should not BLOCK anything."},{"slug":"linear-workflow","when":"Stages are enough and the conditions are not worth enforcing in software."}],"ask_leo":"Add gates to this workflow.\n\n- State each gate as a named, checkable condition attached to a specific\n  transition, not as a general rule. \"Cannot move to Scheduled until the\n  insurance certificate is on file.\"\n- Always show the gate BEFORE it blocks: on the record, list the conditions\n  for the next stage and which are met. Nobody should learn about a gate by\n  being refused.\n- When the advance action is unavailable, say precisely which condition is\n  outstanding and link to the thing that would satisfy it. Never a disabled\n  button with no explanation.\n- Provide an override for a named role where the business genuinely needs one.\n  An override must require a reason, be recorded in the history, and be\n  visible on the record afterwards.\n- Evaluate gates live, so satisfying a condition unblocks the record\n  immediately without anyone re-checking.\n- Report on what is blocked and by which gate, across all records. The most\n  valuable output of this pattern is learning which gate stalls everything.\n","related":[{"title":"Checklist Workflow","url":"/patterns/checklist-workflow","summary":"The same conditions tracked without blocking — decide deliberately which you want."},{"title":"Linear Workflow","url":"/patterns/linear-workflow","summary":"The stages the gates sit between."}]},"body":"## The shape\n\n```\n  New ──▶ Scheduled ──▶ In progress ──▶ Invoiced\n           ▲\n           └── GATE: to schedule this job\n                 ✓ Client contract signed\n                 ✓ Purchase order raised\n                 ✗ Insurance certificate on file   ← blocking, and it says so\n                     → Upload certificate\n\n           [ Schedule job ]  unavailable: 1 condition outstanding\n           [ Override (ops manager) ]  reason required, recorded\n```\n\nFour properties:\n\n1. **The gate is visible before it blocks.** Conditions are listed on the record\n   from the moment it enters the stage, so nobody is surprised.\n2. **The block names the specific condition** and links to the fix.\n3. **Overrides exist, are role-limited, require a reason, and are recorded.**\n4. **Gates evaluate live**, so satisfying a condition unblocks immediately.\n\n## Why it works\n\nIt moves a rule from memory into the system, which is the difference between a\npolicy that mostly happens and one that always does. The value is not\nenforcement for its own sake — it is that the rule becomes **stated**, and a\nstated rule can be argued with, measured and changed.\n\nThe reporting is the sleeper benefit. Once gates are explicit, \"what is\nblocked and by what\" is a query. Most businesses discover that one gate accounts\nfor the majority of their stalled work, and that is usually actionable in a way\nnobody could see before.\n\n## The override is not a weakness\n\nTeams often resist overrides because they seem to defeat the point. In practice\nthe opposite is true: **a gate with no override gets routed around**. People\nwill create a duplicate record, mis-set a field, or do the work outside the\nsystem entirely — and then you have neither the rule nor the record.\n\nA recorded override with a reason keeps the work inside the system and turns\nexceptions into data. If one gate is overridden 40% of the time, it is the wrong\ngate, and now you can prove it.\n\n## Getting it wrong\n\n- **A disabled button with no explanation.** The single most common failure —\n  the person cannot proceed and cannot find out why.\n- **Gates discovered on refusal**, rather than shown on arrival at the stage.\n- **No override**, which pushes work out of the system.\n- **An unrecorded override**, which is the same as no gate but with more\n  ceremony.\n- **Gates on advisory rules**, which trains everyone to override reflexively and\n  devalues the real gates.\n- **Stale evaluation**, where satisfying the condition does not unblock until\n  someone reloads or a nightly job runs.\n\n## Exemplars\n\n**Deployment pipelines** are the clearest technical example: tests, review and\nchecks are conditions on a transition, the failing one is named, and a\nbreak-glass override exists and is logged.\n\n**Regulated onboarding** — banking, insurance, healthcare — is where the pattern\noriginates commercially, and where the reporting benefit is most visible: the\nblocked-by breakdown is the operational dashboard.\n\n**Procurement approvals** demonstrate the override design well: thresholds\ndetermine who may override, and the reason field becomes the audit trail.\n\nThe extractable rule: **a gate must explain itself before it refuses.** A rule\nthe software knows and the person does not is not a gate, it is an obstacle.\n"}