Design an approval gate that changes what a workflow is allowed to do—not just what the interface displays.
Praxenor3 min readSeptember 2026
Approval should change authority.
A review gate should determine what the workflow is allowed to do next. A banner saying “human in the loop” is not enough when the system can continue without a decision.
Define the state before the gate, the evidence available to the reviewer, the action that needs approval, and the specific state transition created by that approval.
Show the evidence, not just the answer.
A useful review package includes the objective, source material, assumptions, checks, unresolved issues, and the exact action being proposed.
Give the reviewer a way to ask whether the result meets the original criteria. The interface should not make approval feel inevitable.
Make “revise” a first-class path.
Revision needs somewhere concrete to go. Record what the reviewer challenged, return the work to the appropriate stage, and invalidate the previous approval state.
The revised work should pass through review again. It should not inherit approval from the version that was rejected.
Try the boundary in the demo.
In the scripted Stillpoint walkthrough, advance an example to review. Choose “Request revision,” inspect the new activity entries, then move the revised draft back through the gate.
The approved-example export remains unavailable until you approve. This is a small, testable interaction—not proof of a complete production authorization system.