Most commercial buildings already collect thousands of data points from the building management system, yet the labels on those points are often abbreviations only the original programmer understands. Brick schema gives that data a shared, machine-readable meaning, so analytics, dashboards, and maintenance tools can ask the same question and get the same answer. This guide explains how Brick works, how it compares with Haystack, and how facility teams can connect a semantic model to maintenance management software that turns insight into work orders.
Brick Schema: Semantic Building Data Model for FM
Brick converts cryptic BMS point names into a structured model of equipment, sensors, locations, and relationships. See how it differs from Haystack, where adoption is heading, and how facility teams can tie the model to real maintenance execution.
Why Facility Data Needs a Semantic Layer
A typical portfolio runs several BMS brands, and each integrator names points differently. One site writes SAT, another DAT, a third SA-TEMP, all meaning supply or discharge air temperature.
Without a semantic model
- Point names follow the installer's habits
- Every analytics project begins with manual mapping
- Relationships between equipment live in drawings and memory
- Dashboards break when a controller is replaced
- Moving to a new vendor means rebuilding everything
With a Brick model
- Every point has a defined class and a defined parent
- Applications query the model instead of guessing names
- Feeds, serves, and location relationships are explicit
- Replacing hardware leaves the model intact
- The same logic can be reused across buildings
The hidden maintenance cost of unlabeled data
For a maintenance team, bad metadata shows up as slow troubleshooting. A technician sees an alarm on a point and cannot tell which unit it belongs to, what it serves, or what else is affected.
- Alarm triage takes longer because context must be rebuilt by hand
- Impact analysis depends on whoever remembers the system layout
- Fault detection rules cannot be copied between sites
- Asset records and control points drift out of sync
What Brick Schema Actually Is
Brick is an open-source semantic metadata schema for buildings. It defines a vocabulary and a set of relationships, expressed with web-standard semantic technologies (RDF and OWL), so a building can be described as a connected graph.
Reading a building as a graph
Because the model is a graph, you can ask questions in a query language called SPARQL. For example: which air handlers serve this floor, and which of their sensors report supply air temperature?
- Air Handling Unit 3 hasPoint Supply Air Temperature Sensor
- Air Handling Unit 3 hasPoint Supply Fan Status
- VAV Box 204 hasPoint Zone Air Temperature Sensor
Brick vs Haystack: The Practical Differences
Both approaches solve the same problem: labeling building data so software can understand it. They get there differently, and the difference matters when you plan tooling and staffing.
| Dimension | Brick | Haystack |
|---|---|---|
| Modeling approach | Formal ontology with defined classes and relationships | Tagging model where meaning comes from combining tags |
| Foundation | RDF and OWL semantic web standards | Tag definitions, with a defs layer in recent versions |
| Relationships | First-class, named, and queryable as a graph | Expressed through reference tags between entities |
| Flexibility | Stricter, so consistency is easier to validate | Looser, so it is faster to apply but easier to vary |
| Query style | SPARQL and graph tooling | Haystack filter syntax and vendor APIs |
| Learning curve | Steeper for teams new to semantic web concepts | Gentler for people used to tagging controls points |
| Typical fit | Research, analytics platforms, portfolio data layers | Controls vendors, field tools, operational platforms |
A fair reading of the comparison
Neither is simply better. Brick favors rigor and cross-system queries. Haystack favors speed of adoption in the field, and its community has strong controls-vendor involvement.
- Brick tends to reward teams that will build a central data layer
- Haystack tends to reward teams working inside vendor platforms that already speak it
- Both can be mapped to each other, though conversion is never perfectly lossless
Adoption Trend: From Competition to Convergence
The most useful trend for facility teams is not one standard winning. It is the growing set of tools that translate between standards, so your investment in clean metadata survives a change of platform.
Check current release notes and vendor support lists before committing. Adoption details change quickly, and your platform vendors matter more than any headline.
How FM Teams Should Choose
Skip the philosophical debate. Decide based on who will build, maintain, and consume the model over the next five years.
Lean toward Brick when
- You are building a central data platform across many sites
- You need relationship queries such as upstream impact analysis
- You have data engineering support or an analytics partner
- You want strict validation of model quality
Lean toward Haystack when
- Your controls vendor and field tools already use it
- Technicians need to tag points quickly during commissioning
- You prefer a lighter model with minimal semantic web overhead
- Your main goal is point discovery rather than graph analysis
Questions to settle before you start
- Which platforms must read the model on day one?
- Who owns model quality after the integrator leaves?
- Can the model be exported and moved if you change vendors?
- Which use cases come first: fault detection, energy, or maintenance?
- How will new equipment get modeled at handover?
From Semantic Model to Maintenance Action
A model that only feeds dashboards has limited value. The payoff comes when a finding creates work that gets assigned, completed, and recorded against the right asset.
Maintenance use cases a Brick model supports
- Condition-based triggers, such as a rising filter differential pressure creating an inspection task
- Runtime-based preventive maintenance driven by fan or pump status points
- Impact analysis, such as which spaces lose service when a chilled water pump fails
- Reusable fault detection rules that apply to every unit of the same class
- Faster onboarding when a new building joins the portfolio
Where Oxmaint fits
Brick describes what the building is. Maintenance software records what you did about it. The practical bridge is a shared asset identifier between the semantic model and the asset register.
- Asset management keeps equipment hierarchy, location, and history in one record
- Preventive maintenance schedules can follow time, meter, or condition triggers
- Work orders capture the corrective action, parts, labor, and sign-off
- Mobile workflows let technicians complete checklists at the equipment
- Reporting shows repeat failures, completion rates, and backlog by asset type
Give Your Building Data a Place to Become Work
A clean semantic model finds the problem. Oxmaint helps your team schedule, assign, complete, and document the fix against the right asset.
Measuring Whether the Model Is Working
A semantic model is infrastructure, so judge it by what it enables. Track these indicators from the first month.
| Indicator | What it tells you | Healthy direction |
|---|---|---|
| Point mapping coverage | Share of useful points classified correctly | Rising |
| Assets with matching IDs in both systems | How reliably model and maintenance records connect | Rising |
| Time to onboard a new building | How reusable your modeling process is | Falling |
| Fault-generated work orders accepted | Quality of rules and trust in alerts | Rising |
| Time from alarm to diagnosis | Value of context for technicians | Falling |
| Repeat work on the same asset | Whether root causes are being fixed | Falling |
Common mistakes to avoid
- Modeling every point instead of the ones tied to a use case
- Treating the model as a one-time project with no owner
- Skipping unique asset IDs, which breaks every later integration
- Accepting a proprietary export that cannot be moved
- Ignoring handover, so new equipment arrives unmodeled
Brick Schema FAQs
Is Brick a software product?
No. It is an open schema, so any compatible tool can read and write it. You still need software to build, store, and query the model.
Can Brick and Haystack coexist?
Yes. Mapping tools exist, and many portfolios use one in the field and the other centrally. Expect some manual review during conversion.
Do I need Brick before starting preventive maintenance?
No. A clean asset register is the first step, and you can start building one now.
Who should maintain the model?
Assign one named owner, usually in facilities engineering or data. Add model updates to your commissioning and handover checklists.
How do I connect a model to my maintenance workflow?
Use shared asset IDs and define which findings create work orders. You can book a walkthrough to map this to your sites.
Turn Semantic Data Into Completed Maintenance
Start with a reliable asset register, structured work orders, and mobile checklists. Your Brick or Haystack model can then connect to a maintenance process your team already trusts.
