Approvals

Every change Tempio makes to an ad account is a draft first, and something has to clear it. Settings → Approvals (/settings/approvals) is where a workspace writes down what that something is: a rule, which lets a named kind of change through on its own, and a chain, which holds a change until the people it names have signed.

Both are rules the workspace wrote. A change is approved by you, or by a rule you wrote — and a chain is the rule that says how many of you.

Everyone in the workspace can read this page. Writing a rule or a chain, turning one on or off, and deleting one are owner and admin: standing authority over spend is the same class of act as minting an MCP key that can approve. The separation-of-duties switch at the bottom is owner only.

Approval rules

A rule is the shortcut. While it is on, a draft it names can be cleared without anyone opening it.

The rules list is oldest first, which is the order they are considered in. A new rule is off: nothing changes about a workspace until somebody turns one on, and switching it on is its own act with its own line in the audit log — not a field somebody changes while renaming the rule.

What a rule says

The cap is compared in the currency it is written in and never converted, the same way every other amount in Tempio is handled. A rule capped in AUD says nothing about a draft on a USD account and will not clear one.

Under each rule the page prints what it actually does, in a sentence built from the rule's own fields — "Auto-approves pauses and budget decreases up to A$500.00 on Meta · Goat Club" — rather than from what it was called.

What a rule never approves

A rule approves only what it names, never a create, an upload, a removal, an increase, or a draft whose validation failed.

Beyond that, a rule does not clear:

• a budget or bid increase, an amount over the rule's own cap, a move bigger than its percentage, or an amount in a currency other than the rule's;
• a resume. A rule that names Pause approves a pause and nothing else, so turning spend back on goes to the gate;
• a change to account defaults, which is covered in Account defaults;
• a change whose direction cannot be read — no record of what the entity held before, a budget that switched between daily and lifetime, a field the account's mirror never carried;
• a draft carrying a special ad category, which is a compliance answer a person signs;
• anything on a connection that is not active — paused, disconnected, or waiting to be reconnected. That is the kill switch, and it stops a rule the same way it stops an apply.

A batch is one reviewable unit, so a rule clears a batch only when it clears every row in it. One row a rule cannot approve sends the whole group to the gate.

Approval chains

A chain is the opposite of a rule. A rule lets a change through with nobody; a chain holds it until several people have said so, in the order the chain names them.

Writing a chain is on the Scale plan and above. Below it the section still explains itself, the New chain button is absent and no chain can be edited — but a chain the workspace already holds can still be turned off and deleted from its menu, because removing authority is never a paid act.

What a chain says

A stage is satisfied by one of three things:

• Anyone with a role — owner, admin or member. The member list is read when the decision is made, so a change in who holds a role changes who may sign.
• Named people — a list of people in the workspace. Someone who has left cannot sign, whatever the chain says.
• The client, by email — a person with no seat, who signs through a link they are sent. Nobody inside the workspace can sign a client stage for them.

The threshold is compared in its own currency and never converted, exactly as a rule's cap is. A lifetime budget is read as its daily equivalent, so a threshold of "above A$2,000" means the same thing whether a change states A$2,000 a day or A$60,000 over thirty days.

Under each chain the page prints what it does in one sentence: "Two stages on Meta · Goat Club for update budget above A$2,000.00: any admin, then the client at client@example.com".

Like a rule, a new chain is off until someone turns it on.

A chain is never shortcut by a rule

When a chain matches a draft, the rules are not consulted at all. A chain is stricter by construction, and a rule that could clear a change a chain is holding would make the chain decorative.

What a chained change looks like

The chain that matched is snapshotted onto the draft when the draft is created, so editing a chain never rewrites a decision already in flight: a change at the gate is held to the chain as it read when the change was made. Deleting a chain stops new drafts joining it and releases nothing that is already waiting.

A chained change’s row on the queue names the stage it waits at, and its own page lists every stage with the signatures given, who gave each and when. The primary action reads Approve stage 2 of 3 rather than "Approve & apply", and the line under it says what pressing it does — recorded, with more stages to go, or the last signature, which applies the change.

A batch is approved as one act, so it is held to one chain: the plan is resolved from the batch's largest row and copied to every row, and no row of a group can be at a different stage from its siblings.

Each signature is its own row in the record and its own line in the change's timeline. Nobody signs the same stage twice — a person who approves from the hub and again through an MCP key they minted has signed once, because a key's approval is its minter's approval.

Rejecting a chained change

Rejecting ends the chain. The stage it was waiting on gets a declined decision, so the record says who stopped it and where, and the draft is rejected like any other. There is nothing left to sign, and the change has to be drafted again.

Separation of duties

Off by default, and on every plan: a safety control is not a paywall. Chains are a Scale capability; the switch that stops a person clearing their own work is free, because a workspace that wants it should never have to buy it.

When it is on, the person who drafted a change cannot be the person who approves it — including through an MCP key they minted, and including a change their agent drafted on their behalf.

It applies everywhere an approval is recorded: the drafts page, approve_drafts under a key, every stage of every chain, and a change no chain matched at all. A solo operator is one person, so leaving it off is what lets them clear their own gate; an agency turns it on.

Only an owner changes it, and the switch writes its own line in the audit log.

The chat agent's inability to approve anything is separate and unconditional: it holds no approve scope, before and after.

What an agent can see

list_approval_chains is a read-only capability over MCP: an agent can say which chains a workspace holds, what each one asks for, and whether separation of duties is on, so a change that is waiting can be explained rather than reported as "not approved". There is no tool that writes a chain. An agent may explain the rules; a person changes them.

list_drafts carries each row's approval plan — its stages, who each one asks for, and which are satisfied — so an agent can say what is waiting on whom. Who actually signed is on the draft's own page.

What the record says

Every act on this page is a line in the audit log: writing a rule or a chain, editing it, turning it on, turning it off, deleting it, and switching separation of duties. Each carries what the rule or chain said at the time.

A draft a rule cleared names the rule on the drafts list and in its timeline. A chained draft carries one approval.recorded line per signature, with the stage and the person. change_request.reviewedBy keeps meaning what it always meant: who cleared the final gate.

See Drafts for the lifecycle every cleared change still goes through, and Account defaults for the values each platform reads off an ad account.