Data Models: Brick & Haystack

Start with the point that names this lesson: AHU1_SAT. To you it probably reads as 'air handling unit 1, supply air temperature'. But look closer at how much you are supplying that the string does not actually contain. You know SAT means supply-air temperature because you have seen the convention; software has not. You know it is a temperature in degrees, a sensor (not a setpoint or a command), that it belongs to a specific air handler, and that the air handler serves some zone. None of that is in the name. It is a bare string, and every one of those facts lives only in an engineer's head or a spreadsheet somewhere.

Now multiply the problem. The next building calls the same thing AH1-SUPTMP, or SF1DAT, or point 40011 on a Modbus register. There is no universal convention - every vendor, contractor and site invents its own shorthand. So any software that wants to do something useful ('find all the supply-air temperatures and check them against setpoint') has to be told, building by building, by hand, which cryptic name means what. This manual mapping is slow, expensive and error-prone, and it is the single biggest reason analytics and digital twins do not simply port from one building to the next. Worse, the knowledge is fragile: the integrator who decoded those names moves on, the spreadsheet is lost, and a year later nobody can say for certain what point 40011 actually measures. The building's own data becomes unreadable to its owner - an asset that quietly decays into a mystery the moment the people who understood it leave.

The fix is not a better naming convention - people have tried for decades and failed, because no single scheme fits every building. The fix is to attach structured, machine-readable meaning to each point alongside its name: to make the data self-describing. That is exactly what a semantic model does.

A semantic data model describes not just the data but what the data means and how things relate. In building terms, it captures that a given point is a sensor, measuring temperature, of supply air, belonging to AHU-1, which feeds a particular zone. Once that context is explicit and machine-readable, software can reason about the building without a human translating every cryptic tag.

Underneath sits the idea of an ontology - a formal, shared vocabulary of the types of things in a domain and the relationships between them. An ontology for buildings defines the concepts (air handling unit, VAV box, zone, sensor, setpoint, temperature, airflow) and the relationships (has-part, feeds, has-point, serves) so everyone - and every piece of software - uses the same terms to mean the same things. This is what turns a pile of disconnected points into a graph: nodes for equipment, points and spaces, edges for how they connect.

That graph is the payoff. Instead of hard-coding 'point AHU1SAT is the one to watch', an application asks a portable question: find every supply-air-temperature sensor, on any AHU, that serves an occupied zone_. If the building is described with the model, the query just works - here, and in the next building, and the one after. Two open standards have emerged to do exactly this for buildings, from slightly different starting points: Project Haystack and Brick Schema. They are the practical face of the semantic idea, and the reason it is more than theory.

Project Haystack came first from the practitioner world of building automation. Its approach is tagging: you attach a set of descriptive tags to each point - marker tags like sensor, temp, supply, air, plus tags linking it to its equipment and site. Haystack is pragmatic and widely used in the controls and analytics industry; its strength is that it grew from real building data and is comfortable for the engineers who live in it. Its historical looseness - tags could be combined fairly freely - has been tightened in later versions for more consistency.

Brick Schema came more from the academic and research world and is built explicitly as an ontology using semantic-web technology (it expresses buildings as a formal graph of classes and relationships). Brick is precise about types and relationships - this is an AHU, it has-point that sensor, it feeds that zone - which makes it powerful for rich, unambiguous queries and for driving digital twins. Its strength is rigour; the trade-off is that it can feel more formal to author.

The important news is that the two worlds have been converging rather than competing - there is active work to align Haystack and Brick so meaning can move between them, and a building tagged in one can be understood in the other. For a practitioner, the takeaway is not to memorise every tag but to grasp the shared idea: describe building data with an open semantic model so software can understand it. Which standard a given project uses matters less than that it uses one at all - because the alternative is the hand-mapping treadmill that keeps every twin trapped on a single site.

A fair question is where these models sit relative to BIM, which also describes a building. The short answer is that they are complementary and aimed at different moments: BIM describes the designed building - its geometry and components - while Brick and Haystack describe the operational data points and how they relate, so live readings can be understood. BIM can seed some of the structure, but it was never built to make a streaming sensor feed meaningful. Think of the semantic model as the layer that teaches software to read the building's nervous system, where BIM drew its skeleton.

It is easy to file semantic models under 'nice to have' - abstract compared with sensors and dashboards. In fact they are the hinge on which the whole field's scalability turns, and here is why.

A digital twin's value is that software can reason about the building. But software can only reason about data it understands, and a bare point name gives it nothing to understand. Feed a twin a wall of strings like AHU1_SAT and every analytic, every fault rule, every optimisation has to be wired to specific points by hand - which means a twin built for one building is a bespoke, non-transferable artefact. That is precisely why so many twins never spread beyond a flagship site: the meaning was never captured, so nothing ports.

Give the same twin a semantic model and the economics invert. A fault-detection rule written once - 'a supply-air temperature persistently above its setpoint on any AHU suggests a problem' - runs on every building described in the model, because the rule speaks the ontology, not the point names. New analytics, new twins and new tools plug into a building they have never seen and simply work. This is how analytics vendors deploy across thousands of buildings, and how digital twins escape the one-off trap. The models are not decoration; they are the layer that lets everything above them scale. So the practical mandate is blunt: if you want data that outlives its installer and software that ports between buildings, insist that points carry meaning - Brick or Haystack - not just names. It is the least glamorous and most leveraged decision in the whole data stack.