IFC and COBie Data Standards in Critical-Facility Projects

U.S. data center construction was worth $48.18 billion in 2024, headed toward $112 billion by 2030, driven mostly by AI computing demand. ConstructConnect logged $14.0 billion in single-month construction starts in July 2025, almost double the previous record of $7.4 billion set just eleven months earlier. Facilities are coming online faster than at any point in the industry's history, and that speed changes what "handoff" actually means: the quality of the data passed from construction to operations now carries as much risk as the construction itself, and that risk scales with every megawatt that comes online.

Up to 30% of building lifecycle data gets lost at the construction-to-operations transition, according to industry estimates. That means facility teams end up re-typing asset information that already exists somewhere in the BIM model. In an office building, that's annoying and costs a bit of money. In a data center, where uptime is a contractual obligation and every mechanical, electrical, and cooling system depends on the others, that same loss turns into a reliability problem. A finished construction schedule means the building got built. It says nothing about whether anyone can run it safely on day one, without calling a subcontractor to ask which chiller has the extended warranty. Those are two different states. The standards meant to bridge them, IFC and COBie, get treated as basically interchangeable far too often. They are not the same thing, and most people get the relationship backwards: COBie isn't a competing standard to learn alongside IFC, it's a narrow slice pulled out of it. Most of the confusion on a project traces back to that one mix-up.

What IFC and COBie are, and how they relate to each other

IFC, short for Industry Foundation Classes, is an open schema that carries the full picture of a building: geometry, systems, spatial relationships, component properties, all of it, in a format any software can read regardless of which tool built the model. It's an open, vendor-neutral format that any software can read regardless of which tool built the model. That's the entire point of it existing.

COBie, the Construction Operations Building Information Exchange, is a filtered view of IFC data, formally defined as a Model View Definition, or MVD, of the IFC schema. A useful shorthand: IFC is the building's DNA, the full genetic code with every system and relationship intact. COBie is the health record, the specific part a facilities manager actually needs pulled out and organized.

Nobody on the FM side wants to dig through a massive IFC file to find a chiller's serial number, and nobody should have to. MVDs exist to carve out exactly the subset a given exchange requires, and COBie is one specific, well-defined version of that.

Structurally, COBie organizes data into a handful of tabs. Facilities covers building name and function. Floors and Spaces cover rooms and zones. Types holds equipment category specs. Components holds individual asset details. Systems shows how components link together. Documents stores manuals, warranties, and datasheets. It can ship as a spreadsheet in SpreadsheetML format, as JSON, or directly inside an IFC file using the COBie IFC Schema module, per NIBS COBie V3.

The governance behind this is not casual, and it shouldn't be treated that way. COBie V3, under NBIMS-US, came out of a workgroup that reviewed more than 100 change requests over nearly five years and implemented around 60 of them. In the UK, COBie usage runs through BS 1192-4:2014. The spec was originally written against IFC2X3, though, and under IFC4, some of those definitions haven't been fully reviewed yet. That version gap creates real friction for teams working in current IFC, and it comes back later in this piece as a live implementation problem, not something to skim past.

Treat COBie as something generated at the end of a project and the whole approach falls apart. It has to get built the whole way through, not reconstructed the week before turnover.

How COBie data is built across the project lifecycle, not generated at the end

The most common mistake on a project is treating COBie like a deliverable someone assembles after the building is done, instead of a data layer that accumulates the whole way through. NIBS COBie V3 states its purpose: shrink, or eliminate outright, the delay between handover and the moment a facilities management system can start running operations and maintenance on those assets. That only works if the data gets captured as the project moves, not pieced back together afterward from memory and PDFs.

During design, architects and engineers populate floors, spaces, equipment types, and system relationships. COBie attributes get added at the family level, covering equipment classification, specifications, and maintenance-related information. During construction, contractors fill in make, model, serial number, install date, and warranty terms, and link manufacturer datasheets in as Documents. The dataset gets validated for completeness before anyone signs off on handover.

At handover itself, the COBie dataset gets exported and checked for completeness against the Employer's Information Requirements, or EIR. If the work happened in layers all along, the CMMS-ready dataset is already sitting there, done. Nobody's assembling it from scratch under deadline pressure, and that difference becomes visible in the building's performance fast once it goes live.

COBie isn't a one-time event either. It applies at the end of new construction and at other defined handoff points in a building's life. Multiple handoffs, same discipline required every single time.

Data centers add a specific wrinkle. Equipment substitutions during construction happen constantly under supply-chain pressure, and those changes have to flow back into the COBie dataset instead of sitting forgotten in a contractor's project files. The resulting scenario is straightforward: a facility manager who can't find a supplier contact, can't confirm warranty status, or can't locate an O&M manual is looking at a data-capture failure that started months earlier. It only becomes visible late, once someone actually needs the information.

In a critical facility, that moment of discovery is never convenient.

Why critical-facility complexity makes IFC and COBie harder to execute, and more necessary

AI-driven rack densities are climbing to 40 to 50 kW per rack now, up from a conventional baseline near 10 kW. At that density, a minor miscalculation in airflow or power distribution doesn't just underperform. It pushes systems past their design limits.

Electrical systems eat 40 to 45% of a data center's construction budget, and cooling takes another 15 to 25%. These aren't background support systems, they're the facility, full stop, and their asset data is the operational information that matters most on the whole project. On an AI-optimized build, mechanical and electrical work accounts for 82% of total project value, versus 59% on a standard building. The share of the asset register that has to get handed over accurately runs far higher here than in conventional construction, where a missed HVAC component record is a nuisance instead of a threat to uptime.

Spatial interdependency makes this worse. Chilled water piping and CRAH units compete with electrical busways for the same overhead real estate, and cable trays from power distribution often block return air paths. A missing or wrong component record in the COBie dataset is never an isolated error in a data center, because nothing in one of these buildings sits by itself.

Clash detection catches geometry conflicts, fine. It never catches constructability problems, sequencing issues, or layouts that are technically clash-free but physically impossible to service. A technician who can't reach a PDU without pulling 400mm of conduit out first has a real problem, and clash detection won't flag it, because nothing's actually overlapping. It's just unreachable.

Vendor models add another layer of risk. They often carry excessive geometry and metadata that's flat wrong, which drags down model performance and hides clashes during coordination. That bad metadata rides straight from IFC export into the COBie dataset, and from there into the DCIM system the operations team is counting on as its source of truth. For mission-critical environments, IFC export needs to be a controlled step with real validation behind it. False clashes waste coordination time. Missed ones raise the odds of rework, or worse, rework discovered after the facility is already live.

The mismatch between versions from earlier isn't theoretical. Teams working in current IFC versions run straight into COBie spec sections written for the older schema and never reviewed for the new one. That has to get planned for ahead of time, not discovered during a failed export at the worst possible moment.

What operations-ready handoff looks like when IFC and COBie are properly connected to DCIM, EPMS, and BMS

A data center's BIM model can't sit off in its own silo. It has to connect to DCIM, BMS, and asset management systems directly. Syncing DCIM to the BIM model is what keeps the DCIM dashboard reflecting the same single source of truth everyone else works from, instead of a stale snapshot from six months before turnover.

A full handover package covers a long list of material: approved drawings, as-built drawings, single-line diagrams, mechanical schematics, fire-system drawings, network diagrams, security-system layouts, BMS and DCIM point lists, EPMS point lists, cable schedules, equipment datasheets, testing and commissioning records, load-bank test records, failure-scenario test records, and snag closure records. The COBie dataset organizes all of that into something queryable, rather than a folder of PDFs nobody wants to open at 2 a.m.

COBie's Components tab captures individual asset details, Types holds equipment category specifications, and Documents links out to supporting records such as manuals and commissioning files. These are exactly the fields that facility management and asset management systems need populated on day one to run operations without a startup delay.

Strong BIM Execution Plans build this in from the start. They typically include a handover data schema, an EPMS/BMS/DCIM integration plan, a moves-adds-changes workflow, and a scan plan for brownfield areas. The integration plan gets specified at kickoff. Negotiating it during the scramble at turnover is too late to fix anything properly.

Research from Otranto and colleagues, published in a peer-reviewed journal, 30 (2025), documents a working example done right: a REST API keeping different systems talking to each other, paired with a BIM add-on that guarantees data moves both ways and gets checked continuously. It shows that IFC-based integration doesn't require locking into one vendor's proprietary software stack. Their work demonstrated that IFC-based integration can support open, interoperable asset management without locking into proprietary tools. The open-standard route means the operations team isn't stuck depending on whatever authoring tools the design team happened to use two years earlier.

Whether a handoff actually worked comes down to one test. Can the operations team run the facility without leaning on hidden knowledge held by vendors, consultants, project managers, or whoever happened to be on site during construction? If the answer is no, the facility isn't operations-ready, no matter what the construction schedule claims.

Where IFC and COBie data quality breaks down in practice, and how structured automation addresses it

The failure pattern repeats the same way on project after project. Design and construction tools stay siloed, so the same information gets rebuilt by hand in each new one. Equipment data sits trapped in manufacturer PDFs and never makes it into the model. A single rack move cascades into manual rework across power, cooling, cable, and drawing sheets, because nothing is actually linked.

In the AHMsys automated HVAC modeling study, HVAC modeling accounted for 65% of total BIM project workload. That kind of labor intensity pushes teams to cut corners, and cut corners produce incomplete or inconsistent component data, which is the raw material COBie depends on to function.

BIM-to-fabrication-to-field pipelines show the alternative works: automated layout and hanger generation, digital shop packages with metadata sent straight from the BIM model to the shop floor, field feedback systems that capture real deviations as they happen. When those deviations get fed back into the model instead of sitting on a paper punch list, the COBie dataset stays current instead of going stale the day construction starts.

None of that runs without BIM maturity in place first, and AI-assisted tools can't produce anything useful out of data that's incomplete or unreliable to begin with, no matter how good the model behind them is. Teams working from a genuinely shared source of truth can support automated risk checks and layout optimization. Teams that aren't working from one can't, regardless of software quality. Get that foundation right, and the handoff dataset stops being a separate task bolted onto the end of the project. It becomes a natural byproduct of how the project already ran.

Emerging research on agentic BIM points toward IFC-based systems that can query models more directly, reducing the manual effort of navigating complex asset data by hand. That's a signal, not a settled fact yet, but it suggests IFC's role is moving past static handoff and toward something closer to a live operational interface.

ArchiLabs Studio goes after the fragmentation itself instead of patching it after the fact. By connecting layouts, critical-systems engineering, cable routing, documentation, RFIs, and operations-ready handoff inside one workflow, a change cascades automatically instead of forcing manual rework across separate models, spreadsheets, and PDFs. The IFC and COBie outputs come out the other end as a structured result of that connected process.

Rules-based automation handles the precision and compliance demands of power, cooling, and cable coordination, where the tolerance for error runs close to zero. AI-assisted tools handle the flexible, language-heavy work: pulling specs out of a manufacturer's PDF, parsing RFI language, tasks that benefit from flexibility rather than rigid rules. Each belongs where it belongs. Swap them, and that's its own kind of failure waiting to happen.

Picking a workflow tool because it can spit out an IFC file misses the point. Plenty of tools can do that much. What actually matters is whether that IFC export carries accurate, complete, traceable asset data all the way back to design decisions made months earlier. Every RFI answer, every design change, every equipment parameter needs a path back to whatever justified it in the first place. That traceability is what turns a COBie dataset into something operationally useful, rather than a file that's technically compliant and practically useless the moment someone actually needs it, which is the specific problem Archil Labs, a data center design automation platform that connects layouts, documentation, RFIs, and ops handoff inside a single intelligent workflow, was built to solve.