What an approval policy should say

The purpose of an approval policy is to remove a decision from a person without removing the record of it. If it does not remove any decisions it is a memo, and if it removes the record it is a liability.

That framing rules out most of what gets written. "Budget increases over ten thousand require sign-off from the marketing director" removes nothing: somebody still has to notice the change, find the director, and wait. It also records nothing that the change itself did not already record. The clause exists to assign blame after an incident rather than to prevent one.

A policy that does the job has to be evaluable by whatever applies the change, at the moment it applies it, with no human in the path. That is a much harder thing to write, and the difficulty is the point: a rule you cannot state precisely is a rule you have not decided.

What it covers. Which connection, or all of them. Scope is the field people skip, and it is what lets a rule be tried on one client's accounts before it governs everything.

Which verbs. Not "changes" — specific operations. Pausing something is a different act from moving money, and a rule that grants both because they are both changes has not been thought about.

A direction and a ceiling. The direction is which way the number may move. The ceiling is the largest amount the rule may clear, in a stated currency, compared and never converted, because a cap stated in one currency says nothing about an amount in another.

A distance. How far the number may move from where it is now, as a percentage of its current value. This is the field that is almost always missing, and its absence is the most common way a well-intentioned rule does something startling: a rule with a ceiling of a thousand will clear a change from nine hundred to nine, because nine is under a thousand. A distance says the move itself was too large regardless of where it landed.

Four things to decide, across five fields. The shortness is not a limitation being apologised for — it is what makes the rule a rule. Anything wider has to be a person, because anything wider cannot be checked.

A rule should also be incapable of saying certain things, and the list is worth stating because people assume it is configurable.

Nothing creating something new. A create has no previous value, so there is no direction to read and no distance to bound; the only thing a rule could do is let it through, which is not approval, it is absence.

Nothing that removes. A removal on some platforms is terminal and the entity is gone rather than archived, and an act with no inverse is not an act to automate.

Nothing whose direction cannot be read. No previous value, or a budget that switched between daily and lifetime — two amounts are only comparable when they mean the same thing, and a daily fifty and a lifetime fifty are different money. Where the comparison cannot be made, "cannot tell" has to be a refusal. At a gate that spends money, an unreadable direction treated as a pass is the bug that eats the account.

Nothing a platform's own dry run already refused, and nothing carrying a compliance answer a person is supposed to sign.

And nothing raw — a request that reaches past the model of campaigns and budgets into a platform's own interface has no shape for a cap or a direction to hold, so it waits for a person, always.

The sharpest objection to all of this is that it is arbitrary. Why should a rule clear a decrease and not an increase, when both are changes of the same kind?

Because they are not changes of the same kind, and the asymmetry is in the consequences rather than in the arithmetic. A decrease that should not have happened costs you delivery you can restore by drafting the inverse. An increase that should not have happened costs you money that has already been spent, and no record undoes that.

An automation is worth having exactly where the worst case is recoverable. That is a real and useful half of the work — a rule can pull spend back at three in the morning without waking anybody — and pretending it is the whole of the work is how governance software ends up promising something it cannot support.

It is worth being exact about what a rule is operating on. Connections read your accounts and change nothing. A change anyone asks for is written down first, with the value it would replace and the checks it passed, and the rule's whole job is to be the second of the two authorities that can clear it, the first being you: approved by you, or by a rule you wrote. Clearing is not arrival, though: no platform write reaches a customer account until that platform has granted write access, and applying a cleared change to a platform is in private beta.

The sequence that works is one rule, one connection, one operation, and a ceiling well below what you would actually tolerate. Leave it a fortnight. Read what it cleared, because every applied change names the authority that cleared it and the rule by name.

Then widen one field. Not three. A rule that starts behaving differently after three fields changed is a rule you have to debug backwards, and debugging a rule after it has done something is the situation the whole exercise exists to avoid.

The thing not to do is write the permissive version now and tighten it later. Tightening always happens after an incident, and by then the conversation is about the incident.

Give the rule to somebody who was not there and ask them two questions: what will this clear without me, and what is the worst thing that can happen when it does.

If both answers are one sentence each, the rule is written. If the second answer needs a paragraph, the rule is too wide. And if the first answer is "it depends", the rule is prose rather than policy, and the system it is meant to govern will carry on exactly as it did before it was written.

Why every change is a draft is the unit this operates on, The case against the autopilot toggle is the shape it replaces, and Write an approval policy for ad changes is the procedure.