## TL;DR
Validate every wait step's unit before a sequence goes live, and add a pacing guardrail that caps sends per lead per week regardless of what the steps say. A unit mismatch turns a 9-day nurture into a 9-hour blast; the guardrail catches it even when the config is wrong.

```
agent's sequence sent 7 emails in 9 days because the wait step was configured in hours instead of days
```

## Steps

1. Audit every wait step in the sequence: read the number AND the unit out loud in review ("wait 72 - hours or days?"), and fix any mismatches.
   Expected: a reviewed list of all wait steps with explicit units, signed off before launch.

2. Add a pacing guardrail above the sequence logic: no lead gets more than N touches in any rolling 7 days, enforced at send time no matter what the steps request.
   Expected: a test sequence with hourly waits gets throttled by the guardrail, and the throttle events are logged.

3. Make wait-step units unambiguous in the builder - a dropdown of hours/days/weeks rather than a bare number field, with days as the default for nurture sequences.
   Expected: new wait steps cannot be saved without an explicit unit, and the default is the safe one.

4. Dry-run the sequence on test leads and check the actual send timestamps before launching to real leads.
   Expected: the dry run's timestamps show the intended spacing, verified against the plan.

5. For leads already over-contacted, pause the sequence, give them a rest period, and have the next touch acknowledge the burst briefly rather than pretending it did not happen.
   Expected: affected leads are paused, and the resume plan includes a cooling-off gap.

## Use this when
- a sequence sends much faster than intended due to unit or config errors
- wait steps use hours where days were meant (or similar mismatches)
- you need a backstop against pacing misconfiguration

## Not for this skill when
- the fast pace was intentional - that is a strategy choice, not a bug
- sends are throttled by the provider's rate limits - see the rate-limit skills
- leads get too many touches from overlapping sequences - that is a cool-down problem

## Variant phrasings
- wait step configured in hours instead of days
- sequence sent 7 emails in 9 days
- pacing unit mismatch caused an email burst
- nurture sequence fired all steps in hours

## Why it happens
Sequence builders accept a number and a unit separately, and the unit defaults to whatever the last person used - often hours, from testing. "Wait 3" means three days in the builder's head and three hours in the config. Nobody notices until the leads do, because the sequence "works" - it just works far too fast.

## Edge cases
- Business days vs calendar days: a "wait 2 days" over a weekend lands differently - decide which one your steps mean and document it.
- Timezone differences compress perceived spacing - the guardrail counts actual sends, not intended ones.
- A lead replying mid-burst should pause the sequence - the guardrail limits sends, but replies should stop them entirely; see the stop-on-reply skills.
- Reused sequence templates carry old wait configs - re-validate units every time a template is cloned for a new campaign.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_ujTO3m792gHWpahliD7dBQ