Detectoare și probleme canonice

Arhitectura detectoarelor

Detector

Detectorul (Detector) este un algoritm care analizează un set de date bine definit și produce o constatare formalizată.

Detectorul nu gestionează execuția și nu generează text arbitrar. Rezultatul lui are un format structurat.

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

Lanțul Detector → Canon → Issue

flowchart TD
  D["Detector"] -->|"clasificare"| C["Canon"]
  C -->|"gestionare"| I["Operational Issue"]

• Detector – un algoritm concret;
• Canon – un tip stabil de problemă operațională;
• Operational Issue – o instanță a problemei într-un context concret.

Mai multe detectoare diferite pot confirma aceeași problemă canonică.

Exemplu:

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

Clase de detectoare

Cerințe pentru fiecare detector

Fiecare detector din mediul de producție are:

• un detector_id unic;
• o versiune semantică;
• un scop declarat;
• un responsabil;
• o descriere a datelor de intrare;
• praguri gestionate;
• reguli de excludere;
• cerințe privind mărimea minimă a eșantionului;
• puncte de control al calității datelor (DQ gates);
• o formulă de calcul al gravității;
• o formulă de calcul al nivelului de încredere;
• o problemă canonică corespunzătoare;
• un set de dovezi (Evidence);
• teste;
• un eșantion de control;
• o estimare a rezultatelor fals pozitive;
• o dată de punere în funcțiune;
• un jurnal al modificărilor;
• un mod de dezactivare și posibilitatea de revenire la versiunea anterioară (rollback).

Puncte de control al calității datelor

Un detector nu trebuie să producă un nivel de încredere ridicat dacă datele sursă sunt incomplete sau contradictorii.

Exemple de puncte de control:

Starea detectoarelor

OHM monitorizează calitatea detectoarelor însele.

Indicatori-cheie:

• numărul de declanșări;
• proporția declanșărilor confirmate;
• rata rezultatelor fals pozitive;
• proporția anulărilor manuale;
• proporția redeschiderilor;
• distribuția nivelurilor de încredere;
• deriva datelor de intrare;
• modificarea structurii eșantionului;
• timpul mediu până la confirmare;
• versiunea algoritmului;
• numărul de probleme (Issues) active pe versiune.

Probleme canonice (Canon)

Problema canonică (Canon) este o clasificare stabilă a problemei din punctul de vedere al activității, independentă de implementarea unui anumit detector.

De ce sunt necesare problemele canonice

Fără probleme canonice, un sistem analitic degenerează repede într-o colecție de mesaje incoerente:

• archive_missing
• no_archive
• archive_gap
• hourly_data_absent
• delivery_error

Problema canonică reunește toate aceste semnale echivalente sub un singur identificator: canon: no_hourly_archive.

Astfel se obțin:

• un flux de lucru unic;
• un singur acord privind nivelul serviciilor (SLA);
• analize clare;
• indicatori-cheie de performanță (KPI) stabili;
• o bază de cunoștințe comună;
• comparabilitatea între versiuni;
• traducerea interfeței fără modificarea logicii;
• integrarea cu sistemele externe.

Structura problemei canonice

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

Setul de bază al problemelor canonice

Versionarea problemelor canonice

Modificarea textului sau a unei traduceri nu impune schimbarea identificatorului.

O nouă versiune a problemei canonice este necesară atunci când se modifică oricare dintre următoarele:

• semnificația pentru activitate;
• regula de atribuire;
• criteriul care stabilește dacă problema necesită intervenție;
• metoda de verificare;
• principiul SLA;
• logica de comasare cu alte probleme.

Analiza calității detectoarelor

Operational Health Matrix evaluează nu numai echipamentele, ci și calitatea propriilor algoritmi analitici.

Pentru fiecare detector, sistemul calculează:

• exactitatea;
• precizia;
• sensibilitatea (recall);
• rata rezultatelor fals pozitive;
• rata rezultatelor fals negative;
• nivelul mediu de încredere;
• deriva;
• stabilitatea;
• timpul mediu de verificare;
• rata de acceptare.

Datorită acestei abordări, modelul analitic al subsistemului Data Platform poate fi îmbunătățit continuu, fără ca reproductibilitatea rezultatelor să fie compromisă.

Portofoliul de detectoare evoluează la rândul lui după o foaie de parcurs etapizată: detectoarele noi se introduc în valuri, iar fiecare val este condiționat de pregătirea interfețelor API ale platformei care stau la baza acestuia.