Governance and approvals guides

Roles decide who may ask. A member reads everything in the workspace and drafts changes; an admin approves, rejects and reverts, connects accounts and writes rules; an owner adds the plan, the workspace itself and raw platform requests. Roles gate actions rather than visibility — a member who cannot connect an account still sees every connection's status, because the half that tells you what is happening is not the half that changes it.

Scopes decide what a credential may do. A key minted for your own AI carries read always, draft if you asked for it, and approve only if you opted in. Tools are registered per request against the scopes the credential holds, so a read-only key does not see the drafting tools at all — they are absent rather than present and refusing.

Rules decide what clears without you. An approval rule names one connection or every connection, and can clear a pause, a budget decrease or a bid decrease under a cap it states in a currency it states. That is the whole of what a rule may say today, and the form refuses anything wider rather than storing a rule that would quietly never fire.

Guardrails refuse regardless. They are not permissions and they are not rules: they are the limits a budget-bearing change has to satisfy before it reaches a platform, whoever approved it and however. The connection's kill switch, the account's own daily ceiling, the movement rule, the first-budget cap and the rolling twenty-four-hour aggregate all sit here, and nothing in the product raises them.

The separation is the point. A permission you granted, a rule you wrote and a limit nobody can raise are three different kinds of answer to "why did that not happen", and collapsing them into one setting would make the answer unreadable.

The refusals worth memorising, because they are the ones people assume are configurable.

A rule never clears a create of any kind, a media upload, a removal, or a change to account defaults. It never clears an increase, an amount over its own cap, or an amount in a currency other than its own. It never clears a change whose direction cannot be read. It never clears a draft the platform's own dry run refused, or one carrying a special ad category, which is a compliance answer a person signs. And it never clears anything on a connection whose kill switch is on.

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 a person.

Every move a change makes is a row on the record: written, edited, approved, applied, refused, reverted behind a failed sibling, rejected, undone, or marked failed by hand. Each row names who acted — a person, the agent, a key, or a rule — and, for an approval, which authority cleared it and whether the approver was the same actor that drafted the change.

That last detail is the one that earns its place. A key approving its own work is a different fact from a person approving it, and a record that flattened the two would be worse than no record.

The log holds an actor by name rather than by a link to a user account, so it holds a rule or a key as readily as a person, and it outlives the change request: a draft can be edited or superseded, and what happened to it stays readable.

There are two authorities and only two. A change is approved by you, or by a rule you wrote. Nothing here promises that a person reviews every change, because that would be a promise the product does not keep and does not want to — an automation you wrote and understood is a perfectly good authority. What the product promises instead is that the authority is always named on the row, that the limits underneath it cannot be raised by the automation, and that the inverse of anything cleared is a draft somebody can write at the same gate.

Undo has that shape too. It is a new draft, built from the state the entity was in before, through the same gate with the same guardrails. Nothing reverses itself behind you, and a removal has no undo at all, which is why a removal says so in a sentence before it is approved.

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.

Every other subject produces the changes this one decides about.

• Budget and bidding produces almost all of them, and the direction rule here is why only half of those can ever be cleared by a rule.
• Media planning produces them in batches, and a materialised plan is the standing example of work that always waits for a person.
• Agent setup decides who may ask in the first place: scopes are this subject's outermost layer and they are set at the mint.
• Creative and testing produces the two operations no rule may ever clear — an upload and a replacement — which is worth knowing before you write one.
• Measurement and metrics is what an audit reads once the record has told you what was changed and by whom.