Inbox Unificato — Alert Aggregator

Il problema classico: tre sistemi di rilevamento indipendenti producono tre alert "critici" quando una pompa si degrada. L'operatore vede tre righe, esita, e il rumore uccide il segnale.

La soluzione: un unico inbox che consolida le tre sorgenti in una riga per asset, con severità = la più alta osservata, sorgenti = unione dei rilevatori, e un trail dei cambi di severità.

Riepilogo esecutivo

Un picco → un alert. Prima: 3 rossi nell'inbox per lo stesso evento fisico. Dopo: 1 riga con source_systems = [anomaly, energy, prognostics].

A cosa serve

• Eliminare ridondanza: lo stesso fenomeno può attivare detection ML + residuo energetico + RUL critico in secondi.
• Preservare il trail: ogni rilevatore contribuisce al campo sources dell'alert consolidato.
• Severità canonica max: l'alert riflette la diagnosi peggiore.
• Escalation automatica: se l'operatore ha riconosciuto ma arriva un rilevamento peggiore, l'alert si riapre.

Come funziona

Contratto di input

Ogni rilevatore chiama l'aggregator dopo aver persistito il proprio record:

ingest_alert(
    tenant_id, asset_id,
    source_system="anomaly" | "energy" | "prognostics",
    severity="warning" | "high" | "critical",
    summary, source_doc_id, extra
)

Filtro: solo severity >= warning alimenta l'aggregator.

Regole di merge

flowchart TD
  IN[Nuovo rilevamento] --> Q{Riga attiva<br/>per asset<br/>nella finestra?}
  Q -- No --> INS[Inserisci<br/>status=open]
  Q -- Sì --> CMP{Severità entrante<br/>&gt; salvata?}
  CMP -- Sì --> UP[Upgrade<br/>severity=max<br/>push sources<br/>riapri se ack]
  CMP -- No --> EQ[Merge silenzioso<br/>count += 1<br/>source_systems addToSet<br/>NO push sources]

• Finestra dedup: alert_dedup_window_minutes (default 60).
• Ricerca: include righe open e acknowledged.
• Upgrade severità: severity := max(salvata, entrante).
• Re-open: ACK + severità maggiore → torna open con reopened_reason = severity_upgrade.
• Hysteresis del trail: severità uguale o minore non pusha a sources.

Persistenza

Collezione _alerts per-tenant. Campi chiave:

Test che codificano il contratto

• test_single_spike_consolidates_into_one_alert — 3 rilevatori nella stessa finestra sullo stesso asset → 1 riga, 3 sources.
• test_two_assets_two_separate_alerts — asset diversi → righe separate.
• test_upgrade_reopens_acknowledged_alert — ACK + critico entrante → riapre.
• test_same_severity_on_ack_keeps_it_acknowledged — ACK + stessa severità → non riapre.
• test_lower_severity_does_not_push_source_trail — salvata critica + warning → nessun push al trail.

Come usarlo

Vedere l'inbox

1. Operazioni → Alert — elenco tenant.
2. Colonne: Asset · Severità · Source systems · Count · First/Last seen · Azioni.
3. Filtri per severità, sorgente, status, date.

Azioni per alert

Configurazione per tenant

Via Configurazione Predittiva: alert_dedup_window_minutes (default 60).

Prima / Dopo

Prima

[14:02:15] CRITICAL  anomaly_detection   pump-B07  vibration score 0.92
[14:02:17] CRITICAL  energy_anomaly      pump-B07  z=3.4 on kwh
[14:02:21] CRITICAL  prognostics         pump-B07  RUL 18h

Dopo

[14:02:15→14:02:21] CRITICAL  pump-B07  [anomaly,energy,prognostics]  count=3
  └ sources: warning→ / →high / →critical

Limitazioni

• Dedup per asset_id. Metriche diverse dello stesso asset collassano.
• Finestra scorre su last_seen_at. Fuori finestra → nuova riga.
• Trail cattura upgrade, non ripetizioni. Usa count per statistiche.
• Non è un sistema di workflow completo. Gestione turni vive in Ordini di Lavoro.

Benefici chiave

• Un solo inbox per asset.
• Severità max canonica, trail auditabile.
• Re-open automatico in escalation.
• Hysteresis intelligente.
• Finestra configurabile per tenant.
• Test E2E che garantiscono il contratto.