Brick Schema

The universal translator for building data. How Tacit uses Brick to make every building queryable with the same API.

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:

1. Canonical class names: Supply_Air_Temperature_Sensor instead of vendor-specific abbreviations
2. 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
3. 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.

Next steps

Buildings and points

Learn the core data model that Brick enables.

Class hierarchy

Deep dive into how type inference works in the API.