Under a percent or two. That is the rejection rate that turns an approval gate into a lie.
Count the approvals, count the rejections, and if a human clicks "yes" on more than roughly ninety-eight or ninety-nine of every hundred prompts over a few hundred actions, per E2, the gate is not catching anything. It is manufacturing an audit trail of human consent for actions no human evaluated.
Hold that number. It is where this whole argument lands, and we need to walk backward to it, starting with the order every product team now hears.
The brief goes like this: move faster, use the tools the company already purchased, keep up with every release, spend less money on AI, and learn all of it without taking time away from your actual work.
That is not a strategy. It is five instructions that cancel each other out, delivered as if they formed a single coherent sentence.
You cannot go faster while learning new tools on top of a full workload. You cannot keep up with every release while spending less. The order is incoherent, and everyone receiving it knows it, which is why the honest response is not a bigger plan. It is a smaller unit of proof.
That smaller unit is what NN/G calls PROVE — Problem Alignment, Risk, Output Quality, Velocity, Experience. The name matters less than the scope. PROVE is explicitly not for organization-wide tool recommendations. It evaluates one tool against one task and ends with a decision one person can defend to a manager, a teammate, a client, or themselves.
Watch how deliberately small it stays. The worked example is not a platform migration. It is one writer asking whether Gemini Notebooks can draft a weekly Slack digest of two to four articles.
Problem alignment first: the task recurs weekly, so any gain compounds; the audience is an internal channel, so it doesn't demand publication quality; and the tool's core mechanic — upload sources, synthesize across them — maps onto the actual job.
Then risk, which is where most honest evaluations die. The inputs here were public articles, so nothing sensitive went in. The writer notes plainly that if the uploads had been research transcripts instead of blog posts, this step would have ended the evaluation.
That is the discipline the corporate brief lacks. Roughly eighty percent of employees admit to using AI tools their employer hasn't approved, and "widespread" does not mean "safe" — feeding organizational data into an unvetted tool can erase the time savings that motivated it.
The point of PROVE is not that Gemini Notebooks is good. It is that a single person, doing a single task, can produce evidence in either direction and say why. Keep it, or drop it, defensibly.
This is authority pushed downward — to the person closest to the task. And it works precisely because it refuses to scale into a verdict for everyone.
But a tool that survives "useful to me" eventually wants to become "wired into production." And the moment it crosses that line, the governing question changes completely.
It is no longer whether the tool is good. It is what happens when it acts and no one is watching. The question becomes blast radius.
Score any action on four axes, decided at definition time, not by vibe. Reversibility: can the effect be undone with the same tools within minutes? Editing a file in a git tree, yes. Sending an email, no. Externality: does anyone outside your system see it? Breadth: one record or all of them? Cost: the only axis with a natural numeric threshold.
Reversibility is the dominant axis, but breadth is the one people get wrong, because breadth usually lives in the arguments, not the tool. The same delete_users call is a routine action with one id and an incident with a filter of "1=1".
So a gate defined per tool is broken by design. It waves through the mass deletion because it waved through the single-id deletion ten minutes earlier. The gate has to read the arguments — "requires approval when the affected count exceeds ten, or the filter is not a primary key."
And here is where that opening number returns. A gate exists to make a bad action less likely, and it fails the instant the approver stops reading. The approver stops reading when the gate fires constantly and is nearly always fine.
That is not a discipline problem. It is a design consequence, and it is measurable: under a percent or two rejection over a few hundred prompts means the gate is decorative. A gate that cannot be rejected is worse than no gate.
A gate that cannot be rejected is worse than no gate. Under a percent or two rejection means the gate is decorative, manufacturing consent no human gave.
So you gate fewer things, richer. No gate on reads, searches, sandbox edits — gating those is exactly how you train approvers to stop reading. Per-action approval on the irreversible and external: payments, emails, deploys, deletes.
And the prompt a human sees must show the literal arguments, formatted, not summarized. If the agent is sending an email, show the recipient, the subject, the body — because a model's summary of what it is about to do is generated by the same process you are trying to check.
Show the computed scope: "this will affect 1,284 rows," derived from a dry run by your code, not asserted by the agent. That is often the single highest-value line in the prompt.
This is why approving a plan is not approving the actions. The plan is prose; the actions are not; nothing binds them. "Clean up stale test accounts" is approvable and tells you nothing about the WHERE clause generated at step fourteen.
Notice the shape of the answer. Authority pushed down to the person and the task; then, at the point of consequence, pushed onto the specific irreversible action with its real arguments exposed. Never onto a plan. Never everywhere at once.
Now the trap that ruins all of it — the instinct of the senior person to bless the tool by using it in public.
Chris Kempczinski, CEO of McDonald's, was reportedly roasted over a video of himself taking a tiny, hesitant bite of the new Big Arch burger. The internet's verdict was instant: this man doesn't eat at McDonald's.
It went viral because viewers sensed he wasn't a genuine user of his own product. And that is the exact failure mode of performative executive dogfooding — insiders performing use, not real users encountering a thing fresh.
There is a harder version of this than optics. It is the curse of knowledge: once you know how something works, you cannot reliably simulate not knowing.
An executive already understands the data model, the jargon, how everything connects. Their success proves nothing about a real user, because they were never able to occupy the real user's vantage point. Their struggle is the only signal worth anything — a usability upper bound, nothing more.
So the two moves leaders reach for instinctively — the org-wide rollout and the executive dogfood — are the two their seniority disqualifies them from running. The rollout skips the one-tool-one-task proof. The dogfood substitutes an insider who literally cannot see straight for a real user.
This is dogfooding's ceiling, and it sits far lower than most teams believe. It straddles QA and user research and does the job of neither, because it assumes users share employees' mental model, and they never do.
Put the three pieces together and the maturing phase has a clear structure. Evaluation authority sits with the person doing the task, producing decisions defensible in either direction.
Approval gates sit on the irreversible action, bound to its exact arguments, with the literal effect shown — not on a plan, and not on everything.
And the verdict on whether the thing works comes from real users encountered fresh, not from the most senior person in the building performing a bite for the camera.
The teams that survive the incoherent brief will be the ones that distribute judgment to where it can actually see. The teams that centralize it — in the leaders least equipped to run either test — will keep clicking yes on a gate that never says no, and calling the audit trail proof.