Fire once, not every cycle

L12 said a rule fires an alert when its condition is met, mediated by a "firing state machine that debounces" — and moved on. This is that machine, and it's the last substantive mechanism in the codebase. The problem it solves is one every on-call engineer feels in their bones: how do you turn "the condition is true right now" — evaluated every cycle — into the right number of alerts?

1 · The three-state machine (threshold rules)

ApplyFiringState (rules/firing.go) tracks a (rule, node) pair through three states, fed each cycle by one boolean — conditionMet:

2 · The re-emit gate (and why cooldown=0 means "fire once")

The ACTIVE re-emit has two guards worth reading — both protect against a stampede:

case StateActive:
    if !conditionMet { … return nil }       // cleared → COOLDOWN
    if rule.CooldownSec <= 0 { return nil }   // no cooldown ⇒ fire-once-per-breach
    if fs.LastAlertAt == "" { fs.LastAlertAt = now; … return nil }  // legacy-state grace cycle
    if cooldownExpiredAt(fs.LastAlertAt, rule.CooldownSec) { … return alert }   // reminder due

• CooldownSec <= 0 disables re-emit — a rule with no configured cooldown fires exactly once per breach. (Without this guard, cooldownExpiredAt returns true unconditionally and you'd alert every eval cycle — spam.)
• The legacy-state grace cycle — states written before LastAlertAt existed have it empty; the machine populates it without emitting, anchoring the cooldown to the first post-upgrade eval. Otherwise an ancient FiredAt would make every old breach look "overdue" and fire a thundering herd of reminders on the first cycle after deploy. A migration that refuses to stampede.

3 · Events are different — no ACTIVE state

Threshold rules describe a sustained condition (a score stays high), so they have an ACTIVE state. Event rules — admin_change, proxy_upgrade, token_mint — are instantaneous: the thing happened, there's no "still happening." So ApplyEventFiringState has no ACTIVE state at all:

CLEAR → (event)  →  emit, go straight to COOLDOWN
COOLDOWN → (event + cooldown expired)  →  emit again

4 · The alert it builds — and the taxonomy

When the machine decides to emit, buildRuleAlert assembles the AlertEvent the alert processor (L15) consumes: rule id/name/type, portfolio, severity, node, scope/view, and the details map. resolveAlertType maps the rule to a downstream alert_type taxonomy — event triggers become admin_change / proxy_upgrade / token_mint / new_edge (firewall rules use the detection module), and everything else is risk_limit_breach. And a hard cap, maxAlertsPerRule = 50 per eval cycle, is the last anti-flood backstop — the same drip-don't-flood discipline as L31's write budget and L33's per-run cap.

What you can now do

• Trace a (rule, node) through CLEAR → ACTIVE → COOLDOWN → CLEAR/ACTIVE and say where each alert fires.
• Explain the cooldown's dual role: repeat-alert suppression while ACTIVE, resolve-hysteresis in COOLDOWN.
• Explain why CooldownSec <= 0 means fire-once, and what the legacy-state grace cycle prevents.
• Contrast the event machine (no ACTIVE) with the threshold machine, and why the topology follows the semantics.
• Describe the AlertEvent built, the alert_type taxonomy, and the per-rule cap as anti-flood.