How Approval Workflows Prevent Automation Mistakes

On August 1, 2012, Knight Capital Group deployed new trading software to eight production servers, but the deployment script only reached seven of them. The eighth kept running old test code that had been dormant for years, and when the market opened, that code began firing unintended orders into live markets at machine speed, with nobody reviewing a single one before it executed. In 45 minutes, Knight Capital lost roughly $440 million and came close to insolvency (Henrico Dolfing, "Case Study 4: The $440 Million Software Error at Knight Capital"; U.S. Securities and Exchange Commission, Administrative Proceeding File No. 3-15570, 2013). An approval workflow, a deliberate human or independent-system checkpoint between "the automation decided what to do" and "the action actually happened," is the specific engineering answer to that exact failure shape: not slower automation, but automation with a pause built into the one moment where a mistake becomes permanent.

This article explains where that checkpoint belongs in a system, which failure modes it actually blocks, why gating everything is its own kind of mistake, and how teams that run production automation at scale decide what earns a human's attention and what doesn't.

Where the checkpoint actually goes

A well-designed approval step sits between evaluation and execution. The automation still does the hard part: it pulls the data, applies its rules, calculates the amount, drafts the message, or prepares the deployment. What it doesn't do, for a defined category of high-stakes actions, is push the button on its own. The system pauses, surfaces what it's about to do and why, and waits for a second, independent decision before the action becomes real.

Stripe's payout infrastructure illustrates the pattern at commercial scale. Payment platforms route outbound transfers through fraud and risk-scoring systems, and transactions that cross a defined risk threshold, based on signals like transfer size, account age, and behavioral anomalies, get routed to manual review rather than released automatically (Stripe, Radar documentation, stripe.com/docs/radar). The reasoning is asymmetric: a delayed legitimate payout costs a customer a day of annoyance and an apology email. An unauthorized payout that already left the building is, in the median case, gone. Reversing a wire transfer or an ACH payment after the fact means chasing the receiving bank, filing a dispute, and hoping the funds haven't already moved again, a process that can take weeks and frequently fails outright. Delaying the transfer by an hour for review costs almost nothing by comparison. That asymmetry, cheap to pause versus expensive to undo, is the actual design principle behind where approval gates get placed, not a general instinct toward caution.

It's worth being precise about what an approval step is not, because the term gets used loosely. A fixed delay before execution is not an approval step, it's just a timer; nothing about waiting four hours automatically catches a bad instruction, it just gives the same bad instruction four more hours before it fires unless a human happens to notice. A dry-run or simulation mode is not an approval step either, it shows what would happen without anyone being required to look at the output or sign off on it. An approval step specifically requires an affirmative decision, someone or something has to look at the proposed action and say yes, this should happen, using context the automation's rule set structurally cannot see. A refund-automation rule might correctly determine "this customer qualifies for a refund under policy," but it has no way to know the same customer opened a support ticket yesterday complaining about a previous refund that never should have gone out, or that this is the fourth refund request from the same account this month, a pattern that reads very differently to a human reviewer than to a rule engine evaluating each request in isolation.

GitHub's branch protection rules, which require at least one human review before code merges into a protected branch, exist for exactly this reason even inside teams that run heavily automated CI/CD pipelines. Automated tests and linters can verify a change doesn't break anything measurable in seconds, far faster than any person, but they cannot judge whether the change actually does what the business intended, which is a category of failure automated checks are structurally unable to catch (GitHub Docs, "About protected branches," docs.github.com).

The three failure modes an approval step actually blocks

It helps to be concrete about what a gate is defending against, because "add a review step" is easy advice that's easy to apply in the wrong place. Automations tend to fail in a small number of recurring shapes, and each maps to a distinct reason an approval checkpoint helps.

Bad input data. A malformed record, wrong currency code, duplicate row, a decimal point in the wrong place, doesn't confuse a rules-based automation the way it confuses a person. The automation applies its logic exactly as designed, faithfully, to garbage input, and produces a confidently wrong output. A human reviewer looking at "refund: $45,000.00" on what should have been a $450.00 refund catches the anomaly instantly, because pattern recognition for "does this number look wrong" is something people are good at and rule engines, absent an explicit check for that specific error, are not.

Logic drift. Business rules change. Pricing tiers get renegotiated, refund policy gets updated after a legal review, a discount code that was supposed to expire in June is still active in September because nobody updated the automation's condition when the policy changed. The automation keeps executing its original logic faithfully, which is precisely the problem: it has no mechanism to notice that the world around it moved and its rules didn't move with it. A human who works adjacent to that policy day to day is far more likely to notice "wait, we don't do 40% off anymore" than a condition buried in a workflow definition that nobody has opened in four months.

Cascading retries and storms. A retry loop, a webhook that fires more than once, or a queue that gets replayed after an outage can cause the same action to attempt repeatedly at volume, sometimes thousands of times in minutes, faster than any monitoring dashboard updates. Left ungated, this turns a single bad decision into a very large, very fast one. An approval step, even a lightweight one, caps the blast radius almost as a side effect: batching requests for human review naturally throttles execution to a pace a person can actually process, which puts a hard ceiling on how much damage a runaway loop can do before someone notices something looks wrong. This is the same principle discussed in why automation needs error queues: don't let a failure propagate at full automation speed, give it a place to land and slow down before it compounds.

Failure mode	What happens without a gate	How an approval step blocks it
Bad input data	Automation applies correct logic to garbage input and executes a confidently wrong action	A reviewer visually catches the anomaly before it becomes irreversible
Logic drift	Rules stay static while business context changes, and the automation keeps executing the outdated version faithfully	A human working adjacent to the policy notices the output no longer matches current reality
Cascading retries or webhook storms	The same flawed action repeats at automation speed, sometimes thousands of times in minutes	Review pace naturally caps execution speed, limiting blast radius before anyone has to intervene manually

None of these three failure modes are hypothetical edge cases. They're the recurring shape of most publicly documented automation incidents, from bad configuration pushes to feedback loops in trading systems to mass-email tools sending the wrong list.

Approval gates as a pattern, not a single design

Not every approval step looks the same, and choosing the wrong pattern for a given risk level creates its own problems, either too much friction for low-stakes actions or too little scrutiny for high-stakes ones. Four patterns show up repeatedly across production systems, and each trades speed against safety differently.

Single-approver gates route an action to exactly one reviewer, who can approve or reject it alone. This is the fastest pattern and the right default for actions that are meaningful but individually bounded in damage, a refund under a set dollar threshold, a single production hotfix, a moderate-sized customer communication. The risk with a single approver is that one person's blind spot, fatigue, or lack of context becomes the system's only line of defense, so this pattern works best paired with a clear escalation path for anything the approver isn't confident about.

Multi-tier or escalation gates route an action to different reviewers depending on its size or risk score, a support agent can approve a $50 refund, but anything over $5,000 automatically routes to a finance manager, and anything over $50,000 escalates further still. This mirrors how financial institutions structure authorization limits internally, and it lets the organization keep routine actions fast while reserving senior judgment for the actions large enough to matter at that level. The tradeoff is complexity: more tiers means more configuration to maintain and more places the routing logic itself can have a bug.

Quorum-based gates require agreement from multiple independent approvers before an action executes, rather than a single yes. Multi-signature (multisig) cryptocurrency wallets are the clearest example: a transaction only broadcasts once a defined threshold of independent private keys has signed off, specifically so that no single compromised key, or single person acting alone, can move funds (Bitcoin Wiki, "Multisignature"). Outside crypto, the same pattern shows up as "two-person review" requirements for the highest-stakes production changes at large infrastructure providers, sometimes called dual control. Quorum gates are slow and deliberately expensive to satisfy, which is the point, they're reserved for actions where a single point of failure, whether malicious or simply mistaken, would be catastrophic.

Time-boxed auto-approve gates flip the default: the action queues for review, but if no reviewer rejects it within a defined window, it proceeds automatically. This pattern accepts a real tradeoff. It keeps automation from stalling entirely when reviewers are slow, backlogged, or asleep across time zones, but it means the "gate" only functions when someone is actually paying attention within the window, and a genuinely dangerous action that nobody happens to look at in time slips through by default rather than by design. It's best reserved for medium-risk actions where a modest delay before default-approval is an acceptable cost, not for anything in the Knight Capital or wire-transfer category of irreversibility.

Pattern	Speed	Best fit	Main weakness
Single-approver	Fast	Bounded, moderate-risk actions (routine refunds, single-service hotfixes)	One reviewer's blind spot is the only safeguard
Multi-tier / escalation	Medium	Actions whose risk scales with size (refunds, discounts, spend limits)	More configuration surface, more places routing logic can break
Quorum-based	Slow	High-irreversibility, high-blast-radius actions (large fund transfers, top-tier production changes)	Deliberately expensive to satisfy; unsuitable for high-volume routine work
Time-boxed auto-approve	Fast by default	Medium-risk actions where a stall is worse than an occasional miss	Only functions if a reviewer is actually watching within the window

Why gating everything is also a mistake

Requiring approval for every automated action defeats the purpose of automating at all, and it introduces a second, subtler failure that's easy to miss until it's already caused damage: approval fatigue. When a reviewer is asked to sign off on hundreds of routine, low-risk actions a day, they stop actually reading each one carefully and start clicking approve on reflex, which is functionally equivalent to having no gate at all, except now it also comes with the false confidence that someone checked.

This is well documented in security operations, where alert fatigue from an excess of low-priority warnings causes analysts to develop pattern-matching shortcuts that let genuinely dangerous alerts slip past unnoticed, buried among hundreds of routine ones that turned out to be nothing (SANS Institute, security operations research on alert fatigue is a recurring theme across published SOC studies). The mechanism transfers directly to approval workflows: a reviewer who has approved 40 nearly-identical low-stakes refunds in the last hour is not reading number 41 with the same scrutiny they applied to number one, and a rule engine that routes every single action through that reviewer regardless of stakes is training them, unintentionally, to stop looking.

How do teams decide what needs approval and what doesn't?

Most mature automation systems tier actions by two variables together, reversibility and blast radius, rather than by how technically complex the underlying automation is. Sending an internal Slack notification needs no gate because getting it wrong costs nothing worse than an ignorable message. A refund under a defined small threshold might auto-approve because the dollar exposure per mistake is capped and low. Deleting a customer account, sending an external mass communication, or transferring funds above a meaningful threshold gets a mandatory human check, because each of those is expensive or outright impossible to undo once it fires. The gate should scale with how costly a mistake would be to reverse, not with how sophisticated the automation logic behind it happens to be. A genuinely simple script that permanently deletes records needs more scrutiny than a genuinely complex pipeline that only ever produces a draft email a human still has to send.

The friction-versus-speed tradeoff, honestly

Every approval gate has a cost that's easy to understate: it adds latency, and latency compounds. A single review step that adds three minutes sounds trivial in isolation, but a workflow with four sequential gates, each waiting on a different person in a different time zone, can turn a task that would complete in seconds into one that takes days, and during that wait, the business context the automation was reacting to can change out from under it. A fraud check that flags a transaction correctly at the moment of the attempt might, by the time a human finally reviews it two days later, be reviewing a decision that's no longer relevant, because the customer already contacted support and resolved the issue through another channel.

The honest framing isn't "approval gates are safer, full stop." It's that approval gates trade a quantifiable amount of speed for a specific, targeted reduction in the probability of an irreversible mistake, and that trade is only worth making where the cost of the mistake clearly outweighs the cost of the delay. Applying a gate to the wrong category of action, something reversible, cheap, and low-volume, doesn't make the system safer, it just makes it slower for no corresponding benefit, and teams that over-gate tend to discover this the same way teams that under-gate discover their mistake: after the friction has visibly cost them something, in this case velocity and reviewer trust in the process, rather than a specific dollar figure.

Real systems resolve this tension by keeping the number of sequential gates per workflow small and by making sure each gate that exists is actually earning its place, tied to a specific, named failure mode it's meant to catch, rather than added reflexively because "review steps feel responsible." A useful discipline is asking, for every gate already in a system, what specific incident would this have prevented, and if nobody can answer that concretely, the gate is very likely there out of habit rather than design.

What the Knight Capital incident actually teaches about gating

It's worth returning to the Knight Capital case with more precision than "a bug cost $440 million," because the specific mechanics show exactly where an approval-style checkpoint would have changed the outcome, and where it wouldn't have. The root cause was a deployment process: new trading logic was pushed to seven of eight production servers, and the eighth kept running an old, dormant test routine internally called "Power Peg," left over from a feature that had been retired years earlier but never removed from the codebase (SEC Administrative Proceeding File No. 3-15570, 2013). When the market opened, that dormant code activated under a repurposed flag and began sending unintended orders, and because there was no automated circuit breaker or human checkpoint positioned between "the trading algorithm decided to send an order" and "the order reached the exchange," the errant trades executed at full machine speed for 45 minutes before anyone intervened manually.

An approval gate wouldn't have been the right tool for reviewing each individual order, that volume and speed is precisely the kind of task algorithmic trading exists to handle and no human review process could keep pace with it. But a deployment-level gate, a mandatory verification step confirming that all eight servers were running the intended code before trading began, or an automated kill switch that halted trading the moment order volume or order pattern deviated sharply from expected baselines, sits exactly in the category this article describes: a checkpoint between "the system is about to do something with significant, hard-to-reverse consequences" and "it actually happens." Knight Capital did have risk controls in principle, the incident is generally understood as a case where deployment verification and pre-trade risk checks that should have caught the anomaly were either misconfigured, bypassed, or insufficiently strict for the scenario that actually occurred, not a case where no safeguards existed on paper at all. The lesson isn't "add more approval steps to every automated system." It's that the checkpoint has to sit at the actual point of highest leverage, in this case deployment verification, not somewhere further downstream where the damage is already compounding at machine speed.

What this means

Approval workflows aren't a statement of distrust in automation, they're an acknowledgment that some mistakes are cheap to undo and some effectively aren't, and no rule engine, however well designed, can anticipate every piece of context a human reviewer can weigh in a few seconds of looking at the right screen. The engineering discipline isn't maximizing how many actions get reviewed, it's identifying, honestly and specifically, which actions in a given system are expensive or impossible to reverse, and making sure those, and only those, are the ones a person looks at before they become permanent. Get the tiering wrong in one direction and a $440 million deployment error runs unsupervised for 45 minutes. Get it wrong in the other direction and reviewers stop reading what they're approving, which is the same failure wearing a different disguise.

---

Read next:

• How idempotency keys make automation safe
• Why automation needs error queues
• Why webhooks fail silently and how to monitor them

FAQ

Q: What kinds of automated actions typically require approval workflows?

Actions that are expensive or effectively impossible to reverse once they execute, large financial transfers, mass customer communications, account deletions, or production deployments to critical systems, are the most common candidates for a mandatory human checkpoint. Low-risk, easily reversible actions like internal notifications or small, capped-value refunds usually run without a gate, because the cost of a mistake is low enough that the delay isn't worth it.

Q: Doesn't requiring approval defeat the purpose of automating a task?

Not if the gate is applied selectively and to the right step. Automation still handles detection, data gathering, evaluation, and preparation of the action; the approval step only pauses the final, highest-risk execution moment, which is typically a small fraction of the overall workflow's total time and effort. The goal is gating the one irreversible moment, not re-inserting a human into every step that came before it.

Q: What is approval fatigue and why does it undermine safety?

Approval fatigue happens when reviewers are asked to sign off on so many routine, low-risk actions that they stop reading each one carefully and start approving on reflex, a pattern well documented in security operations research on alert fatigue. At that point the gate provides no real judgment even though it still appears in the audit log as "reviewed," which is why mature systems reserve human approval steps for genuinely high-stakes actions rather than routing everything through the same checkpoint.

Q: How do companies like Stripe decide which transactions need manual review?

Payment platforms typically use risk-scoring systems that weigh factors like transaction size, account history, and behavioral anomalies, routing only the transactions that cross a defined risk threshold to human reviewers rather than reviewing every transaction manually. This keeps routine, low-risk payouts moving at automation speed while reserving reviewer attention for the transfers where a mistake would be genuinely costly to reverse.

Q: What actually went wrong at Knight Capital in 2012, and could an approval step have prevented it?

A software deployment reached seven of Knight Capital's eight production trading servers, leaving one running old, dormant test code that activated under a repurposed feature flag and generated unintended trades for 45 minutes, costing the firm roughly $440 million (SEC Administrative Proceeding File No. 3-15570, 2013). A per-order approval step wouldn't have worked at trading speed, but a deployment-verification checkpoint confirming all servers ran the intended code, or an automated kill switch tied to abnormal order-pattern detection, sits exactly where this article's framework says a gate belongs: at the specific point of highest leverage before an action becomes irreversible.

Q: What's the difference between a single-approver gate and a quorum-based approval gate?

A single-approver gate lets one reviewer approve or reject an action alone, which is fast but means that reviewer's judgment is the only safeguard. A quorum-based gate requires agreement from multiple independent approvers, similar to how multi-signature cryptocurrency wallets require several private keys to sign before a transaction broadcasts, and it's deliberately slower and reserved for actions where a single point of failure would be catastrophic.