The building graph

The data model

Every building in Tacit follows the same structure, regardless of the underlying BMS vendor or naming convention.

Building
├── Location (Wing)
│   ├── Location (Floor)
│   └── HVAC_Zone
├── Equipment
│   ├── AHU
│   │   ├── Supply_Air_Temperature_Sensor (point)
│   │   ├── Return_Air_Temperature_Sensor (point)
│   │   ├── Supply_Air_Flow_Sensor (point)
│   │   └── Supply_Air_Temperature_Setpoint (point)
│   ├── VAV
│   │   ├── Zone_Air_Temperature_Sensor (point)
│   │   └── Damper_Position_Command (point)
│   └── Chiller
│       ├── Chilled_Water_Supply_Temperature_Sensor (point)
│       └── Chilled_Water_Return_Temperature_Sensor (point)
└── Relationships
    ├── Chiller feeds AHU
    ├── AHU feeds VAV
    ├── VAV feeds HVAC_Zone
    └── HVAC_Zone isPartOf Wing

Five entity types make up the graph: buildings, equipment, points, locations, and zones. Relationships connect them: equipment feeds other equipment, sensors are pointOf equipment, zones are partOf floors.

How Tacit uses Brick

Every building management system (BMS) has its own naming conventions. The same physical sensor might be called AHU1_SAT, Supply_Air_Temp_AHU_01, or SA-T-1 depending on the vendor. Across a portfolio, this is impossible to manage manually. Tacit maps every building’s raw BMS data to Brick Schema, an open-source ontology that gives building data a shared vocabulary. 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 }
    }
  }
}

Brick provides three things that make this possible:

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

Name-based discovery

Every entity can be found by name, no UUIDs required. The name argument does case-insensitive substring matching by default:

# Find buildings by name
{ building(name: "Pool") { id name } }

# Find equipment by name
{ equipment(name: "AHU") { id name type } }

# Find points by name
{ point(name: "SupplyTemp") { name type equipment { name } } }

Use nameMatch: EXACT for precise matches. This works on every entity type and on nested fields too.

Buildings

A building is the top-level container. It has a spatial hierarchy of locations (wings, floors, zones) and contains all equipment, systems, and points for that physical site.

{
  building {
    id
    name
    type
  }
}

Most queries are scoped to a single building by ID.

Equipment

Equipment represents physical devices: air handling units, variable air volume boxes, chillers, boilers, fan coil units, pumps, cooling towers, and more. Each piece of equipment has a type that describes what it is, and a typeHierarchy showing its full class lineage.

{
  equipment(is: "AHU") {
    id
    name
    type
    location { name }
  }
}

Equipment connects to other equipment through feeds relationships, forming chains that represent the physical distribution of air, water, or electricity through a building. Equipment can also have parts (sub-components like fans, dampers, and valves). See relationships and traversal. typeHierarchy returns the full class lineage (leaf to root), e.g. ["AHU", "HVAC_Equipment", "Equipment", "Entity", "Class"]. This is why is: "HVAC_Equipment" matches AHUs.

Points

Points are the leaf nodes of the model: individual sensor readings, actuator commands, and setpoints. A point always belongs to a piece of equipment (or directly to a zone in some cases).

Point category	Description	Examples
Sensors	Measured values from physical sensors	Temperature, humidity, CO2, pressure, flow rate
Setpoints	Target values for control loops	Temperature setpoint, pressure setpoint
Commands	Actuator positions or on/off states	Damper position, valve position, fan on/off
Status	Equipment state feedback	Running status, fault status, mode

{
  equipment(id: "TE01-XX-AHU-001") {
    name
    points {
      name
      type
      unit
    }
  }
}

Each point has a unit (e.g., DEG_C, PA, CFM), a type from the Brick ontology, and an equipmentId linking it back to its parent equipment.

Use currentValue { value timestamp quality } on the Point type for the latest reading. For historical time-range data, use the timeseries REST endpoint with the point’s timeseriesId.

Locations

Locations represent the spatial hierarchy of a building: wings, floors, rooms, and areas. They provide the physical context for where equipment is installed and zones are defined.

{
  building(id: "B001") {
    locations {
      name
      type
      locations {
        name
        type
        equipment(is: "HVAC_Equipment") { name }
      }
    }
  }
}

Zones

Zones represent the spaces that equipment feeds. An HVAC zone is the area controlled by a single terminal unit (like a VAV box). Zones reference locations and are fed by equipment.

{
  zone {
    id
    name
    type
    locations { name }
    fedBy { name type }
  }
}

Cross-cutting queries

The most powerful pattern is querying across the entire building graph without UUIDs:

{
  point(locationName: "Tower East", equipmentIs: "VAV", is: "Temperature_Sensor") {
    name
    type
    unit
    equipment { name type }
  }
}

This returns all temperature sensors on any VAV at or below “Tower East”, joining locations, equipment, and points in one request.

Properties on all entity types

Every entity type carries structured metadata via properties. Buildings, locations, zones, systems, equipment, and points can all have properties:

{
  equipment(id: "TE01-XX-AHU-001") {
    properties { name value unit }
  }
}

Properties return structured objects like controllerName, isVirtual, pointCount, each with a name, value, and optional unit.

The properties available depend on what’s in the Brick model, so not all entities will have properties. Use hasProperty on root queries to filter by property existence.

IFC integration

Entities that come from an IFC (BIM) model carry an ifcId field linking back to the BIM element:

{
  equipment(name: "AHU") {
    name
    ifcId
  }
}

ifcId is null when equipment was created from BMS data rather than an IFC model. Available on Building, Equipment, Location, Zone, and System.

Next steps

Class hierarchy

How is: "HVAC_Equipment" matches all subtypes automatically.

Relationships and traversal

How equipment connects, what it contains, what it feeds, and where it sits.

Getting started

Core concepts

Guides

The building graph

The data model

How Tacit uses Brick

Name-based discovery

Buildings

Equipment

Points

Locations

Zones

Cross-cutting queries

Properties on all entity types

IFC integration

Next steps

Class hierarchy

Relationships and traversal

​The data model

​How Tacit uses Brick

​Name-based discovery

​Buildings

​Equipment

​Points

​Locations

​Zones

​Cross-cutting queries

​Properties on all entity types

​IFC integration

​Next steps

Class hierarchy

Relationships and traversal

The data model

How Tacit uses Brick

Name-based discovery

Buildings

Equipment

Points

Locations

Zones

Cross-cutting queries

Properties on all entity types

IFC integration

Next steps