Brick vs Project Haystack: Semantic Tagging for Building Data

Photo: Industrial pipes and machinery in a plant room. Photo by Dave Meckler on Unsplash.

A BMS point list is names and addresses. It is not meaning. AHU3_SAT, register 40012 and a BACnet Analog Input instance all move a number. None of them tell an analytics engine, an FDD rule or a portable app that the number is zone discharge air temperature on a specific air-handling unit.

Semantic tagging is how you close that gap. Two open efforts dominate the conversation: Project Haystack and Brick Schema. People search "brick vs haystack" because the job looks similar on a slide deck and diverges the moment you model a messy estate. This article compares the two for operators and integrators who already have points flowing and need those points to mean the same thing in the next building.

Neither scheme replaces BACnet, Modbus or OPC UA. Those protocols move values. Tagging names what the values mean. Readable BACnet point naming still helps humans at the workstation. Tags and ontologies help machines across sites.

Why point names alone are not enough

Controls engineers ship the names they need to commission and hand over. Portfolio tools inherit those names years later, often after two vendor swaps and a spreadsheet that no longer matches the live objects.

Short labels collide. SAT might be supply air, mixed air or a spare. The same physical idea shows up as SA_TEMP, TEMP_SA and DischargeAirTemp across three sites. Mapping cost rises first. False fault rules follow when a template binds to the wrong twin. Cross-building apps stall because there is no shared vocabulary for "this sensor belongs to that AHU and feeds that zone."

A protocol object model helps inside one standard. BACnet already carries object type and some properties. Modbus still gives you a register and a PDF. Neither gives you a portable equipment graph that says AHU-3 feeds Floor-2 and has a discharge-air temperature point. That graph is what semantic tagging is for.

What Project Haystack is

Project Haystack is an open-source initiative for semantic data models and related web services around building and IoT operational data. In practice most engineers meet it as a tagging system: markers such as ahu, discharge, air, temp and sensor applied to entities so meaning emerges from the combination.

That design is deliberate. Tags are lightweight. A controls engineer can mark points without learning RDF, OWL or SPARQL. Where a site already exposes a Haystack API, or where the estate standard already expects Haystack markers, the path from "points exist" to "points are queryable by tag" is short.

The trade-off is consistency. Because combinations are flexible, two sites can encode the same plant differently and both look valid under local habit. Brick's own comparison notes that Haystack-style descriptions often become ad-hoc collections of tags with custom modelling practices across buildings. Haystack still ships widely where the tooling and APIs already speak it. Do not confuse Project Haystack with MIT Haystack, the unrelated NLP research project.

What Brick Schema is

Brick Schema is a formal RDF ontology for buildings. Equipment, points, locations and relationships are typed classes, not only free tags. Relationships such as feeds, hasPoint and isPartOf are first-class: you can state that an AHU feeds a zone and that the zone has a temperature sensor, then query that structure.

Brick includes a tagging layer that looks familiar if you already know Haystack-style markers, then adds formal semantic rules on top so models stay more consistent and interpretable. Because it sits on the Semantic Web stack, you can query it with SPARQL and validate against the ontology rather than against tribal spreadsheet rules alone.

That formality is the cost. Modelling takes longer on a messy existing point list. You gain portable analytics, stronger validation and queries that reason across buildings instead of only filtering tag sets. Brick's documentation positions it against Haystack, BIM/IFC and related efforts such as BOT; the short version for operators is classes plus relationships plus queryability.

Side-by-side: Brick vs Project Haystack

Brick vs Haystack is not a protocol contest. Both sit above the wire. Both can coexist with estate naming conventions. The comparison that matters is structure and query power versus speed of application on messy points.

When Haystack fits vs when Brick fits

Choose Project Haystack when the estate already speaks Haystack, when the priority is tagging points quickly so local apps can filter, and when the team living in the plant room thinks in markers rather than ontologies. Tag-and-ship wins on speed.

Choose Brick Schema when portable analytics and FDD templates must travel building to building, when you need typed relationships you can validate, and when SPARQL-style questions ("every discharge air temp on AHUs that feed occupied zones") are the product, not a one-off report. Reason-and-port wins on queryability.

Many portfolios sit in the middle: Haystack markers already exist on some sites, Brick-shaped models are the target for new analytics. Migrating is work. Declaring a universal winner is marketing. Match the scheme to the job you are hiring it for.

For estate-wide fault ranking once points carry meaning, see BMS analytics and portfolio BMS analytics.

Units: why QUDT shows up next to Brick

A tagged temperature point that does not declare its unit is still half-finished. Degrees Celsius and Fahrenheit look alike until a portfolio rule multiplies the wrong scale. QUDT (Quantities, Units, Dimensions and Types) is a units ontology that often accompanies Brick models so quantity kinds and units are machine-readable, not buried in a point name suffix.

Brick classes describe equipment and points. QUDT describes the unit of the measurement. Together they reduce silent unit bugs when an analytics layer compares sites. Haystack estates also carry unit conventions; the Brick + QUDT pairing is simply the combination Explore uses when ontology tagging is enabled.

How Explore uses Brick and QUDT

FrostLogic Explore is Sensor Intelligence: it reads the BMS and meters you already run and ranks what to fix. It is not a CMMS and not a BAS replacement. Write access starts off; you grant scopes when you want write-back.

Universal ontology tagging is opt-in per tenant. When enabled, Explore labels points with Brick Schema equipment and point types and QUDT units, using a text classifier plus an LLM second pass. Humans finalize those tags. Only finalized tags reach the AI. Training learns from corrections.

Explore is not a Haystack server and does not replace Haystack estates that already work. The bridge for teams who need portable analytics on messy BMS points is human-finalised Brick + QUDT tagging on top of the protocols you already speak. If your question is which wire protocol to keep, start with the integrator guide to BACnet, Modbus and OPC UA. If your question is how meaning sits above those wires, Brick vs Project Haystack is the fork.

FAQ

What is the difference between Brick Schema and Project Haystack? Project Haystack is primarily a lightweight tagging system where meaning emerges from tag combinations. Brick Schema is a formal RDF ontology with typed classes and relationships, queryable with SPARQL. Both name building data; they differ in structure, consistency rules and how you query them.

Does Brick or Haystack replace BACnet? No. BACnet, Modbus and OPC UA move values between controllers, meters and head-ends. Brick and Haystack describe what those values mean. You still need a working protocol stack underneath any tagging scheme.

Is Project Haystack the same as MIT Haystack? No. Project Haystack is the building and IoT semantic tagging initiative at project-haystack.org. MIT Haystack is a separate natural-language processing research project. They share a name, not a purpose.

When should I use Haystack instead of Brick? Prefer Haystack when you need to tag messy existing points quickly, when Haystack APIs or tooling are already on site, and when local filter-by-tag workflows matter more than formal cross-building ontology queries.

When should I use Brick instead of Haystack? Prefer Brick when portable analytics, typed relationships and SPARQL queries across buildings are the goal, and when you can invest in ontology modelling and validation rather than only fast tag application.

What is QUDT and why pair it with Brick? QUDT is a units and quantities ontology. Paired with Brick it makes measurement units machine-readable so portfolio rules do not silently mix incompatible scales. Explore's opt-in ontology tagging uses Brick types with QUDT units.

Can I use Brick and Haystack on the same estate? Yes in principle: some sites carry Haystack tags while analytics targets a Brick-shaped model. Plan the mapping work explicitly. Do not assume the two encodings are interchangeable without a translation step.

How does FrostLogic Explore use Brick? Opt-in universal ontology tagging labels points with Brick Schema types and QUDT units; humans finalize tags before they reach the AI. Explore does not market itself as a Haystack product or as a replacement for working Haystack deployments.

What's your building not telling you?

If your points move but your analytics still guesses what they mean, tell us how the estate is tagged today. We listen first, then say straight whether Explore's Brick + QUDT path helps. 30 or 60 minutes, your pick. No commitment either way. Talk it through.