The shape
New ──▶ Scheduled ──▶ In progress ──▶ Invoiced
▲
└── GATE: to schedule this job
✓ Client contract signed
✓ Purchase order raised
✗ Insurance certificate on file ← blocking, and it says so
→ Upload certificate
[ Schedule job ] unavailable: 1 condition outstanding
[ Override (ops manager) ] reason required, recorded
Four properties:
- The gate is visible before it blocks. Conditions are listed on the record from the moment it enters the stage, so nobody is surprised.
- The block names the specific condition and links to the fix.
- Overrides exist, are role-limited, require a reason, and are recorded.
- Gates evaluate live, so satisfying a condition unblocks immediately.
Why it works
It moves a rule from memory into the system, which is the difference between a policy that mostly happens and one that always does. The value is not enforcement for its own sake — it is that the rule becomes stated, and a stated rule can be argued with, measured and changed.
The reporting is the sleeper benefit. Once gates are explicit, "what is blocked and by what" is a query. Most businesses discover that one gate accounts for the majority of their stalled work, and that is usually actionable in a way nobody could see before.
The override is not a weakness
Teams often resist overrides because they seem to defeat the point. In practice the opposite is true: a gate with no override gets routed around. People will create a duplicate record, mis-set a field, or do the work outside the system entirely — and then you have neither the rule nor the record.
A recorded override with a reason keeps the work inside the system and turns exceptions into data. If one gate is overridden 40% of the time, it is the wrong gate, and now you can prove it.
Getting it wrong
- A disabled button with no explanation. The single most common failure — the person cannot proceed and cannot find out why.
- Gates discovered on refusal, rather than shown on arrival at the stage.
- No override, which pushes work out of the system.
- An unrecorded override, which is the same as no gate but with more ceremony.
- Gates on advisory rules, which trains everyone to override reflexively and devalues the real gates.
- Stale evaluation, where satisfying the condition does not unblock until someone reloads or a nightly job runs.
Exemplars
Deployment pipelines are the clearest technical example: tests, review and checks are conditions on a transition, the failing one is named, and a break-glass override exists and is logged.
Regulated onboarding — banking, insurance, healthcare — is where the pattern originates commercially, and where the reporting benefit is most visible: the blocked-by breakdown is the operational dashboard.
Procurement approvals demonstrate the override design well: thresholds determine who may override, and the reason field becomes the audit trail.
The extractable rule: a gate must explain itself before it refuses. A rule the software knows and the person does not is not a gate, it is an obstacle.