What is the difference between Brick Schema and Project Haystack?

Brick and Project Haystack are both open approaches to describing building equipment, points and spaces so that software can interpret building data consistently. They grew from different starting points, and they have different modelling conventions and communities. Brick models a building as a graph of typed entities joined by explicit relationships, using the RDF data model. Haystack began with tags, short standard labels attached to data, and has since added formal definitions, a taxonomy and an ontology.

Asking which is superior in the abstract gets an owner nowhere. The question that matters is which approach the proposed tools, suppliers and operating team can implement, validate and maintain for the use cases that matter.

"Just tags" versus "a real ontology"

A common shorthand holds that Haystack is just tags while Brick is a real ontology. That undersells current Haystack. Its documentation describes a three-layer semantic model: a vocabulary of formally defined tag terms, a taxonomy that organises those terms into a subtype tree, and an ontology that models more complex relationships. The borrowing runs the other way too. Brick's documentation notes that it takes the concept of tags from Haystack for flexible annotation, while not relying on tags alone to decide what an entity is.

How they differ in practice

Both are still evolving, and ASHRAE's proposed 223P standard, not yet final, is a further option. Comparisons should therefore be made on the versions suppliers actually implement, whatever their brochures say. A supplier may support only part of an approach, or add project-specific conventions that limit reuse.

Put both to the same test

The most revealing evaluation is a practical one. Ask each proposed solution to model the same small sample: one air-handling unit, its terminal units, the zones and rooms they serve, and the relevant meters and points. Run identical queries against each, for example "all supply-air temperature sensors on units serving the third floor", and inspect what comes back. Then look at the validation tools, the export formats, the documentation and the effort needed to add a second building. Finally, ask who in your organisation or supply chain could maintain the model once the supplier has gone.

When a portfolio uses both

Some portfolios end up with both, because different tools favour different approaches. In that case the mapping between them needs defining, and someone needs to maintain it. Translation is not automatically lossless, since one model may hold relationships or extensions the other cannot represent directly.