If you're modelling building data, two names come up immediately: Project Haystack and the Brick Schema. They overlap enough to look like competitors and differ enough that picking the wrong one for your use case is a real cost. This is the practical comparison — what each is actually good at, where they clash, and why the honest answer is usually "both, in sequence."
The core difference: tags vs an ontology
Project Haystack is a tagging convention. You describe an entity by attaching tags to it — ahu, discharge, air, temp, sensor — and the meaning emerges from the combination. It's lightweight, it maps naturally onto BACnet point lists, and a controls engineer can start applying it in an afternoon. That low barrier is exactly why it spread so widely through the building-automation world.
Brick is a formal ontology. It's built on RDF, defines explicit classes (Air_Handling_Unit, Zone_Air_Temperature_Sensor) and typed relationships between them (feeds, hasPoint, isPartOf), and you query it with SPARQL. It carries more structure up front, and that structure is what makes automated reasoning reliable.
The trade-off is the whole story: Haystack's looseness makes it fast to apply and harder to compute over; Brick's rigour makes it slower to build and far more queryable.
Where each one wins
Haystack is the better fit when:
- you're tagging a large estate of existing BACnet points quickly
- the consuming tools already speak Haystack (much of the BAS/analytics vendor world does)
- you need something a controls contractor can apply on site without ontology expertise
Brick is the better fit when:
- you're driving analytics, fault detection or a digital twin that needs to reason about structure — "find every VAV downstream of this AHU," "every chilled-water sensor in this zone"
- you need portability: the same rule running unchanged across many buildings
- you need a model you can validate automatically (Brick ships SHACL shapes; a model can be checked for structural correctness rather than eyeballed)
The dividing line is roughly: Haystack describes; Brick reasons. If your endgame is dashboards fed by clearly-named points, Haystack may be enough. If your endgame is portable analytics or a twin, the typed relationships in Brick are doing work tags can't.
The RealEstateCore question is mostly settled
For years there was a third name in the room — RealEstateCore, an ontology focused on commercial real estate and portfolio-level concerns — and a genuine "which standard do we bet on?" anxiety.
As of Brick 1.4, that's largely resolved: RealEstateCore has converged into the Brick distribution. Choosing Brick no longer means betting against real estate's preferred vocabulary, which removes one of the bigger reasons teams used to stall before committing.
You usually don't have to choose
Here's the part that dissolves most of the debate: these aren't mutually exclusive, and the real world is already messy. Many sites are tagged in Haystack today. That existing work is an asset, not an obstacle.
A good building-data staging workflow ingests Haystack tags as a source and maps them into a validated Brick model — alongside the raw BACnet scrape and the equipment schedules. You keep the speed and ubiquity of Haystack at the point of capture, and you get the reasoning power and validation of Brick where the analytics live. The migration isn't "rip out Haystack"; it's "promote what Haystack captured into something a twin can compute over."
That's why the choice rarely has to be made blind. The hard part was never the ontology — it was getting messy source data into clean shape, and that staging step is the same whichever target you land on.
The short version
- Haystack — a tagging convention. Fast, widespread, light. Best for quick tagging of existing points and Haystack-native tools.
- Brick — a formal ontology. Richer, queryable, validatable. Best for analytics, fault detection and digital twins that need to reason about structure.
- RealEstateCore — folded into Brick as of 1.4; no longer a separate bet.
- In practice — ingest Haystack tags and stage them into a validated Brick model. It's a sequence, not a fork in the road.
Working out how to get from Haystack tags to a clean Brick model? See Brick Schema staging, explore the smart-buildings approach, or get in touch.