# Guards

A guard is a checkpoint about the person, checked in the instant an email is
about to send. It answers one question: should this go out right now?

**Guards never act on their own.** They don't run on a schedule
and they don't react to anything — they exist only at the moment of a send.
If you want something to _happen_ when a person changes, that's a
[flow](/content/docs/usage/flows.html). Guards are passive filters, not
trigger-and-action rules.

They live under **Automation → Guards**, which is also where
they're edited. A flow or sequence page lists the guards that can affect its
emails, read-only, so there's one place they're changed.

## What a guard can do

The four actions escalate.

### Pause & wait

The email waits and goes out in the minute the condition clears. The person's
run stays exactly where it was.

**Everything behind it shifts too.** When the paused email finally
sends, the rest of that run moves by however long it waited — so a three-day
hold doesn't compress the rest of the sequence into a burst.

### Skip & continue

This one email is dropped and the run stays on its original schedule. Nothing
behind it moves, and a dropped step never stalls the ones after it.

### Cancel sequence

The person's run is canceled along with everything still ahead of them. A flow
step waiting on that sequence is released — a cancellation is a way of
finishing, and stranding them at the step forever would be worse.

### Exit flow

The run is canceled and the person leaves the surrounding flow entirely. The
exit is recorded on their timeline with the guard's name on it.

**When several guards match the same email, the most severe wins.**
Exit flow beats cancel sequence, which beats skip, which beats pause —
pausing and then canceling the same run would be incoherent, and your most
emphatic instruction is the one to honor.

## Scopes

A scope decides which emails a guard can see at all.

- **All emails** — every email Mimeo sends: broadcasts, sequences, and flows alike.
- **Emails with a label** — which is how "don't pitch to members" stays narrow.
- **Emails from a flow or sequence** — only what that one scheduled, including the emails of any sequence the flow started.

## Conditions

A guard's condition uses exactly the same vocabulary as a flow's if/else and
gates — [see the flows guide](/content/docs/usage/flows.html) for the full
list. Anything genuinely complex is a named code predicate rather than a deeper
settings screen.

## The built-in suppression guard

Unsubscribed people don't get automated email. This checkpoint is always on and
can't be edited, disabled or deleted — it's the floor everything else stacks on
top of.

It's listed on the Guards page so drops can be attributed to something you can
see rather than disappearing into a log. Enforcement lives in the sending code,
so it applies even to test sends.

## Recent activity

What each guard actually did, and why, with the value it saw:
"_Field current_track is muted (muted)_". Transitions only — a row that
stays held tick after tick is logged once, not sixty times an hour.

Turning a guard off releases whatever it was holding, and those emails go out on
the next tick. A hold with no guard behind it would be a queue row nobody could
explain.

## Two guards worth copying

**Give people a mute button.** A field like
`current_track` set to `muted`, with a Pause & wait
guard scoped to the flow that does the drip. Someone who needs a break stops
receiving and picks up exactly where they left off, with the cadence intact.

**Don't pitch to people who already bought.** A Skip & continue
guard on the `pitch` label, conditioned on the tag or subscription
that means "already a customer". They stay in the sequence and keep getting
everything else; only the pitch is dropped.

Next: [The flow API →](/content/docs/api/flows.html)