Delivery Protection Rules

Why a rule engine rather than alerting

An alert asks a human to act. That is fine for a problem that develops over days and useless for one that develops over minutes.

Bounce and complaint rates do not wait. By the time someone reads a dashboard, the receiving provider has already formed a view of the sending domain, and that view persists for weeks. So the rules do not notify — they act, and then notify.

The corollary is that a rule which acts must be trustworthy, which is why they are banded by consequence rather than treated as a flat list.

The workflow

1. Monitoring / feedback

   Evaluation tick

   A fixed cycle while any campaign is sending. Not event-driven — a steady heartbeat is easier to reason about under load.

2. Automated software

   Collect signal

   Per-provider delivery outcomes, seed-inbox placement, content risk score, authentication failures, agent liveness.

3. Approval gate

   Kill switch check

   Decision point: If the automation kill switch is engaged, evaluate nothing and take no action. One switch stops all of it.

4. Automated software

   Critical band — four rules

   Decision point: Bounce rate halt, spam block halt, severe seed-spam pause, campaign placement failure. These stop a send outright.

5. Automated software

   High band — five rules

   Decision point: Bounce throttle, seed-spam warning throttle, low inbox rate throttle, missing seeds throttle, deferral rate throttle. These slow a send rather than stopping it.

6. Automated software

   Medium band — two rules

   Decision point: Campaign risk block, authentication failure throttle.

7. Automated software

   Low band — recovery and alerts

   Decision point: Provider recovery, campaign risk recovery, promotions-tab alert, agent-down alert. The recovery rules are what let the system un-throttle itself.

8. Approval gate

   Mode check before executing

   Decision point: Enforcing mode acts. Advisory mode records what it would have done. Off does neither. Advisory is how a new rule earns trust.

9. Automated software

   Execute the action

   One of eleven types: pause, resume or throttle a provider; pause, resume, block or unblock a campaign; pause or resume an offer; adjust warm-up; alert.

10. Data store

    Record the firing

    Which rule, which signal, which action, against which target.

11. Human action

    Operator reviews and resumes

    Decision point: The engine can pause autonomously. Only a person resumes a campaign it stopped.

Legend

• Human action
• Automated software
• Data store
• Approval gate
• Monitoring / feedback

The bands, and why they exist

Band	Rules	Consequence
Critical	4	Halt the send. Reserved for signals where continuing makes things materially worse.
High	5	Throttle. The send continues more slowly while the signal is watched.
Medium	2	Block content or throttle on authentication problems.
Low	4	Recovery and alerting. Un-throttling is deliberately the lowest-priority action.

Banding by consequence rather than by subsystem is the design decision worth noting. It means the question "what is the worst this rule can do?" is answerable from where the rule lives, and it makes the recovery path structurally lower-priority than the protective path — so the system is biased toward staying cautious.

Decision points

• Is the kill switch engaged? Above everything else.
• Which band does the signal trip? Determines whether the send stops or slows.
• Is there enough volume to judge? Each rule carries a minimum, so a handful of bounces on a small send cannot halt a campaign.
• Advisory or enforcing? How a rule is introduced without trusting it immediately.
• Resume? Human only.

Responsibilities

Human approval points

1. Setting thresholds and minimum volumes.
2. Promoting a rule from advisory to enforcing.
3. Resuming anything the engine paused.
4. Engaging or releasing the kill switch.

Failure handling

Failure	Response
Signal source unavailable	The rule cannot evaluate and does not fire. Silence is not read as health — agent liveness is itself a rule.
Two rules target the same campaign	Band precedence decides; the more severe action wins.
A rule fires incorrectly	The audit record carries the signal that triggered it, which is what makes threshold tuning possible rather than guesswork.
The engine itself stops	The agent-down alert exists for this. A protection engine that dies quietly is the worst case.
Recovery fires too eagerly	Recovery is the lowest band deliberately, so a protective action outranks it on the same tick.

Monitoring

Firings per rule, actions taken by type, time from signal to action, advisory-mode firings that would have acted, resume latency, and engine liveness. A rule that never fires is either well-tuned or broken, and the advisory count is how you tell the difference.