Brick Schema Explained: How to Model and Stage Building Data
How Brick models buildings, how it compares to Haystack, and how to stage messy source data into a clean, validated Brick model.
Read article →Turn raw BACnet scrapes, BMS exports and Haystack tags into a validated Brick Schema model — with the spatial and connectivity relationships your analytics, FDD and digital-twin platforms actually need.
Common obstacles teams face when managing CMMS data in smart buildings
A raw BACnet scrape arrives as thousands of cryptic point names with no consistent convention. Every point has to be classified to the right Brick type before any analytics rule can run against it.
A Brick model needs two separate graphs at once: where equipment lives (spatial containment) and what feeds what (flow connectivity). A single-parent tree throws half the model away.
The BACnet list, the controls contractor’s equipment schedule, the BMS export and the as-built drawings rarely agree. Reconciling them by hand in spreadsheets is slow and error-prone.
Many sites are already tagged in Project Haystack. Moving to Brick means ingesting those tags and mapping them into a richer, formally-structured ontology without losing what’s there.
Loading a malformed model into a live analytics or twin platform propagates errors into every downstream rule and dashboard. Models must validate against Brick’s SHACL shapes first.
For the same fault-detection rule or energy query to run across every building, each site has to be modelled to the same standard — not to each vendor’s naming conventions.
Purpose-built solutions for smart buildings maintenance teams
Pull together BACnet scrapes, equipment schedules, BMS exports and existing Haystack tags into one working layer — then reconcile the conflicts visually instead of in colour-coded spreadsheets.
Map every point, piece of equipment and location to its Brick class in a reviewable, visual workflow rather than by hand. The mapping step is the bulk of the effort — and the step most worth getting right once.
AssetStage supports multiple, typed parent relationships per node, so it represents spatial containment (isPartOf, isLocatedIn) and flow connectivity (feeds) at the same time — exactly what a Brick model, a Maximo network hierarchy or a linear asset network requires.
Fix errors in bulk and validate against the ontology before export. Hand a clean, validated model — as Turtle or JSON-LD — to your analytics, FDD or digital-twin platform, with a full audit trail.
Built-in support for smart buildings standards
An open-source RDF ontology for buildings — equipment, points and locations with typed, many-to-many relationships, validated with SHACL and queried with SPARQL. RealEstateCore is folded in from version 1.4.
Learn more →The widespread tagging convention for building-automation data. AssetStage ingests Haystack tags as a source and maps them into a richer Brick model so existing work is reused, not discarded.
Native support for the raw point scrapes and building-management-system exports that real projects start from — the messy inputs that have to become a structured, loadable model.
Learn more about CMMS data in smart buildings
How Brick models buildings, how it compares to Haystack, and how to stage messy source data into a clean, validated Brick model.
Read article →The staging discipline behind a clean Brick model — why the best implementations never load data straight into production.
Read article →How to structure equipment, locations and systems into a hierarchy that downstream platforms can actually use.
Read article →See how AssetStage helps smart buildings teams clean, validate, and prepare maintenance data in weeks, not months.
See how AssetStage helps teams across sectors