· Rakesh Gangwar
An approval request arrives with an invoice attached and a note: “Please review.”
The reviewer opens the invoice, finds the account in another system, checks the current exposure, looks for the policy that applies, and tries to work out why the case was escalated. The software created an approval step. It did not reduce the work required to approve anything.
This is where many human-in-the-loop designs fail. They treat the gate as a place to send work rather than a place to make a decision.
A gate should preserve the decision boundary
The first thing on the screen should be the decision being requested.
Not “review this case.” Something closer to: approve an exception, reject it, or return it for more evidence. The reviewer should also see what will happen after each choice. Approval may release the case to the next step. Rejection may close it. A request for evidence may pause it and notify the person who can supply what is missing.
That boundary matters because approval is authority, not feedback. A comment box attached to an agent output does not say who owns the decision or what the process is allowed to do next.
The reason it stopped should be explicit
An AI worker can produce a plausible recommendation even when the case is outside its authority. The gate therefore needs to show why the process stopped.
Perhaps a confidence threshold was not met. Perhaps a policy rule requires a second approver. Perhaps two documents disagree, or a required document never arrived. These are different situations. “Low confidence” alone is not enough if the reviewer cannot see what the uncertainty is about.
The escalation reason should come from the process and its policy, not from a sentence the model invents after deciding to ask for help.
Evidence should arrive with the recommendation
Consider an illustrative invoice exception. The reviewer may need the invoice, the buyer record, the exposure returned by a system of record, the applicable policy result, and the discrepancy that triggered the gate.
Showing only the model’s summary makes the reviewer trust the model or repeat its work. Showing every raw event creates a different problem: the relevant facts disappear inside a trace.
A useful review packet sits between those extremes. It presents the source material, the checks that ran, the result of each check, and the proposed action. The reviewer can inspect the underlying evidence when necessary without rebuilding the file from the beginning.
Policy belongs beside the case
The reviewer should see which rule applied and which version of that rule was in force.
This is one reason we keep policy in versioned decision models rather than burying thresholds in prompts. The gate can show that a case was routed because a named rule produced a specific result. If the rule changes later, the old decision still points to the policy that governed it at the time.
The policy is also what limits the reviewer. If one role may approve up to a certain boundary and another role is required beyond it, the task should be routed accordingly. The interface should not offer an action the reviewer has no authority to take.
The response becomes part of the process record
Approve and reject are not enough. A reviewer needs to record a rationale, especially when overriding the recommendation or making an exception to the usual path.
That rationale should travel with the case. The record then contains the input, the policy version, the recommendation, the person who decided, the decision, and the time it happened. An override can later reveal a bad threshold, a missing policy exception, or a model behavior worth testing.
In Superprocess, confidence thresholds and policy flags can pause a run and route it to a human task with the case context. The process resumes from the gate only after the assigned decision is made. The point is not to eliminate the reviewer. It is to make review the only work left for them to do.
If your approval queue still begins with “find out what happened,” it is not an approval system yet. It is another inbox.