Spend caps and kill switches

Pause the connection. Immediate, and total for anything Tempio would write. Syncing stops and every apply written against that connection is blocked — whatever is queued, whatever rule would otherwise have cleared it, whoever approves it afterwards. Nothing is rejected: the drafts stay where they are, and setting the connection active again lets them run. This is the kill switch.

Revoke the credential. Immediate for that client, and narrow. The next call the key makes is refused. Nothing it already drafted is affected, because a change request records the key that wrote it and revoking the key does not un-write the row.

Reject the queued batches. Terminal and specific. A rejected row can never be cleared, by you or by a rule. Use it when the work is wrong rather than when you are unsure.

Draft the changes that stop delivery. The slowest, and the only one that changes what the platforms are doing. Pausing campaigns, or taking budgets down, is a change like any other: drafted, checked against the guardrails, and applied when an authority clears it.

That last line is the distinction most worth being clear about before you need it. Pausing a connection stops Tempio writing. It does not stop a platform spending money it has already been told to spend.

Three limits are the product's rather than yours, and knowing they exist changes how you plan rather than how you configure.

The account's daily cap. Three times the highest single-campaign daily spend in the account's last twenty-eight days, floored at a default stated in the account's own currency. Derived from the account's own behaviour, refreshed as the account grows, and not settable.

The movement rule. A budget may not move more than a 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.

The twenty-four-hour aggregate. Applied budget increases on one connection are summed over a rolling day, and the sum plus the raise being approved has to stay under the account's cap. This is the one that refuses a change every earlier check allowed, and it is what stops a loop of individually reasonable raises — including one driven by an agent doing exactly what it was asked.

An entity with no budget yet is held to a lower first-budget cap instead of the movement rule, since there is nothing to measure a movement against.

None of it converts. Every comparison happens in the account's own currency, and no rate is applied anywhere on the writing side.

It is the budget. That is not an evasive answer — it is the honest one, and it is worth saying because people go looking for a separate setting and conclude one is missing.

A budget is the amount allowed to leave. Guardrails bound how fast it can change; the number itself is yours, and lowering it is the cap. Where the total is a genuine commitment over fixed dates, a lifetime budget delegates the pacing inside that total to the platform, which is a different shape of ceiling.

The layer above that is the plan. A media plan carries one window, one currency and a whole-flight total per line, and the total at the top of the page is the number you committed. Nothing about a plan enforces itself — it is a document, and it does not watch the accounts — but it is where the number you will later defend gets written down.

A rule your workspace wrote can clear a pause, a budget decrease or a bid decrease under a cap it states in a currency it states. It can never clear an increase.

That asymmetry is exactly what you want for this subject. An automation can pull spend back on its own at three in the morning and cannot push it up, which means a rule is a usable brake and can never be an accelerator. If you want one standing safeguard in the workspace, a decrease rule scoped to one connection is the one that earns its place.

What a rule cannot do is stop something. It clears drafts; it does not create them. A rule does not notice spend running away, because nothing in the product watches for that — the watching is a rhythm you keep.

One setting reaches past Tempio's own model: raw platform requests. It lets a credential call a connected platform's own API for the endpoints Tempio has not normalised. It is off until a workspace owner turns it on, it is granted per workspace or per connection with a connection's own row winning over the workspace one, and it is two switches — reads, and mutations — where turning reads off turns writes off with them.

An admin can write approval rules, mint keys and approve drafts, and still cannot touch this one. A mutation through it is a change request like anything else, and it is one no rule may ever clear, because a rule is written against a shape and a raw request does not have one.

The arrangement all of this sits inside, 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.

Pause the connection. That stops everything Tempio would write, without destroying anything.

Read the queue and the record. What is waiting, what was applied in the last day, and which authority cleared each one.

Revoke any credential you are unsure about. Investigate afterwards — the audit log holds what it did and that record survives the revocation.

Then, and only then, decide what to draft. Stopping delivery is a change, and it deserves the same reading as any other.

If the morning ends with somebody else taking the accounts over, the client handover template is the document that carries which connection was paused and why — a pause nobody wrote down is a pause somebody quietly undoes a fortnight later.

Guardrails that stop expensive mistakes is the detail on the three limits, Write an approval policy for ad changes is how to build the brake, and Give a contractor limited account access is the version of this question that is really about people.