Object Model — ER Diagram

Three properties carry all the edges: isIn (physical containment), partOf (functional membership), and dependsOn (operational dependency).

erDiagram
    AREA    |o--o{ AREA   : "isIn"
    DEVICE  }o--o| AREA   : "isIn"
    DEVICE  |o--o{ DEVICE : "isIn"
    DEVICE  }o--o{ SYSTEM : "partOf"
    SYSTEM  |o--o{ SYSTEM : "partOf"
    DEVICE  }o--o{ DEVICE : "dependsOn"

Cardinality key

Symbol	Meaning
||	exactly one
|o	zero or one
o{	zero or many
|{	one or many

The marker closest to each entity name describes that entity’s cardinality as seen from the other side of the relationship.

Relationships

Edge	Property	Left cardinality	Right cardinality	Notes
AREA → AREA	isIn	zero or one parent	zero or many children	Top-level areas have no parent
DEVICE → AREA	isIn	zero or many devices per area	zero or one area per device	All devices should have a location
DEVICE → DEVICE	isIn	zero or one parent device	zero or many sub-devices	e.g. a circuit breaker is in a panel
DEVICE → SYSTEM	partOf	zero or many devices per system	zero or many systems per device	Many-to-many; a UPS can serve multiple systems
SYSTEM → SYSTEM	partOf	zero or one parent system	zero or many sub-systems	Top-level systems have no parent
DEVICE → DEVICE	dependsOn	zero or many dependents	zero or many dependencies	Many-to-many; traversed for root-cause analysis

Properties in use

Property	Type	Notes
isA	string	area | system | device | term
isIn	link or link[]	Physical containment — upward pointer
partOf	link or link[]	Functional system membership
dependsOn	link[]	Infrastructure this requires to operate; always an array
title	string	Display name for Dataview / Bases
listOf	string	Drives Base view filters on this note

Semantic distinctions

Question	Property to follow
Where is this physically?	isIn (upward to area)
What system does this serve?	partOf (upward to system)
What must be working for this to work?	dependsOn (to other devices)
What else breaks if this fails?	reverse of dependsOn (computed by query)

dependsOn is always an array because a device typically has more than one dependency (power source and network connection at minimum). It is the key property for automated triage: an n8n workflow detecting a failure can walk the dependsOn graph to determine whether the failure is local or a cascade from an upstream dependency.

Publishing note

As of 2026-02, Obsidian Bases support on Publish is planned but not yet available. Dynamic relationship lists (devices in an area, sub-systems of a system) render correctly inside Obsidian via embedded Base views, but appear blank on the published site until Obsidian ships Bases support for Publish.