The problem: data you can’t query
Here is a question an owner should be able to answer in seconds: which rooms on the second floor were empty for more than half of yesterday, and did their HVAC set back?
Most buildings already collect the data needed to answer it. Lighting sensors log occupancy, the BMS trends airflow and setpoints, and meters record energy. Yet in most buildings, answering that question takes an engineer a week with a spreadsheet, if it can be answered at all.
The missing ingredient is not data. It is metadata: a machine-readable description of what each point is, where it is, and how it relates to everything else. Brick Schema, Project Haystack and ASHRAE 223P are three ways of providing it. This post explains how they differ, how they fit together, and what to put in a contract so you actually receive usable metadata.
Naming is not metadata
Every building has a point naming convention, or several: L2_RM214_OCC, AHU2-SAT, VAV-2-14 ZN-T. Humans can often guess what these mean. Software cannot, at least not reliably, because:
- Each contractor uses a different convention, and many buildings have three.
- Names encode some facts, such as floor, room and type, but not relationships: which VAV serves Room 214, which lighting zone covers it, which air handler feeds that VAV.
- Names drift. Renovations, replaced controllers and quick fixes leave a trail of exceptions.
- Names rarely carry units, or say whether a value is a sensor reading, a setpoint or a command.
Analytics, fault detection and lighting-to-HVAC integration all need those answers. Without a model, every new application starts with someone mapping points by hand, and that cost is paid again for the next one.
Project Haystack: tags
Project Haystack describes points and equipment with tags: short marker words and values attached to each entity. A zone temperature point might carry tags such as zone, air, temp, sensor and point, plus references to the equipment and site it belongs to. Software queries by tags, for example all occupancy sensor points on this floor, rather than parsing names.
Haystack’s strengths are practicality and adoption. Tags are easy to apply and easy to read, and they are widely used in building analytics and controls. Newer versions add a formal definitions layer, so tags and their combinations have defined meanings. Its traditional weak spot is relationships: references exist, but expressing a full system topology, where this air handler feeds these VAVs that serve these rooms containing these lighting zones, has been less formal than in a graph model.
Brick Schema: a graph
Brick is an open ontology that describes a building as a graph of typed entities and the relationships between them. Equipment, points, locations and systems are classes, such as Occupancy_Sensor or Lighting_Zone, and relationships connect them: an air handler feeds a VAV, a VAV feeds a room, a sensor hasLocation in a room, and equipment hasPoint for each of its points.
Brick’s strength is exactly those relationships. A question like “occupancy status for every room served by AHU-2” becomes a graph query. Because Brick is built on semantic web standards, models can be validated automatically. The tradeoff is that Brick models are harder to author by hand, and the tooling, while maturing, is less familiar to many controls technicians than tags.
ASHRAE 223P: systems and connections
ASHRAE 223P is a proposed standard for semantic models of building systems. It goes deeper than Brick or Haystack on topology: how equipment connects through defined connection points, what flows through those connections, such as air, water or electricity, and how systems are composed from parts. It draws on ideas from both Brick and Haystack, and the three communities have discussed aligning their work.
Status matters here. 223P went to public review in 2025, and at the time of writing its final publication is unconfirmed. We don’t recommend making it a contractual deliverable yet. We do recommend collecting the information it needs, especially which equipment feeds and serves what, because that inventory is the expensive part and it can be converted later.
Side by side
| Project Haystack | Brick Schema | ASHRAE 223P | |
|---|---|---|---|
| Approach | Tags on entities, with defined meanings | Ontology of classes and relationships in a graph | Detailed topology with connection points and flows |
| Strength | Simple; widely used in analytics and controls | Relationships and cross-system queries | Precise system modeling |
| Weak spot | Relationships less formal | Harder to author by hand | Final publication unconfirmed |
| Status | Established | Established and growing | Public review in 2025 |
| Best use today | Tagging points for analytics and fault detection | Whole-building models for integration and analytics | Collect the data now, specify later |
Where MQTT and Sparkplug fit
IoT sensors and newer lighting platforms often publish data over MQTT rather than BACnet. Sparkplug, whose 3.0 version is now an international standard (ISO/IEC 20237:2023), adds structure on top of MQTT: defined topic layouts, payload formats and device state, so a subscriber knows when a device is online and what metrics it reports.
That solves a real problem, but a different one. Sparkplug tells you that a device named occ-214-03 is alive and publishing a value called occupied. It does not tell you that the device sits in Room 214, belongs to a lighting zone, or shares an area with a particular VAV. The building semantics still come from Haystack or Brick. In practice we carry a reference to the model entity in each device’s metadata, so a value arriving over MQTT can be joined to the model the moment it lands.
What this looks like for lighting
Lighting data shows why relationships matter. A single open-office area might involve:
- a lighting zone of 24 luminaires, each with its own occupancy sensor;
- an energy reading per fixture or per zone;
- one VAV box serving most of the area and a second serving the rest;
- a room that the space-planning team knows by a different name than the drawings.
To use that occupancy data for HVAC setback, the integration has to know which fixtures’ sensors fall within each VAV’s area. To use the energy data for measurement and verification, the analytics have to know which fixtures belong to which zone and which meter. To report space utilization, occupancy has to roll up to the room as the space planners know it. Each of those is a relationship. Tags can describe the points; a model like Brick describes how they connect.
What to put in the contract
Metadata almost never appears unless it is a named deliverable with acceptance criteria. Our standard language covers:
- The model. Haystack tags, a Brick model or both, with versions stated.
- Coverage. Which systems are included: lighting zones, sensors and energy points; HVAC equipment and points; meters; spaces.
- Relationships. At minimum: equipment to points, equipment to the spaces it serves, lighting zones to rooms, VAVs to air handlers, and meters to what they measure.
- Naming. A consistent naming convention as a backup for humans, not a substitute for the model.
- Units and kinds. Every point states its units and whether it is a sensor, setpoint or command.
- Format and delivery. Machine-readable files at closeout, updated after every change.
- Validation. The model is checked against the schema and spot-checked in the field: random points are traced to the real device, location and relationship.
- Ownership. The owner owns the model and can hand it to any future vendor.
A representative scenario: a clinic campus
Consider a representative outpatient campus in North Mississippi: three buildings of different ages, BMS controllers from two contractors, a newer networked lighting system in one building, and electric meters on each main service. The owner wants to compare energy across the buildings and use lighting occupancy to set back HVAC in the exam suites.
Without a model, each of those goals is a custom mapping project. With one, they become queries. We would inventory and tag points in all three buildings with Haystack, generate a Brick model with the relationships the HVAC integration and analytics need, validate both against the field, and keep them in Lytbit Ledger beside the data. When the owner adds a fourth building, its points join the same model instead of starting a new spreadsheet.
What we’d do
- Pick the model your software consumes. For most owners today that means Haystack tags, a Brick model, or both generated from one validated inventory.
- Tag during commissioning, not after. The person verifying that a sensor works in Room 214 is the right person to confirm its tags and relationships.
- Collect topology now. Even without specifying 223P, record what feeds what. It is the hardest information to rebuild later.
- Validate against reality. Spot-check the model in the field at closeout, and again after every renovation.
- Keep it with your data. Our energy analytics work and Lytbit Ledger use the model directly, and you can export it whenever you like. It is your data.
Where to start
If your building has plenty of data and few answers, our IoT hardware integration service builds the point inventory, applies Haystack and Brick models, and validates them in the field, so your next application doesn’t start from scratch.
Filed under: Brick Schema · Project Haystack · ASHRAE 223P · building data · metadata
