Caso: Inbox Unificado — 1 pico, 1 alerta

Contexto

• Industria: Manufactura metalmecánica
• Equipo: Bomba centrífuga de proceso B-07, 75 kW
• Sensores: vibración triaxial, presión descarga, corriente del motor, kWh instantáneo
• Criticidad: alta — alimenta la línea de corte por agua
• Stack Rela AI activo: anomaly detection ML + monitoreo de energía + pronósticos

El problema anterior (antes del aggregator)

Cuándo un rodamiento empezaba a fallar, tres subsistemas detectaban la misma anomalía al mismo tiempo y producían tres alertas independientes:

[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

Consecuencias reales que el cliente experimentaba:

• El operador veía 3 rojos simultáneos y no sabía cuál atender primero.
• 3 tareas creadas en el kanban para el mismo activo — el técnico las cerraba todas y el supervisor confirmaba 3 veces lo mismo.
• Las notificaciones por WhatsApp llegaban en tres mensajes a los 6 segundos de diferencia, que el operador interpretaba como 3 problemas diferentes.
• Métricas de MTTR se ensuciaban — el CMMS sincronizaba 3 incidentes cuando era uno solo.

Lo que Rela AI hace ahora

sequenceDiagram
  participant S as Sensores
  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: Vibración + spike
  A->>A: Ensemble score 0.75 (warning)
  A->>AG: ingest_alert(warning)
  AG->>I: Insert row · status=open · severity=warning

  S->>E: kWh spike
  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 colapsa
  P->>P: RUL 18h (critical)
  P->>AG: ingest_alert(critical)
  AG->>I: Upgrade · severity=critical · source_systems=[anomaly,energy,prognostics] · count=3

Las tres detecciones llegan al aggregator dentro de la ventana configurada (alert_dedup_window_minutes, default 60). El resultado en _alerts:

Cómo lo ve el operador

Antes:

[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

Después:

[14:02:15 → 14:02:21]  🔴 CRITICAL  B-07  [anomaly, energy, prognostics]  count=3
  └ trail:
      14:02:15  anomaly      warning→    ensemble score 0.75
      14:02:17  energy       →high       z=3.4 on kwh
      14:02:21  prognostics  →critical   RUL 18h

Una sola fila. La severidad es la peor observada. El trail cuenta la historia de escalación — permite auditar cómo se deterioró el incidente sin abrir 3 colecciones distintas.

Escalación post-ACK

El jefe de mantenimiento marca la fila como "reconocida" (acknowledged) para indicar "ya vi, voy a investigar". 15 minutos después entra una nueva detección de anomaly_detection para el mismo activo con severidad critical.

Antes del re-open automático: la alerta reconocida quedaba silenciada mientras llegaban detecciones peores sin que nadie las viera.

Ahora: la fila vuelve a status = open con reopened_reason = severity_upgrade. La UI la repromueve a la vista activa del inbox y dispara nueva notificación — no hay forma de perder visibilidad en una escalación.

Hysteresis: el trail no se ensucia

Si una detección entrante tiene severidad igual o menor a la almacenada, el aggregator aún actualiza count y source_systems (para estadísticas) pero no agrega al trail sources. Evita que una alerta crítica quede con un trail de 87 entradas warning que no aportan información.

Impacto

Configuración usada

{
  "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
  }
}

Ver Configuración Predictiva y Inbox Unificado para la lista completa de parámetros.

Qué lo hizo posible

Este caso está respaldado por cambios técnicos concretos:

• R1: servicio alert_aggregator_service con reglas de merge por asset y ventana configurable.
• R3: severidad canónica compartida (info/warning/high/critical) entre los 3 detectores.
• R6: test E2E (test_single_spike_consolidates_into_one_alert) que codifica el contrato "1 pico → 1 alerta".
• R8: hysteresis del trail, re-open en upgrade, búsqueda de dedup que incluye acknowledged.

Por qué importa comercialmente

• Menos ruido → más acción. El operador deja de ignorar alertas porque "todas gritan igual".
• MTTR limpio. El CMMS reporta incidentes reales, no duplicados — la métrica vuelve a ser confiable.
• Confianza post-ACK. Los jefes de turno pueden reconocer alertas sin miedo a perder escalaciones.
• Integraciones externas. WhatsApp, email, ServiceNow, SAP PM — todas reciben una sola notificación por incidente, no tres.

Este caso no es un "nice to have" de UI: son cambios de contrato persistidos en _alerts, con tests de integración que garantizan que nadie rompa la semántica. Ver Inbox Unificado para el contrato técnico completo.