Align Durable Stage, Gate Status, and Dispatch Authority
Jul 07, 2026
A governed workflow can block premature execution and still record a lie. When durable state says you have reached the next stage while a human gate is still pending, dispatch protection alone is not enough. The fix is to align three truths: the recorded lifecycle stage, the gate status, and who is allowed to dispatch work.
The problem
The symptom looked like a documentation mismatch. A workflow item appeared to be at the implementation stage while it was still waiting at a human design review gate.
The first assumption was that work was starting too early. That was wrong. Preflight checks already blocked premature dispatch. Execution remained protected.
The deeper defect was semantic. Durable lifecycle state claimed the next stage while the item was still parked at the gate. Three concepts had drifted apart:
- Current lifecycle stage — what the system records as the item's position
- Human gate status — whether a required review is pending, accepted, or not applicable
- Worker dispatch authority — whether automated work may actually start
The old design kept dispatch safe but allowed those three truths to diverge. Operators and downstream automation could read state that did not match gate reality.
What actually happened
What began as a small wording correction turned out to be a material lifecycle change. The guarded implementation waypoint was encoded across protocol definitions, manual guidance, automated stage writers, transition rules, validation logic, and tests. Changing one invariant — routes that require design review must remain durably parked at that gate until review is accepted or explicitly overridden — required coordinated updates across many surfaces.
The fix was structural, not cosmetic:
- Post-audit helpers now write the correct gate stage instead of advancing prematurely
- The transition graph removes a bypass that normalized state to the implementation stage before the gate cleared
- The execution adapter performs the authorized gate-to-implementation advance immediately before dispatch
- Validation rejects the contradictory combination of implementation stage plus required-and-pending gate
- Documentation and automated guidance now describe the same lifecycle
The chosen mutation seam mattered. The stage write occurs only after classification and unchanged preflight have authorized implementation. That preserved existing dispatch authority rather than moving or duplicating gate logic.
A deliberate exception remained. Direct routes that do not require design review still start at implementation with the gate marked not applicable. The change did not become a broad route-policy redesign.
Verification went beyond unit tests. Controlled runtime scenarios exercised multiple route types and confirmed each one:
- persisted the design gate while review was pending
- paused rather than dispatched
- reached implementation only after gate acceptance
The lesson
A durable stage label is not merely descriptive metadata. In a governed lifecycle, it is part of the control model. It must represent the item's actual position.
Blocking worker dispatch is necessary but insufficient. If persisted state already claims the next stage, dashboards, audits, resumption logic, and human operators inherit a false picture even when execution stays safe.
Treat recorded lifecycle state and dispatch permission as separate concepts that must align. They can diverge temporarily during transitions, but they should never contradict each other in a steady state.
The broader principle
Lifecycle semantics live in many mirrors: protocol canon, operator prompts, automated writers, transition graphs, parsers, and tests. A change that looks like one invariant on paper often has hidden cross-surface complexity.
For lifecycle work, partial landing is worse than no landing. Shipping the runtime fix without updating transitions, or updating prompts without validation, recreates contradictory truths across the system.
The residual risk is drift. Later changes that touch only one surface can silently reintroduce the old contradiction.
How to apply it
For similar lifecycle corrections:
- State the invariant in both dimensions — durable stage and dispatch authority, not just "don't start too early."
- Name every affected surface at intake — canon, manual mode, automated mode, transition model, validation, and active tests.
- Require a route matrix covering every affected route and every gate disposition, including deliberate exceptions.
- Identify the sole authority that may perform the stage transition. Do not duplicate gate logic at a second layer.
- Preserve existing gate enforcement where possible. Fix semantics at the write boundary rather than relocating controls.
- Add a negative test for the exact invalid state you are removing.
- Include a runtime probe demonstrating: pending gate → parked state and no dispatch; accepted gate → stage advance and dispatch eligibility; exceptions unchanged.
- Land coordinated changes together when partial deployment would create conflicting lifecycle truths.
If you are reviewing an existing system, ask:
- Can dispatch be blocked while durable state already names the next stage?
- Do transition edges, validation rules, and operator guidance agree on what stage means?
- Is there exactly one place authorized to advance past a human gate?
- Would a search for the old invalid state still find active enforcement paths?
When those answers disagree, you do not have a wording problem. You have a control-model problem.
