---
title: 'Detectors and canonical problems'
description: 'How detectors turn telemetry into findings and canons turn findings into managed problems — detector classes, data-quality gates, canon catalog and detector quality analytics.'
section: 'Operations Center'
weight: 5
related:
- evidence-and-correlation
- ai-intelligence
---
import Alert from '@/components/docs/Alert.astro';
import Image from '@/components/docs/Image.astro';
## 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.
```yaml
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
```mermaid
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:
```mermaid
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
| Class | Purpose |
| ------------ | ---------------------------------------------------- |
| Connectivity | communication, sessions, availability, signal |
| Archive | archive completeness and delivery |
| Data Quality | validity, gaps, contradictions |
| Metering | flow, volume, metrological relationships |
| Pressure | ranges, spikes, stuck readings |
| Temperature | ranges, trends, physical consistency |
| Power | battery, power supply, degradation |
| Registry | registry, duplicates, ghost objects |
| Passport | completeness and correctness of the passport |
| Integrity | signs of tampering and integrity violations |
| Security | anomalous access and configuration events |
| Firmware | errors, incompatibility, regressions |
| Topology | dependencies between devices, gateways, and services |
| Operations | overdue items, missing owner, recurrence |
| Predictive | forecast of failure or degradation |
### 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:
| Condition | Effect on the detector |
| --------------------- | ------------------------------------------- |
| No valid `asset_id` | block automatic action |
| Insufficient history | lower confidence |
| Timestamp error | do not compute freshness |
| No unit of measure | do not compare against a physical threshold |
| Sample too small | do not build a forecast |
| Registry ghost object | make related Issues non-actionable |
### 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
```yaml
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 | Meaning | Primary zone |
| ----------------------------- | ------------------------------------------------------------------ | --------------------------- |
| `no_sessions_in_period` | no sessions in the analyzed period | integration / communication |
| `stale_communication` | the device has not communicated for a long time | field / communication |
| `no_hourly_archive` | hourly archive is missing | backend / integration |
| `archive_delivery_failure` | archive was generated but not delivered | backend / integration |
| `archive_incomplete` | archive is incomplete | metering service |
| `abnormal_session_length` | anomalous session duration | communication / integration |
| `battery_low` | critically low battery resource | service |
| `battery_unknown` | battery state is unknown | service / integration |
| `passport_incomplete` | passport data is incomplete | metrology |
| `registry_ghost` | the object exists logically but is not physically confirmed | registry |
| `registry_duplicate` | identifier conflict or duplicate | registry |
| `pressure_out_of_range` | pressure outside the permissible range | operations |
| `pressure_sensor_stuck` | pressure sensor does not change under expected dynamics | metrology / service |
| `temperature_out_of_range` | temperature outside the permissible range | operations |
| `data_quality_degraded` | data quality does not allow reliable analysis | integration |
| `firmware_regression` | problems are linked to a firmware version | firmware / backend |
| `tampering_suspected` | signs of possible tampering detected | security / metrology |
| `leak_suspected` | indirect signs of a possible leak detected | operations |
| `topology_dependency_failure` | symptoms are caused by the failure of a shared dependent component | backend / infrastructure |
The canons `tampering_suspected` and `leak_suspected` are analytical hypotheses. They do not prove
a violation, a leak, theft, or the guilt of any specific person. Confirmation requires a regulated
technical inspection.
### 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.