A Graph-of-Graphs Model for Digital Buildings

By Rick Justis, Coalition for Smarter Buildings (C4SB)

For most of the history of building automation, we have organized information around the questions we already knew we wanted to ask.

A BAS database was structured so we could command equipment and display points. A CMMS was structured so we could issue and close work orders. BIM was structured primarily around designing and constructing a building. Utility data was organized around meters, accounts, and bills. Asset management systems were designed around assets, depreciation, replacement, and capital planning.

Each system made sense.

The problem is that the building does not actually exist in any one of them.

The air handler in the BAS is the same physical air handler that appears on a mechanical drawing, has an asset record in a CMMS, consumes electricity measured by a meter, serves rooms occupied by people, has maintenance history, participates in operating sequences, and will eventually require capital replacement.

Those are not eight different air handlers.

They are eight different ways of knowing the same thing.

That distinction may become extremely important as buildings enter the AI era.

From Databases of Answers to Models of Reality

For roughly the last 60 years, software development has largely followed a familiar pattern:

Decide what questions the application needs to answer, then structure the data to answer those questions.

That approach gave us thousands of useful applications. But it also gave buildings dozens—or hundreds—of isolated representations of the same physical reality.

AI changes the premise.

We increasingly do not know in advance which questions will be asked.

An owner might ask:

Which rooftop units serving classrooms scheduled to be occupied tomorrow have recurring compressor problems, are more than 15 years old, have unusually high energy consumption, and should be considered for replacement before next summer?

No traditional building application was designed specifically to answer that question.

But the facts needed to answer it probably already exist.

They simply exist in different places.

The challenge, therefore, is not to build an application for every possible future question.

It is to create a sufficiently structured representation of the building so that future questions can be answered.

This is where graphs become interesting.

The Building Is Not One Graph

There is a temptation in our industry to search for the building ontology or the universal building model.

That may be the wrong objective.

A building is simultaneously a physical system, spatial system, operational system, collection of assets, energy system, financial investment, maintenance responsibility, and participant in a larger geographic and electrical infrastructure.

Each perspective has different facts and relationships worth preserving.

Instead of forcing all of those perspectives into one enormous ontology, C4SB is exploring a simpler architecture:

a graph of graphs.

For discussion, consider eight canonical graph classes.

1. Spatial Graph

This graph answers:

Where is it?

Buildings contain floors. Floors contain spaces. Spaces have boundaries, uses, occupants, adjacency relationships, and geographic locations.

BIM, IFC, GIS and related models can contribute enormously here.

A spatial graph might connect:

Campus → Building → Floor → Room → Zone

and relate those spaces to coordinates, geometry, occupancy, use, and neighboring spaces.

This becomes the geographic and spatial skeleton of the Digital Building Profile.

2. Asset Graph

This graph answers:

What physical things exist?

RTUs, chillers, pumps, VAV boxes, panels, meters, lighting controllers, elevators, batteries, windows, doors and thousands of other physical assets belong here.

The asset graph can preserve identity and attributes such as manufacturer, model, serial number, capacity, installation date, expected life, warranty, and replacement information.

The important concept is persistent identity.

RTU-3 should remain RTU-3 whether we encounter it in BIM, BACnet, a maintenance record, a photograph, a utility analysis, or a capital plan.

3. Systems & Relationships Graph

This graph answers:

How are physical things connected, and what serves what?

This is where ASHRAE Standard 223 becomes especially interesting.

A mechanical plan is not merely a collection of equipment symbols. It describes relationships:

AHU-1 supplies VAV-12.

VAV-12 supplies Room 223.

CHWP-1 moves chilled water through a loop.

A temperature sensor observes the air in a zone.

These relationships allow machines to reason about the building as a system rather than a bag of points.

Brick Schema can also play an important role here. These standards should not necessarily be viewed as competing attempts to describe everything. They can become valuable graphs within a larger architecture.

4. Controls & Operational Graph

This graph answers:

How does the building operate?

Controllers, BACnet objects, sensors, commands, setpoints, schedules, sequences, operating modes and supervisory strategies live here.

This graph can connect the physical building to its operational capabilities.

It also creates a bridge toward emerging work around executable sequences, ASHRAE Guideline 36, Standard 231P concepts, supervisory optimization, demand flexibility, optimal start, resets, load shifting and eventually autonomous building operation.

The asset tells us what something is.

The systems graph tells us what it is connected to.

The operational graph tells us what we can do with it.

5. Energy & Resource Graph

This graph answers:

What does the building consume, produce, store and exchange?

Electricity, natural gas, water, thermal energy, photovoltaics, batteries, generators, EV charging and other resources form another set of relationships.

A meter is not simply a number.

It measures something, serving something, during some interval, under some operating condition.

Concepts emerging from RealEstateCore and other energy-focused semantic work can become particularly useful here.

For grid-interactive buildings, this graph can extend beyond the property line to utilities, tariffs, carbon signals, demand-response events and distributed energy resources.

6. Maintenance & Condition Graph

This graph answers:

What has happened to it?

Work orders, inspections, failures, alarms, technician observations, repairs, parts replacements, commissioning findings and condition assessments belong here.

Consider the difference between a conventional maintenance database and a graph.

A database might tell us:

Work Order 18472 — Replace compressor.

The graph can tell us:

Work Order 18472 → replaced Compressor-2 → component-of RTU-3 → serves Zone-17 → contains Rooms 201–208.

Suddenly maintenance history becomes part of the building’s operational knowledge rather than a historical document sitting in another application.

7. Financial & Lifecycle Graph

This graph answers:

What is it worth, and what should we do next?

Installed cost, maintenance cost, energy cost, expected useful life, replacement cost, incentives, avoided costs, capital plans and lifecycle economics belong here.

This is where technical building information becomes useful to executives and asset managers.

Instead of simply reporting that RTU-3 has a failed compressor, we can potentially reason across graphs:

RTU-3 is 17 years old.

It has experienced three major repairs.

It serves an important occupied area.

Its energy performance is poor.

Replacement would cost approximately X.

An incentive may cover Y.

The 15-year lifecycle economics favor replacement over another major repair.

That is no longer simply building automation.

It is decision support.

8. Organization, People & Responsibility Graph

Finally:

Who owns it, uses it, operates it, pays for it, and is responsible for it?

Buildings exist within organizations.

Owners, tenants, facility managers, technicians, service contractors, engineers, utilities, manufacturers and authorities all have relationships to physical assets and spaces.

This graph can also describe permissions and responsibility.

Who is authorized to change the schedule? Who maintains RTU-3? Who should receive an alarm? Which tenant occupies the affected rooms? Which contractor installed the equipment? Who approved the replacement?

These relationships are essential if AI is expected to move from simply answering questions to helping people take action.

The Digital Building Profile Becomes the Front Door

This leads to a different way of thinking about the Digital Building Profile, or DBP.

A Digital Building Profile should not necessarily contain every piece of building information.

It should tell us enough about the building to discover and connect its digital representations.

Think of the DBP as the building’s digital passport and graph directory.

At its simplest, it might establish:

This is Building X.
Here is its canonical identity.
Here are its major spaces and systems.
Here are the authoritative sources of information about it.
Here are the graphs that describe it.
Here are the interfaces through which those graphs can be queried.
Here are the credentials and policies governing access.

The DBP therefore becomes the entry point into a federated building knowledge environment rather than another giant database that everyone must populate.

C4SB’s roadmap from existing building to digital building. The Digital Building Profile is the map; the eight graphs above are step six. Source: C4SB.

The Standards Already Exist — In Pieces

Perhaps the most encouraging part of this idea is that we do not have to invent everything.

ASHRAE 223 can describe systems and their relationships.
Brick can describe equipment, points and relationships.
RealEstateCore can contribute important real-estate, spatial and operational concepts.
IFC and BIM contain rich representations of design and construction.
GIS platforms understand geography and spatial relationships.
BACnet exposes operational objects.
CMMS and asset management platforms contain maintenance and lifecycle information.
Cybersecurity frameworks can describe devices, identities, vulnerabilities and trust relationships.

None needs to become the universal building model.

Instead:

Let each model describe what it describes well—and connect the graphs.

That is a much more achievable interoperability strategy.

Why Eight?

Eight is not sacred.

There may ultimately be six canonical graph classes, or ten.

The purpose of proposing eight is to force an architectural conversation that our industry badly needs.

Before creating another application, database, ontology or digital twin, ask:

What facts does this system uniquely know? What relationships does it know? What persistent identities does it share with other systems? Can those facts become part of the building’s larger graph of graphs?

That may be more important than arguing over which ontology wins.

A Mechanical Drawing Is Already a Graph

Take an ordinary M100 mechanical plan.

To a human mechanical engineer, it already describes a graph.

The drawing tells us that an RTU serves ductwork, that ductwork serves diffusers, that diffusers serve spaces, that spaces belong to a building, and that equipment has capacities and characteristics.

Today much of that knowledge remains trapped in lines, symbols and annotations intended for human interpretation.

The increasingly practical opportunity is to convert those relationships into a machine-readable graph—perhaps using ASHRAE 223 as the systems representation—and connect that graph to the other seven perspectives.

Now the drawing has not simply been “digitized.”

Its meaning has become computational.

AI Makes This Architecture Urgent

This matters because large language models have dramatically changed the economics of asking questions.

Natural language is becoming a query interface.

But an AI system cannot reliably reason about a building merely because we connected it to 40 databases.

It needs context.

What does this point represent? What equipment does it belong to? What space does that equipment serve? What other equipment serves that space? What maintenance has occurred? What is the equipment’s expected life? How much energy does it consume? What can actually be controlled?

Graphs provide those relationships.

And a graph of graphs allows us to preserve specialized models without demanding that the entire industry agree on one enormous schema before anything useful happens.

From Applications to Knowledge Infrastructure

There is a larger transition underneath all of this.

The previous software era was dominated by applications designed around predefined questions.

The emerging era will increasingly be built around representations of knowable reality from which unanticipated questions can be answered.

For buildings, that suggests a different architectural principle:

Model what exists. Preserve its relationships. Connect the graphs. Let tomorrow’s applications ask tomorrow’s questions.

The Digital Building Profile can become the practical starting point.

Not another dashboard.

Not another proprietary digital twin.

Not another attempt to put every piece of building information into one database.

Instead, the DBP can give every building a durable digital identity and a map to the graphs through which that building can be understood.

The industry already has most of the pieces.

Perhaps the next step isn’t another platform.

Perhaps it is simply agreeing that the pieces should be able to find each other.

Sources and Further Reading

• About C4SB, Coalition for Smarter Buildings
• C4SB Projects and Interest Groups
• Linux Foundation Welcomes C4SB, Announces Intent to Form C4SB Foundation
• C4SB: Past and Future (2022–2026), AutomatedBuildings.com
• C4SB on LinkedIn
• Rick Justis on LinkedIn
• C4SB Placemat 5.0 (PDF)

https://www.automatedbuildings.com/wp-content/uploads/2026/08/C4SB-Placemat-5.0.pdf