Docs Portal

Overview

Expert Center pairs an AI agent with targeted human expertise to turn a building's raw data into an enriched building model.

Everything lives under an organization → building hierarchy. Each building has one or more connectors: integrations that pull a source system's data, such as a BMS, into the building as raw entities. Enrichment turns those raw entities into an integrated, normalized building model representing the real world. This is achieved through an iterative, human-in-the-loop workflow: experts describe a small part of the building, an AI agent they talk to in chat generalizes that description into rules, and experts review what those rules produce. A few labels typically carry most of a building and rules do the rest.

Three things drive that loop:

Concept	What it is	Who creates it
Entity	A point, device, space, or other instance in the building, plus its metadata.	Connectors, rules, or experts
Label or instruction	Expert knowledge of the building, and how they want an entity's data interpreted. A label is a fact asserted on one entity. An instruction is the same knowledge in plain language, with no entity attached.	Experts
Rule	A condition that matches entities and an action that enriches them. A single rule enriches every entity it matches.	The agent, from labels and instructions

The Loop

Copy1
2
3
4
5
┌──────────┐      ┌──────────┐      ┌──────────┐
│  Label   │ ───▶ │  Infer   │ ───▶ │  Review  │
└──────────┘      └──────────┘      └──────────┘
     ▲                                    │
     └────────────────────────────────────┘

Label. Experts label a fraction of the building. A label is a fact asserted on one entity, and it is its own approval: it never has to be reviewed.
Infer. The agent turns each label, or each instruction, into a rule and proposes how far it reaches. Every rule must satisfy the labels it was generated from. The agent runs the rule against them, then checks and revises it.
Review. Experts approve or reject rules. Approving a rule approves everything it produced at once. When a rule produces something that does not belong, the expert flags it as a false positive. That flag is feedback: the agent narrows the rule's condition to exclude it and checks the rule against its labels again.
Repeat. The cycle starts again where the rules did not reach.

Three Kinds of Enrichment

Kind	What it does	Example
Classification	Assigns a type and/or unit to an entity	This point is a Zone Air Temperature Sensor, °F
Reification	Creates a new entity derived from an existing one	This point implies a parent device VAV101
Link	Declares a relation between two entities	VAV101 has point VAV101_ZNT

Each kind can appear as a label (one entity, set by an expert) or a rule (many entities, generated by the agent).

A Concrete Example

A BMS connector contains a point named

Copy

1
VAV101_ZNT

. An expert labels it:

Classification: this is a Zone Air Temperature Sensor (point type + unit).
Reification: it implies a parent device VAV101.
Link: VAV101 has point VAV101_ZNT.

The agent turns each label into a rule. The classification rule matches every entity whose name ends in

Copy

1
_ZNT

and tags it the same way. One label, hundreds of enriched entities.

How the Pieces Connect

A label is made on one entity. The agent reads it and generates a rule of the matching kind. The rule records which labels and entities it came from.
An instruction is given to the agent in plain language. The agent transcribes it directly into rules. Instructions are authoritative, so the resulting rules are not checked against existing entities.
A rule's condition matches entities across the building; its action enriches each match. Each result (a derived entity, an inferred relation, or inferred metadata) is recorded as a rule output that credits the rule and the source entities involved.
A rule output is approved if any rule crediting it is approved, or if a label vouches for it directly. It is pending while any crediting rule is still in progress, and declined when every crediting rule is rejected.

Unification

Several entities can describe the same real-world thing, for example one air handler seen through two connectors. Experts group them under one canonical entity, which gives the group its name and type, so the final building model has one entity per real-world thing.