Separate the thing from the kind of thing.

AHU-3 is an entity in a particular building. brick:Air_Handling_Unit is a class in the Brick ontology. The first is an instance; the second supplies shared meaning.

That distinction is easy to say and easy to blur. A class defines a reusable category. An instance identifies the occurrence that applications, drawings and source systems refer to. More specific classes can add precision without changing the identity of the occurrence.

Brick can describe physical entities such as fans and rooms, logical entities such as HVAC zones, and virtual entities such as points. These categories can meet around the same AHU without being collapsed into one object.

Classification tells us what AHU-3 is. Relationships tell us why it matters.

Open the casing with hasPart.

Composition describes an entity as containing or being composed of other entities. For AHU-3, brick:hasPart can connect the unit to its supply fan, heating coil, cooling coil and filter. The inverse relation is brick:isPartOf.

This is not merely a visual nesting device. A maintenance application can ask which components belong to an AHU; an analysis can discover the fan inside the unit; a validation rule can test whether an agreed component is represented.

The relation should reflect the intended Brick composition, not be imported mechanically from a bill of materials or an IEC 81346 aspect structure. Those sources can inform the assertion, but their relation semantics are not automatically identical.

State what it feeds, and where it is.

brick:feeds represents a directional flow of some medium between entities. It can connect AHU-3 to downstream equipment or a served zone when that assertion is appropriate to the model. It is a semantic topology relation, not a licence to model arbitrary physical air-flow physics, pressure fields or every duct segment.

brick:hasLocation answers a different question: where the entity is located. AHU-3 may have a mechanical room as its location while feeding equipment and zones elsewhere. Location must not be substituted for service topology.

The figure is deliberately a subgraph. It says enough to follow composition, place, telemetry and a selected service path. It does not claim that these nodes are a complete engineering model of AHU-3.

Connect the machine to its points and roles.

brick:hasPoint links an entity to a point that measures, commands, sets or otherwise represents a property associated with it. The inverse brick:isPointOf supports the opposite traversal. AHU-3 may have supply-air temperature, fan command and filter alarm points, each classified according to its role.

Brick 1.5 also introduces brick:hosts and brick:controls. Hosting can express that one entity provides the execution or deployment environment for another. Control can state a control relationship between entities. They add useful vocabulary, but should be asserted only where the project can establish the relationship.

No single lens replaces the others. A fan can be part of an AHU, a point can be associated with the fan, the AHU can be located in a room, and the assembled equipment can participate in a downstream topology.

Read every relationship in its declared direction.

Brick relationships are directed. AHU-3 brick:feeds VAV-3A is not the same assertion as the reverse. Brick defines inverse relationships for many common predicates, such as hasPart/isPartOf, hasPoint/isPointOf and feeds/isFedBy. Inference tooling may materialise inverse statements, but a query should not casually reverse an edge.

Systems, loops and other collections provide another way to organise context. Brick’s collection modelling lets entities participate in a named grouping without claiming that the collection is a physical container. A hot-water system, an air loop or an owner-defined analytical collection can become a useful query anchor when modelled with the applicable Brick collection vocabulary.

An edge label without direction is only half a statement.

Let competency questions draw the boundary.

A model expands indefinitely if “complete” is the only requirement. Competency questions provide a sharper contract: concrete questions that the graph must answer for an intended use.

• Which supply-air temperature points belong to AHU-3?
• Which terminal units are downstream of AHU-3?
• Which zones are reached through those units?
• Which physical components are part of the AHU?
• Where is the AHU located?
• Which external identifier locates each point’s data?

These questions define an initial boundary around AHU-3. Add the entities and relationships required to answer them, then test the queries against expected results. A later use case can extend the graph without pretending the first delivery represented every cable, duct, control sequence and operational state.

Say what was observed, inferred or referenced.

A graph statement may look equally certain in RDF while having a very different origin. Owner governance should preserve that distinction outside or alongside the core Brick assertions.

External representations do not turn the Brick graph into the source of live values. They help an application locate a representation in another system. Stable graph identity, source-system identity, provenance and effective dates should remain explicit enough for change control.

The result is not the largest possible graph. It is a bounded, testable and explainable subgraph: one in which AHU-3 can be discovered as equipment, traversed through its parts and topology, located in space, connected to points and related to external data without confusing those roles.

A useful graph does not say everything. It says what matters, with accountable edges.