Classify consequence → define evidence → route authority → escalate → test failure states → preserve record
An AI approval workflow is a controlled path that determines whether an AI supported recommendation may become an institutional action. A useful design does more than place an approval button after a model output. It classifies the consequence, defines the evidence required, resolves valid authority, creates explicit escalation paths, tests failure states, and preserves the basis of the final decision.
Start with the action that needs approval
Approval workflow design often begins too early in the technical stack. Teams start with a model, agent, automation, or interface and then ask where to insert an approval step. That approach can create a review process without first defining the decision the institution is actually authorizing.
A stronger starting point is the proposed action. State what can change if the recommendation is accepted. The action might release a payment, reroute a shipment, isolate equipment, allocate capacity, prioritize a case, publish a communication, or alter another institutional state. The approval workflow should be designed around that consequence rather than around the fact that AI produced the recommendation.
Once the action is explicit, the workflow can determine which evidence matters, which policies apply, which authority is required, whether human judgment is necessary, and what record must survive.
A six stage AI approval workflow
The operating sequence can be expressed as six stages. The sequence is intentionally decision centered. It does not assume that every workflow requires a person at every stage, and it does not assume that approval is always the correct outcome.
| Stage | Question | Required result |
|---|---|---|
| 1. Classify consequence | What can materially change if this action proceeds? | A consequence class and operating boundary |
| 2. Define evidence | What must be known before movement is allowed? | Required evidence, sources, freshness, and unresolved behavior |
| 3. Route authority | Who can accept this consequence under these conditions? | Valid authority or an explicit insufficient authority state |
| 4. Create escalation | Where does the decision go when the current path cannot resolve it? | A defined next state with context preserved |
| 5. Test failure states | What happens when evidence, systems, people, or rules fail? | Known hold, review, fallback, block, or stop behavior |
| 6. Preserve the record | Can the institution later reconstruct why the action was allowed or denied? | A coherent decision record |
The sequence is: classify consequence → define evidence → route authority → escalate → test failure states → preserve record. Each stage produces information required by the next rather than treating approval as one isolated click.
1. Classify consequence before routing the decision
An approval workflow should know what kind of institutional consequence it is handling before it decides who or what can approve it. The same recommendation type can create different consequences depending on value, geography, customer commitment, operating state, asset class, safety exposure, or another domain specific condition.
Consequence classification does not require a universal enterprise risk score. It requires a practical boundary for the workflow. Define which cases are routine, which cross a material threshold, which require independent review, and which are outside the approved operating envelope entirely.
This step prevents a common design error: routing every recommendation to the same person because the recommendations came from the same system. Approval should follow the consequence of the action, not the identity of the model that proposed it.
2. Define the evidence required for movement
The workflow should distinguish information that is helpful from information that is required. Approval should not depend only on the recommendation text, a confidence value, or a summary generated by the same system that produced the recommendation.
For each material evidence item, define the authoritative source, required freshness, completeness condition, and behavior when the evidence cannot be obtained. If evidence is stale, the workflow may refresh it or hold the decision. If two sources conflict, the workflow may route to review. If required evidence is missing, the action may remain blocked.
This creates an evidence gate that is independent of model confidence. A recommendation can be technically persuasive while the institution still lacks the factual basis required to approve the action.
3. Route authority instead of routing to whoever can access the screen
Technical permission is not the same as institutional authority. A user can be permitted to operate the system and still lack authority to accept the consequence of the proposed action.
Authority routing should evaluate the decision context. Relevant conditions can include role, delegation, threshold, jurisdiction, operating state, evidence status, policy exception, or a requirement for independent confirmation. The result should be either a valid authority path or an explicit state showing why the current actor is insufficient.
This is where approval workflows become materially different from ordinary task assignment. The objective is not merely to get the item into an inbox. It is to place the decision with an actor who can legitimately resolve it.
For a deeper treatment of contextual authority, see Decision Authority Is Not Access Control.
4. Make escalation part of the normal workflow
Some decisions will exceed the current authority, contain unresolved evidence, encounter a policy conflict, or reach a state the ordinary path cannot resolve. Escalation should therefore be designed as a normal state rather than as an emergency workaround.
A useful escalation rule identifies the trigger, the next authority or review function, the information that must travel with the decision, the actions available at the next level, and the state that follows if the escalation is still unresolved.
The recommendation, evidence, policy state, authority result, prior human actions, and reason for escalation should remain attached to the decision. An escalation that forces the next reviewer to reconstruct the case from separate systems creates delay and weakens accountability.
Approval is only one possible decision state
An approval workflow is stronger when it can represent more than approved and rejected. Consequential decisions often need intermediate states that explain what is unresolved.
| State | Meaning | Typical next action |
|---|---|---|
| Ready for authorization | Required evidence and control conditions are resolved | Route to valid authority or automated authorization inside the approved boundary |
| Evidence required | A required factual condition is missing, stale, or conflicting | Request, refresh, or verify evidence |
| Review required | Human judgment is a defined control condition | Present context and available reviewer actions |
| Authority insufficient | The current actor cannot accept the consequence | Escalate to valid authority |
| Hold | The decision should pause pending a condition or event | Reevaluate when the hold condition changes |
| Blocked | The proposed action is not permitted under the current boundary | Stop or redesign the proposed action |
| Authorized | The institutional conditions required for action are satisfied | Transmit only the permitted action to the execution path |
These states make the reason for movement visible. They also prevent unresolved conditions from being silently converted into approval because the workflow has no other place to put them.
Human review should have a defined purpose
An AI approval workflow does not become more governed merely because every recommendation requires a person. Human review should be used where a person contributes necessary authority, expertise, exception judgment, independent confirmation, or consequence ownership.
The review surface should show the decision context required for that contribution. It should also provide actions that correspond to the reason the decision entered review. A reviewer may need to approve, reject, modify, request evidence, hold, escalate, or stop the decision.
If the person cannot meaningfully change the path, the review step may become procedural rather than substantive. The design should therefore connect review triggers to real reviewer authority and available actions.
See Human in the Loop Is a Design Problem, Not a Checkbox for the detailed review model.
Avoid serial approval chains that do not add decision value
Adding more approval layers can create the appearance of control while increasing delay and obscuring responsibility. Each approval stage should have a distinct institutional function.
One reviewer might validate domain evidence. Another might hold authority above a financial threshold. An independent reviewer might be required for a specific exception class. If two stages perform the same function and neither changes the decision basis, the workflow should question why both exist.
The objective is not the fewest possible reviewers. It is a review path in which every required human or institutional control has a defined reason to exist.
5. Test failure states before production
A normal case proves that the workflow can move. It does not prove that the workflow remains controlled when something necessary is unavailable.
Test cases should force each critical dependency into an unresolved state. Use scenarios with stale evidence, conflicting evidence, unavailable authority, an expired delegation, a policy condition that blocks the action, a reviewer who disagrees, an unavailable downstream system, and an action that exceeds the approved operating envelope.
For each scenario, define the expected state, actual state, owner of the next action, and evidence that proves the workflow behaved as designed. If the result is an improvised message or an undocumented manual workaround, the failure path is not yet fully governed.
Separate authorization from execution
Approval determines whether an action is institutionally permitted. Execution changes the downstream system or operating state. Keeping those concepts distinct makes the boundary easier to control.
The authorization result should specify what action is permitted and under which limits. The execution layer should receive only that bounded action rather than the entire recommendation context with open ended discretion. If execution fails or only partially succeeds, the workflow should capture that state and determine whether the authorization remains valid.
This separation is especially useful when several systems participate in the path. The institution can preserve one coherent decision basis even when the final action is performed elsewhere.
6. Preserve the decision basis, not just the approval event
A timestamp showing that someone clicked approve is not enough to reconstruct a consequential decision. The record should connect the recommendation, required evidence, policy outcomes, authority basis, human actions where required, escalation or exception states, final authorization, downstream action, and observed outcome where available.
The goal is not to store every technical event forever. It is to preserve the material institutional path so a later reviewer can understand why the decision moved from recommendation to action.
See What Is an AI Decision Record? for the minimum field model once that Resource is installed with this program.
A compact workflow specification
Before implementation, one consequential approval workflow should be describable in a compact specification. If the team cannot fill the fields below, the workflow still contains unresolved institutional design questions.
| Specification field | What to define |
|---|---|
| Decision object | The recommendation and proposed action being controlled |
| Consequence boundary | The material states and thresholds that change control requirements |
| Required evidence | Sources, freshness, completeness, and conflict rules |
| Policy conditions | Rules that can permit, constrain, hold, or block movement |
| Authority route | Eligible authority, delegation, threshold, and jurisdiction rules |
| Human review | Triggers, reviewer context, and available actions |
| Escalation | Triggers, next authority, carried context, and unresolved state |
| Execution boundary | The exact downstream action permitted after authorization |
| Failure behavior | Known responses to missing evidence, unavailable systems, and unresolved controls |
| Decision record | The material fields needed to reconstruct the path |
Questions to test an AI approval workflow
- Is the action being approved defined more precisely than the model or agent producing it?
- Does the workflow classify consequence before routing authority?
- Can required evidence prevent movement when it is missing or stale?
- Is authority resolved separately from system access?
- Does human review occur for a defined institutional reason?
- Can the workflow represent evidence required, review, escalation, hold, block, and authorization as distinct states?
- Does escalation preserve the decision context?
- Have failure states been exercised before production?
- Is the authorized action narrower than the open ended recommendation when necessary?
- Can the institution reconstruct why the final action was permitted?
Where Vidamonti fits
Vidamonti is designed to make approval a controlled institutional decision rather than an isolated interface event. The platform model connects consequence, policy, evidence, authority, human review, escalation, authorization, execution boundaries, and decision records inside one operating path.
The objective is not to add approval steps to every AI workflow. It is to make the conditions for movement explicit so routine decisions can proceed inside a defined boundary and unresolved or higher consequence decisions move to the correct state.
Explore the broader operating path in Decision Workflows, the control layer in Decision Control, and the record capability in Decision Record.