Detectors and canonical problems

Detector Architecture

Detector

A Detector is an algorithm that analyzes a defined data set and produces a formalized finding.

A detector does not manage execution and does not generate arbitrary text. Its output has a structured format.

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"] -->|"classification"| C["Canon"]
  C -->|"management"| I["Operational Issue"]

• Detector — a specific algorithm;
• Canon — a stable type of operational problem;
• Operational Issue — an instance of the problem in a specific context.

Several different detectors can confirm the same canon.

Example:

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

Detector Classes

Requirements for Every Detector

Every production detector has:

• a unique detector_id;
• a semantic version;
• a stated purpose;
• an owner;
• a description of input data;
• controlled thresholds;
• exclusion rules;
• minimum sample requirements;
• DQ gates;
• a severity formula;
• a confidence formula;
• a corresponding canon;
• an Evidence set;
• tests;
• a control sample;
• a false positive estimate;
• a commissioning date;
• a change log;
• a disable mode and rollback.

Data Quality Gates

A detector must not produce a high confidence level if the source data is incomplete or contradictory.

Examples of gates:

Detector Health

OHM monitors the quality of the detectors themselves.

Key indicators:

• number of triggers;
• share of confirmed triggers;
• false positive rate;
• share of manual cancellations;
• share of reopens;
• confidence distribution;
• input data drift;
• change in sample structure;
• mean time to confirmation;
• algorithm version;
• number of active Issues per version.

Canonical Problems

A Canon is a stable business classification of a problem that does not depend on a specific detector implementation.

Why Canons Are Needed

Without canons, an analytical system quickly degenerates into a set of inconsistent messages:

• archive_missing
• no_archive
• archive_gap
• hourly_data_absent
• delivery_error

A canon unifies all of these equivalent signals under a single identifier: canon: no_hourly_archive.

This provides:

• a single workflow;
• a single SLA;
• clear analytics;
• stable KPIs;
• a shared knowledge base;
• comparability across versions;
• interface translation without logic changes;
• integration with external systems.

Canon Structure

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

Base Set of Canons

Canon Versioning

Changing text or a translation does not require changing the identifier.

A new canon version is required when any of the following changes:

• business meaning;
• assignment rule;
• actionability criterion;
• verification method;
• SLA principle;
• logic of merging with other problems.

Detector Quality Analytics

The Operational Health Matrix evaluates not only the equipment but also the quality of its own analytical algorithms.

For each Detector, the system calculates:

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

This approach enables continuous improvement of the IIoT Platform’s analytical model without compromising the reproducibility of results.

The detector portfolio itself evolves along a staged roadmap: new detectors are introduced in waves, each gated by the readiness of the underlying platform APIs.