Campaign Autopilot Braking

What it is, and what it is not

This is the self-service sibling of the delivery protection rules. The protection engine is fourteen rules in Go, banded by consequence, running on a tick. This is an operator writing their own rule in the interface and running it.

The distinction matters because the two are constantly confused, including by the naming inside the codebase — there is a separate governance component that also carries the word "autopilot" and does something entirely unrelated. This page is about the campaign rule engine.

The workflow

1. Human action

   Operator authors a rule

   Conditions of metric, operator and threshold; actions of pause, stop or alert. Scoped to one campaign or to any running campaign.

2. Human action

   Operator clicks run or simulate

   Decision point: There is no scheduler. Nothing evaluates a rule unless a person asks it to — which is the single biggest limitation of this design.

3. Approval gate

   Ownership check

   Decision point: A rule can only be evaluated by the person who created it.

4. Automated software

   Evaluate each condition

   Eleven metrics available: bounce, open, click and unsubscribe rates; complaint, block, hard-bounce, soft-bounce, delivered, sent and deferred counts. Five comparison operators.

5. Automated software

   Any-campaign matching

   Decision point: For a scope of any running campaign, a condition is met if a single campaign satisfies it — and that campaign becomes the action target. Scanning is capped, so the blast radius is bounded.

6. Automated software

   Combine conditions

   Decision point: All conditions must be met. A logical AND across the set, not a score.

7. Approval gate

   Simulate?

   Decision point: If simulating, return the evaluation and execute nothing. This is how a rule is checked before it is trusted.

8. Automated software

   Execute the actions

   Pause the campaign, stop it, or raise an alert. A closed set of three — it cannot change rates, budgets or content.

9. Data store

   Write the audit record

   Before and after: which conditions were met with per-condition results, and which actions executed.

Legend

• Human action
• Automated software
• Data store
• Approval gate

Decision points

• Which metric, and against what threshold? Authored by the operator.
• One campaign or any running campaign? Scope determines the blast radius.
• Simulate or execute? Per invocation.
• Which campaign gets the action? The first match, when scoped broadly.

Responsibilities

Human approval points

1. Authoring the rule.
2. Every evaluation — there is no scheduler, so a human is always the trigger.
3. Resuming anything it paused.

Failure handling

Failure	Response
Metric unavailable for a campaign	The condition cannot be met and does not fire.
Rule scoped too broadly	The scan cap bounds it, and only the first matching campaign is acted on.
Statistics stale	Evaluated against whatever the campaign statistics report; there is no freshness check, which is a gap.
An action targets a campaign already paused	The action is idempotent in effect.

Monitoring

Rule count and how many are enabled, evaluations run versus simulated, conditions met, actions executed by type, and audit-record completeness. The most telling metric for this feature is how rarely it is invoked at all.