Detectores y problemas canónicos

Arquitectura de detectores

Detector

Detector es un algoritmo que analiza un conjunto de datos definido y produce un hallazgo formalizado.

El detector no gestiona la ejecución ni genera texto arbitrario. Su resultado tiene un formato estructurado.

detector_id: archive.tail_gap.v3
detector_version: '3.2.1'
run_id: 'run-20260723-0400'
asset_id: 'station-5690'
observed_at: '2026-07-23T04:00:00Z'

finding:
  canon: no_hourly_archive
  detected: true
  severity: critical
  confidence: 0.98
  value: 73
  unit: 'hours'
  threshold: 24
  baseline: 0

evidence:
  last_valid_hour: '2026-07-20T03:00:00Z'
  expected_end: '2026-07-23T04:00:00Z'
  missing_hours: 73

Cadena Detector → Canon → Issue

flowchart TD
  D["Detector"] -->|"clasificación"| C["Canon"]
  C -->|"gestión"| I["Operational Issue"]

• Detector — un algoritmo concreto;
• Canon — un tipo estable de problema operativo;
• Operational Issue — una instancia del problema en un contexto concreto.

Varios detectores distintos pueden confirmar un mismo canon.

Ejemplo:

flowchart TD
  D1["archive.tail_gap.v3"] --> CANON["no_hourly_archive"]
  D2["archive.coverage.v2"] --> CANON
  D3["archive.delivery_queue.v1"] --> CANON
  D4["session.freshness.v4"] --> CANON
  CANON --> ISSUE["OHM-2026-001842"]

Clases de detectores

Requisitos de cada detector

Todo detector en producción tiene:

• un detector_id único;
• una versión semántica;
• un propósito declarado;
• un responsable;
• una descripción de los datos de entrada;
• umbrales controlados;
• reglas de exclusión;
• requisitos de muestra mínima;
• DQ-gates;
• una fórmula de severity;
• una fórmula de confidence;
• un canon correspondiente;
• un conjunto de Evidence;
• pruebas;
• una muestra de control;
• una estimación de falsos positivos;
• una fecha de puesta en servicio;
• un registro de cambios;
• un modo de desactivación y rollback.

Gates de calidad de datos (DQ-gates)

Un detector no debe generar un nivel de confianza alto si los datos de origen son incompletos o contradictorios.

Ejemplos de gates:

Salud de los detectores (Detector Health)

OHM supervisa la calidad de los propios detectores.

Indicadores principales:

• número de disparos;
• proporción de disparos confirmados;
• tasa de falsos positivos;
• proporción de cancelaciones manuales;
• proporción de reaperturas;
• distribución del confidence;
• deriva de los datos de entrada;
• cambio en la estructura de la muestra;
• tiempo medio hasta la confirmación;
• versión del algoritmo;
• número de Issues activos por versión.

Problemas canónicos

Canon es una clasificación de negocio estable de un problema, independiente de la implementación concreta del detector.

Para qué sirven los canons

Sin canons, un sistema analítico degenera rápidamente en un conjunto de mensajes incoherentes:

• archive_missing
• no_archive
• archive_gap
• hourly_data_absent
• delivery_error

El canon unifica todas estas señales equivalentes bajo un identificador único: canon: no_hourly_archive.

Esto aporta:

• un workflow único;
• un SLA único;
• analítica clara;
• KPI estables;
• una base de conocimiento común;
• comparabilidad entre versiones;
• traducción de la interfaz sin cambios en la lógica;
• integración con sistemas externos.

Estructura del canon

canon_id: no_hourly_archive
name: 'Hourly archive is missing'
domain: archive
default_owner_zone: backend_integration
default_priority: P1
actionable: true
verification_mode: data
sla_policy: archive_p1
suppression_group: communication_archive
knowledge_tags:
  - archive
  - delivery
  - communication

Conjunto base de canons

Versionado de los canons

Cambiar el texto o la traducción no requiere cambiar el identificador.

Se necesita una nueva versión del canon cuando cambia:

• el significado de negocio;
• la regla de asignación;
• el criterio de actionability;
• el método de verificación;
• el principio de SLA;
• la lógica de fusión con otros problemas.

Analítica de calidad de los detectores

Operational Health Matrix evalúa no solo los equipos, sino también la calidad de sus propios algoritmos analíticos.

Para cada Detector se calculan:

• Accuracy;
• Precision;
• Recall;
• False Positive Rate;
• False Negative Rate;
• confianza media;
• Drift;
• Stability;
• tiempo medio de verificación;
• tasa de aceptación.

Este enfoque permite mejorar de forma continua el modelo analítico de la Plataforma IIoT sin comprometer la reproducibilidad de los resultados.

El propio portafolio de detectores evoluciona según una hoja de ruta por etapas: los nuevos detectores se incorporan en oleadas y cada oleada se habilita en función de la preparación de las API subyacentes de la plataforma.