Skip to content

Alert or Label Budget

Issuance policy — instantiates Signal Value Preservation

Caps how many alerts or labels a channel may issue per period, forcing issuers to spend a scarce budget of receiver attention and trust on only the cases that most deserve it.

The Alert or Label Budget is a standing quota on how many high-salience firings a channel may emit in a period. The one idea that makes it this mechanism is that it treats receiver attention and channel credibility as a fixed budget that each firing spends — not a free broadcast pipe — so adding a new alert means displacing or downgrading an existing one. It is a portfolio-level cap on quantity, which sets it apart from the timing-based spacing of a cooldown and from the per-signal evidence bar of an issuance rubric. Its whole purpose is to make depletion visible: everyone can see the channel filling up, so the next firing has to earn its slot.

Example

A security operations center is drowning its on-call engineers in P1 pages, and tuning individual detection rules never quite works because every team believes its own rule deserves to page. The team sets a budget instead: no more than roughly fifteen P1 pages per on-call week across all detections, with P1 treated as a fixed-size pool. To add a new P1 detection, a team must show it will displace a lower-yield one already in the pool. Almost overnight the argument changes from "is my alert important?" to "is my alert more important than the one it would push out?" — and because slots are allocated by evidence of past true-positive rate, the weakest detections lose their P1 status. A page starts to mean stop and look again, because there are only ever a handful of them.

How it works

The channel (or each tier within it) is allotted a fixed number of firings per period, denominated in the receiver's scarce resource — interrupts per shift, red banners per dashboard, push notifications per day. Issuance beyond the allotment forces a trade: displace a current occupant, downgrade to a lower tier, or wait for the next period. The remaining budget is posted where issuers can see it, so the cost of each firing is felt at the moment of issuing rather than discovered later in receiver apathy.

Tuning parameters

  • Budget size — how many firings per period. Set it from receiver capacity, not issuer demand; too tight starves real events, too loose defeats the point.
  • Allocation rule — first-come, priority-ranked, or auctioned against evidence of past yield. Auctioning slots by demonstrated true-positive rate is the strongest anti-inflation lever.
  • Granularity — one global budget versus per-team or per-tier sub-budgets. Sub-budgets stop a single noisy source from consuming the pool but add bookkeeping.
  • Burst policy — whether a verified surge of real events can borrow ahead or unused budget rolls over. Some elasticity avoids suppressing a genuine cluster; too much reintroduces flooding.

When it helps, and when it misleads

Its strength is that it makes the scarce resource explicit and forces real competition for the channel — the one thing that reliably halts issuance inflation, because it stops treating broadcast as free. Its failure modes are two. A budget sized by issuer demand rather than receiver capacity simply legitimizes the flood, and a hard cap can suppress a genuine burst — a real outage that generates thirty true P1s at once. It is also gamed by relabeling: issuers dodge the budget by firing under a different tier, which is why it must be paired with tier-integrity checks. The discipline that keeps it honest is to denominate the budget in receiver capacity, allow bounded bursts for verified real clusters, and watch for leakage into adjacent tiers.[1]

How it implements the components

  • receiver_attention_budget — its core: a hard, visible ration of the receiver's finite attention (interrupts, banners, pushes) that every firing must draw down.
  • credibility_budget — each weak firing also spends the channel's trust; the cap bounds that depletion so a firing keeps meaning "this one is worth it."

It does not space firings across time (channel_scarcity_policy) — that's Cooldown or Quiet Period — nor set the per-signal evidence bar (evidence_and_specificity_rule) — that's Signal Issuance Rubric.

Notes

A budget rations how many firings a channel emits but says nothing about whether the right cases fill it — a well-run budget can ration noise very efficiently. It therefore depends on an upstream evidence or actionability gate (a rubric, the Actionability Checklist) to decide what deserves a slot; without one, it makes the flood tidy rather than meaningful.

References

[1] Herbert Simon's observation that "a wealth of information creates a poverty of attention" — when information is abundant, attention is the scarce resource that must be budgeted. Correctly applied here, the binding constraint is not how many alerts can be sent but how many a receiver can meaningfully attend to. ↩