Buildings and points

The core data model: buildings contain equipment, equipment has points.

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

All root queries require siteId to scope to your site. Examples below omit it for brevity. See multi-tenant scoping.

Name-based discovery

Every entity can be found by name, with 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.

Equipment has a typeHierarchy showing its full class lineage (root → leaf), and carries structured metadata via properties:

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

typeHierarchy returns ["AHU", "HVAC_Equipment", "Equipment", "Entity", "Class"], which is why is: "HVAC_Equipment" matches AHUs. properties returns structured objects like controllerName, isVirtual, pointCount, each with a name, value, and optional unit.

Properties on all entity types

Every entity type has properties: [EntityProperty!]!, not just equipment. Buildings, locations, zones, systems, and points can all carry metadata:

{
  building(id: "B001") {
    properties { name value unit }
  }
}

{
  zone(name: "Lobby") {
    properties { name value unit }
  }
}

The properties available depend on what’s in the Brick model. 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.

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. Query 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. See points reference for the full cross-cutting query surface.

Next steps

Class hierarchy

How is: "HVAC_Equipment" matches all subtypes automatically.

Relationships and traversal

How upstream and downstream follow equipment chains.