TL;DR — four things to remember

The 4-Yes Rule. Something is a sub-asset if you measure it alone, replace it alone, maintain it alone, or it carries its own programming/firmware. If all four are "no" → it's a property.
One canonical identity, single writer. Every asset is born with one canonical identity (UUID) through one canonical entry point. Every other identifier — meter code, drive serial, legacy graph id — is an alias that resolves to it. No inline writes, no second source of truth, no duplicate identities.
Five canonical levels. Organization → Plant → Area → Asset (equipment) → Asset (sub-component). Don't go deeper than 3 levels of CONTAINS without a strong reason.
Orphan → adopted lifecycle. Assets exist digitally before anyone manages them. Registration is unlimited; adoption is the deliberate act that makes an asset managed. "Register unlimited. Manage what matters."

We didn't invent this. The doctrine materializes ISA-95 / IEC 62264 (hierarchy), ISO 14224 (taxonomy + failure modes, 9 levels), Brick Schema 1.4 (HVAC ontology), Project Haystack 4 (tagging), and KKS / RDS-PP / IEC 81346 (power plants). Detail in Standards alignment.

The 4-Yes Rule — granularity in four questions

The hardest part of modeling industrial assets isn't naming things — it's deciding what counts as a thing. The 4-Yes Rule answers that question for any physical component (extended 2026-05-02 with the firmware question, after recognizing that drives and PLCs warrant their own asset track regardless of containment):

For any component, ask four questions:

Do you measure it alone? Does it have a sensor that measures its vibration, its temperature, its kWh, its pressure — independent from the parent equipment?
Do you replace it alone? When it fails, do you swap it without touching the rest of the equipment? Does it have its own serial number, install date, and manufacturer?
Do you maintain it alone? Do you open dedicated work orders for it? Does it have its own lubrication, calibration, or overhaul cadence?
Does it carry its own programming or firmware? VFDs, PLCs, HMIs, BMS controllers, modems with their own setup. The firmware, parameters, and configuration are independent of the parent equipment — replacement requires loading a backup of the program.

One yes → model as a sub-Asset with CONTAINS from the parent.
Four nos → model as a property of the parent asset.

Why the 4th rule. A VFD inside a motor starter cabinet shares physical space with its PLC, HMI, contactors — but its firmware, ramp parameters, and accel curves are independent. When the drive is replaced, the programming backup has to be reloaded. When the setpoint changes, it's the drive's documentation that updates (not the cabinet's). That operational autonomy makes it an atomic asset even though it lives inside another asset. Same logic applies to PLCs, HMIs, and BMS controllers — and is captured in the catalog by the has_programming flag and the D/K/P ISO 81346-2 family classes.

The rule applied to real components

Component	Measure?	Replace?	Maintain?	Firmware?	Verdict
Chiller compressor	✅	✅	✅	❌	sub-Asset
Pump motor	✅	✅	✅	❌	sub-Asset
VFD on a pump	✅	✅	✅	✅	sub-Asset
AHU filter bank	✅	✅	✅	❌	sub-Asset
Belimo damper (with Modbus feedback)	✅	✅	✅	✅	sub-Asset
Refrigerant (R-1234ze)	❌	❌	❌	❌	property
Bolts and gaskets	❌	❌	❌	❌	property or none
Filter count (5 filters)	❌	❌	❌	❌	property of filter bank
Compressor O-ring	❌	⚠️ at overhaul	❌	❌	property / consumable

Where this rule comes from. ISO 14224 explicitly says: "In some instances there is no need to dive deeper than level 6, and in other instances, it is vital to dive down to the individual part level." The 4-Yes Rule is exactly that decision, made operational. The first three "yeses" are criteria the standard lists — ability to analyze (measure), level of reliability required (replace), needs of the organization (maintain) — and the fourth captures configuration autonomy: a component whose firmware and parameters must be backed up and restored independently is a maintainable item in its own right.

Five canonical levels

Wertek's hierarchy maps one-to-one onto ISA-95 / IEC 62264 (Enterprise → Site → Area → Work Unit) extended with a sub-component layer governed by ISO 14224. ISA-95 calls the top level Enterprise; Wertek's label for the same concept is Organization (aligned with the Postgres organizations table).

Level 0 Organization (client / organization) │ HAS_PLANT Level 1 Plant (physical site, building) │ HAS_AREA Level 2 Area (zone within the site) │ CONTAINS Level 3 Asset (equipment) ← operational unit │ CONTAINS Level 4 Asset (sub-component) ← instrumented part

Hard rules

Only Asset nests via CONTAINS. Never Organization→Organization, never Area→Area.
Maximum recommended depth: 2 levels of Asset (equipment + sub-component). 3 levels is acceptable when instrumentation requires it.
Sensor is its own label, never an Asset. Connection is via HAS_SENSOR.
Required identity: every node carries its canonical id (UUID) plus organization_id for tenant isolation.

Identity & lifecycle — orphan to adopted

Hierarchy answers where an asset sits. Two more questions complete the model: who is this asset, exactly? (identity) and who cares for it? (lifecycle). Both are doctrine, not convention.

One canonical identity

Every asset is born with one canonical identity — a UUID minted at creation — shared by every store that knows about the asset (the relational system of record and the graph). Everything else that can name the asset in the real world is an alias:

meter and gateway codes bound to it,
manufacturer serial numbers (a drive's nameplate),
legacy or import identifiers from a customer's CMMS/SCADA,
graph-era ids that predate the canonical key.

An identity resolution layer maps any alias to the canonical id at the entry point of every data path — telemetry ingest, alerting, incident tracking, reporting. The consequence that matters: a measurement, an alert, and a work order about the same physical machine can never disagree about which machine they mean. Duplicate identities are prevented by construction (creation is relational-first through the single writer, then mirrored to the graph) and guarded by CI — not cleaned up after the fact.

Why this is hard enough to deserve doctrine. Industrial data arrives keyed by whatever the source device knows — a Modbus id, a serial, a bus address. Systems that key their history on those raw identifiers fracture the asset's story the first time a meter is rebound or a drive is replaced. Resolving to one canonical identity at ingest is what keeps years of history attached to the machine instead of to the cable.

The orphan → adopted lifecycle

"The asset exists digitally before the user interacts with it." Wertek platform doctrine

Assets enter the platform through many doors — a QR/NFC scan on a cabinet, a gateway discovering devices on a bus, a bulk import from a customer inventory. All of them create the asset in the same state: orphan. An orphan is a real, fully-identified asset (canonical id, type, location if known) that nobody has committed to manage yet.

State	What it means	Cost
Orphan	Registered and identified; visible; accumulating identity (and telemetry if a source is bound). Nobody has claimed responsibility.	Unlimited, on every plan.
Adopted	A deliberate act: someone commits to manage this asset — condition monitoring, alerting, work orders, reporting.	Counts against the plan's adopted-asset limit.

The split is the commercial model and the modeling doctrine at once: "Register unlimited. Manage what matters." Registering everything costs nothing, so hierarchies can be complete from day one; adoption is the explicit signal of what the organization actually operates and cares for.

Standards alignment

Each level and decision in the Wertek model traces back to a published international standard. This is not coincidence — the goal of the doctrine is to not invent what already exists.

Standard	Covers	Wertek implementation
ISA-95 / IEC 62264	Hierarchy: Enterprise → Site → Area → Work Unit → Equipment Module	1:1 mapping to `Organization→Plant→Area→Asset→sub-Asset`
ISO 14224	Equipment taxonomy and failure modes (9 levels: industry → part)	`EquipmentType` via `IS_TYPE`; depth guided by the 4-Yes Rule
Brick Schema 1.4 (May 2025)	Open semantic ontology for buildings (HVAC, lighting, fire, security) — RDF/Turtle	Each `equipment_type` carries `brick_class`; export to Turtle on roadmap
Project Haystack 4 (Mar 2026)	Tagging system for building data (site / equip / point) — adopted by Niagara, JCI, Siemens	`haystack_tags` array as Asset property; interop with BMS legacy
ASHRAE 223P	Emerging convergence of Brick + Haystack (RDF/SHACL/SPARQL) — DOE-funded	Roadmap: align when published (currently in development)
KKS (Kraftwerk-Kennzeichensystem)	Power plant identification system (legacy German standard)	Optional `kks_code` property; CSV importer for fast onboarding
RDS-PP / IEC 81346-10	Modern successor to KKS, published by VGB (2007), based on IEC 81346 series	Optional `rds_pp_code` property; works alongside KKS for plants in transition
IEC 81346	Reference designation system (=, +, − prefixes for function / location / product)	Foundation of RDS-PP; properties available for plants requiring it

The pitch in one sentence

"Wertek implements the ISA-95 / IEC 62264 hierarchy natively, with ISO 14224 taxonomy for failure modes. For HVAC sites we export Brick Schema 1.4 and support Project Haystack 4 tags. For power plants we support KKS and RDS-PP (IEC 81346-10) as asset properties, allowing direct import from existing drawings and SCADA systems." Standard intro for any senior engineer or BMS Tier-1 evaluator.

ISO 14224 nine levels — and where Wertek lands

Level	Name (ISO 14224)	Wertek modeling
1	Industry	Property on `Organization`
2	Business category	Property on `Organization`
3	Installation	`Organization` node
4	Plant / unit	`Plant` node
5	Section / system	`Area` node
6	Equipment unit	`Asset` (equipment-level)
7	Subunit	`Asset` (sub-component, level 1)
8	Component / maintainable item	`Asset` (sub-component, level 2 — rare)
9	Part	Property or consumable (not modeled as a node)

Brick Schema 1.4 — equipment class mapping (HVAC)

Wertek `equipment_type`	Brick class
`chiller`	`brick:Chiller`
`cooling_tower`	`brick:Cooling_Tower`
`pump` (CHWP)	`brick:Chilled_Water_Pump`
`pump` (CWP)	`brick:Condenser_Water_Pump`
`ahu`	`brick:Air_Handling_Unit`
`vav_box`	`brick:Variable_Air_Volume_Box`
`compressor_air`	`brick:Air_Compressor`
`motor`	`brick:Motor`
`vfd`	`brick:VFD`
`damper`	`brick:Damper`
`heat_exchanger` (evap)	`brick:Evaporator`
`heat_exchanger` (cond)	`brick:Condenser`

Sub-component catalog — preview

Each equipment_type has a canonical set of sub-components, defined to satisfy the 4-Yes Rule and to remain consistent across customers. The catalog is prescriptive (used by the UI to suggest one-click components) but extensible.

Chiller (any type)

Sub-component	Type	ISO 14224	Typical sensor
Compressor	`compressor`	CO-SC / CO-CE / CO-RE	Accelerometer, winding RTD
Evaporator	`heat_exchanger`	HE	Water in/out RTD, ΔP
Condenser	`heat_exchanger`	HE	Water in/out RTD
Control panel	`control_panel`	CT	Modbus to chiller (status, faults, capacity)
Oil pump (screw only)	`pump`	PU-PD	Oil pressure, oil temp

Air Handling Unit (AHU)

Sub-component	Type	ISO 14224	Typical sensor
Supply fan	`fan`	FA	Accelerometer
Return fan (dual-fan only)	`fan`	FA	Accelerometer
VFD (Delta MS300, ABB ACH580)	`vfd`	CT	Modbus (freq, kWh, faults)
Filter bank	`filter_bank`	(custom)	ΔP filters
Cooling coil	`heat_exchanger`	HE	Water/air RTD
Outdoor air damper	`damper`	VA	Belimo MFT feedback (Modbus)
Return air damper	`damper`	VA	Position feedback

Pump (CHWP, CWP, process water)

Sub-component	Type	ISO 14224	Typical sensor
Motor	`motor`	MO-IN	Accelerometer, current CT
VFD	`vfd`	CT	Modbus telemetry
Coupling	`coupling`	GB	(no typical sensor — sub-Asset only when replaceable)

The full catalog covers HVAC (chiller plants, VRV, CRAC), industrial utilities (compressed air, cooling loops, boilers, pump stations), electrical (transformers, switchgear, capacitor banks, UPS), and power generation (gas turbines, HRSG, steam turbines). New verticals are added by PR review, not improvised per customer.

Asset templates — preview

Templates pre-build complete systems from a few parameters. Customers don't design hierarchies — they pick a template, set 3-5 parameters, and the catalog + the hub do the rest.

Template ID	What it builds	Vertical
`chiller_plant_2_redundant`	2 chillers (N+1) · 1 cooling tower · 4 pumps · edge agent	HVAC
`chiller_plant_n_lead_lag`	N chillers + N+1 pumps + 1 tower (large industrial)	HVAC
`ahu_dual_fan_economizer`	AHU with SF + RF + economizer + 4 dampers	HVAC
`vrv_daikin_office`	1 ODU + N IDUs + DIII-NET → BACnet gateway	HVAC
`compressed_air_2_redundant`	2 compressors + dryer + receiver + filter chain	Industrial
`combined_cycle_block`	GT + HRSG + ST + condenser (TechGen-style)	Power
`solar_pv_string`	Inverters + MPPTs + DC strings	Renewable
`capacitor_bank_compensation`	Controller + N steps + contactor + power meter	Electrical

How they compose with everything else. Templates use the same hub (core/asset_hub.py), the same catalog, the same ISO 14224 codes, the same Brick mappings. They are the "happy path" of modeling — but the same primitives remain available for anyone who needs to deviate.

Worked examples

Chiller with screw compressor

Asset: Chiller-1                  type=chiller
  ├ CONTAINS → Asset: Compresor   type=compressor   IS_TYPE → CO-SC
  │                ↑ HAS_SENSOR: Accelerometer
  ├ CONTAINS → Asset: Evaporador  type=heat_exchanger
  │                ↑ HAS_SENSOR: RTD evap_in / evap_out
  ├ CONTAINS → Asset: Condensador type=heat_exchanger
  └ CONTAINS → Asset: Tablero     type=control_panel
properties: refrigerant="R-1234ze", tonnage_tr=150, model="EWAD-TZ"

The compressor is a sub-Asset because it has its own accelerometer (measure), it gets replaced or overhauled independently (replace), and it has its own oil and lubrication maintenance schedule (maintain). Three of the four yeses — one is enough. The refrigerant is a property because none apply.

Pump CHWP-1 with motor + VFD

Asset: CHWP-1                     type=pump          IS_TYPE → PU-CE
  ├ CONTAINS → Asset: Motor       type=motor         IS_TYPE → MO-IN
  │                serial: "SIE-2024-3-001"
  ├ CONTAINS → Asset: VFD         type=vfd           IS_TYPE → CT
  │                manufacturer: "Danfoss", model: "iC2-Micro"
  └ CONTAINS → Asset: Acople      type=coupling      IS_TYPE → GB
properties: head_ft=120, flow_design_gpm=400, motor_hp=75

When a motor is replaced years later, the old node is marked status="retired" (not deleted) and a new node is created with its own serial and install date. History survives the swap.

Anti-patterns

Common modeling mistakes and what to do instead. Detection queries and remediation patterns are documented internally; the table below summarizes the failure modes.

Anti-pattern	Why it's wrong	Instead
Modeling every bolt and gasket	10K+ nodes with no analytical value	Property or consumable
`Sensor` as a sub-`Asset`	Confuses what operates with what measures	Use `HAS_SENSOR` with a `Sensor` node
CONTAINS depth > 3 levels	One intermediate level usually should be a property	Flatten to 2-3 levels
Sub-areas (`Area→Area`)	Breaks single-level Area assumption	Sibling Areas under the same Plant
Inline Cypher creating Assets	Breaks the single-writer guarantee	Always go through the asset hub
Free-form `Asset.type`	"Bomba", "bomba", "BOMBA", "pump" — impossible to query	Enum from canonical catalog
Asset with no sensor and no work order	Empty container — likely should be an Area	Convert to Area or delete

References

License. This documentation is released under CC BY 4.0. Free to use, adapt, redistribute with attribution to Wertek AI.

Changelog

Version	Date	Changes
`1.1.0`	2026-07-05	New section Identity & lifecycle: one canonical identity (UUID) per asset with alias resolution at every ingest entry point, relational-first creation through the single writer, duplicate identities prevented by construction; the orphan → adopted lifecycle ("Register unlimited. Manage what matters."). Consistency pass on the 4-Yes Rule (hero, TL;DR and applied-components table updated to the fourth question — firmware/programming — introduced 2026-05-02). Hard-rules identity bullet updated to the canonical UUID.
`1.0.1`	2026-05-01	Canonical names normalized to `Organization → Plant → Area → Asset` (aligned with Postgres `organizations` table). ISA-95 Enterprise terminology preserved as parenthetical reference. Note added on Neo4j legacy labels (`:Empresa`, `:Planta`) pending migration.
`1.0`	2026-05-01	Initial publication. The 3-Yes Rule, five canonical levels, full standards alignment (ISA-95 / IEC 62264, ISO 14224, Brick Schema 1.4, Project Haystack 4, KKS / RDS-PP / IEC 81346), sub-component catalog preview, asset templates preview, anti-patterns, references.

Asset Hierarchy & the 4-Yes Rule

On this page