ISA-95 asset hierarchy

edgentia organizes everything as an ISA-95 asset hierarchy — the same structure plant and operations teams already think in. Raw MQTT topics are shaped into this tree so the catalogue is queryable and consistent across the enterprise.

The seven levels

Enterprise is the root; a Control Module is always a leaf.

Control Module = a first-class leaf asset

A Control Module is the measured thing — temperature, speed, status. It is a real leaf asset, not a "tag" hung off the equipment node. Each Control Module carries:

• a current value,
• a time-series history,
• a unit and a value type (gauge, counter, or enum),

and is the level at which live SSE updates, history charts, alerts, and API read-exposure operate. Higher levels (Enterprise → Equipment Module) are structural containers; only Control Modules carry measurement.

Addressing by dotted path

Assets are addressed by their dotted ISA-95 path, not opaque ids:

ahmad-co.lyon.assembly.line-01.welding.robot-1.temperature

This path is stable, human-readable, and the same everywhere — the API, the catalogue tree, history, and UNS republish all use it. The last segment is the Control Module; the rest is its place in the hierarchy.

From MQTT topic to asset

When a numeric MQTT topic is first seen, the runtime classifies it and proposes the full asset chain + the Control Module leaf under the workspace's ingest root. Proposals are reviewed and approved (ingest no longer auto-provisions silently), so the catalogue stays curated. Non-numeric or unmapped topics stay visible under the runtime's topic list until mapped.

Why it matters

A consistent ISA-95 tree means a query like "every temperature Control Module under lyon.assembly" works across lines and cells, dashboards and alerts reference assets by a durable path, and the same model feeds UNS republish to downstream systems.