Durable Approval Gate
Approval should be a durable truth fact checked at the effect boundary, not a reminder or transient workflow state. Let automation prepare work quickly, but require recorded approval before external effects execute.
Problem
Approval often begins as a reminder: "make sure someone reviews this before it goes out." Reminders depend on attention, habit, and the happy path. They fail when work is automated, retried, delegated, queued, or executed by a worker after the person who approved it has moved on.
Context
Use this pattern when a workflow can create outbound actions, commitments, public messages, financial effects, bookings, access changes, or any other consequential effect outside the system. It is especially important when automation can prepare work faster than people can inspect it.
Forces
- Internal drafting should stay fast.
- External effects need accountability.
- Approval stored in a queue, UI flag, chat thread, or cache can disappear or be misread.
- Workers and retries need to know whether approval exists without asking a person again.
- Missing information should block approval instead of being guessed away.
- Operators need to answer who approved what, when, under which workflow, and what happened next.
Solution
Make approval a durable truth fact and place it on the boundary before external effect. Separate prepare from execute. Let the system inspect, draft, route, and request missing information before approval, but require an approval record before the effect crosses into the outside world.
The approval record should identify the actor, workflow, action, scope, evidence or inputs, approval time, result, and idempotency key or execution identity. Workers and connectors check that record, not a transient queue or UI state. Queue entries may dispatch approved work, but they are hints, not approval records. If approval creates work for later execution, that obligation needs its own durable work record or an approval binding that serves the same truth-plane role. The record should also bind to the specific payload or connector invocation it authorizes, so a later worker cannot reuse it for a broader or different effect. It should preserve lifecycle state, so pending, expired, revoked, executed, or failed approvals are not treated as currently executable. A retry policy should decide whether a failed or uncertain approved action may run again or must return to review.
Consequences
Approval becomes architecture instead of etiquette. Automation can prepare useful work without being allowed to send, book, publish, charge, or commit prematurely. The system can prove whether a specific action was authorized and whether it already executed.
Failure Modes
- Approval exists only as a checkbox, chat message, queue item, or notification.
- Workers execute because a task moved to a column that "means approved."
- Approval records do not bind to a specific action or workflow.
- Missing information is guessed so the approval path can continue.
- A retry sends the same approved external action twice.
Proof Points
MariaDB truth; workers and queues accelerate execution but do not own permission.
demands it, and the decision record preserves the authorization path.
- SADIE — outbound actions require approval recorded in
- AISDR — security actions require approval where policy
Full source pattern: durable-approval-gate.md.