Brick Schema Explained: How to Model and Stage Building Data

The Brick Schema is an open-source ontology for describing the assets, sensors and spaces inside a building and the relationships between them. It gives building data a common vocabulary, so analytics, fault detection and digital-twin platforms can understand any building's data without bespoke integration work for each site. This guide explains how Brick is structured, how it compares to the alternatives, and — the part most teams underestimate — how to get your existing data into it cleanly.

What is the Brick Schema?

Brick came out of academic research in the mid-2010s and is now maintained as a community standard, with RealEstateCore (the other major real-estate ontology) folded in from version 1.4 onward. The current releases sit in the 1.4.x line.

At its core, Brick is three things: a dictionary of standard terms for the equipment, points and locations you find in buildings; a set of relationships for connecting those terms together; and a flexible data model that lets you attach this metadata to your existing systems. It is built on RDF, the same graph-based data model behind much of the semantic web, and Brick models are queried with SPARQL.

The practical payoff is portability. If two buildings are both described in Brick, the same fault-detection rule, energy-analytics query or twin configuration runs against both without rewriting it for each site's naming conventions. That is the whole point: Brick turns idiosyncratic, vendor-specific building data into something consistent and machine-readable.

How a Brick model is structured

A Brick model describes a building as a graph. Three families of entity do most of the work:

Equipment — the physical plant: air handling units, chillers, boilers, pumps, VAV boxes, fans, meters.

Points — the data sources and control objects associated with equipment: sensors, setpoints, commands, alarms and status points. A temperature sensor, a fan-speed command and a high-pressure alarm are all points.

Locations — the spatial structure: sites, buildings, floors, rooms, HVAC zones.

What makes Brick more expressive than a simple equipment list is its typed relationships. Rather than one generic "belongs to" link, Brick distinguishes what kind of connection exists between two things:

• hasPoint / isPointOf ties a sensor or setpoint to the equipment it measures or controls.
• hasPart / isPartOf captures composition — a VAV box is part of an air-handling system.
• feeds / isFedBy captures flow and connectivity — an AHU feeds the VAVs downstream of it.
• hasLocation / isLocatedIn ties equipment and points to spaces.

Because these relationships are typed and many-to-many, a single chiller can sit in a spatial containment graph and a separate "what feeds what" connectivity graph at the same time. That dual membership is exactly what a flat asset list or a single-parent tree cannot represent — and it is the detail that trips up most first attempts at a Brick model.

Brick also ships SHACL shapes, which means a model can be validated automatically against the ontology's rules rather than checked by hand. A valid model isn't just well-spelled; it's structurally correct.

Brick vs Haystack vs RealEstateCore

If you're evaluating Brick, you'll quickly meet two neighbours.

Project Haystack is a tagging convention rather than a formal ontology. It's widespread in the building-automation world, lightweight, and easy to apply to BACnet point lists — but its looser structure makes some kinds of automated reasoning harder. Many real sites are tagged in Haystack today, so interoperability with it matters in practice.

RealEstateCore was a parallel ontology focused on commercial real estate and portfolio-level concerns. As of Brick 1.4, the two have effectively converged — RealEstateCore now ships inside the Brick distribution — which removes a long-standing "which standard do we pick?" headache.

The short version: Haystack is the pragmatic incumbent for tagging; Brick is the richer, more queryable model for analytics and twins; and the Brick/RealEstateCore merger means choosing Brick no longer means betting against real estate's preferred vocabulary.

The hard part: getting your data into Brick

Here's what the standards documentation tends to gloss over. Adopting Brick isn't really a modelling problem — it's a data problem.

Real building data does not arrive Brick-shaped. It arrives as a raw BACnet point scrape with cryptic abbreviations, a controls contractor's equipment schedule, a spreadsheet exported from a building-management system, and a set of as-built drawings that disagree with all three. Before any analytics or twin platform can consume it, every point has to be classified to the right Brick type, every piece of equipment related to its points and its parent systems, and every location placed in the spatial graph — and the whole thing has to validate.

That mapping-and-cleaning step is where Brick projects stall. It's slow, it's error-prone, and a mistake made here propagates into every downstream rule and dashboard. Loading a malformed model straight into your production analytics platform is the building-data equivalent of pushing untested data into a live CMMS: expensive to unpick after the fact.

This is fundamentally a staging problem — the same pattern we see across CMMS and asset-management projects, and the reason asset data staging exists as a discipline. You want a working layer where messy source data is transformed, validated and corrected before it loads into the system of record. Brick is just another target model that benefits from being staged into rather than loaded into blind.

Why hierarchies make or break a Brick model

The single biggest structural decision in a Brick model is getting the relationship graph right — and this is where containment and connectivity have to be kept separate.

Containment answers "where does this live / what is it part of." Connectivity answers "what feeds what." In Brick these are different relationship types, and the same asset routinely participates in both at once. A staging approach that can only model one parent per asset — a strict tree — forces you to throw away half the graph. To stage building data for Brick properly, your working model has to support multiple, typed parent relationships per node: spatial and flow membership simultaneously.

This is the same capability that linear and networked industrial assets demand — a pipeline, a power network or an HVAC distribution system is a connectivity graph with branches, not a tidy tree. Get multi-parent, typed relationships right once, and the same engine that stages a Maximo network hierarchy can stage a Brick model.

A practical path to a clean Brick model

1. Inventory the sources. Pull together the BACnet scrape, equipment schedules, BMS exports and any existing Haystack tags. Expect them to conflict.
2. Map to Brick classes. Classify each point and asset to its Brick type. This is the bulk of the effort and the step most worth doing in a visual, reviewable way rather than by hand in a spreadsheet.
3. Build the relationships — both graphs. Establish containment (isPartOf, isLocatedIn) and connectivity (feeds) as separate, typed relationships. Don't collapse them.
4. Validate against the ontology. Run the model against Brick's SHACL shapes and fix errors in bulk before export, not one at a time after load.
5. Export and load. Produce Turtle or JSON-LD and hand a validated model to your analytics, FDD or twin platform.

The order matters. Validation and correction belong in a staging layer, not in your production platform after the fact.

Where staging fits

AssetStage is a visual, collaborative staging layer for exactly this kind of work, and staging data for smart buildings is one of the things it's built for: import messy source data, build and review the model visually, validate in real time, fix errors in bulk, and keep a full audit trail — before anything loads into the system of record. Its support for multiple, typed parent relationships means it can represent the containment-and-connectivity graphs that a Brick model (or a Maximo network hierarchy, or a linear asset network) actually requires, rather than flattening them into a single tree.

If you're staring at a BACnet export wondering how it ever becomes a clean Brick model, that gap — from raw source data to validated, loadable model — is the problem worth solving first. That's exactly what Brick Schema staging is for.

---

Want to see how visual staging handles a real building or asset hierarchy? Get in touch or explore what asset data staging means for the wider picture.