Human gate
A workflow pause that waits for a named person to approve a high-value or high-risk agent action, and leaves an audit entry behind.
A human gate pauses a workflow until a named person approves. It is the control that makes high-value or high-risk actions safe, and it leaves an audit entry.
A human gate pauses a workflow until a named person approves. It is the control that makes high-value or high-risk actions safe, and it leaves an audit entry.
All glossary terms
The short version
- A human gate is a deliberate stop in a workflow where a named person must approve before the agent continues.
- It is not a guardrail. A guardrail is an automated policy check that decides in milliseconds; a gate exists for the exception that policy should not decide alone.
- A gate that approves almost everything is worse than no gate, because it records consent without exercising judgement.
- Design the reviewer screen before the workflow: the decision, the evidence, the diff and a recommendation on one page.
- Gates cost time, so place them by value, irreversibility and regulatory exposure, not on every step that feels important.
- Every approval is a record. Under DPDP and any audit, the useful artefact is who approved what, on which policy version, at what time.
The definition: a stop with a name attached
A human gate is a point in an automated workflow where execution pauses until a specific person approves, edits or refuses the next action. The pause is deliberate, not a fallback for an error. The workflow knows it is waiting, the waiting is visible to someone, and the run cannot continue on a timeout without a defined escalation. The gate produces a decision attributed to a person, and that attribution is the whole point: the organisation is choosing to accept human judgement for this class of action.
Three properties separate a real gate from a decorative one. The approver is named or belongs to a named role with delegated authority, not an anonymous shared inbox. The evidence needed for the decision is present at the moment of the pause, not one click away in another system. And the decision is recorded with enough context that a later reviewer could reconstruct it. Remove any of the three and you have a notification, a rubber stamp or a rumour.
What it is not: a gate is not an approval step in a marketing tool that auto-approves after two hours, and it is not a Slack message asking whether something looks fine. It is not a guardrail, which is automated and runs on every request. And it is not a blocker. A gate should offer a clear path forward, including a refusal with a reason, so that the customer is not left in silence while the organisation deliberates.
Human gate and guardrail: the line to draw
The two controls answer different questions. A guardrail asks whether this action is inside the policy, and answers automatically: the amount is under the cap, the consent record exists, the tool is allowed for this intent. A human gate asks whether to make an exception, and answers with a person: the amount is over the cap, the customer has a genuine dispute, the case does not fit the rule but refusing would be wrong. The guardrail is the fence; the gate is the gate in the fence.
The order matters. Put the guardrail first, so that the routine cases never reach a person. Then put the gate behind the threshold, so that only exceptions consume attention. A workflow that gates everything has no policy, just a queue. A workflow that gates nothing has policy but no discretion, and it will refuse the cases that generate the angriest customers. The refund cap is the clearest example: below the cap the guardrail decides, above it the gate decides, and the cap itself is reviewed quarterly using the gate override rate. The companion entry on the guardrail covers the automated side of that pair in detail.
The two controls also fail differently. A guardrail fails by being wrong at scale: a threshold set too tight blocks a thousand legitimate requests before anyone notices. A gate fails by being absent in practice: the reviewer is on leave, the queue is three days deep, or the approval button is pressed without reading. Monitoring a guardrail means watching block and override rates. Monitoring a gate means watching time-to-decision, edit rate and the share of approvals that changed anything. Neither dashboard tells you about the other.
What a gate must capture
A gate that records only approved is useless. The minimum record is who decided, what exactly was proposed, which policy version framed the decision, what evidence was shown, when the decision was made, and what changed as a result. If the reviewer edited the amount or the wording, the edit is part of the record, because the difference between the proposal and the outcome is where the learning lives. An approval that mirrors the proposal exactly tells you the agent was right or the reviewer was not reading, and the edit rate is how you tell which.
The policy version matters more than teams expect. A gate decision is only defensible against the policy that was in force at the time. If the cap moved from twenty-five thousand to forty thousand last month, an approval from three months ago should be read against the older number. Storing the version turns a pile of approvals into an auditable history. It also makes a policy change testable: you can compare the edit rate before and after the threshold moved, which is a far better argument than an opinion in a review meeting.
Keep the record small and durable. The full conversation does not belong in the approval row; a link to the run trace does. The row should survive when the transcript is deleted under a retention rule, which means it must not depend on personal data that will disappear. Store identifiers, amounts, timestamps and the decision. If the customer later exercises a right to erasure, the approval record can remain as a business record with the personal detail removed, and that separation should be designed before the first request arrives.
Where to place a gate
Four criteria justify a gate, and a case usually needs only one. Value: the amount is large enough that a mistake is material, whether that is a refund, a discount, a credit note or a contract term. Irreversibility: the action cannot be undone, such as deleting an account, sending a legal notice, publishing a price or transferring a domain. Regulatory exposure: the message or decision touches a regulated claim, a lending approval, an insurance outcome or a medical statement. Novelty: the situation is outside the cases the agent has been evaluated on, which includes a new product, a new market or a new channel.
Value thresholds should be set in rupees and reviewed against the loss distribution rather than against a feeling. If the average refund is twelve hundred rupees and the ninety-ninth percentile is eighteen thousand, a gate at twenty-five thousand catches almost nothing and a gate at five thousand catches a fifth of the volume. The right number is where the expected cost of a wrong automated decision exceeds the cost of review, and that calculation should be written down so the threshold can move when either side changes.
Avoid gating by anxiety. A gate on every outbound message feels safe and produces a queue that nobody can clear, which in practice becomes a two-hour auto-approval. A better pattern is a small number of gates on the decisions that actually carry risk, plus a sampled review of the automated cases. Sampling catches drift without blocking throughput, and it gives you evidence about whether the guardrail thresholds are still right.
The rubber stamp problem
A gate is a control only while the reviewer is actually deciding. When the queue is long, the cases are repetitive and the agent is usually right, approval becomes a keystroke. The symptoms are recognisable: approval rates above ninety-eight percent, median decision times under ten seconds, edit rates near zero, and reviewers who cannot recall a case from the previous day. At that point the gate is producing evidence of oversight without oversight, which is more dangerous than no gate because it looks like a control to an auditor.
The cause is usually design rather than laziness. If the approval screen shows a wall of text, the reviewer learns to scan for the approve button. If the same case type arrives two hundred times a day, attention collapses. If refusing requires typing a reason and approving is one click, the interface is making the decision. And if the reviewer is measured on queue clearance rather than decision quality, the incentive points the same way.
The remedies are structural. Route only genuine exceptions to a person, so the queue stays small enough to think about. Show the decision and its evidence, not the whole transcript. Make the approve and refuse actions equally easy, and require a reason for both, not just for refusal. Rotate a sample of automated cases into the queue as unlabelled controls, so the reviewer cannot tell which ones the agent was confident about. And report the edit rate as a quality signal for the gate itself, not as a failure of the agent.
Designing the reviewer screen
The reviewer screen is the interface of the control, and most teams build it last. It should answer four questions in one view: what is the agent asking to do, why does it think that is right, what would change if the answer is yes, and what is the recommended action. The recommendation is not a substitute for judgement, but it gives the reviewer a position to disagree with, which is faster than starting from a blank page.
Show the diff. If the agent proposes to send a message, show the exact text. If it proposes an amount, show the computation, including tax, fees and any prior credit. If it proposes to change a record, show the before and after. A reviewer who has to open three tabs to understand the change will stop opening tabs. The screen should also show the customer history that matters, such as previous refunds and open tickets, without becoming a second CRM.
Then make the safe action fast and the risky action deliberate. Approve can be a button. Refuse needs a short reason, ideally from a list plus a free-text note. Edit should be possible without leaving the screen, because the common case is not a binary yes or no but a correction of one field. And every action should show what happens next, including the message the customer will receive and the time it will arrive, because the reviewer is approving the customer experience as well as the transaction.
Time, delegation and the hours nobody staffs
A gate introduces latency, and the latency has to be designed rather than discovered. A decision that takes four hours is fine for a credit note and unacceptable for a delivery slot. Set a target for each gate class, staff to it, and tell the customer what to expect at the moment of the pause. The worst outcome is not a slow approval; it is a customer who was told a person would confirm and then hears nothing for two days.
Delegation needs a matrix, not a habit. Who can approve up to what amount, who covers when the primary approver is on leave, and what happens outside business hours. An out-of-hours gate should either route to an on-call approver for urgent classes or hold the action and set an expectation. It should never auto-approve because nobody is watching. If the volume outside hours is high enough that auto-approval feels necessary, the threshold is wrong.
Escalation is the third leg. A refused case needs a path to a second reviewer, and a stalled case needs a timeout that notifies someone rather than silently expiring. Expiry is a decision too, and it should be recorded as one. The design rule is that every state of the gate, approved, edited, refused, escalated and expired, has an owner and a customer-facing consequence, and none of them is silence.
Audit, DPDP and the authority matrix
An approval is a business record, and it should be treated like one. Keep the approver identity, the role that granted authority, the policy version, the timestamp and the decision. Do not keep the whole conversation in the approval table; link to the run trace and let retention rules govern the transcript. Under the DPDP Act, an erasure request may remove the personal data in the conversation while the approval record survives as evidence that a decision was taken, provided the record itself is minimised. That balance has to be designed, not improvised after the first request.
The authority matrix is the document that makes the gate defensible. It maps roles to limits: a support lead up to twenty-five thousand rupees, a finance manager up to two lakh, a director above that. It should also say who can approve a policy exception, who can change the matrix, and how a delegation is recorded when someone is acting out of role. A gate whose approver has no documented authority is a signature without a mandate, and an auditor will ask for the mandate before the signature.
Access control should enforce the matrix rather than rely on the interface. If a support lead can technically press approve on a two lakh credit note because the button is visible, the matrix exists only on paper. Enforce the limit in the service that executes the action, check the approver role at decision time, and log a refusal when the limit is exceeded. The interface can hide what is not permitted, but the enforcement belongs in the action layer.
Measuring gate health
Five numbers describe a gate well. Volume is how many cases arrive per day, by class. Time to decision is the median and the p95, because the tail is what customers experience. Approval rate is the share approved without change, and a rate near one hundred percent is a warning rather than a success. Edit rate is the share where the reviewer changed the proposal, which measures how often the agent was close but wrong. Refusal rate is the share rejected outright, which should be small and explainable.
Add a quality check that is independent of the queue. Every week, sample ten decided cases and have a second person judge whether the decision was right given the evidence. That review is the only way to know whether the gate is improving outcomes or merely moving them. It also catches the slow drift where a threshold quietly becomes too permissive because the reviewer has stopped reading.
Report the numbers next to the guardrail metrics. A rising edit rate with a stable block rate suggests the agent is being asked to handle cases outside its evaluation, not that the guardrail is broken. A falling time to decision with a rising refusal rate suggests reviewers are rushing. The pair of dashboards tells a story that neither one tells alone, and that story is what a quarterly policy review should be based on.
Worked example: a credit note above twenty-five thousand
A Mumbai distributor runs an agent that handles damaged-goods claims on WhatsApp and email. A claim below twenty-five thousand rupees is settled automatically if the photos, the invoice and the delivery date all validate. Above that, the agent prepares a credit note and opens a gate. The reviewer sees the order, the invoice line items, the photos, the computed credit including eighteen percent GST, the customer history and a recommendation with the reason.
The agent is not allowed to issue the credit note itself. The action layer enforces the limit, so even a bug that calls the tool directly returns a refusal. The reviewer can approve, edit the amount or refuse with a reason. When the amount is edited, the difference and the reason are recorded, and the credit note is regenerated with the corrected figure. The customer receives a message at the moment of the pause saying that a person is reviewing the claim and when to expect an answer, and a second message when the decision is made.
After a quarter, the edit rate is twenty-one percent and most edits reduce the amount because the agent was not deducting a restocking fee consistently. That is a guardrail fix, not a gate problem: the fee rule moves into the policy layer, the edit rate falls, and the gate handles fewer routine cases. This is the loop the two controls are supposed to form. The gate generates the evidence, and the evidence improves the automation.
Frequently asked questions
What is the difference between a human gate and a guardrail?
A guardrail is an automated policy check that runs on every request and decides in milliseconds whether an action is allowed. A human gate is a deliberate pause where a named person approves an exception. The guardrail covers the routine at scale and costs almost nothing per decision; the gate covers the rare case that needs judgement and costs attention. Most workflows need the guardrail first and the gate behind a threshold.
When should a workflow have a human gate?
When at least one of four conditions holds: the value is material, the action is irreversible, the decision carries regulatory exposure, or the situation is outside what the agent was evaluated on. A refund above a cap, a domain transfer, a lending approval and a new product launch are four different examples of the same principle. Gating everything feels safe but produces a queue that gets rubber-stamped.
How do we stop reviewers from rubber-stamping?
Keep the queue small by routing only genuine exceptions, show the decision and its evidence rather than a wall of transcript, make approve and refuse equally easy with a required reason for both, and mix a sample of automated cases into the queue as unlabelled controls. Measure the edit rate and review ten decisions a week with a second person. If the approval rate is near one hundred percent, the gate is not working.
How long should a gate take?
Set a target per class rather than one number. A delivery reschedule needs minutes, a credit note can take hours, a contract exception can take a day. What matters is that the customer is told the expectation at the pause and that the promise is met. A stalled case should escalate on a timer, and an expired case should be recorded and communicated rather than silently dropped.
What should the approval record contain?
The approver, the role that granted authority, the proposal, the policy version in force, the evidence shown, the timestamp and the final decision including any edit. Link to the run trace rather than copying the conversation. The record should survive deletion of the transcript, so keep it minimised and free of personal detail that a retention rule might remove.
Does DPDP require human review of automated decisions?
The DPDP Act does not create a general right to human review of every automated decision in the way some other frameworks do, but it does require lawful processing, notice, purpose limitation and grievance redressal. Sector rules and contractual commitments can add more. In practice, a gate is often the mechanism that makes a contested decision explainable, which is why it belongs in the design even when the statute is silent.
Should the agent recommend a decision at the gate?
Yes, with the reason attached. A recommendation gives the reviewer a position to disagree with, which is faster than starting from a blank page, and it makes disagreement explicit in the record. The risk is anchoring, so show the underlying evidence and the computation, not only the conclusion. Reviewers should be able to edit a single field without redoing the whole analysis.
What happens if nobody approves in time?
The case escalates on a timer to a backup reviewer and then to a team lead, and the customer is told what is happening. If the class is genuinely urgent, route it to an on-call approver. Never auto-approve because the queue is unattended, and never let a case expire without a recorded outcome, because an unanswered request is still a decision from the customer point of view.
How many gates should a workflow have?
As few as the risk justifies, usually one or two. Each gate adds latency and a queue to staff, and every additional gate dilutes attention across more cases. Start with one gate on the highest-value or least-reversible action, measure its edit and refusal rates for a quarter, and add a second only when the evidence shows a class of decision that the current controls handle badly.