Proposal lifecycle
How a single change moves from a copilot proposal to a live edit — and back.
Every write follows the same path, whether it comes from the dashboard, the copilot, or an MCP client. Nothing mutates Google Ads until the change has been validated and classified.
Validate
The change runs as a validate_only dry-run against Google Ads. Failures are recorded as failed rows —
auditable, and surfacing advertising-policy violations you can appeal.
Classify
The safe-apply policy scores it safe or review. The risk tier and a
snapshot of the policy decision are stored on the action either way.
Apply or queue
- Operator-confirmed (a dashboard click, or an MCP approve) → recorded
approvedand applied immediately. - Autonomous and safe (the copilot asked to auto-apply and the policy agrees) →
approvedandauto_applied; the worker re-checks the policy before mutating. - Everything else →
proposed, waiting in Approvals.
Revert
Applied changes are revertible wherever the prior state was snapshotted. A revert is itself a safe action, so undoing an auto-applied change is always allowed.
The result of a proposal always carries mode (auto_applied or queued), the riskTier, and
policyReasons — the copilot and MCP surface these so you know what happened and why.
Guards
Two guards run before a change is even recorded: a redundancy guard drops AI keyword adds already covered by a looser enabled match type, and a no-op guard rejects target changes that don't move the number (for example €40 → €40).