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

Архітектура детекторів

Детектор (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 платформи.