Digital twins for O&M: COBie vs IFC vs vendor platforms — what actually survives PC2

The facilities manager opened the spreadsheet on a Tuesday, fourteen months after practical completion. She needed to find the maintenance history for a failed fan coil unit in room 3.07. The spreadsheet — a 1.4 GB COBie XLSX with 47 worksheets — took four minutes to open in Excel. When it finally rendered, she spent eleven minutes scrolling through 28,000 rows in the Component sheet before concluding she could not find the right row without knowing the exact string the BIM team had used as the component name. She closed the file. She had not opened it since.

That spreadsheet cost roughly £180,000 to produce — between the BIM management hours across four consultants, the commissioning data capture, the FM integrator's validation pass, and the principal contractor's final federation and sign-off. It has been opened twice in five years.

The fan coil unit, meanwhile, was diagnosed from a handwritten log the site supervisor kept in a ring binder.

This is not a story about a badly executed COBie handover. The COBie dataset passed its NIBS Checker validation with a clean bill of health. The data was accurate. The classification codes were Uniclass 2015. The component count matched the equipment schedule. By every contractual measure, the handover was successful. The problem was not the data quality. The problem was that nobody on the operations side had a path from a physical asset they could touch to a record in a system that matched how they actually worked.

This post is about that gap — the one between what COBie, IFC, and the vendor digital-twin platforms promise at PC2 and what actually survives the transition into day-to-day operations. We will work through the technical architecture of each handover format, the real-world failure modes that cause FM teams to revert to spreadsheets and ring binders, and the handover design patterns that give structured data a fighting chance of remaining useful past the two-year mark.

What's actually happening

The AIM versus the PIM: ISO 19650's two-model world

ISO 19650-3:2020, which governs information management during the operational phase, draws a clear line between the Project Information Model and the Asset Information Model. The PIM is what gets built during design and construction: the federated models, the COBie exports, the specification data. The AIM is what operations inherits: a maintained, queryable record of the physical asset as built and as currently configured.

In principle the AIM is the PIM at practical completion, plus operational updates over time. In practice the gap between the two is where the 1.4 GB spreadsheet lives unopened.

The ISO 19650-3 operational phase requirements define what an AIM should contain: asset registers, maintenance records, condition data, performance data, configuration change history. They do not specify the file format, the software, or the exchange standard. That is left to the Asset Information Requirements (AIR) that each client is supposed to write before the project starts. In the UK, the UK BIM Framework provides guidance templates for AIR preparation; the GSA BIM Guide Series in the US does equivalent work on the owner side.

The problem is that most AIRs are written by the client's project team — not by the FM or operations team that will use the AIM for the next thirty years. The result is an AIR that specifies COBie because COBie is in the framework, IFC because IFC is what BIM people know, and vendor platform compatibility because the IT department has an IBM Maximo licence. None of those specifications connect to the actual question: what does a site engineer need when a fan coil unit fails at 2 a.m.?

COBie: what it is and what it is not

COBie — Construction Operations Building Information Exchange — was developed by Bill East at the US Army Corps of Engineers. Its core idea is sound: capture the asset information that design and construction teams already produce (equipment schedules, warranty records, commissioning data) in a structured format that FM systems can import, rather than having it evaporate into PDF binders and CDE archives at handover.

COBie 2.4 — the version most UK and US federal projects contractually require — presents as an Excel spreadsheet with sixteen worksheets: Contact, Facility, Floor, Space, Zone, Type, Component, System, Assembly, Connection, Spare, Resource, Job, Document, Attribute, Coordinate. The data model is relational: Component rows reference Type rows by name, Type rows reference Contact rows by email, Space rows reference Floor rows by name. buildingSMART International's COBie documentation makes explicit that COBie is a Model View Definition (MVD) of IFC — a curated subset of IFC properties presented in spreadsheet form for FM system consumption.

NBIMS-US V3 specifies COBie as a required handover format for US federal projects. The GSA BIM Guide extends this to GSA-contracted buildings. UK BIM Level 2, formalised under PAS 1192-2:2013 and its successor BS EN ISO 19650-2:2018, mandates COBie data drops at each project stage. The requirement is widespread enough that most mid-to-large AEC projects in English-speaking markets now have COBie in the contract.

What COBie is not: a live database, a spatial query engine, a mobile interface, a work-order system, or a document management system. COBie is an exchange format. It is the truck that delivers the furniture; it is not the house. Once the CAFM system has imported the COBie data, the CAFM is the system of record, and the COBie spreadsheet is an archive. If the CAFM import fails, or if the CAFM is not set up to receive the data, or if the data in COBie does not match the vocabulary the CAFM uses — the truck arrives and nobody opens the door.

IFC 4.3 for FM: the asset profile

IFC 4.3, published by buildingSMART International in 2022 and adopted as ISO 16739-1:2024, is the current IFC release. For FM purposes, the relevant concepts are IfcAsset, IfcFacility, IfcZone, IfcSystem, and the property sets defined in the IFC 4.3 Asset Information delivery profile.

IfcAsset is the IFC entity for a maintainable asset. Unlike COBie's Component row — which is a flat record in a spreadsheet — an IfcAsset is an object in a typed schema. It carries relationships: it belongs to a system (IfcRelAssignsToGroup), is located in a space (IfcRelContainedInSpatialStructure), has properties (IfcRelDefinesByProperties), has documents attached (IfcRelAssociatesDocument), and has a type (IfcRelDefinesByType linking to IfcAssetType or IfcTypeObject). The spatial hierarchy is IfcFacility → IfcFacilityPart → IfcSpace, mirroring COBie's Facility / Floor / Space structure but expressed as a typed graph rather than cross-referenced strings.

The IFC 4.3 Asset Information Model (AIM) delivery defines a reference view that specifies which IFC entities and property sets must be present for an AIM-compliant delivery. The property sets for FM include Pset_ManufacturerTypeInformation (manufacturer, model, serial number), Pset_MaintenanceStrategy (maintenance cycle, maintenance type), Pset_Warranty (warranty start date, duration), and Pset_AssetInformation (expected life, replacement cost).

This is, on paper, richer than COBie. The schema is self-describing; FM systems that can read IFC natively do not need a mapping table to understand what IfcAsset.Name means. The graph structure captures assembly relationships (a boiler contains a burner, a heat exchanger, a controls panel) in a way that COBie's Assembly sheet rarely achieves in practice. And IFC files can carry spatial geometry: an FM technician using an IFC-native viewer can navigate to the physical location of an asset in 3D, not just find its room number in a spreadsheet.

The practical problem is that very few CAFM systems read IFC natively. IBM Maximo Application Suite has a BIM-IFC connector, but it maps IFC properties to Maximo's internal asset schema through a configuration layer that must be set up by an implementation specialist. Planon and Archibus support IFC import in specific versions, with similar configuration requirements. FM:Systems has a BIM integration module. In each case, "supports IFC" means "can be configured to import certain IFC properties given a trained implementation team and a well-documented IFC file structure." It does not mean "open file, press import, done."

The vendor platform landscape

The digital-twin platform market has consolidated around a small number of dominant players, each approaching the problem from a different starting point.

Autodesk Tandem, built on the Autodesk Platform Services (APS) infrastructure (formerly Forge), is Autodesk's answer to the AIM problem. Tandem ingests Revit models and IFC files, extracts asset data, and presents it as a queryable database with a spatial viewer. The platform uses the Autodesk viewer for 3D navigation and adds a "Facility" layer where assets are linked to their physical location. Tandem supports COBie import and IFC import, and has REST APIs for integration with third-party CMMS systems. Its differentiation is the direct pipeline from Revit: teams already using BIM 360 or Autodesk Construction Cloud can push data to Tandem without format conversion.

Bentley iTwin, built on iModel.js and the Bentley iTwin Platform, takes a different approach. An iModel is a SQLite database containing a representation of the physical asset — geometry, properties, relationships — that can be queried like a database rather than viewed like a 3D model. The iTwin Asset Information Manager imports IFC, processes it into an iModel, and provides a query layer where FM operators can ask structured questions ("which HVAC assets in Zone B are approaching warranty expiry?") without opening a model viewer. Bentley's focus is infrastructure and industrial assets as much as buildings — the iTwin platform serves rail, utilities, and industrial plant as well as real estate — which makes it a stronger choice for complex mixed-asset estates.

IBM Maximo Application Suite (MAS) is not a digital-twin platform in the traditional sense; it is a CMMS (Computerised Maintenance Management System) with a BIM integration layer. Maximo MAS manages work orders, preventive maintenance schedules, spare parts inventory, and condition monitoring. Its BIM connector allows Maximo asset records to be linked to IFC geometry, enabling technicians to navigate to a spatial view of an asset from within a work order. Maximo is the system of record for maintenance operations at many large estates; the digital-twin layer is a visualisation add-on, not the operational core.

Planon and Archibus are Integrated Workplace Management Systems (IWMS) that evolved from space planning and real-estate management tools into asset management platforms. Both have IFC and BIM integration capabilities, both support COBie import, and both are more commonly found in corporate real estate than in construction-intensive sectors. Their strength is portfolio-scale operations — managing 200 buildings from a single platform — rather than deep integration with BIM authoring tools.

The choice among these platforms is not primarily a technology decision. It is a data model decision: which platform's internal asset schema most closely matches the data that the COBie or IFC handover contains, and the operational vocabulary that the FM team uses day to day?

The pattern: how handover formats die in the field

The CMMS vocabulary problem

Every CAFM or CMMS has an internal asset taxonomy: a hierarchical classification of asset types, from "Mechanical Plant" down through "HVAC" to "Fan Coil Unit" to a specific model. COBie carries Uniclass 2015 or OmniClass classification codes. IFC carries IfcClassificationReference. But the CMMS's own hierarchy may have nothing to do with either classification system.

IBM Maximo uses its own Classification tree, maintained in CLASSSTRUCTURE and CLASSANCESTOR tables. Planon uses a hierarchical Product Catalogue. Archibus uses Activity Types. None of these internal taxonomies map directly to Uniclass 2015 or OmniClass Table 23 out of the box. The mapping has to be built — by the implementation team, in the CMMS configuration — before a COBie import can route an asset to the correct position in the CMMS hierarchy.

If that mapping is not built before the COBie import runs, one of three things happens: the assets are imported into a flat, uncategorised list (which the FM team cannot navigate); the import fails on the unmapped classifications (which generates errors that look like data quality problems even when the COBie data is correct); or the CMMS's default import logic assigns everything to a generic "Unknown" category that the FM team then has to manually reclassify — at a rate of maybe 200 assets per day for a team that also has a building to run.

The mobile interface problem

The maintenance engineer who needs to find the fan coil unit in room 3.07 is standing in the corridor with a tablet. They need to identify the asset, pull up its maintenance history, check if there is an open work order, verify the serial number, and confirm the model number before calling the supplier's technical helpdesk.

COBie is a desktop Excel spreadsheet. IFC is a file that requires a desktop or browser viewer with the full model loaded. Even vendor platforms — Autodesk Tandem, Bentley iTwin — present primarily as web applications that assume a reliable internet connection and a screen large enough to navigate 3D models.

The operations tools that field engineers actually use are purpose-built mobile CMMS apps: IBM Maximo Mobile, eMaint, Limble CMMS, ServiceMax. These apps are offline-capable, barcode/QR-scannable, and designed for a 5-inch screen in a plant room. The connection from a QR code on a fan coil unit to a structured asset record in one of these apps is not automatic. It requires: an asset tag strategy (who prints the QR codes, in what format, with what data encoded), an asset record in the CMMS (imported from COBie or built manually), and a link between the physical tag and the CMMS record (which means the COBie Component Name or CMMS asset number is encoded in the QR code, and the QR code scanner opens the right CMMS screen).

None of this is specified in a COBie handover. None of it is automatic in an IFC handover. It is project-specific integration work that usually happens — if it happens at all — twelve to eighteen months after practical completion, funded from the operations budget by a team that was not involved in the BIM handover conversation.

The static versus live twin problem

COBie and IFC at practical completion describe the building as built. They do not update as the building operates. Assets get replaced. Spaces get repurposed. New equipment is installed. Maintenance reveals that the as-built condition differs from the construction record. Three years after PC2, the gap between the AIM and the physical building begins to widen.

This is the difference between a static digital twin and a live digital twin. A static twin is a snapshot: accurate at the moment of capture, increasingly unreliable as time passes. A live twin connects to the building's operational systems — IoT sensors, CMMS work orders, BMS condition data, SCADA for critical plant — and updates continuously.

Autodesk Tandem's IoT connector and Bentley iTwin's IoT integration both support sensor data feeds via REST or MQTT. IBM Maximo integrates with IoT sensor data through the Maximo Monitor module, using IBM Watson IoT as the connectivity layer. These integrations exist. They are real. They also require IoT infrastructure — sensors on the assets, a connectivity layer (typically an OT/IT gateway bridging the building's BACnet or Modbus network to an IP-addressable stream), and an integration layer mapping sensor readings to specific asset records in the twin.

On a standard commercial or healthcare building, that OT/IT gateway and IoT sensor layer is not included in the construction contract. It is a separate systems integration project, typically scoped and funded separately from BIM, and typically happening on a different programme timeline. The digital twin that the BIM team hands over at PC2 is almost never live — it is static by default. Whether it becomes live depends on whether the operations team has budget, integration expertise, and executive sponsorship to connect it.

The data attribute mismatch problem

COBie's Component sheet carries these fields for an individual asset: Name, TypeName, Space, Description, SerialNumber, InstallationDate, TagNumber, BarCode, AssetIdentifier, WarrantyStartDate. The IFC equivalent on an IfcAsset carries similar properties plus geometry.

A Maximo asset record carries: Asset Number, Description, Asset Type, Classification, Site, Location, Serial Number, Model Number, Vendor, Warranty Expiry, PM Schedule, Status, GL Account, Purchase Price, Replacement Cost, Parent Asset, and dozens of custom fields added by the implementation team. A Planon Equipment record carries: Code, Name, Standard Object Type, Main Asset Type, Manufacturer, Model Number, Location, Responsible Department, Expected Replacement Date, and a configurable extended attribute set.

The overlap between what COBie delivers and what the CMMS expects is significant but not complete. COBie does not carry GL account codes. It does not carry replacement cost in a field the CMMS always recognises (COBie has ReplacementCost in the Type sheet; whether that field imports to the CMMS replacement cost field depends on the mapping). It does not carry the responsible department or the business unit that owns the maintenance budget. These fields have to be populated in the CMMS separately — either by manual entry or by a data migration from the client's existing asset register.

If the client has a legacy CMMS with 15,000 asset records from their previous building, and the new building COBie delivers 28,000 records, the operations team needs to reconcile the old records (some of which may still be relevant for shared infrastructure) with the new records. COBie gives them no help with this reconciliation. It is a data migration project that arrives on the FM team's desk on the same day as practical completion, funded by nobody, owned by nobody, and competing with the immediate operational demands of a building that just started.

The fix: handover design that survives PC2

Pre-PC2: define the AIM before the PIM starts

The single most impactful intervention is writing the Asset Information Requirements before the BIM Execution Plan is finalised — not after. The AIR specifies what information the operations team needs, in what format, mapped to the specific CAFM or CMMS that will receive it.

A useful AIR for FM handover answers these questions:

1. What CAFM or CMMS system will receive the handover data? What is its version? Who is the vendor contact for import support?
2. What is that system's asset classification hierarchy? How do Uniclass 2015 or OmniClass codes map to that hierarchy?
3. What fields in the CAFM are mandatory for a PM schedule to be created? (These fields must be in the COBie or IFC export.)
4. What is the naming convention for assets in the CAFM? Does it match COBie's Component.Name format?
5. What is the mobile field interface? How are assets identified in the field — QR codes, NFC tags, barcodes? What data is encoded on the tag?
6. Which assets will have IoT sensors at or after PC2? Who is responsible for the OT/IT integration?
7. What is the document delivery format? Where will O&M manuals live after the CDE is archived?

The Penn State BIM Execution Planning Guide recommends that the Facility Management BIM use case be specified at project start, with explicit workflows for asset data collection, validation, and handover. Most projects skip this step and treat FM as a handover deliverable rather than a project-long data management discipline.

1. Step 1 — Engage the FM team and CAFM vendor at project inception

   Before any BIM content is produced, hold a one-day workshop with: the client's facilities manager, the CAFM system administrator, the BIM Manager who will own the PIM, and the FM integrator who will run the handover. Outputs: CAFM field-mapping matrix (COBie / IFC field → CAFM field), asset classification mapping (Uniclass / OmniClass → CAFM hierarchy), document delivery specification (file format, folder structure, naming convention), mobile field interface specification (tag type, data encoded, CMMS workflow), IoT scope (which assets, which sensors, who integrates).

2. Step 2 — Write the AIR from workshop outputs

   The AIR is a contractual document issued with the Employer's Information Requirements. It specifies: required COBie sheets at each data drop milestone, mandatory field completeness by asset category, classification code system (pick one — Uniclass 2015 or OmniClass Table 23, not both), attribute vocabulary for custom FM data, document delivery method, and CAFM compatibility test procedure. Reference: ISO 19650-3:2020 Section 5.2 on asset information requirements.

3. Step 3 — Establish the canonical asset type list at Stage 3

   Before any consultant issues a COBie data drop, establish a canonical asset type list: the exact Type.Name strings that all COBie authors will use, each mapped to its Uniclass 2015 code and its CAFM asset category. Version-control this list. Distribute a shared-parameter file to all Revit authors mapping Type.Name to the canonical string. Every downstream referential integrity failure in the COBie dataset traces back to Type.Name inconsistency between disciplines — this list prevents that failure at source.

4. Step 4 — Run pilot CAFM import at RIBA Stage 5 (or equivalent)

   Generate a pilot COBie dataset covering one floor or one system — 100 to 200 Component records. Run it through the actual CAFM import path, end to end: import, classification mapping, PM schedule creation, work-order generation for one asset, mobile lookup via the field app. Document every failure. Resolve each before the final dataset is produced. This is the only test that verifies the full handover chain under conditions that resemble production.

5. Step 5 — Select handover format based on CAFM capability, not BIM team preference

   COBie XLSX is the path of least resistance only if the CAFM has a working COBie import. If the CAFM natively reads IFC (uncommon but not impossible), an IFC 4.3 AIM delivery profile export may be richer. If the client is investing in a vendor digital-twin platform (Autodesk Tandem, Bentley iTwin), the handover format should be whatever that platform's ingestion pipeline expects — which is typically a specific IFC export configuration from Revit or Bentley tools, not a generic COBie XLSX. Do not deliver COBie to a Tandem project or an IFC file to a Maximo-only installation without validating the import path first.

At PC2: the practical completion data handover

The moment of handover is the highest-risk point in the AIM lifecycle. The construction team is demobilising. The operations team is taking over a building they have never operated. The pressure to declare success and move on is intense. This is the moment to slow down and verify, not to trust that validation tools caught everything.

A structured PC2 data handover procedure covers the following verification steps:

Format verification. Run the COBie XLSX through the NIBS Checker (or buildingSMART Standard Checker for UK projects) and confirm the error count is zero or within agreed thresholds. For IFC deliveries, run through Solibri Model Checker with FM-specific rule sets enabled. For vendor platform deliveries (Tandem, iTwin), verify that the model appears in the platform with correct asset counts before the contractor demobilises.

Count verification. The Component sheet row count (minus header) must match the agreed equipment schedule. On a project with 28,000 assets, a 5 percent variance (1,400 missing or extra records) is not acceptable. Count by system category: mechanical, electrical, specialist. Any significant variance requires investigation before sign-off.

Sample asset round-trip. Select 20 assets at random across asset categories, floors, and disciplines. For each: find the Component record in COBie; find the matching Type record; verify that the warranty data, serial number, and installation date are present; run the CAFM import for those 20 records; verify that the PM schedule populates correctly; navigate to the asset in the vendor platform or IFC viewer; confirm the spatial location matches the physical installation. If the sample fails, the full dataset is not ready for handover.

Document link verification. For 10 percent of Document records, verify that the linked file is accessible from the delivery path. If the delivery uses a file share, verify the share is accessible from the FM team's network. If the delivery uses a vendor platform's document store, verify that the link opens in the platform. CDE URLs that will expire must be resolved to file paths before handover.

Mobile round-trip test. Using the actual mobile CMMS app and a test device, scan the QR code or barcode on a physical asset in the building. Verify that the scan opens the correct CMMS record. Verify that the record shows the PM schedule, the serial number, and a document link that resolves. This test is the only way to confirm that the QR-code-to-CMMS-record link was set up correctly.

Post-PC2: keeping the AIM alive

The AIM is not a deliverable. It is an operational system. Its accuracy degrades from the moment of handover unless someone owns the process of keeping it updated.

Asset replacement is the most common degradation vector. When a fan coil unit fails and is replaced with a different model, the CAFM record should be updated: serial number, model number, warranty start date, potentially the Type record if the replacement is a different product. In practice this update depends on whoever closes the work order remembering to update the asset record — which happens reliably only if the CMMS workflow makes the update mandatory and the field engineer has the information on hand.

The organisations that maintain AIM accuracy beyond the first two years have three things in common. First, the FM manager owns a named role in the organisation chart: "asset information manager" or equivalent. This person is responsible for AIM quality, not as an additional duty but as their primary function. Second, every work order closure for an asset replacement or modification includes a mandatory field: "has the asset record been updated?" The work order cannot close without a yes. Third, the AIM is audited annually: a sample of 100 assets is physically verified against their CAFM records, and discrepancies are documented and resolved.

None of these practices requires expensive technology. They require organisational commitment to treating asset information as a managed asset in its own right.

Anti-patterns

Anti-pattern 1: Treating COBie as the end state

COBie is a delivery format. The FM team does not work in COBie. They work in their CMMS, their mobile app, their work-order system. A project team that celebrates COBie delivery without verifying CAFM import is celebrating the truck delivery, not the furniture in the room.

The fix: define success at PC2 as "PM schedules are generating work orders in the CMMS for the top 20 asset categories" — not as "COBie validation passed."

Anti-pattern 2: One-size digital twin platform

The vendor platform decision — Autodesk Tandem, Bentley iTwin, IBM Maximo — is made by the client's IT procurement team based on enterprise licences, vendor relationships, and what the BIM team is familiar with. The FM team's actual workflow is not consulted. The result is a platform that the design and construction team can demonstrate impressively but that the FM team cannot navigate to find the asset they need.

Autodesk Tandem is powerful for clients already in the Autodesk ecosystem with BIM 360 or ACC workflows. It is an additional platform to manage for an FM team whose daily work is in ServiceMax or IBM Maximo. Bentley iTwin is excellent for infrastructure-heavy estates and for clients who want programmatic asset queries. It is not intuitive for a site engineer whose IT skills run to a mobile CMMS app and a spreadsheet. IBM Maximo MAS is a CMMS first and a digital twin second; for clients whose operations are maintenance-management-intensive, that is the right order of priority.

The fix: select the platform based on the FM team's workflow, not the BIM team's familiarity. Demo the platform to the site engineer who will use it daily, not to the IT director who approves the purchase.

❌ Anti-pattern: BIM team selects Autodesk Tandem because the project is on ACC
   Why it fails: FM team uses IBM Maximo. Tandem has a Maximo connector but it
   requires configuration that was not scoped. FM team never connects the platforms.
   Tandem is used as a 3D viewer twice a year. Maximo runs independently.
   
   Do instead: At project inception, confirm whether Tandem-Maximo integration is
   in scope. If not, either add it to scope with a budget, or accept that Tandem
   is a standalone viewer and plan accordingly. Do not create an integration
   dependency that has no funding.

Anti-pattern 3: IFC as the handover format without a native IFC CAFM

IFC 4.3 with the AIM profile is richer than COBie for expressing asset relationships, property sets, and spatial context. But "rich" is only useful if the receiving system can consume the richness. Delivering an IFC 4.3 file to an FM team whose CAFM is Archibus running a version with partial IFC support means delivering a file that Archibus will import with significant property loss — silently, without error messages, because the IFC is valid; Archibus simply ignores the properties it does not map.

The fix: before specifying IFC as the handover format, obtain the CAFM vendor's published IFC import compatibility matrix. Identify which IFC entities and property sets are imported, which are ignored, and which cause import failures. Deliver only the IFC content the CAFM can consume; supplement with COBie or direct field population for everything else.

Anti-pattern 4: COBie data drops not consumed until PC2

Most projects that require COBie data drops at RIBA Stages 3, 4, and 5 treat those drops as archival records rather than validation events. The Stage 3 drop is filed. The Stage 4 drop is filed. Nobody runs the FM integrator's import against the Stage 4 data. At PC2, the FM integrator runs the import for the first time and discovers that the Stage 3 spatial hierarchy conflicts with the Stage 5 component data because the room numbering changed during construction and was never reconciled.

The fix: run the CAFM import — or at least a pilot import — at each data-drop milestone. The Stage 4 pilot import is not for operations; it is a validation event. If it fails, the failures are resolved while the construction team is still active and the data owners are identifiable.

Anti-pattern 5: Vendor platform demo data is not production data

Every digital-twin platform vendor demonstrates their product on a model that has been pre-configured, pre-cleaned, and pre-connected to working sensors. The demo shows assets populating with live temperature readings, work orders generating from condition thresholds, technicians navigating in 3D to the exact asset location. The demo is real — the platform can do these things — but it does not show the configuration effort required to get there.

Autodesk Tandem's getting started documentation estimates that model setup for a complex building takes two to six weeks of platform configuration. Bentley iTwin iModel creation requires iModel Bridge configuration that maps the source model's schema to the iModel schema — a process that requires an iModel.js developer. IBM Maximo's BIM-IFC connector requires Maximo Configuration framework expertise, which is a distinct certification track from Maximo implementation.

The fix: before committing to a vendor platform, scope the implementation effort independently, not from the vendor's pre-sales estimate. Talk to an organisation that has run the platform in production for two or more years on a building of comparable complexity.

Case studies and numbers

Case study 1: NHS trust, static AIM, manual reconciliation

A 12-ward acute hospital in the north of England. PC2 in 2021. COBie 2.4 delivered — 31,400 Component records, Uniclass 2015 classified, schema-valid. The FM team used IBM Maximo 7.6.1. There was no Maximo COBie import module configured; the Maximo implementation team had not been consulted during the project.

The FM integrator spent eleven weeks manually importing assets into Maximo by copying data from the COBie XLSX into Maximo's asset creation form. Average throughput: 280 records per day. At 31,400 records, the theoretical import time was 112 days of full-time work. In practice the team worked on Maximo import part-time while also managing building commissioning tasks; the full import was not complete until fourteen months after PC2.

During those fourteen months, the building operated on a paper-based PM schedule. Several warranty periods ran for six to eight months without any PM records attached, which created a warranty-claim risk for assets that had maintenance-related failures during the period.

The cost of the manual import (contracted FM integrator time) was approximately £68,000. A configured Maximo COBie import module, had it been scoped at project inception, would have been approximately £22,000 — including configuration, testing, and a pilot import at Stage 5. The delta was £46,000 in additional cost and fourteen months of operational risk. In our observation of this project, neither the project team nor the client drew a direct line from the missing import configuration to the cost overrun, because the costs appeared in different budget lines (construction vs. operations) and at different times.

Case study 2: Commercial estate, Autodesk Tandem pilot

A 220-person property company piloted Autodesk Tandem on three buildings from a portfolio of 65 commercial offices. The pilot scope was defined as: ingest the construction-phase Revit models, establish asset records for mechanical plant, link to a live BMS feed for chiller performance data, and surface chiller condition in the Tandem dashboard.

The Revit ingestion worked smoothly for two of the three buildings. The third had a Revit model produced by a sub-consultant using a non-standard MEP template; the Tandem ingestion pipeline extracted incomplete property sets for mechanical equipment. The FM team manually supplemented approximately 340 asset records in the Tandem interface.

The BMS integration — mapping the BMS point list to Tandem asset records — took six weeks of systems integration work from a building controls specialist. The BMS used BACnet IP; the integration team built a custom OPC-UA to Tandem REST adapter. The adapter cost approximately $34,000 (USD) in development time. This cost had not been in the Tandem pilot budget; it was funded from a contingency reserve.

The outcome after twelve months: the Tandem dashboard shows live chiller operating data for two of the three pilot buildings. Energy managers use it weekly for performance trend review. The maintenance team does not use Tandem for reactive maintenance; they continue to use their existing ServiceNow CMMS for work orders. The Tandem-ServiceNow integration remains unbuilt due to budget constraints.

The pilot demonstrates a pattern that recurs across vendor platform deployments: the visualisation and monitoring layer works, the operational integration (work orders, maintenance scheduling, reactive maintenance lookup) does not get built because it requires CMMS integration funding that was not in the original scope.

Case study 3: University estate, IFC 4.3 AIM delivery

A research-intensive university building, 14,000 m², PC2 in 2023. The client specified IFC 4.3 AIM profile delivery alongside COBie 2.4, with the intent of feeding the IFC into Bentley iTwin for the asset database and COBie into their legacy CAFM (a Planon installation).

The IFC 4.3 export from Revit required a custom export configuration using the Revit IFC Export plug-in (open-source, maintained by buildingSMART) with specific property sets mapped for FM: Pset_ManufacturerTypeInformation, Pset_Warranty, Pset_MaintenanceStrategy, and a project-specific property set for university maintenance codes. The export configuration took the BIM manager three days to produce and validate in Solibri.

The Bentley iTwin iModel creation from the IFC file was carried out by an iTwin implementation partner. The iModel creation took four weeks, primarily because the IFC file's IfcZone population was incomplete — the mechanical equipment had not been assigned to zones during BIM production, and the iTwin data model relies on zone assignment for maintenance planning queries. The zones were added retrospectively by the iTwin partner, working from the project's spatial planning documentation.

The Planon COBie import ran successfully for spatial data (spaces, floors, zones) but imported only 60 percent of the mechanical plant records correctly. The remaining 40 percent had Uniclass codes that Planon's asset type mapping did not recognise — the BIM team had used the Pr_65 sub-table at five levels of specificity that Planon's mapping table had only configured to three levels. The Planon administrator spent three weeks extending the mapping table.

Twelve months post-PC2: the iTwin platform is used by the university's estates technology team for capital planning queries — specifically, asset replacement cost forecasting. The Planon installation is used for day-to-day maintenance management. The two systems are not integrated; data does not flow between them. The university has identified the integration as a priority for their next IT investment cycle but has not funded it.

Limits and caveats

This post cannot tell you which platform to choose

The choice between Autodesk Tandem, Bentley iTwin, Maximo MAS, Planon, Archibus, FM:Systems, or a custom integration is highly dependent on factors this post cannot see: your existing enterprise software stack, your client's IT governance, your FM team's technical capability, your budget, and your operations workflow. The post can help you ask better questions. It cannot answer them on your behalf.

The comparison above reflects the state of these platforms as of mid-2026. The vendor platform space is moving quickly. Autodesk Tandem added bidirectional CMMS integration in late 2025; Bentley iTwin's iModel creation pipeline was substantially simplified in iTwin Platform 4.0; IBM Maximo MAS 9.0 shipped a significantly reworked IFC connector. By the time you read this, some of the friction points described in the case studies may have been resolved.

COBie is not going away

There is a recurring narrative in the AEC digital-twin space that COBie is a legacy format that IFC and smart platforms will replace. This is not accurate for the medium term. COBie is contractually mandated on US federal projects under GSA guidance and on UK government projects under the UK BIM Framework Level 2 mandate. Changing a contractual requirement takes years, not product cycles. COBie 2.4 will be the required handover format on projects contracted today for years to come, regardless of what the vendor platforms support.

IFC 4.3's AIM profile is the technical future of structured handover, but CAFM market adoption of native IFC import is still limited in 2026. The gap between the standard's capability and the market's implementation is real and consequential for projects happening now.

The live twin is expensive and requires sustained commitment

The IoT-connected, continuously updated live digital twin is technically achievable. It is also a multi-year, multi-party programme that costs significantly more than the construction-phase BIM delivery. The OT/IT gateway, the sensor hardware, the integration development, the operational data governance, and the ongoing maintenance of the integration infrastructure are not trivial. Organisations that have live twins that actually work in operations have sustained a programme commitment over three to five years with dedicated technical staff.

For most FM operations, a well-maintained static AIM — accurate, accessible from the mobile CMMS, updated on asset change — delivers more operational value than a partially implemented live twin where the integration budget ran out before the work-order system was connected.

Data quality is a people problem, not a technology problem

No vendor platform, no IFC standard, and no COBie validation tool resolves the fundamental challenge: the data that enters the AIM is only as good as the people who captured it during design and construction. If the commissioning team records serial numbers from the packaging (which is sometimes incorrect) rather than from the nameplate, the AIM has wrong serial numbers. If the M&E consultant's Revit model does not have warranty durations populated because the shared-parameter setup was done by a junior technician who left the project at Stage 4, the AIM has no warranty data. If the space names changed during construction and the M&E component records still reference the old space names, the CAFM cannot locate 15 percent of the assets.

These are people, process, and contract problems. They are solved by AIRs that specify field-level requirements, BEPs that assign data ownership, milestone validations that surface gaps when there is still time to fix them, and contracts that make data quality a completion condition — not a courtesy.

Sources and further reading

The following primary sources informed this post. All URLs were verified accessible at time of writing (June 2026).

• ISO 19650-3:2020 — Organization and digitization of information about buildings and civil engineering works, including building information modelling (BIM) — Part 3: Operational phase of assets — The international standard governing information management during the operational phase. Defines the Asset Information Model concept, AIR requirements, and the AIM lifecycle. Essential reading for any FM handover programme.

• buildingSMART International — IFC 4.3 documentation — The authoritative technical reference for IFC 4.3, including the IfcAsset, IfcFacility, and FM-relevant property set definitions. The Asset Information Model (AIM) delivery view is specified within this documentation.

• NIBS — COBie (Construction Operations Building Information Exchange) — The National Institute of Building Sciences' COBie project page, including links to the NBIMS-US V3 specification, COBie 2.4 downloads, and the COBie V3 development update. The primary US source for COBie requirements.

• GSA BIM Guide Series — The US General Services Administration's BIM Guide, which specifies COBie requirements for federally funded buildings. The FM use case guide is directly relevant to AIM handover.

• UK BIM Framework — Guidance for clients — The UK government's BIM Framework, providing guidance on ISO 19650 implementation, Asset Information Requirements, and COBie handover for UK publicly funded projects.

• Penn State BIM Execution Planning Guide — The leading reference for BIM Execution Planning in the US. The Facility Management use case section provides a detailed workflow for AIM data collection, validation, and handover.

• Autodesk Tandem — Platform documentation — Autodesk's technical documentation for Tandem, including model ingestion, asset data APIs, and IoT connector configuration. Verified as the current production documentation as of June 2026.

• Bentley Systems — iTwin Platform — Bentley's iTwin platform documentation, covering iModel creation, Asset Information Manager, and IoT integration. The iModel.js open-source documentation at itwinjs.org provides the technical detail for custom integrations.

• IBM Maximo Application Suite — IBM's Maximo product page and documentation hub. The BIM-IFC connector documentation is within the Maximo Manage component. The Maximo Monitor module documentation covers IoT sensor integration.

• AECbytes — Building information for architecture, engineering, and construction — The primary trade publication for practitioner-level AEC technology analysis. Several long-form assessments of digital twin platform implementations in real estate and infrastructure operations are available in the archives.

• ISO 16739-1:2024 — Industry Foundation Classes (IFC) for data sharing in the construction and facility management industries — The ISO publication of IFC 4.3 as an international standard. Referenced by procurement authorities requiring standards-compliant IFC delivery.

• buildingSMART International — COBie standard documentation and certification — buildingSMART's COBie documentation, including the Model View Definition (MVD) that defines COBie as a view of IFC, and the COBie Certified Professional (COBie CP) examination reading list.