Operational domain model

Operational Domain Model

Operational Health Matrix is built on a unified operational domain model that defines the core entities, relationships and responsibilities across the IIoT Platform.

Every process, detector, API endpoint and analytical component operates on the same domain model, ensuring consistency throughout the entire system.

The domain model eliminates ambiguity, minimizes data duplication and provides a common operational language for all platform components.

Core Entities

The Operational Health Matrix domain consists of the following primary entities:

• Asset
• Detector
• Evidence
• Operational Issue
• Task
• Root Cause
• Health
• Knowledge Article
• Massive Incident
• SLA Policy
• Team
• User
• Notification
• Attachment
• Comment
• Audit Record

Each entity owns its lifecycle and participates in one or more operational workflows.

Asset

Asset is the central entity of the platform.

Every monitored physical or logical object is represented as an Asset.

Typical examples include:

• Gas Meter
• Pressure Sensor
• Corrector
• RTU
• Gateway
• Valve Controller
• Telemetry Unit
• Communication Device
• Software Component

Every Asset contains:

• unique identifier;
• type;
• model;
• manufacturer;
• serial number;
• owner;
• operational region;
• configuration;
• firmware version;
• communication profile;
• lifecycle state.

Detector

Detector is an analytical component responsible for transforming telemetry into operational observations.

Detector does not create business logic.

Its responsibility is limited to identifying observable patterns and producing evidence.

Detector attributes include:

• Identifier
• Version
• Canon
• Confidence
• Status
• Accuracy Metrics
• Health

Evidence

Evidence represents immutable proof supporting an operational conclusion.

Evidence may originate from:

• telemetry;
• communication logs;
• audit records;
• user confirmation;
• uploaded photographs;
• system diagnostics;
• external systems.

Evidence cannot be modified after creation.

If correction is required, a new Evidence object is created while preserving the previous version.

Operational Issue

Operational Issue represents a confirmed operational problem requiring investigation or resolution.

Each Operational Issue contains:

• Canon;
• Severity;
• Priority;
• Status;
• Owner;
• Root Cause;
• SLA Policy;
• Verification State;
• Operational History.

Operational Issue is the primary operational object of the platform.

Task

Task represents an executable action required to resolve an Operational Issue.

Tasks cannot exist independently.

Each Task belongs to exactly one Operational Issue.

An Operational Issue may contain multiple Tasks.

Root Cause

Root Cause represents the confirmed underlying reason for one or more Operational Issues.

Multiple Operational Issues may reference the same Root Cause.

This relationship enables enterprise-wide operational analytics and recurring problem identification.

Health

Health is a calculated operational indicator.

Health exists for:

• Asset;
• Site;
• Region;
• Organization;
• Entire Ecosystem.

Health values are always calculated automatically.

Knowledge Article

Knowledge Article stores validated operational experience.

Each article may reference:

• Canonical Issues;
• Root Causes;
• Asset Types;
• Firmware Versions;
• Operational Procedures;
• Manufacturer Documentation.

Massive Incident

Massive Incident groups multiple Operational Issues originating from a common operational event.

It provides a single management object for large-scale infrastructure incidents.

Operational Principles

Operational Health Matrix follows several architectural principles that define the behavior of every subsystem.

Asset First

Every operational event is associated with an Asset.

Assets remain the primary objects throughout the entire lifecycle.

Issue-Centric Operations

Operations are managed through Operational Issues rather than individual alarms or telemetry events.

Evidence-Driven Decisions

Every operational conclusion must be supported by one or more Evidence objects.

Unsupported assumptions are never treated as confirmed facts.

Root Cause Before Resolution

Corrective actions target confirmed causes rather than observable symptoms whenever possible.

Human-in-the-Loop

The platform supports operational decision making but never replaces engineering responsibility.

Critical actions require explicit human confirmation.

Explainable Analytics

Analytical conclusions remain transparent.

Every recommendation includes supporting evidence and confidence information.

Immutable Audit

Operational history cannot be rewritten.

Every modification produces a new audit record.

API First

Every platform capability is accessible through documented APIs.

User interfaces and external integrations rely on the same operational services.

Event-Driven Architecture

Operational changes are propagated as events.

This enables asynchronous integrations and scalable processing pipelines.

Operational Data Model

The platform follows a unified operational data model.

flowchart TD
    A["Asset"] --> DET["Detector"]
    A --> EV["Evidence"]
    A --> ISSUE["Operational Issue"]
    ISSUE --> TASK["Task"]
    ISSUE --> RC["Root Cause"]
    ISSUE --> SLA["SLA Policy"]
    ISSUE --> CMT["Comment"]
    ISSUE --> ATT["Attachment"]
    A --> HLT["Health"]
    A --> KB["Knowledge Articles"]

Ownership

Every entity has exactly one lifecycle owner.

Lifecycle Rules

The domain model follows several invariants:

• Assets are never deleted while historical Operational Issues exist.
• Evidence is immutable.
• Tasks cannot exist without an Operational Issue.
• Root Causes may be shared by multiple Issues.
• Health values are calculated and cannot be edited manually.
• Audit Records are append-only.
• Knowledge Articles remain versioned throughout their lifecycle.

These constraints ensure consistency, traceability and reproducibility across the Operational Health Matrix platform.