Evidence and correlation

Evidence Model

What Evidence Is

Evidence is a structured proof on the basis of which the system creates, updates, or verifies an Issue.

Evidence can be:

• automatically computed;
• received from a device;
• imported from an external system;
• added by a user;
• generated by a specialized report;
• attached as a document, photo, or comment.

Evidence Structure

evidence_id: EVD-830129
issue_id: OHM-2026-001842
type: detector_finding
source:
  provider: analyze_station
  detector_id: archive.tail_gap.v3
  detector_version: '3.2.1'
observed_at: '2026-07-23T04:00:00Z'
created_at: '2026-07-23T04:03:12Z'

payload:
  missing_hours: 73
  coverage_valid: 0.91
  last_valid_hour: '2026-07-20T03:00:00Z'

quality:
  completeness: 1.0
  freshness: 0.98
  consistency: 0.96
  confidence: 0.98

links:
  report: '/reports/analyze-station/5690'

Evidence Types

Evidence Quality

Quality is computed for each Evidence:

where:

• $C$ — completeness;
• $F$ — freshness;
• $S$ — consistency;
• $T$ — trust in the source;
• $w_c + w_f + w_s + w_t = 1$.

Recommended base weights:

The result is normalized to the range 0 to 1.

Evidence Immutability

Original Evidence is never edited retroactively. A correction creates a new version or a separate corrective Evidence.

This ensures:

• auditability;
• reproducibility;
• protection of history;
• correct review of disputed cases;
• the ability to recompute.

Event Correlation and Root Cause

The Correlation Task

Correlation prevents the creation of many independent Issues for the same technical cause.

The system analyzes:

• asset match;
• temporal proximity;
• topological dependency;
• shared firmware;
• shared gateway;
• shared communication operator;
• shared region;
• shared server queue;
• symptom sequence;
• historical links;
• confirmed root causes of past cases.

Correlation Levels

Within a Single Asset

Several symptoms are consolidated around a primary canon.

flowchart TD
  A["stale_communication"] --> C{"Correlation within the asset"}
  B["no_hourly_archive"] --> C
  D["battery_unknown"] --> C
  C --> R["Root issue stale_communication"]
  C --> S1["Secondary signal no_hourly_archive"]
  C --> S2["Secondary signal battery_unknown"]

Across Assets

Similar problems are grouped into a massive incident.

flowchart TD
  A["38 devices"] --> G{"Grouping"}
  B["One firmware version"] --> G
  C["One time window"] --> G
  D["One failure type"] --> G
  G --> M["Massive Incident firmware_regression"]

By Dependency

Problems of child devices are linked to the failure of a shared component.

flowchart TD
  A["Gateway-17 unavailable"] --> B["12 correctors without communication"]
  B --> C["12 archives not delivered"]
  C --> D["One dependency incident"]

Correlation Score

An explainable model is used to assess the strength of a link:

where:

• $A$ — asset or dependency match;
• $T$ — temporal proximity;
• $P$ — pattern match;
• $C$ — shared context;
• $H$ — historical confirmation of the link.

Example weights:

The merge threshold is set per problem class. A more conservative threshold is allowed for critical security signals.

Root Cause Class

OHM uses a managed catalog of root causes:

Root Cause Statuses

Root Cause Confidence

Confidence in a hypothesis is computed from the aggregate of evidence:

where:

• $r_i$ — reliability of the detector or source;
• $q_i$ — Evidence quality;
• $a_i$ — consistency of the Evidence with the hypothesis;
• $K_{independence}$ — source independence coefficient.

If several pieces of Evidence originate from the same source data set, they are not considered fully independent.

Operational Confidence

Operational Confidence indicates how certain the system is that an Issue is a real and correctly classified problem.

where:

• $D$ — detector reliability;
• $E$ — Evidence quality;
• $R$ — correlation consistency;
• $H$ — historical confirmation rate;
• $X$ — penalty for contradictions and lack of data.

Interpretation: