Stage Your Building Data into a Clean Brick Model
Brick Schema staging is the step the standards documentation skips: turning a raw BACnet scrape, BMS export and pile of Haystack tags into a validated Brick model — before it loads into your analytics, fault-detection or digital-twin platform. Adopting Brick isn't a modelling problem. It's a data problem.
Why Brick Models Stall
Real building data does not arrive Brick-shaped. The mapping-and-cleaning step is where projects get stuck.
Loading Blind
- Cryptic BACnet points mapped by hand in spreadsheets
- Containment and connectivity collapsed into one tree
- Errors surface in the analytics platform, not before
- Every bad mapping propagates into downstream rules
Staging into Brick
- Points classified to Brick types in a reviewable workflow
- Spatial and flow graphs modelled separately
- Validated against the ontology before export
- A clean Turtle / JSON-LD model loads with confidence
From BACnet Scrape to Validated Brick Model
A structured, auditable path — not a hand-edited spreadsheet
1. Inventory the Sources
Bring together the BACnet point scrape, controls contractor's equipment schedule, BMS export and any existing Haystack tags. Expect them to conflict.
2. Classify to Brick
Map every point, piece of equipment and location to its Brick class visually — the bulk of the effort, and the step most worth doing in a reviewable way.
3. Build Both Graphs
Establish containment (isPartOf, isLocatedIn) and connectivity (feeds) as separate, typed relationships. Don't collapse them into one tree.
4. Validate
Run the model against Brick's SHACL shapes and fix errors in bulk before export — not one at a time after load.
5. Export & Load
Produce Turtle or JSON-LD and hand a validated model to your analytics, FDD or digital-twin platform — with a full audit trail.
Two Graphs, Not One Tree
The structural decision that makes or breaks a Brick model
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 chiller routinely participates in both at once. A staging tool that allows only one parent per asset forces you to throw away half the graph. AssetStage supports multiple, typed parent relationships per node — so it represents the spatial and flow membership a Brick model actually requires. The same capability that stages a Maximo network hierarchy or a linear asset network stages a Brick model.
Brick vs Haystack vs RealEstateCore
Where Brick fits — and why you don't have to discard your Haystack tags
Project Haystack is a lightweight tagging convention — widespread in building automation and easy to apply to BACnet point lists, but looser structure makes automated reasoning harder. Brick is a richer, formally-structured RDF ontology better suited to analytics and digital twins. As of Brick 1.4, RealEstateCore ships inside the Brick distribution, so choosing Brick no longer means betting against real estate's preferred vocabulary.
Many sites are tagged in Haystack today, so interoperability matters. AssetStage ingests Haystack tags as a source and maps them into a validated Brick model — your existing work is reused, not thrown away.
Upstream of Your Platform
Stage once, export a clean model to whatever consumes it
AssetStage sits upstream of your analytics, fault-detection and digital-twin tools — not inside any one of them. Build and validate the model once, export it as standard Turtle or JSON-LD, and load it wherever it needs to go. The same workspace handles a building's Brick model, a fleet's SFI hierarchy or a plant's ISO 14224 taxonomy.
Ready to Stage Your Brick Model?
See how AssetStage turns a messy BACnet export into a validated, loadable Brick model — visually, collaboratively, with a full audit trail.