Caso: Inbox Unificato — 1 picco, 1 alert

Contesto

• Industria: metalmeccanica
• Attrezzatura: pompa centrifuga di processo B-07, 75 kW
• Sensori: vibrazione triassiale, pressione scarico, corrente motore, kWh istantaneo
• Criticità: alta — alimenta la linea di taglio ad acqua
• Stack Rela AI attivo: rilevamento anomalie ML + monitoraggio energia + prognosi

Il problema prima dell'aggregator

Quando un cuscinetto iniziava a guastarsi, tre sottosistemi rilevavano la stessa anomalia allo stesso tempo e producevano tre alert indipendenti:

[14:02:15]  🔴 CRITICAL  anomaly_detection   B-07  ensemble score 0.92
[14:02:17]  🔴 CRITICAL  energy_anomaly      B-07  z=3.4 on kwh
[14:02:21]  🔴 CRITICAL  prognostics         B-07  RUL 18h

Conseguenze reali che il cliente viveva:

• Operatore vedeva 3 rossi e non sapeva quale affrontare prima.
• 3 task duplicati sul kanban per lo stesso asset.
• 3 messaggi WhatsApp a 6 secondi di distanza.
• MTTR sporco — CMMS sincronizzava 3 incidenti quando era uno solo.

Cosa Rela AI fa oggi

sequenceDiagram
  participant S as Sensori
  participant A as anomaly_detection
  participant E as energy_service
  participant P as prognostics
  participant AG as alert_aggregator
  participant I as Inbox

  S->>A: Picco vibrazione
  A->>A: Ensemble score 0.75 (warning)
  A->>AG: ingest_alert(warning)
  AG->>I: Insert · status=open · severity=warning

  S->>E: Picco kWh
  E->>E: z-score 3.4 (high)
  E->>AG: ingest_alert(high)
  AG->>I: Upgrade · severity=high · source_systems=[anomaly,energy] · count=2

  S->>P: AHI collassa
  P->>P: RUL 18h (critical)
  P->>AG: ingest_alert(critical)
  AG->>I: Upgrade · severity=critical · source_systems=[anomaly,energy,prognostics] · count=3

I tre rilevamenti arrivano all'aggregator nella finestra configurata (alert_dedup_window_minutes, default 60). Risultato in _alerts:

Cosa vede l'operatore

Prima:

[14:02:15] 🔴 CRITICAL  anomaly    B-07  score 0.92
[14:02:17] 🔴 CRITICAL  energy     B-07  z=3.4
[14:02:21] 🔴 CRITICAL  prognostics B-07  RUL 18h

Dopo:

[14:02:15 → 14:02:21]  🔴 CRITICAL  B-07  [anomaly, energy, prognostics]  count=3
  └ trail: warning→ / →high / →critical

Escalation post-ACK

Se marcato acknowledged, un rilevamento successivo di severità maggiore lo riapre (reopened_reason = severity_upgrade) — nessuna perdita di visibilità.

Hysteresis

Se la severità entrante è uguale o minore a quella salvata: count e source_systems si aggiornano, ma sources non si sporca con ripetizioni non informative.

Impatto

Configurazione usata

{
  "alert_dedup_window_minutes": 60,
  "ahi_weights": {
    "condition": 0.35,
    "alarm_health": 0.20,
    "maintenance_compliance": 0.15,
    "trend_stability": 0.10,
    "anomaly_pressure": 0.20
  }
}

Cosa lo rende possibile

• R1: alert_aggregator_service con regole di merge per asset.
• R3: severità canonica condivisa tra i 3 rilevatori.
• R6: test E2E (test_single_spike_consolidates_into_one_alert).
• R8: hysteresis del trail, re-open in upgrade.

Perché conta commercialmente

• Meno rumore → più azione.
• MTTR pulito.
• Fiducia post-ACK.
• Integrazioni esterne ricevono una notifica per incidente.

Non è un "nice to have" di UI: sono cambi di contratto persistiti in _alerts, con test di integrazione che garantiscono che nessuno rompa la semantica. Vedi Inbox Unificato.