# Requirement change

We had an incident overnight. A retry loop somewhere upstream generated a few hundred distinct
notifications for one customer and we sent every single one of them. She has, understandably, turned
us off entirely.

So there is a cap now. **Nobody gets more than three notifications from us in any one hour.**

What I need to be true:

- Three go out, and the fourth inside the same hour does not. It is not queued for later, it is not
  sent on a different channel — we simply do not contact her, and that is the answer we record.
- The fourth one is **exactly the same kind of answer** as somebody being in their quiet hours. It
  is not an error, nobody threw anything, and support does not need to chase it. It is us deciding
  not to send, which is a decision we already know how to record.
- **An hour later she can hear from us again.** The cap is a rolling hour, not a bucket that resets
  at the top of the hour, and not something that has to be reset by hand.
- **It is per person.** Three for her has nothing to do with three for anybody else.
- **A notification we never sent does not count against her.** If we held one back because it was
  three in the morning, that is not one of her three — she did not hear from us, so nothing was spent.
- **The same notification submitted twice counts once.** Our upstream resubmits, and if two
  submissions of the same thing burn two of her three then the cap is a lottery.
- One that we tried and failed **does** count. We did go and bother the provider on her behalf, and
  honestly if email, text and push have all just failed for her then hammering her again inside the
  hour is not the move.

Nothing else changes: the same channels, the same order, the same quiet hours, the same retry
schedule, the same idempotency.
