Детекторы и канонические проблемы

Детекторная архитектура

Детектор (Detector)

Detector — алгоритм, который анализирует определённый набор данных и создаёт формализованный finding.

Детектор не управляет исполнением и не создаёт произвольный текст. Его результат имеет структурированный формат.

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

Цепочка Detector → Canon → Issue

flowchart TD
  D["Detector"] -->|"классификация"| C["Canon"]
  C -->|"управление"| I["Operational Issue"]

• Detector — конкретный алгоритм;
• Canon — стабильный тип эксплуатационной проблемы;
• Operational Issue — экземпляр проблемы в конкретном контексте.

Несколько разных детекторов могут подтверждать один канон.

Пример:

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"]

Классы детекторов

Требования к каждому детектору

Каждый production-детектор имеет:

• уникальный detector_id;
• семантическую версию;
• назначение;
• владельца;
• описание входных данных;
• контролируемые пороги;
• правила исключения;
• требования к минимальной выборке;
• DQ-гейты;
• формулу severity;
• формулу confidence;
• соответствующий канон;
• набор Evidence;
• тесты;
• контрольную выборку;
• оценку false positive;
• дату ввода;
• журнал изменений;
• режим отключения и rollback.

Гейты качества данных (DQ-гейты)

Детектор не должен формировать высокий уровень уверенности, если исходные данные неполны или противоречивы.

Примеры гейтов:

Здоровье детекторов (Detector Health)

OHM контролирует качество самих детекторов.

Основные показатели:

• число срабатываний;
• доля подтверждённых срабатываний;
• false positive rate;
• доля ручных отмен;
• доля повторных открытий;
• распределение confidence;
• drift входных данных;
• изменение структуры выборки;
• среднее время до подтверждения;
• версия алгоритма;
• число активных Issues по версии.

Канонические проблемы

Canon — стабильная бизнес-классификация проблемы, не зависящая от конкретной реализации детектора.

Зачем нужны каноны

Без канонов аналитическая система быстро превращается в набор несогласованных сообщений:

• archive_missing
• no_archive
• archive_gap
• hourly_data_absent
• delivery_error

Канон объединяет все эти эквивалентные сигналы под единым идентификатором: canon: no_hourly_archive.

Это обеспечивает:

• единый workflow;
• единый SLA;
• понятную аналитику;
• устойчивые KPI;
• общую базу знаний;
• сопоставимость между версиями;
• перевод интерфейса без изменения логики;
• интеграцию с внешними системами.

Структура канона

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

Базовый набор канонов

Версионирование канонов

Изменение текста или перевода не требует изменения идентификатора.

Новая версия канона требуется, если меняется:

• бизнес-смысл;
• правило назначения;
• критерий actionability;
• способ верификации;
• принцип SLA;
• логика объединения с другими проблемами.

Аналитика качества детекторов

Operational Health Matrix оценивает не только оборудование, но и качество собственных аналитических алгоритмов.

Для каждого Detector рассчитываются:

• Accuracy;
• Precision;
• Recall;
• False Positive Rate;
• False Negative Rate;
• Average Confidence;
• Drift;
• Stability;
• Mean Verification Time;
• Acceptance Rate.

Подобный подход позволяет непрерывно совершенствовать аналитическую модель IIoT Платформы без нарушения воспроизводимости результатов.

Сам портфель детекторов развивается по поэтапному roadmap: новые детекторы вводятся волнами, и каждая волна открывается по готовности соответствующих API платформы.