The safe-apply policy
How Tap & Scale decides which money-moving changes auto-apply and which wait for your approval.
Every mutation is money-moving, so every write flows through one path — propose → validate →
policy → action — and nothing mutates live inside the proposal call. The policy is a pure,
unit-tested function that classifies each change as safe (auto-applies) or review
(queues in Approvals).
The pipeline
Propose
The dashboard, the copilot, and the MCP asa_propose_* tools all call the same proposal path. No
tool writes to Apple directly.
Validate
Local validation stands in for Apple's missing dry-run — there is no validate_only and no
sandbox. A validation failure is recorded as an auditable failed action, never applied.
Policy
The change is classified safe or review and stamped with its risk tier and a snapshot of the
policy that judged it.
Action
It lands as a row in the action queue. safe rows auto-apply; review rows wait for you.
What auto-applies
The safe tier is deliberately narrow — bounded, low-risk, reversible changes:
- Negative keywords — add and remove.
- Up to 10 EXACT keywords with bids ≤ 1.5× the account's 30-day average CPT.
- Keyword or ad-group pause.
- Budget raises ≤ 30% on campaigns whose 30-day CPA is inside your CPA band; cuts ≤ 30%.
- One ≤ 10% step on an existing campaign
targetCpaor ad-groupcpaGoal. - Reverts of changes that were auto-applied.
Everything else — larger keyword batches, bigger budget moves, campaign creation, and any bid strategy switch (it changes the optimization objective and resets Apple's learning) — is review-tier and queues.
Global gates
Independent of tier, these must all hold for anything to auto-apply:
- The org kill switch (
asaAutoApply) is on — checked at both propose and apply time. - The account is active.
- Fewer than 20 auto-applies for that account in the last 24 hours.
Defense in depth
The apply worker doesn't trust the queued decision. Before mutating an auto-approved row it
re-runs the policy (demoting to review if the change is no longer safe), re-validates,
and hard-caps any budget change at 3× the warehouse value. Applied changes are revertible
wherever prior state was snapshotted — every payload carries prior* fields because Apple has no
change history to reconstruct from.
Want to see why a specific change would or wouldn't auto-apply? asa_explain_policy returns the
tier and reasons for a proposed action without proposing it.