There is no shared vocabulary for AI factory operations. We are building one.

An alarm fires at 3 AM. The PLC in the coolant distribution unit has detected coolant in one of three rope sensor zones.

The technician on the floor locates the leak response procedure and reads the steps. The procedure carries the steps. What it does not carry by default:

• Which of the isolation points on this unit are relevant to this fault, and whether they cover the fluid loop, the electrical enclosure, or both
• Which interlocks are currently active and how they change the available response sequence
• The lockout/tagout sequence required before any work on the high voltage VFD enclosure, and which OSHA 1910.147 control step each action corresponds to
• Which section of which version of the specification the procedure was derived from, and whether that version matches the unit installed

Those questions are answerable. Answering them requires a senior engineer, multiple documents, and time that a 3 AM fault response does not have. The answers cannot be looked up once and filed away: they need to be revisited any time the equipment changes, the specification updates, or a new engineer joins who was not part of the original commissioning.

A facility running hundreds of CDUs faces those questions independently for each one.

The first post in this series described where the knowledge required to operate an AI factory lives today: in vendor manuals, engineering drawings, commissioning reports, and safety standards, none of which share a format or a common reference vocabulary. The knowledge cannot travel from facility to facility, or be verified by someone who did not author it.

The building automation world has spent a decade building infrastructure to solve exactly this problem for buildings. That infrastructure already exists. This post describes how we are extending it to cover AI factory operations, and walks through a complete worked extraction against a production CDU specification published through the Open Compute Project (OCP).

Brick Schema and ASHRAE standard 223: the foundation

Brick Schema is an open RDF ontology that covers building systems equipment, sensors, setpoints, and the relationships between them. A chiller, a VAV box, a temperature sensor, its setpoint, the zone it serves. Data centers have been adopting Brick for DCIM and telemetry. Version 1.4.4 was published in May 2025. Brick describes what the equipment is and what it measures. It does not describe what the operator does when the equipment enters a fault state, which isolation points govern safe access, or what the safety standards require for that equipment type. That operational layer is not represented as a first-class, queryable graph in the building schemas we rely on today for AI factory facilities.

ASHRAE 223 is a standard for semantic modeling developed by ASHRAE that draws on Brick and Project Haystack 3 but describes electrical and mechanical systems in more detail, including wiring and piping topologies and medium flow. ASHRAE 223 is designed for seamless integration and compatibility with the Brick schema. The standard is currently undergoing public review with expected publication in the next few months. Marco Pritoni, staff scientist at Lawrence Berkeley National Laboratory, a collaborator on this effort, is a member of the ASHRAE 223 technical committee.

Anchoring this work on the published and stable Brick schema ensures it can ship immediately, while its deliberate alignment with the upcoming ASHRAE 223 standard positions the model for future integration.

The equipment vocabulary gap

Before any operational layer is possible, the equipment it covers has to exist in the schema. Brick v1.4.4 does not include AI-factory-specific classes for coolant distribution units, rear-door heat exchangers, direct-to-chip cold plates, liquid-cooling manifolds, or GPU-specific rack hierarchy, even though it does include broader classes such as Heat_Exchanger and ICT_Rack.

Brick’s published vocabulary was built around mainstream building and HVAC equipment for building applications. Direct-liquid-cooling equipment sits outside that vocabulary today. The equipment vocabulary extension adds the liquid cooling stack and the compute hierarchy as a prerequisite for everything else.

The twelve operational entity classes

The twelve operational entity classes are the novel surface. We have not found an adjacent standard that represents this as a queryable operational layer inside the building-controls or data-center semantic graph. The design logic behind the class list is worth explaining.

Procedure is the top-level class, with Method of Procedure (MOP), Standard Operating Procedure (SOP), and Emergency Operating Procedure (EOP) as subclasses. The distinction matters operationally: an EOP is triggered by a fault condition, a MOP governs a planned one-time change, an SOP governs a routine task. The triggering context changes the review requirements and the approval chain.

Sequence and Action break the procedure into its steps. Sequences are not strictly linear: each Action carries an on_failure path to a named branch, so an EOP can fork on whether an isolation valve responds or a pump stops. Each Action also carries a verb from a closed ten-verb vocabulary (Start, Stop, Open, Close, Set, Reset, Wait, Compare, Jump, Verify), making procedure steps precise enough to support simulation and downstream tooling. Actor is the role that executes or approves a given Action. SystemAutomation covers automated steps; Technician or SafetyOfficer covers manual ones. The same Actor concept covers the approval chain: a MOP requires an approving Actor before execution, and that relationship is first-class in the graph.

OperatingMode captures discrete equipment states and the allowed transitions between them. The mode names and their valid transitions come from the vendor O&M manual or equipment design specification. In the graph, each mode’s entry_conditions and exit_conditions reference Brick sensor points, connecting the declared state to live data from building systems. The transitionsTo predicate declares which next states are valid from a given mode; it is not a full state machine with guards, but it makes the allowed transition set explicit and queryable.

IsolationPoint and Interlock are first-class entities rather than fields inside procedure records because the same physical hardware appears in multiple procedures. Consider a fluid isolation valve on a CDU: it appears in the leak EOP, the scheduled filter service MOP, and any maintenance procedure that requires isolating the primary loop. If that valve were only a field inside each procedure record, the query “which procedures involve this valve” would require reading every procedure in the facility. As a named entity in the graph with relationships pointing to it, that query is a single traversal. Interlock follows the same design for the same reason: the same interlock can gate actions in multiple procedures, and whether it is currently active changes the response available to the operator.

IsolationPoint covers both fluid and electrical isolation. For a liquid-cooled CDU, fluid isolation points are shutoff valves that take sections of the primary loop out of service; electrical isolation points are disconnects or breakers that remove power before work inside high-voltage enclosures. Both types are represented in the same class; the source citation and the procedure context distinguish them. The worked extraction below shows both types in the same CDU, including how one electrical isolation point is also the entry point for the OSHA 1910.147 lockout/tagout sequence.

FailureMode connects an alarm event to the equipment that generated it and the procedure that handles it. Event is the first-class representation of the alarm firing, distinct from the Brick alarm point. The connection between the sensor point and the downstream response procedure requires Event as the bridge.

CommissioningStep, MaintenanceTask, and LockoutTagoutStep are not procedure steps. They are records attached to the equipment (its acceptance criteria and its maintenance tasks) or to a procedure (its lockout/tagout steps). A lockout step that the operator also executes appears twice, once as a record and once as an Action in the procedure sequence, joined through the procedure. The Step naming is the OSHA and commissioning domain term, not the ontology Action.

Worked extraction: OCP Project Deschutes CDU

OCP Project Deschutes: Data Center Facilities (v0.8.0, Google, OCP 2025) is a CDU design specification published through the Open Compute Project. We applied the operational schema to this specification. The full extraction is in the aif-ops repository. A few examples show how the schema concepts work in practice.

Simplified operational graph for the leak-response example. Blue is the Brick equipment layer; teal is the aif-ops operational layer that extends it; amber is the Actors. Every entity is cited to a clause in the specification; the dashed edges show a representative few.

Who performs an action is explicit in the graph

The leak response EOP starts with an AutomatedAction: the PLC fires the alarm on detection of coolant in any of the three rope sensor zones, as required by the CDU design specification. All subsequent steps are ManualAction, performed by the on-site technician. This boundary between automated and manual response is not a comment or a narrative note in the procedure; the PLC is modeled as an Actor (deschutes:PLC_ControlSystem) with a typed performedBy relationship to that action. When a downstream system reads this graph, both the automated and manual actors are fully addressable.

IsolationPoint covers both fluid and electrical isolation

The Deschutes CDU has four isolation points: the pump supply shutoff valve, two filter shutoff valves on the fluid loop, and the VFD main disconnect for electrical isolation of the variable-frequency drive. All four are IsolationPoint instances in the same class. The label and the source citation distinguish them; the class does not need to bifurcate to cover both types.

The VFD main disconnect is also the entry point for the LOTO sequence. The first two steps of the VFD removal MOP (turning off the main disconnect and verifying power removal) are recorded both as MOP sequence steps and as LockoutTagoutStep instances linked via partOfProcedure. The same physical actions serve two documentation purposes, and both are queryable independently.

CommissioningStep carries the actual criteria, not a summary

The filter commissioning step in the OCP specification illustrates the CommissioningStep class. The pass and fail criteria are verbatim from the specification, not editorial summaries. Pass: “Measure dP vs flow of filter assemblies; validation shall be done with DI water and PG25 coolants.” Fail: “The filter cartridge will be removed and inspected for damage” (after a 150 psig impulse pressurization test). Both are string literals in the graph under hasPassCriteria and hasFailCriteria, defined properties in the ontology.

OnConditionMaintenanceTask handles the case where no fixed interval exists

The OCP Deschutes specification does not specify a fixed filter replacement interval. Section 20.5 states: “Vendor to provide guidance on alert/alarm thresholds for maintenance.” The OnConditionMaintenanceTask subclass captures this directly with hasTriggerCondition using the verbatim spec language. A ScheduledMaintenanceTask with recursEvery is not assertable from this specification; asserting one would misrepresent the source.

What the graph makes queryable

Once the extraction exists as a graph, queries that previously required reading multiple procedures and cross-referencing multiple documents become single traversals.

“Which procedures involve the pump supply valve on this CDU” returns two results: the leak response EOP (step 3) and the pump removal MOP (step 1). A maintenance engineer scheduling pump work sees, in a single lookup, every procedure that depends on that valve and needs to be coordinated.

“Which interlock gates pump removal” returns Interlock_HotswapFluidIsolation along with its source citation in the OCP specification. An operator preparing for a pump hotswap can trace the permissive requirement to the exact design-spec clause that mandates it.

“Which procedures include LOTO steps” returns the VFD removal MOP. A safety officer auditing energy-control compliance does not need to read every procedure to find the ones that require lockout/tagout documentation.

“Which procedure steps reference the pump removal section of this specification” returns every action in every procedure that cites it. When the specification is revised, those steps surface for review without scanning the entire procedure library.

Provenance as a first-class feature

The relationship vocabulary wires these entities into Brick’s existing equipment, point, and location graph via thirty-five predicates. hasSource is the one that changes the trust model.

In the worked example, each asserted fact is paired with a source citation that identifies the supporting document, section, and page. Each citation also carries a sourceKind attribute that classifies the authority behind it: normative for a design requirement that cannot be overridden, vendor_default for a factory-shipped value that can be site-configured, site_setting for a value the facility has set, or sme_confirmed for a value a subject-matter expert has reviewed and signed off.

A procedure step does not assert an action in isolation. It asserts an action and attaches the specific document evidence behind it. Step 3 of the leak EOP (Action_EOP_ShutSupplyValve) cites the pump removal procedure in the OCP specification as vendor_default and the CDU design requirements section as normative, which mandates stop valves to prevent disruptive flow conditions. Both citations are structured triples in the graph, not text in a comment field.

This is source citation and change-surface detection, not graph version control. When the OCP specification is revised, the procedure steps that cite the affected sections can be identified, compared against the new source, and updated with a new citation. The history of the graph itself, tracking who changed what and when, is a separate problem the schema does not attempt to solve. What hasSource provides is the ability to answer “which steps need review after this specification update” without reading every procedure.

Validation: the extension is executable

Each operational entity class ships with a paired SHACL shape. SHACL is the W3C validation language the Brick Consortium and the ASHRAE 223 technical committee already use to check conformance of various applications, including ASHRAE Guideline 36. The pattern here is schema conformance of the instance graph: checking that each entity has the required structure. Every Action must have a performedBy. Every CommissioningStep must have hasPassCriteria and hasFailCriteria. Every CDU must have at least one IsolationPoint. A graph where a CDU has no associated emergency procedure fails validation.

The OCP Deschutes extraction validates against the published shapes file with zero violations. That result is reproducible by anyone with the schema files and the extraction TTL:

pyshacl -s aif_ops_shapes.ttl -e aif_ops.ttl \
        -df turtle -f table ocp-deschutes-extraction.ttl

A graph where a CDU is missing a required entity, such as an EOP or an IsolationPoint, fails that command. The missing piece is visible before the graph is accepted as complete, and a reviewer can verify conformance with a single command rather than reading every entity by hand.

Why Brick, and why an extension rather than a new standard

The extension is published as a standalone ontology that owl:imports Brick v1.4.4, following the Brick Consortium’s own guidance for extension architecture. It ships without waiting on consortium governance. A pull request to upstream the additions into Brick core is a parallel deliverable.

If that PR is accepted, the operational vocabulary for AI factories becomes part of the same schema that governs smart buildings, hospitals, and commercial HVAC systems. A query that retrieves a CDU emergency procedure would work unchanged against any Brick-compliant building management system that adopts the extension. Building this on a proprietary vocabulary would mean re-solving the integration problem at every tool boundary.

Brick uses RDF and SHACL. ASHRAE 223 is built on the same semantic web stack: RDF, SPARQL, and SHACL. Brick includes a tagging system similar to Haystack 3, augmented with formal semantic rules. Because both use RDF, SPARQL, and SHACL, a Brick extension does not require reformatting to work within the ASHRAE 223 toolchain.

What comes next

The schema ontology, SHACL shapes, and worked extraction files are published at github.com/Visum-ai/aif-ops. A full technical report with the complete gap analysis, all predicate definitions, step-by-step procedure tables, and the starter ASHRAE 223 mapping is at github.com/Visum-ai/aif-ops/blob/main/docs/technical-report.md. We are working with Lawrence Berkeley National Laboratory to submit this as a contribution to the Brick Consortium.

If you work on AI factory operations, building automation standards, data center commissioning, or adjacent tooling and have a view on the schema design, contact us.

With thanks to Marco Pritoni (Lawrence Berkeley National Laboratory) for technical review and collaboration on this work.

References

Balaji B., Bhattacharya A., Fierro G., Gao J., Gluck J., Hong D., Koh J., Kolb J., Ploennigs J., Agarwal Y., Berges M., Culler D., Gupta R., Kjaergaard M.B., Srivastava M., Whitehouse K. (2016). “Brick: Towards a unified metadata schema for buildings.” Proceedings of the 3rd ACM International Conference on Systems for Energy-Efficient Built Environments, pp. 41-50. https://doi.org/10.1145/2993422.2993577

Fierro G., Koh J., Nagare S., Zang X., Agarwal Y., Gupta R.K., Culler D.E. (2020). “Formalizing tag-based metadata with the Brick ontology.” Frontiers in Built Environment, 6, 558034. https://doi.org/10.3389/fbuil.2020.558034

Pritoni M., Wetter M., Paul L., Prakash A., Huang W., Bushby S., Delgoshaei P., Poplawski M., Saha A., Fierro G., Steen M., Bender J., Ehrlich P. (2024). “Digital and Interoperable: the future of building automation is on the horizon. What’s in it for me?” ACEEE Summer Study on Energy Efficiency in Buildings, Pacific Grove, CA, August 2024. https://doi.org/10.20357/B76W3X

Wetter M., Chen B., Devaprasad J., Ehrlich P., Gautier A., Hu H., Prakash A., Pritoni M. (2025). “Modelica Meets ASHRAE: Towards A Digital Standard for Building Control.” 16th International Modelica and FMI Conference, Lucerne, 2025. https://doi.org/10.3384/ecp218505