Object Model — ER Diagram

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

classDiagram
    direction LR
    class AREA
    class DEVICE
    class SYSTEM

    AREA   "0..*" -->  "0..1" AREA   : isInA
    DEVICE "0..*" -->  "0..1" AREA   : isInA
    DEVICE "0..*" -->  "0..1" DEVICE : isInD
    DEVICE "0..*" -->  "0..*" SYSTEM : partOf
    SYSTEM "0..*" -->  "0..1" SYSTEM : partOf
    DEVICE "0..*" ..>  "0..*" DEVICE : dependsOn

Solid arrows (-->) are structural relationships: physical containment (isIn) and functional membership (partOf). Dashed arrows (..>) are operational dependencies (dependsOn). Cardinality is shown at each end of the arrow.

Cardinality key

Notation	Meaning
0..1	zero or one (optional, singular — root nodes have zero)
0..*	zero or many
1	exactly one

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.