Every action that spends money or cannot be undone is approved by a person before it happens. Not most of them. Not the large ones. Not the ones a threshold flags. All of them, permanently.
That rule needs a classification behind it or it is only a slogan. Actions in this operation fall into a few kinds: reading, which changes nothing and runs freely; reversible writes, which a later action can put back; irreversible writes, which no later action can put back; actions that spend money; and actions that leave the building, meaning anything reaching a customer or a platform and therefore no longer inside the operation's control.
Reading is most of the volume and none of the risk. Pulling yesterday's spend, checking a rank, reading a return rate, comparing a landing page's behaviour across two weeks: this runs continuously and nobody approves it, because nothing about the world changes when it runs.
A reversible write is one where the previous state still exists and an action of the same size restores it. Changing a product description, swapping a creative in an active set, adjusting a page's layout, editing a subject line before it sends. If the change is wrong, the change is undone, and the cost of being wrong is the time the wrong version was live.
An irreversible write is one where undoing requires something other than the reverse of the action. Deleting a record. Publishing a page that gets crawled and indexed. Changing an address other systems already point at. The reverse operation exists on paper and does not restore the state, because part of the state was being held outside the system.
Spending is its own class rather than a subtype of the others, because money leaves in a way that correcting the action does not recover. Turning on a budget, raising a bid, launching a paid placement, issuing a refund. A bid raised in error is lowered in a minute and the money spent during that minute is gone. The correction is available. The consequence is not.
The last class covers anything reaching a person outside the company. A sent email. A published post. A message to a customer. A change submitted to a platform for review. Once it has left, the operation no longer owns the state, and no internal permission structure reaches it.
Money and one-way actions go through a person. The ceiling sits there, and the rest is detail about exactly where the lines fall.
The classification is applied at the action level rather than the tool level, and this is where most permission systems go wrong in a way that looks fine on a diagram. A single tool holds actions from several classes at once. The same connection to an ad platform reads yesterday's spend, edits a headline, and turns a budget on. Granting the tool grants all three. Once permission is granted at the tool level, the only remaining question is which tools the system holds, and for an operation running a company's entire digital side the honest answer is all of them. Tool-level permission produces a security model that is either useless or total, and it is usually described in language suggesting it is neither.
The unit of permission has to be the unit of consequence, and consequence lives in the action, not in the connection that carried it. So the check happens where the spend or the irreversibility actually occurs, and the record notes what was approved, by whom, and on what evidence, which is what makes an approval something other than a click.
This is a ceiling, not a phase. It does not lift as the operation improves, and the reason is not a lack of confidence in the execution.
Reliability changes how often something fails. It does not change what happens when it does. An irreversible action that goes wrong once is not made recoverable by a good average, and the arithmetic that makes a high success rate comforting stops applying the moment the failure is permanent. A system that is right almost always, executing an unrecoverable action at volume, is a system producing unrecoverable errors at a steady rate while reporting an excellent success rate. Both statements are true at the same time and only one of them turns up in a summary.
There is a second reason, and it belongs to accountability rather than to risk. The one number pipera reports is meaningful only if somebody is answerable for the decisions behind it. An approval a person gave, on a named piece of evidence, is a point where that answerability is real. Removing those points because the execution has become reliable would remove the last places a human being stands on the record.
A vendor who describes this requirement as temporary, something that relaxes as the models improve or the track record lengthens, is describing a different property than the one that matters. Improvement addresses frequency. The ceiling addresses consequence. Frequency is worth improving and the operation works on it constantly. Consequence is a property of the action, and it does not improve, because it was never a performance question.
Before granting anyone this much execution authority, ask which actions stay with a person permanently, and treat any answer containing a timeline as the answer to a different question.