Configuración Predictiva

La configuración predictiva es el panel de control del motor de mantenimiento predictivo. Permite a cada tenant ajustar los parámetros que gobiernan cómo se calcula el AHI, cuándo se considera que un activo está en riesgo, qué ventana usa el inbox unificado para consolidar alertas, y cuánta confianza mínima se requiere para generar una intervención automática — todo sin cambios de código ni despliegues.

¿Cómo funciona?

La configuración está versionada (config_version) y es consumida online por el pipeline predictivo. Los cambios se validan, persisten y propagan vía pub/sub sin reinicio del worker.

¿Para qué sirve?

• Personalizar el motor predictivo según la tolerancia al riesgo y el contexto operativo de cada organización.
• Ajustar los pesos de los 5 sub-índices del AHI y los umbrales de grados (A/B/C/D).
• Definir los breakpoints de RUL (horas remanentes que separan critical/high/medium/low) y de probabilidad de falla.
• Configurar la ventana de dedup del Alert Aggregator.
• Overridear la configuración per-asset-type (una bomba crítica puede tener umbrales más estrictos que un compresor tolerante).
• Trazabilidad completa vía config_version — cada snapshot persistido lleva la versión con la que fue calculado.

Parámetros configurables

Pesos del AHI (ahi_weights)

Importancia relativa de cada sub-índice del Asset Health Index. La suma debe dar 1.0.

Ver Monitoreo de Condición para la semántica de cada sub-índice.

Grados del AHI (ahi_grades)

Thresholds que convierten el score 0–100 en letra A/B/C/D/F:

Tenants más estrictos pueden subir los thresholds (grade_a = 95, grade_b = 80...) para que la misma salud numérica reciba una calificación más dura.

Umbrales de RUL (rul_thresholds)

Horas restantes que separan los niveles de riesgo:

Los rangos se relajaron para cubrir activos industriales de larga vida (transformadores, recipientes a presión) cuya vida útil se mide en años y no en semanas. Tenants con cadencia de mantenimiento mensual pueden aumentar estos thresholds; plantas 24/7 con turnos cortos suelen bajarlos.

Probabilidad de falla (failure_probability)

Breakpoints que traducen AHI en bucket de riesgo de falla:

Alert Aggregator

Ver Inbox Unificado.

Otros

Requisitos de madurez (maturity_requirements)

Condiciones para promover un activo entre niveles:

Ver Niveles de Madurez.

Overrides por tipo de activo

Para cada asset_type, se puede sobrescribir cualquier sub-dict de la configuración sin repetir los parámetros que se mantienen:

{
  "rul_thresholds": { "critical_hours": 24, "high_hours": 168, "medium_hours": 720 },
  "asset_type_overrides": {
    "critical_pump": { "rul_thresholds": { "critical_hours": 12 } },
    "hvac_chiller":  { "rul_thresholds": { "critical_hours": 48, "high_hours": 336 } }
  }
}

Las bombas críticas pasan a "crítico" a las 12h restantes; los chillers HVAC son más tolerantes (48h). El resto de parámetros sigue usando el default del tenant.

config_version — trazabilidad de auditoría

Cada vez que un usuario guarda cambios en la configuración, config_version se incrementa atómicamente ($inc: {config_version: 1}). Los tenants nuevos arrancan en 0 (defaults de fábrica).

Cada documento persistido por el motor lleva el config_version activo en el momento del cálculo:

• _asset_health_snapshots — campo config_version en cada snapshot.
• _asset_prognostics — campo config_version en cada prognóstico.
• compute_enhanced_prognostics — expone config_version en el response.

Por qué importa: si tu tenant ajusta ahi_grades tres veces en 6 meses, los snapshots antiguos no se reescriben — cada uno conserva la versión con la que fue calculado. Una auditoría puede reconstruir exactamente qué umbrales produjeron cada calificación histórica.

Callers no pueden smuggle un config_version: el servicio lo filtra en cada update_config — el counter es propiedad del sistema, no del payload.

Cache

La configuración se cachea en memoria (TTL 5 min) y en Redis si está disponible. Cada update_config invalida el cache para que los siguientes lectores vean los valores nuevos. Los cambios no requieren reinicio.

¿Cómo usarlo?

Desde el dashboard

1. Configuración → Motor Predictivo.
2. Ajusta los pesos del AHI usando sliders (la suma se normaliza automáticamente al guardar).
3. Modifica thresholds de grados y RUL.
4. Configura overrides por asset_type en la sección Per-Tipo.
5. Guardar — el config_version se incrementa y los próximos cálculos lo usan.
6. Restaurar Defaults — limpia toda la configuración del tenant (el config_version queda como quedaría después de un update).

Desde la API

GET  /api/v1/predictive-config            # retorna config resuelta (defaults + overrides)
PATCH /api/v1/predictive-config           # actualiza parcialmente, bumpea config_version
POST /api/v1/predictive-config/reset      # borra la config del tenant (vuelve a defaults)

Las actualizaciones son deep-merge: si mandas solo {"rul_thresholds": {"critical_hours": 12}}, los otros campos de rul_thresholds conservan su valor.

Beneficios clave

• Un solo panel per-tenant — ajuste sin código, sin despliegues.
• Granularidad fina: pesos + grados + thresholds + overrides por tipo de activo.
• config_version incremental trazable en cada snapshot persistido.
• Cache transparente de 5 min + invalidación automática en updates.
• El sistema protege su propio counter — callers no pueden smuggle versiones.
• Reset idempotente que no rompe el versionado.

Consumidores

La configuración resuelta (defaults + tenant + asset_type override) la consumen:

• health_assessment_service — pesos + grados + anomaly_pressure.
• prognostics_service — rul_thresholds + failure_probability + confidence_snapshots_ceiling.
• maturity_calculation_service — maturity_requirements.
• alert_aggregator_service — alert_dedup_window_minutes.
• Daily briefings WhatsApp/email — ahi_risk_threshold.