Guardrails that stop expensive mistakes
Tempio6 min read
A guardrail is a refusal with a number behind it. It is not a permission, it is not an approval rule, and it is not something you configure. It is the set of limits a budget-bearing change has to satisfy before Tempio will send it to a platform, whoever approved it and however it was approved. This guide is the five of them, what each refuses, and the two that surprise people.
Checked when written, at approval, and at the apply
The budget guardrails run when the change request is written. Every guardrail, the kill switch included, runs again when it is approved, and once more inside the apply, immediately before the platform is called.
More than once because a draft can sit at the gate while real time passes. The account it targets can spend, a sibling draft can land, the connection can be paused. The last check is the one that decides, and it reads current state rather than the state the draft was written against.
The same functions run at all three points, which is the property that matters: the sentence you read at the gate and the decision made at the apply cannot disagree.
The kill switch
A connection whose status is anything but active blocks every apply written against it. Pausing a connection is the one control that stops Tempio writing to those accounts — whatever is queued, whatever rule would otherwise have cleared it, and whoever approves it afterwards.
Nothing is rejected. The drafts stay where they are, and setting the connection active again lets them run. That is deliberate: a control you reach for when you are not yet sure what is happening should stop what is next without destroying what is recorded.
The account's daily cap
Every ad account carries its own ceiling, derived from what that account has actually done: three times the highest single-campaign daily spend in its last twenty-eight days, floored at a default stated in the account's own currency.
The peak is taken over one campaign's day rather than the account's total, because that is the shape of the number a draft is asking for — what one campaign was trusted to spend in a day. The multiple gives enough headroom to grow a winner and not enough to double an account by accident.
An account with no history gets the floor, which is the conservative answer rather than an unlimited one. The cap is computed on the first draft that needs it and refreshed by the weekly deep re-read, so it follows the account as the account grows.
A lifetime budget is checked as its daily equivalent over the flight it states. A lifetime amount with no readable flight is checked as-is, which is the tight reading — a large total with no dates looks exactly like a large daily figure, and assuming it would be spread would be assuming the thing that has not been said.
The movement rule, and the first budget
A budget may not move more than one hundred per cent of what the entity carries today. Upward, doubling is the most a single change may do. Downward, a hundred per cent of the current figure is the whole of it, so one change can take a budget to zero — pulling spend back is not what this rule is for.
Reading a movement needs a pre-image: the mirror's record of what the entity currently carries. Where there is none, the first-budget cap applies instead, which is a lower number stated per currency. Once an account's own derived cap has risen above the currency's default — which only happens on the strength of the account's own twenty-eight days — that derived cap becomes the ceiling for a first budget too, because a real account's first campaign should not be blocked by a number picked to be safe for an empty one.
The aggregate, which is the interesting one
Applied budget increases on one connection are summed over the last twenty-four hours. The sum, plus the raise being approved, must stay under the account's daily cap.
This is the only check that can refuse a change every earlier check allows. Ten individually legal increases are still a doubled account by dinner, and this is what stops the loop — including a loop driven by an agent doing exactly what it was asked, which is the scenario the whole draft-first arrangement exists for.
Decreases contribute nothing to the sum. The cap exists to stop spend running away, not to stop it being pulled back. And the sum is per connection and per currency: a connection holding two accounts billing in different currencies keeps two sums, because adding them would not be a number.
Said before the refusal
A guardrail is not only a wall at the end. Several of them announce themselves on reads, as warnings carried on the result rather than as refusals.
An account whose busiest campaign-day already sits near its own daily cap carries a warning saying there is little headroom left. A large move from the current amount carries one saying its size is part of what an approval agrees to. A connection whose increases already add up over the last day carries one saying so before the next raise is drafted. And a budget shared across several campaigns carries one saying that changing it changes every one of them at once.
A warning never changes a value and never refuses anything. It only says what is near, which is what lets an agent plan a raise against the ceiling instead of meeting it.
One more is worth knowing because it blocks rather than warns: if an account's currency changes after a draft was written, the amount no longer means what it did, and the draft has to be written again rather than approved.
What guardrails are not
They are not the approval decision. A change that satisfies every limit still needs an authority, and there are two: you, or a rule you wrote. The arrangement, 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.
They are also not yours to tune. The rules above are Tempio's, they are the same on every plan, and nothing in the product changes them; the account's own daily cap moves with the account's own spend and with nothing else. What you can change is what surrounds them: pausing a connection, and the rules under Write an approval policy for ad changes.
And where a platform offers a dry run, its verdict sits beside all of this: Tempio asks while the change request is being written and records the answer on the row, so a platform's refusal arrives at the gate with its own message and the fields it names rather than after the change was approved. A draft the dry run refused is also one no rule may clear.
Spend caps and kill switches is the operator's view of the same machinery, and Review a batch of campaign changes is what to do with what reaches the gate.
And the argument for limits shaped like this rather than like a single switch is The case against the autopilot toggle.
Read next
Governance and approvals guides
Who may clear what, and what the record says afterwards: roles, scopes, approval rules, guardrails, kill switches and reading an account after a bad week.
Write an approval policy for ad changes
A rule that never fires is worse than no rule. What one may say, the five refusals it cannot express, and how to write one you would defend later.
Spend caps and kill switches
What actually stops money leaving, in order of how fast it acts. The one control that stops everything, and the three limits nobody can raise.
Review a batch of campaign changes
Read three fields, then the rows that carry warnings. What a batch guarantees, what stops when one row fails, and how to fix a row without rejecting it.
Questions
Put frontier AI to work on every ad account you run.
Tempio connects your ad accounts into one workspace and hands your own AI the numbers and the tools. Every change it writes is a draft until you approve it, or until a rule you wrote does.
Request early access- Read and draft by default. Approve is a separate permission you grant.