Digital Twins & BIM
What is IFC and why does it matter for building data exchange?
What IFC covers, how MVDs and IDS make exchanges specific and why early tests with the receiving application matter.
Ask for each deliverable for a stated reason, and keep identities consistent across all three.

"The contractor shall provide BIM, IFC and COBie." A clause like that, with nothing to say what each is for, is a reliable way to buy duplicated effort and three inconsistent sets of information.
The three terms sit at different levels. BIM is a process: managing information about a built asset across its life cycle. IFC is an open data schema, published as ISO 16739-1, for exchanging that information between software applications. COBie is a defined exchange of the information needed to operate and maintain a facility's assets; NIBS, which maintains it, describes it as a non-graphic subset of a BIM model, defined as a model view definition (MVD) of IFC. All three can serve the same project, but they answer different questions and cannot stand in for one another.
Scroll horizontally to read the full table.
| BIM | IFC | COBie | |
|---|---|---|---|
| What it is | An information-management process | An open data schema and file format | A defined exchange of asset data |
| Defined in | ISO 19650 series | ISO 16739-1:2024 | NIBS: COBie version 3, a module of NBIMS-US version 4 |
| Typical content | Models, documents, data, workflows | Geometry, properties, relationships | Spaces, types, components, systems, documents, jobs |
| Geometry? | Usually | Yes, where needed | No — non-graphic |
| Main receiver | Whole project team; later the operator | Other BIM and analysis software | Maintenance and asset-management systems |
On a typical project, BIM processes coordinate design and construction information; IFC is used to share models between disciplines and to hand over an open-format model; and COBie transfers the asset records the maintenance team will load into its system. The owner's requirements should state the purpose and the receiving system for each.
How they connect has practical consequences. Because COBie is defined as a view of IFC, COBie data can be generated from a well-structured model, and NIBS lists IFC alongside SpreadsheetML and JSON as approved COBie formats. That only works, though, if the model carries the identifiers, classifications and properties the COBie requirement needs. If it does not, the COBie file ends up assembled by hand from schedules, and falls steadily out of step with the model.
When the same pump appears in the model, the COBie file and the maintenance system, it must have one identity, with an agreed rule for which source wins when they disagree. The requirements should settle which deliverable is authoritative for each kind of information, whether geometry, asset identity or maintenance data; how identifiers are carried from one to another; and who resolves differences, and by when.
The receiving tools need testing as well. A product's claim to support IFC or COBie does not prove that every required field or relationship will transfer under the project's chosen versions and conventions.
Where requirements ask for all three without saying why, rewrite them so that each deliverable has a defined purpose, an authoritative scope and a receiving system. The technology and controls assets are a good place to start.
This article connects to our work on Digital twin.
We can discuss the asset information requirements.
Contact Pagin Consulting