Brick Schema

The naming problem

Every building management system (BMS) has its own naming conventions. Here are three names for the exact same physical thing, a temperature sensor measuring supply air from an air handling unit:

BMS / System	BMS point name
One Pool Street, Trend IQ	`AHU1_SAT`
One Pool Street, Siemens Desigo	`Supply_Air_Temp_AHU_01`
One Pool Street, BACnet export	`SA-T-1`

If you’re building a dashboard, an analytics pipeline, or an AI agent, you need to understand what each point means. Even within a single building like One Pool Street, different subsystems use different conventions. Across a portfolio it’s impossible to manage manually.

What Brick does

Brick Schema is an open-source ontology that gives building data a shared vocabulary. It solves the naming problem by providing:

Canonical class names: Supply_Air_Temperature_Sensor instead of vendor-specific abbreviations
A class hierarchy: Supply_Air_Temperature_Sensor is a kind of Temperature_Sensor, which is a kind of Sensor, which is a kind of Point
Typed relationships: equipment feeds other equipment, sensors are pointOf equipment, zones are partOf floors

The class hierarchy

Point
└── Sensor
    └── Temperature_Sensor
        ├── Supply_Air_Temperature_Sensor
        ├── Return_Air_Temperature_Sensor
        ├── Zone_Air_Temperature_Sensor
        ├── Chilled_Water_Temperature_Sensor
        └── Outside_Air_Temperature_Sensor

When you query for Temperature_Sensor, you get all five subtypes. When you query for Sensor, you get temperature sensors plus humidity sensors, pressure sensors, CO2 sensors, and everything else. The hierarchy does the filtering for you.

Relationships

Chiller
  └── feeds → AHU
                ├── hasPoint → Supply_Air_Temperature_Sensor
                ├── hasPoint → Return_Air_Temperature_Sensor
                └── feeds → VAV
                              ├── hasPoint → Zone_Air_Temperature_Sensor
                              └── feeds → HVAC_Zone
                                            └── isPartOf → Floor

Relationships capture how equipment connects. A chiller feeds an AHU, which feeds VAV boxes, which feed zones. This chain is what enables upstream/downstream traversal. You can ask “what is upstream of Zone 3?” and get the full equipment chain without knowing how deep it goes.

How Tacit uses Brick

Tacit maps every building’s raw BMS data to Brick classes and relationships. Once mapped, the same query works on any building:

# This query works on ANY building in your portfolio
{
  equipment(siteId: "your-site-id", is: "HVAC_Equipment") {
    name
    type
    points(is: "Temperature_Sensor") {
      type
      timeseriesId
      currentValue { value timestamp quality }
    }
  }
}

The is argument triggers class hierarchy inference. HVAC_Equipment matches air handling units, variable air volume boxes, chillers, boilers, fan coil units, and every other HVAC equipment type in the Brick hierarchy. You don’t need to list them.

Three capabilities that matter

Brick, combined with Tacit’s API, gives you three capabilities that no other building data platform offers:

1. Class hierarchy inference

Query a parent class and automatically match all subtypes.

# Matches AHUs, VAVs, chillers, boilers, FCUs, heat pumps...
equipment(is: "HVAC_Equipment") { ... }

# Matches supply temp, return temp, zone temp, OAT, CHW temp...
points(is: "Temperature_Sensor") { ... }

Learn more: Class hierarchy

2. Transitive traversal

Follow equipment chains to any depth without recursive API calls.

# Returns the full chain: VAV → AHU → Chiller
zone(name: "Library") {
  upstream {
    name
    type
  }
}

Learn more: Relationships and traversal

3. Pattern matching

Find things by relationship shape, not by ID. Combine type filters, relationship traversals, and value conditions in a single query.

# "Temperature sensors on AHUs, and what they feed"
{
  equipment(siteId: "site-id", is: "AHU") {
    name
    points(is: "Temperature_Sensor") {
      currentValue { value timestamp quality }
    }
    feeds {
      name
      type
    }
  }
}

Learn more: Relationships and traversal

Why not use Brick/SPARQL directly?

Brick data is stored as RDF (Resource Description Framework) and traditionally queried with SPARQL. SPARQL is powerful but hostile to most developers:

SELECT ?ahu ?sat_val WHERE {
  ?ahu a/rdfs:subClassOf* brick:Air_Handling_Unit .
  ?ahu brick:hasPoint ?sat .
  ?sat a/rdfs:subClassOf* brick:Supply_Air_Temperature_Sensor .
  ?sat brick:timeseries ?sat_ts .
  ?sat_ts brick:hasValue ?sat_val .
}

This query does the same thing as the GraphQL example above. The concepts are identical: class hierarchy, relationships, pattern matching. The interface is the problem. Tacit preserves the concepts and replaces the interface. You get SPARQL’s power through GraphQL’s developer experience.

Getting started

Core concepts

Guides

Brick Schema

The naming problem

What Brick does

The class hierarchy

Relationships

How Tacit uses Brick

Three capabilities that matter

1. Class hierarchy inference

2. Transitive traversal

3. Pattern matching

Why not use Brick/SPARQL directly?

Next steps

Buildings and points

Class hierarchy

​The naming problem

​What Brick does

​The class hierarchy

​Relationships

​How Tacit uses Brick

​Three capabilities that matter

​1. Class hierarchy inference

​2. Transitive traversal

​3. Pattern matching

​Why not use Brick/SPARQL directly?

​Next steps

Buildings and points

Class hierarchy

The naming problem

What Brick does

The class hierarchy

Relationships

How Tacit uses Brick

Three capabilities that matter

1. Class hierarchy inference

2. Transitive traversal

3. Pattern matching

Why not use Brick/SPARQL directly?

Next steps