Write an approval policy for ad changes

A rule is not a permission. Who may ask for a change is a matter of roles and scopes, decided before anything is drafted.

A rule is not a guardrail either. A guardrail is a limit nothing in the product raises, checked when a change request is written, again at approval, and once more immediately before a platform is called. A rule sits between those two: it decides whether a draft that already satisfies every guardrail still needs a person.

So the question a rule answers is narrow and worth stating precisely. Given a draft that is valid, that passes every limit, and that somebody with the right scope asked for — does a human still have to look at it.

Four fields, and the shortness of the list is the design rather than an accident.

Which connection. One connection, or every connection in the workspace. Scoping to one is how a rule covers a single client's accounts without touching anybody else's.

Which operations. Pause, budget decrease, bid decrease. Those are the three, and each reads on the form as the verb you are granting rather than as the internal operation name — a status rule clears a pause and nothing else.

The cap, the currency and the direction. For the two money operations, an amount the change may not exceed, the currency that amount is stated in, and the direction the number may move. Currencies are compared and never converted: a cap stated in one currency says nothing about an amount in another, and a rule whose currency does not match the draft's simply does not match.

The size of the move. Optionally, a percentage of what the entity carries today that the change may not exceed. A cap is an absolute ceiling; this is a ceiling on the distance, and it is what stops a rule clearing a decrease from a thousand to ten.

The first enabled rule that matches, by the order they were created, is the one that clears the draft. Nothing merges two rules together.

These are refusals checked before a single stored rule is read, which is why widening a rule cannot reach them.

Anything that creates, uploads, removes or changes account defaults. A create of any kind, a media upload, a removal, and a change to an ad account's defaults all wait for a person, and so does a raw platform request, because a rule is written against a shape and a raw request has none. The creates are derived from the operation list rather than typed out, so a create added to the product later is excluded by existing behaviour rather than by somebody remembering this rule.

An increase, an over-cap amount, or a foreign currency. Covered above and worth repeating because it is the most common surprise.

A change whose direction cannot be read. No previous value, a budget that switched between daily and lifetime, or a field the account's mirror never held. Two amounts are only comparable when the mode is the same, so a mode change is never a decrease.

A draft the platform's own dry run refused. Where a platform offers a dry run, Tempio asks it while the change request is being written and records the verdict on the row. A refusal there is not a rule's to overrule.

A special ad category, or a paused connection. A payload carrying a special ad category is a compliance answer a person signs. A connection whose kill switch is on blocks everything written against it regardless.

The arrangement underneath, stated once: your connections read your accounts, a change is written as a draft on the record with the state it would change from and the checks it passed, applying it is gated on approval — by you, or by a rule you wrote — and no platform write reaches a customer account until that platform has granted write access. Applying a cleared change to a platform is in private beta.

Four questions, in order, and if you cannot answer one of them the rule is not ready.

What is the job? Not "reduce review load" — a specific recurring decision you are tired of making. "Pause anything the weekend script flags" is a job. "Handle small changes" is not.

What is the worst case if it fires when it should not? For a pause, an entity stops delivering until somebody resumes it, which is an afternoon. For a budget decrease, spend is lower than planned, which is a window you can still use. If you cannot describe the worst case in one sentence, you do not yet understand what you are granting.

Is the cap a number or a hope? The cap is the amount the rule may clear, and it should be a number you would approve without reading. If you would want to look at anything near it, the cap is too high.

Would you recognise it misbehaving? A rule clearing three drafts a week is legible. A rule clearing sixty is a rule nobody reads the output of, and the record it leaves is only useful if somebody looks at it. Give a rule a job narrow enough that a change in its volume is noticeable.

The sequence that works: one rule, one connection, one operation, a cap well below what you would actually tolerate. Leave it for a fortnight. Read what it cleared — every applied change is a row naming the authority that cleared it and the rule by name.

Then widen one field. Not three. A rule that stops behaving after a change to three fields is a rule you have to reason about backwards.

The thing not to do is write the permissive version first with the intention of tightening it later. Tightening happens after something has gone wrong, and by then the argument is about the incident rather than the rule.

Two cases come up constantly and neither is a rule's job.

"I want the agent to handle routine increases." No rule clears an increase. What you can do is have the agent draft them and review the batch as a batch, which takes about as long as reading a summary. Review a batch of campaign changes is that workflow.

"I want a hard ceiling on spend." That is a guardrail rather than a rule, and the ones that exist cannot be raised. Spend caps and kill switches covers what actually holds, and Guardrails that stop expensive mistakes covers why they are checked three times.

When you want to know what a rule has been doing, the record is the answer rather than the rule sheet: Who approved what, and when.

The argument for why a rule may say so little — and why that is the feature rather than the limitation — is in What an approval policy should say.