A BIM-to-COBie mismatch that cost a project six weeks

The six-week delay nobody planned for

The practical completion certificate was issued on a Thursday. By Friday morning the FM integrator had run the COBie spreadsheet through their validation tool and filed a non-conformance. By Monday the client had called a meeting with the principal designer, the mechanical contractor, and the BIM manager. By Wednesday it was clear nobody was moving into the new ward block on schedule.

The project was a 450-bed district general hospital in the UK. Design development had taken thirty months. Four separate consultant teams — architect, structural engineer, mechanical and electrical engineer, and a specialist facade contractor — had all been modelling in Revit, exporting partial COBie drops at data-drop milestones as required by the Employer's Information Requirements. The final federated dataset was supposed to land in the client's CAFM system within seventy-two hours of practical completion. Instead, the CAFM vendor's import script threw 2,847 errors on first pass, and the validation report highlighted a single underlying cause that cascaded through the entire asset register: the Type.Name field was populated with fourteen different strings for what was, operationally, the same piece of equipment.

A condensate pump in the mechanical engineer's model was Condensate-Pump-Inline. The same pump in the contractor's model — where serial numbers and commissioning data had been added during construction — was Inline Condensate Pump. The CAFM import expected a one-to-one match between Component.TypeName and Type.Name. It did not get one. Every component linked to a mismatched type became an orphan record. That was 312 pumps, 88 boiler types, and 197 valve assemblies. The FM team could not load preventive maintenance schedules for any of them. The facilities manager could not generate work orders. The ward could not open until the asset register was complete.

The remediation took six weeks. Two of those weeks were pure data archaeology: going back into four models, re-mapping type names against a canonical list that should have existed from day one, re-exporting the COBie drops, re-running federation, re-validating, re-importing. The other four weeks were contractual: determining whose scope the remediation fell under, getting change orders agreed, and scheduling the physical access needed to verify that the records matched the installed equipment.

This post is a practitioner's account of what went wrong, what the data tells us in retrospect, and — most importantly — the specific workflow changes that would have caught this class of error at week four of design development rather than week one of building occupation.

We will work through the COBie data model in enough depth that you can reason about where mismatches live, then walk the hospital project's specific failure chain step by step, then describe the pre-flight checks, canonical type list strategy, cross-consultant audit process, and shared-parameter approach that make this failure class largely preventable.

What COBie actually contains

Origins and purpose

COBie — Construction Operations Building Information Exchange — was developed by Bill East of the US Army Corps of Engineers in 2007. Its core insight was both obvious and underappreciated: enormous amounts of facility operations data are generated during design and construction, but almost none of it reaches the FM team in a usable form. O&M manuals arrive as PDF binders. Equipment schedules come as spreadsheets with no consistent naming. Serial numbers are hand- written on commissioning certificates that get lost in transit. COBie is the attempt to intercept that data at the point of creation — in the BIM model, in the specification, in the commissioning record — and deliver it as structured, validated, importable information.

Version 2.4, published as part of the National BIM Standard United States Version 3 in 2015, is the version most BIM Execution Plans reference today. It defines the spreadsheet presentation of COBie as the primary delivery format, though IFC, ifcXML, and COBieLite are also supported. NIBS is currently developing COBie V3 as part of NBIMS-US V4, reorganising the tables and adding new sheets for Risk, Event, and Package data — but for any project that started before 2025, COBie 2.4 is almost certainly what is contractually required. The technical architecture of the problem we are discussing is native to version 2.4.

The sixteen sheets

A COBie 2.4 spreadsheet has sixteen primary worksheets. Understanding what each one contains and how they link is not optional knowledge for a BIM manager overseeing handover — it is the minimum reading required to do the job.

Contact is the address book. It holds company and individual contact records for every organisation involved with the project: architect, structural engineer, M&E consultant, subcontractors, manufacturers, suppliers. Every other sheet that references a company or person — Type.Manufacturer, Component.CreatedBy, Document.ApprovalBy — is a foreign key lookup into Contact.Email. If a manufacturer's contact record is missing from the Contact sheet, every Type record for their products will fail validation on that reference field.

Facility is the top-level record for the building. It holds the project name, description, phase, measurement units, linear units, currency, area units, and geographic coordinates. There is one row per building or infrastructure asset. The Facility record is the anchor for all spatial hierarchy below it.

Floor holds the level records — every storey, basement, roof, and site level that contains maintainable assets. Each Floor record has a name, elevation above datum, and height. Space records reference Floor by name. If a floor name in the Floor sheet does not exactly match the floor reference in a Space record, that space is unlocated.

Space is the room and area register. Every space where maintainable equipment lives must appear here: plant rooms, riser cupboards, corridor sections, ward bays, car parks. Fields include gross area, net area, usable height, and the floor-level reference. Component records reference Space by name to establish where an asset is installed. Missing or incorrectly named spaces mean components cannot be located — a common failure mode in large healthcare projects where room numbers change during design development and the change is not propagated to the COBie export.

Zone groups spaces that share an operational function: a fire zone, an air-handling zone, a department. A space can belong to multiple zones. Zones are important for FM planning because preventive maintenance is often scoped and scheduled at zone level rather than individual component level.

Type is the product catalogue. This is the single most important sheet in the handover context and the one most frequently broken. Each row in Type defines a product class: a particular model of air-handling unit, a specific boiler series, a valve type. Fields include the manufacturer name (referencing Contact), model number, warranty duration, warranty guarantee period, replacement cost, expected life, nominal length, nominal width, nominal height, and shape. The Type.Name field is the primary key: every Component record that is an instance of this product class will reference it. If you have thirty identical inline condensate pumps installed across six plant rooms, there is one Type row and thirty Component rows. The Type row carries the warranty, the datasheet, the manufacturer contact. The Component rows carry the serial number, the space location, the installation date.

Component is the individual asset register. One row per installed, maintainable item. Key fields: Name (unique identifier for this physical instance), TypeName (foreign key to Type.Name), Space (foreign key to Space.Name), SerialNumber, InstallationDate, WarrantyStartDate, TagNumber. The integrity of the entire asset register depends on Component.TypeName matching Type.Name exactly — case-sensitively, character-for-character. No trailing spaces. No hyphen/space variations. No abbreviated vs. spelled-out forms.

System groups components that together provide a service: the domestic hot water system, the sprinkler system, the main low-voltage switchgear. A component can belong to multiple systems. The System sheet is how the FM team navigates from an operational failure — "DHW system in Block B has lost pressure" — to the specific components that constitute that system.

Assembly records the parent-child relationships between components: a boiler module contains burner, heat exchanger, controls panel, and expansion vessel, each of which is also a separately maintained component. Assembly is often the most sparsely populated sheet because it requires a clear decomposition strategy agreed between the design consultant and the contractor during design — and that conversation rarely happens.

Connection records logical links between components: the pipe connection between a pump and a heat exchanger, the cable connection between a distribution board and a luminaire. In well-executed healthcare projects these connections support downstream maintenance planning — when component A fails, what else is affected? In practice, Connection is rarely populated correctly because it requires coordination between M&E disciplines that typically do not share a common component naming convention.

Spare records the field-replaceable units for each Type: replacement belts, filter cartridges, control boards, impellers. Fields reference the Type record and include the supplier's part number, set number, trade name, and description. A well-populated Spare sheet means the FM team can immediately identify and order the correct part when an asset fails, without reverse-engineering the manufacturer's parts catalogue from a paper manual.

Resource records the labour, specialist tools, or training required to complete a maintenance task. Resource rows are linked to Job rows, enabling the FM system to calculate the true cost of a planned maintenance schedule.

Job is the planned maintenance schedule. Each row is a maintenance task: a description, the Type it applies to, the task category (planned, reactive, condition-based), the frequency, the duration, and the skill required. A complete Job sheet means the FM team can generate a first-year preventive maintenance programme immediately after import. An empty or skeletal Job sheet means that programme has to be built from scratch from O&M manuals — typically a three-to-six month effort for a large building.

Document links external files — O&M manuals, test certificates, warranties, commissioning records, COSHH datasheets — to Type or Component records. Each Document row carries a file reference (typically a URL or relative path), a document name, document number, and an approval status. The Document sheet is frequently populated with broken file paths: the documents were linked to a project CDE folder that was decommissioned at practical completion, and the FM team receives a spreadsheet full of references to files they cannot access.

Attribute carries additional properties that do not fit any standard COBie field. If a medical gas outlet requires a type designation, a flow rating, and an outlet orientation that are not captured in the standard Type fields, they live in Attribute rows. Every FM system handles Attribute data differently: some import it as custom fields, some ignore it, some require specific attribute keys to trigger specific import behaviours. Inconsistent attribute key names — FlowRate vs Flow_Rate vs NominalFlowRate — are a common source of import failures.

Coordinate records the spatial position of components: X, Y, Z in the project coordinate system, plus rotation. This data matters for FM systems that have a spatial navigation layer, and for asset tagging workflows where a QR code or NFC tag must be positioned correctly on a floor plan. Coordinate data generated from federated models is subject to alignment errors if consultants have not shared a common survey point and project north.

The data model as a relational graph

The sixteen sheets form a relational graph. The key relationships — the ones that break — are:

• Component.TypeName → Type.Name (the most commonly broken link)
• Component.Space → Space.Name
• Space.FloorName → Floor.Name
• Type.Manufacturer → Contact.Email
• Document.Stage references lifecycle stage; Document.Reference must resolve to an accessible file
• Job.TypeName → Type.Name
• Spare.TypeName → Type.Name
• System.ComponentNames → Component.Name (one-to-many, comma-separated in 2.4)
• Assembly.ChildNames → Component.Name or Type.Name depending on assembly type

Every validation tool — the NIBS Checker, the buildingSMART Standard Checker, Solibri, the Viewpoint validation report — runs these referential integrity checks first. When you get 2,847 errors, most of them are downstream consequences of a small number of upstream naming breaks. In the hospital project, virtually every error traced back to the Type.Name inconsistency.

FM use cases that COBie enables

The value proposition is clearest when the data is correct. A clean COBie import enables:

• Day-one PM schedules. Every maintainable asset is in the CAFM system with its manufacturer's recommended maintenance intervals, labour resource, and spare-parts list, before the building is occupied. Without COBie, this takes three to six months of manual data entry.
• Warranty claim processing. Warranty start date and duration are on the Component record. The FM team can generate a list of assets coming out of warranty in the next ninety days without touching a single paper document.
• Reactive maintenance routing. When a pump fails, the technician looks up the component by room number, finds the Type record, finds the Spare parts list, and places an order. If the TypeName is broken, the component has no type record and no spare parts list.
• Lifecycle costing. Expected life and replacement cost in the Type record, combined with the installation date in the Component record, give the FM team a rolling replacement cost forecast for budget planning.
• Compliance evidence. Fixed-wire test certificates, gas-safety certificates, pressure vessel test records, and statutory O&M documents are linked via the Document sheet to the specific asset they relate to. Auditors can pull the evidence for a named component in seconds.

Where mismatches happen

The COBie data model is unambiguous about how references should work. The real world of a large construction project is not. Mismatches arise at every transition: from design intent to model, from model to specification, from specification to construction submittal, from construction to commissioning record, from commissioning record to COBie export. Understanding where each class of mismatch originates is prerequisite to preventing it.

Type-name divergence: the most common single failure

In a multi-consultant project, every discipline creates its own Revit families with its own naming conventions. The architect names a door type Int-FD30-Single-900. The contractor's subcontractor, working from the architect's door schedule but building their own submittal model, names it FD30 Single Internal 900mm. At the time they are doing this, nobody is looking at COBie. Both names appear perfectly reasonable within their own context.

The problem becomes visible only when the COBie exports are federated. The federation tool combines the Type sheets from all disciplines and flags duplicates — but only if the names are identical. Two names that describe the same product but do not match character-for-character are not flagged as duplicates. They are treated as two distinct product types. Every Component record from the architect's model references one Type row. Every Component record from the contractor's model references the other. If you then run the federated dataset through a CAFM import, you may get duplicate type entries in your asset register, or — worse — import failures if the CAFM has a deduplication rule that rejects near-duplicate names but does not merge them.

For mechanical equipment specifically, the variation patterns are predictable:

# COBie Type Name — mechanical equipment, real-world variation patterns
# Same physical product class, different consultant naming conventions
 
"Discipline","Type.Name","Standard classification"
"M&E Design Consultant","Condensate-Pump-Inline","Pr_65_90_12"
"M&E Contractor","Inline Condensate Pump","Pr_65_90_12"
"Commissioning Engineer","Condensate Pump (Inline)","Pr_65_90_12"
"FM Integrator (expected)","Condensate Pump - Inline","Pr_65_90_12"
 
"M&E Design Consultant","LTHW-Circulation-Pump-Centrifugal","Pr_65_90_73"
"M&E Contractor","Centrifugal Circ Pump LTHW","Pr_65_90_73"
"Commissioning Engineer","LTHW Circ Pump (Centrifugal)","Pr_65_90_73"
 
"M&E Design Consultant","Gas-Fired-Condensing-Boiler","Pr_70_65_42_15"
"M&E Contractor","Condensing Boiler Gas Fired","Pr_70_65_42_15"
"M&E Contractor (replacement during construction)","Boiler - Gas Condensing","Pr_70_65_42_15"

The Uniclass 2015 classification code Pr_65_90_12 (inline centrifugal pump) is the same in all four rows. The Type.Name is different in all four rows. The COBie specification requires the Type.Name to be consistent. It does not enforce the classification code. This is the structural weakness.

Classification code drift

Classification codes are the promised solution to type-name divergence. If every consultant uses the same Uniclass or OmniClass code for a given product class, then even if the free-text name varies, the classification gives you a stable anchor for federation and FM import.

The difficulty is that classification code assignment is not automated in current BIM workflows. It requires a human to look up the correct code in the classification table and type it into the Revit family parameter. Under project pressure, this step is frequently skipped or delegated to junior team members who have not been trained on the classification system.

The result is classification code drift:

• Half the families have no classification code at all.
• Those that do may use different levels of the hierarchy: one consultant classifies an AHU at Pr_70_65_02 (air-handling unit), another at Pr_70_65_02_48 (roof-mounted air- handling unit). Same product, different codes.
• Projects spanning US and UK consultants may find one team using OmniClass Table 23 codes and another using Uniclass Pr table codes. Both are legitimate in their own context. A federation that expects one system gets chaos.
• Classification codes sometimes change between the design stage and the construction stage because the product specified was substituted for an equivalent, and the substitute has a different classification. The code is updated in the submittal model but not back-ported to the design model's COBie export from the last data drop.

Missing connections: the invisible network

The Connection sheet describes the logical relationships between components — which pump feeds which heat exchanger, which distribution board serves which MCB, which valve isolates which section of pipework. This information is critical for reactive maintenance: when something fails, the technician needs to know what else to isolate, what else might be affected, what the system topology looks like.

In most projects, the Connection sheet is entirely empty at handover. The reasons are structural. Connection data requires both upstream and downstream component names to already be finalised. It requires agreement between disciplines about what constitutes a "connection" worth recording. It requires someone to actually enter the data — it is not automatically exported from most BIM authoring tools. And unlike the Type/Component relationship, a missing Connection record does not cause a validation error. The spreadsheet passes validation. The FM team simply discovers, after handover, that their CAFM has no topology data and they cannot do impact analysis on failures.

Attribute-key inconsistency

The Attribute sheet is the COBie standard's catch-all for custom properties. It is also the most inconsistently populated sheet in almost every project because there is no enforced vocabulary for attribute keys.

In the hospital project, the M&E consultant exported pump curve data under the key PumpDutyCurve. The contractor's commissioning records used DutyCurve. The specialist controls contractor used PumpCurve_Duty. Three records for three different phases of the same project, all describing the same property, with three different keys. The CAFM imported the first, created a new custom field for the second, and discarded the third as a duplicate of the second. The FM team ended up with partial pump curve data that gave no reliable picture of any single pump's performance characteristics.

The fix is straightforward in principle: a published attribute vocabulary, defined in the BEP, that all consultants and contractors are required to use. In practice this requires upfront work — enumerating the attributes you actually want in FM, defining the key names, distributing a shared parameter file to all authors — that most projects do not invest in during the BEP stage.

Coordinate drift

Coordinate data in COBie records the X, Y, Z position of each component in the project coordinate system. This data is used by FM systems that have a spatial navigation layer, and by asset-tagging workflows.

When four consultants are working in separate Revit models that are linked via a shared coordinate system, the coordinate data should be consistent across all exports. In practice, coordinate drift occurs when:

• A consultant recalibrates their model's survey point without updating the shared-coordinates reference file.
• The project north or project base point is set differently in two models.
• A contractor builds a site model in a local coordinate system and does not acquire the project coordinate system before exporting COBie.
• The coordinate system is in metric but the COBie export is set to imperial (or vice versa), and the conversion is not applied consistently.

Coordinate drift manifests in the FM system as assets appearing in the wrong location on the floor plan, or — more commonly — as assets appearing at coordinates that place them outside the building boundary entirely. Neither case breaks COBie validation. Both cases break FM spatial navigation.

Document linking gaps

The Document sheet requires a file reference for every linked document. In a project where documents are stored in a CDE (Common Data Environment) such as Autodesk Docs, BIM 360, or Aconex, the file reference is typically a URL. At project close, CDEs are archived or decommissioned. If the Document references use CDE URLs, those URLs will be dead links by the time the FM team needs to access the underlying files.

The correct pattern is to deliver documents as physical files alongside the COBie spreadsheet, with the Document sheet references using relative file paths that resolve within the delivery package. This is specified in BS 1192-4:2014 and in most EIRs. It is consistently ignored in practice because assembling a complete document package is a separate workstream from COBie export, and the two workstreams are rarely coordinated.

The case study in detail

Project context

The project was a new ward block attached to an existing district general hospital: eight floors of inpatient accommodation, a new energy centre, a central sterile services department, and a roof-mounted plant room serving the entire block. Gross internal area approximately 28,000 square metres. Approximately 3,200 maintainable assets in the COBie scope, across mechanical, electrical, and specialist medical equipment categories.

The project team comprised four BIM-authoring organisations:

• Architect (A): Revit, producing architectural and spatial COBie data — Facility, Floor, Space, Zone records, plus architectural Type/Component for doors, windows, and fixed finishes with maintenance implications.
• Mechanical and Electrical Engineer (MEE): Revit MEP, producing the bulk of mechanical and electrical Type and Component records — approximately 70% of the total asset count by volume.
• Specialist Facade Contractor (SFC): Revit, producing Type and Component records for the facade system, including motorised vents, smoke extract dampers, and facade-access equipment.
• Controls and Automation Contractor (CAC): Revit MEP, producing Type and Component records for BMS controllers, sensors, and actuators.

The principal contractor employed a BIM manager (BIM-MC) who was responsible for federating the four COBie drops at each milestone and delivering the final federated dataset to the client's FM integrator (FMI) at handover.

The EIR required COBie 2.4 data drops at:

• RIBA Stage 3 (Spatial Coordination) — Space, Zone, and preliminary Type records
• RIBA Stage 4 (Technical Design) — complete Type records, preliminary Component records
• RIBA Stage 5 (Construction) — monthly updated Component records with installation dates
• Practical Completion — final validated federated dataset

The failure chain

The root cause was established in a forensic data audit conducted six weeks after practical completion. The audit traced the following chain of events:

Month 1, RIBA Stage 3: MEE establishes their Revit MEP model using a template developed for a previous NHS project. The template includes pre-loaded Type families for common mechanical plant: boilers, pumps, air-handling units, valves. The family names follow MEE's internal naming convention: [Service]-[Plant Type]-[Subtype] — for example, LTHW-Pump-Inline, LTHW-Pump-End Suction, LTHW-Boiler-Condensing.

Month 8, RIBA Stage 4: MEE issues the Stage 4 COBie data drop. The Type sheet has 287 rows. The BIM-MC federates the drop with the Architect's and SFC's drops. The federated dataset has 412 Type rows. BIM-MC runs a basic cell-count check and issues the federated file to the client. No referential integrity validation is performed.

Month 14, Construction starts: The principal contractor appoints MEE's design as the construction model basis but engages the mechanical subcontractor (MSub) to develop the construction-phase Revit MEP model for the energy centre and plant rooms. MSub has their own Revit template. Their Type family names follow a different convention: [Plant Type]-[Subtype] -[Service] — for example, Pump-Inline-LTHW, Pump-End Suction-LTHW, Boiler-Condensing-LTHW. These names are also completely reasonable. They just do not match MEE's convention.

Month 16: BIM-MC receives the first construction-phase COBie drop from MSub. The Type sheet now has 156 rows from MSub for mechanical plant in the energy centre. BIM-MC federates the four consultant drops. The federated dataset now has two Type rows for every piece of mechanical plant in the energy centre: one from MEE's design model and one from MSub's construction model. Total Type rows: 568.

Nobody notices because the federation tool does not flag these as duplicates — the names are different. Nobody cross-references the Type sheet against the equipment schedule to check whether 568 rows for 287 designed types represents a problem.

Month 22: The CAC issues their first full COBie drop. They use a third naming convention for the BMS-controlled equipment: [Manufacturer]-[Plant Description]-[Reference Number] — for example, Grundfos-Inline-Condensate-Pump-ECP-01. The CAC's Type.Name values embed manufacturer names and reference numbers because they were building against a specific construction-issue specification. There are now three Type rows for each pump type.

Month 26, RIBA Stage 5 monthly update: MSub has substituted the specified inline condensate pump during construction (the original specified product was discontinued by the manufacturer). The substitute is functionally identical but has a different manufacturer and model number. MSub creates a new Type row: Condensate Pump Inline-Alt. The Component records for all installed substitute pumps reference this new Type. MEE's design-model Type row LTHW-Pump-Inline-Condensate now has no corresponding Components — those components were all physically installed with the substitute product and are linked to MSub's Type row. MEE's original Type row is an orphan: a type that was designed but not installed.

Month 30, Practical Completion: BIM-MC federates the final drops from all four consultants. The Type sheet has 724 rows for what is operationally a 287-type asset register. The Component sheet has 3,247 rows. Of those, 1,089 Component records from MEE's final design-model export reference Type.Name values that exist in MEE's Type sheet but do not match any Type.Name in the federated sheet — because the installed components are referencing MSub's and CAC's Type names for the same product classes, not MEE's.

The 2,847 validation errors break down as follows:

Total: 2,747 (the FM integrator's report logged 2,847 because some errors were double- counted across sheets in their tool's reporting logic.)

Pre-flight checks that would have caught it

The following checks, implemented as automated validation at each data-drop milestone, would have surfaced the type-name divergence at Month 16 — fourteen months before practical completion.

Step 1: Canonical type list diff at federation

At each federation event, compare the incoming Type.Name column from each consultant's drop against the canonical type list established at the BEP stage. Flag any Type.Name that:

• Does not appear in the canonical list
• Is a near-duplicate of a canonical list entry (Levenshtein distance less than 5)
• Appears in more than one consultant's drop with non-identical names

This check at Month 16 would have flagged 156 MSub Type rows as not matching the canonical list. The BIM-MC could have resolved the mapping in hours, not weeks.

Step 2: Referential integrity check on Component.TypeName

At each federation event, verify that every value in Component.TypeName exists as a value in Type.Name. This is a simple spreadsheet lookup that takes less than a minute in Python or Excel. Run it. Every time.

The Month 16 federation would have shown zero broken references — because at that point MSub's Type.Names were different from MEE's but both sets of Components were linking to their respective Types correctly. The issue would have become visible at Month 22, when CAC's Type.Names introduced a third variant. Still fourteen months before practical completion.

Step 3: Contact sheet completeness check

Verify that every value in Type.Manufacturer, Type.Supplier, and Document.ApprovalBy resolves to a row in Contact.Email. Run this check every time a new consultant's data drop is federated. New consultants bring new manufacturer contacts. Those contacts must be in the Contact sheet before the Type records that reference them are valid.

Step 4: Document reference audit

At RIBA Stage 5, audit every Document.Reference value against the intended delivery method. If references are CDE URLs, document the plan for converting them to relative file paths at PC. Assign responsibility. Put it in the handover programme.

Step 5: Coordinate bounds check

After federation, verify that all Coordinate records fall within a bounding box defined by the project extent. Any coordinates outside the bounding box indicate a coordinate-system mismatch. In the hospital project, this check would have flagged 474 MSub Coordinate records at Month 16 — the first time MSub's data was federated.

The canonical type list strategy

The single most effective intervention is establishing a canonical type list at the BEP stage and treating it as a contractual deliverable from that point forward.

A canonical type list is a spreadsheet that contains:

• Type.Name: the exact string that will appear in every consultant's COBie export
• Uniclass2015 or OmniClass23 classification code
• NominalDescription: a human-readable description for reference
• OwnerDiscipline: which consultant is the data owner for this type
• ApprovedSubstitutes: alternative products that may be installed; each substitute maps to the same canonical Type.Name

# Canonical Type List — Hospital Project Ward Block
# Maintained by: BIM Manager (Principal Contractor)
# Version: 1.0 | Date: [Stage 3 Freeze]
# All COBie exports MUST use Type.Name exactly as listed. No variations.
 
Type.Name,Uniclass2015,NominalDescription,OwnerDiscipline,ApprovedSubstitutes
Condensate-Pump-Inline,Pr_65_90_12,Inline condensate pump (LTHW/MTHW),MEE,Grundfos CM3-5;Wilo-Star-RS
Circulation-Pump-Centrifugal-LTHW,Pr_65_90_73,Centrifugal LTHW circulation pump,MEE,Armstrong Design Envelope 4380;Grundfos Magna3
Boiler-Gas-Condensing,Pr_70_65_42_15,Gas-fired condensing boiler,MEE,Ideal Vulcan 2;Vaillant ecoTEC
AHU-Roof-Mounted,Pr_70_65_02_48,Roof-mounted air-handling unit,MEE,Biddle Air Systems RA;Nuaire MRXBOX
Valve-Isolating-Ball-65mm,Pr_60_70_33,Isolating ball valve DN65,MEE,IMI TA; Crane FS6000
BMS-Controller-DDC,Pr_65_17_08,Direct digital control BMS controller,CAC,Siemens DESIGO;Johnson Controls METASYS
Damper-Smoke-Extract-Motorised,Pr_70_65_17_58,Motorised smoke extract damper,SFC,Actionair SE; Swegon GOLD

The canonical type list serves three functions:

1. Shared reference for all COBie authors. Every consultant and subcontractor knows exactly what string to put in Type.Name. There is no ambiguity, no judgment call, no creative naming.

2. Federation validation anchor. At every federation event, the BIM-MC can run a simple lookup: does every Type.Name in this drop appear in the canonical list? If not, it is a validation failure before federation.

3. Substitution mapping. When a product is substituted during construction, the approved substitute list defines whether the substitution requires a new canonical entry (different product class, different maintenance regime) or just a note in the Component's description (functionally identical product, same maintenance regime). This prevents the proliferation of near-duplicate Type entries that destroyed the hospital project's data quality.

Cross-consultant audit at federation milestones

Beyond automated validation, the hospital project would have benefited from a quarterly cross-consultant COBie audit during the construction phase. The audit process should be:

1. Federate all current drops into a single dataset.
2. Generate a pivot table of Type.Name by discipline. Any Type that appears under more than one discipline with different names is a candidate mismatch.
3. Run Levenshtein distance comparison between all Type.Name values. Pairs with distance less than 5 are candidate near-duplicates requiring review.
4. Verify Component counts against the equipment schedule. If the schedule says there are 40 condensate pumps and the Component sheet has 63 components referencing three variants of condensate-pump Type names, that is a mismatch requiring resolution.
5. Produce a written audit report identifying all open issues, assigning responsibility for resolution, and establishing a resolution deadline before the next data-drop milestone.

On a project of this scale, this audit takes a half-day per quarter. The alternative — as the hospital project demonstrated — is six weeks of remediation work post-practical-completion, at a point when the project team is largely demobilised and the client's tolerance for delay is zero.

Shared-parameter constrained-values approach

The most robust technical prevention is to constrain the Type.Name field in Revit to a validated pick list, using shared parameters with data validation.

In Revit, you can add a shared parameter of type Text to a family or project, and then use the COBie Extension's parameter mapping to direct that parameter to the Type.Name export field. You cannot natively constrain a Text parameter to a pick list in Revit. However, you can achieve equivalent control through a combination of approaches:

Option A — Shared parameter as a lookup with Dynamo validation: Create a COBie_TypeName shared parameter. Write a Dynamo script that, on model open or on sync, checks the COBie_TypeName value of every element against the canonical type list CSV. Elements with non-conforming values are highlighted in a Dynamo warning. This does not prevent entry of invalid values, but it surfaces them immediately.

Option B — Use a Type Mark with constrained values: Map the existing Type Mark parameter to Type.Name in the COBie Extension. Populate Type Mark from a project-specific Revit Parameter Catalog or from a shared parameter text file that enumerates allowed values. This approach works if all families in the project use a common shared parameter file, but breaks down when consultants bring families with different parameter setups.

Option C — Dynamo pre-export gate (recommended for large projects): Write a Dynamo script that runs immediately before COBie export. The script:

1. Reads the canonical type list CSV.
2. Reads the Type.Name (or mapped parameter) value from every element in COBie scope.
3. Checks each value against the canonical list.
4. Writes a validation report to a CSV file, listing every non-conforming element.
5. Aborts the COBie export if non-conforming elements are found.

The export cannot complete while there are naming violations. The consultant must resolve the mapping before they can issue their data drop. This is the COBie equivalent of a failing pre-commit hook in a software development workflow: it makes the invalid state unshippable.

# COBie pre-export validation: Type.Name check against canonical list
# Designed for use with Dynamo or as a standalone openpyxl script
# Run against each consultant's COBie drop BEFORE federation
 
import openpyxl
import csv
from Levenshtein import distance as levenshtein_distance
 
def load_canonical_types(canonical_csv_path: str) -> set[str]:
    """Load approved Type.Name values from the project canonical type list."""
    canonical = set()
    with open(canonical_csv_path, newline="", encoding="utf-8") as f:
        reader = csv.DictReader(f)
        for row in reader:
            if row.get("Type.Name"):
                canonical.add(row["Type.Name"].strip())
    return canonical
 
def validate_cobie_type_names(
    cobie_xlsx_path: str,
    canonical_csv_path: str,
    levenshtein_threshold: int = 5,
) -> dict:
    """
    Validate Type.Name values in a COBie spreadsheet against the canonical list.
    Returns a report dict with errors and near-duplicate warnings.
    """
    canonical = load_canonical_types(canonical_csv_path)
    wb = openpyxl.load_workbook(cobie_xlsx_path, read_only=True, data_only=True)
 
    errors = []
    warnings = []
 
    # --- Type sheet: check all Type.Name values ---
    if "Type" not in wb.sheetnames:
        errors.append({"sheet": "Type", "row": 0, "message": "Type sheet missing"})
    else:
        ws_type = wb["Type"]
        headers = [cell.value for cell in next(ws_type.iter_rows(min_row=1, max_row=1))]
        try:
            name_col = headers.index("Name")
        except ValueError:
            errors.append({"sheet": "Type", "row": 1, "message": "Name column not found"})
            name_col = None
 
        if name_col is not None:
            for row_idx, row in enumerate(ws_type.iter_rows(min_row=2, values_only=True), start=2):
                type_name = row[name_col]
                if type_name is None or str(type_name).strip() in ("", "n/a"):
                    errors.append({
                        "sheet": "Type",
                        "row": row_idx,
                        "value": type_name,
                        "message": "Type.Name is blank or n/a",
                    })
                    continue
 
                type_name_clean = str(type_name).strip()
 
                if type_name_clean not in canonical:
                    # Check for near-duplicates in canonical list
                    near_dupes = [
                        c for c in canonical
                        if levenshtein_distance(type_name_clean.lower(), c.lower()) <= levenshtein_threshold
                    ]
                    if near_dupes:
                        warnings.append({
                            "sheet": "Type",
                            "row": row_idx,
                            "value": type_name_clean,
                            "message": f"Not in canonical list. Near-duplicates: {near_dupes}",
                        })
                    else:
                        errors.append({
                            "sheet": "Type",
                            "row": row_idx,
                            "value": type_name_clean,
                            "message": "Not in canonical list. No near-duplicate found.",
                        })
 
    # --- Component sheet: check TypeName references against Type.Name ---
    if "Component" not in wb.sheetnames:
        errors.append({"sheet": "Component", "row": 0, "message": "Component sheet missing"})
    else:
        ws_type = wb["Type"]
        type_names_in_file = set()
        type_headers = [cell.value for cell in next(ws_type.iter_rows(min_row=1, max_row=1))]
        if "Name" in type_headers:
            name_col = type_headers.index("Name")
            for row in ws_type.iter_rows(min_row=2, values_only=True):
                if row[name_col]:
                    type_names_in_file.add(str(row[name_col]).strip())
 
        ws_comp = wb["Component"]
        comp_headers = [cell.value for cell in next(ws_comp.iter_rows(min_row=1, max_row=1))]
        try:
            typename_col = comp_headers.index("TypeName")
        except ValueError:
            errors.append({"sheet": "Component", "row": 1, "message": "TypeName column not found"})
            typename_col = None
 
        if typename_col is not None:
            for row_idx, row in enumerate(ws_comp.iter_rows(min_row=2, values_only=True), start=2):
                type_name_ref = row[typename_col]
                if type_name_ref and str(type_name_ref).strip() not in type_names_in_file:
                    errors.append({
                        "sheet": "Component",
                        "row": row_idx,
                        "value": type_name_ref,
                        "message": "Component.TypeName has no matching Type.Name in this file",
                    })
 
    wb.close()
 
    return {
        "errors": errors,
        "warnings": warnings,
        "error_count": len(errors),
        "warning_count": len(warnings),
        "valid": len(errors) == 0,
    }
 
 
# Example usage:
if __name__ == "__main__":
    result = validate_cobie_type_names(
        cobie_xlsx_path="./MEE_COBie_Drop_Stage5_Month22.xlsx",
        canonical_csv_path="./canonical_type_list_v1.csv",
        levenshtein_threshold=4,
    )
    print(f"Valid: {result['valid']}")
    print(f"Errors: {result['error_count']}, Warnings: {result['warning_count']}")
    for e in result["errors"][:20]:  # Show first 20 errors
        print(f"  [{e['sheet']} row {e['row']}] {e.get('value', '')} — {e['message']}")

The Levenshtein distance check is particularly important: it catches the case where a consultant has typed Condensate Pump Inline when the canonical name is Condensate-Pump-Inline. The strings are different, the referential integrity check passes, but the near-duplicate check flags it as a likely naming error.

The validation rule set

Beyond Type.Name, a complete COBie validation rule set for a large project should cover the following:

# COBie validation rules — project template
# Format: rule_id, sheet, field, check_type, parameters, severity
# severity: ERROR (must fix before handover) | WARNING (must justify) | INFO (advisory)
 
rules:
  # ── Referential integrity ──────────────────────────────────────────────────
  - rule_id: RI-001
    description: Component.TypeName must match a Type.Name value
    sheet: Component
    field: TypeName
    check_type: foreign_key
    reference_sheet: Type
    reference_field: Name
    severity: ERROR
 
  - rule_id: RI-002
    description: Component.Space must match a Space.Name value
    sheet: Component
    field: Space
    check_type: foreign_key
    reference_sheet: Space
    reference_field: Name
    severity: ERROR
 
  - rule_id: RI-003
    description: Space.FloorName must match a Floor.Name value
    sheet: Space
    field: FloorName
    check_type: foreign_key
    reference_sheet: Floor
    reference_field: Name
    severity: ERROR
 
  - rule_id: RI-004
    description: Type.Manufacturer must match a Contact.Email value
    sheet: Type
    field: Manufacturer
    check_type: foreign_key
    reference_sheet: Contact
    reference_field: Email
    severity: ERROR
 
  - rule_id: RI-005
    description: Job.TypeName must match a Type.Name value
    sheet: Job
    field: TypeName
    check_type: foreign_key
    reference_sheet: Type
    reference_field: Name
    severity: ERROR
 
  - rule_id: RI-006
    description: Spare.TypeName must match a Type.Name value
    sheet: Spare
    field: TypeName
    check_type: foreign_key
    reference_sheet: Type
    reference_field: Name
    severity: ERROR
 
  # ── Canonical type list ───────────────────────────────────────────────────
  - rule_id: CT-001
    description: Type.Name must appear in the project canonical type list
    sheet: Type
    field: Name
    check_type: value_in_list
    list_source: canonical_type_list.csv
    list_field: Type.Name
    severity: ERROR
 
  - rule_id: CT-002
    description: Type.Name near-duplicate check (Levenshtein <= 4)
    sheet: Type
    field: Name
    check_type: levenshtein_near_duplicate
    threshold: 4
    severity: WARNING
 
  # ── Classification codes ──────────────────────────────────────────────────
  - rule_id: CC-001
    description: Type.Category must be a valid Uniclass 2015 Pr code or OmniClass 23 code
    sheet: Type
    field: Category
    check_type: regex_match
    pattern: "^(Pr_[0-9_]+|23-[0-9 ]+)$"
    severity: WARNING
 
  - rule_id: CC-002
    description: Component.TypeCategory must match Type.Category for the referenced Type
    sheet: Component
    field: TypeCategory
    check_type: cross_reference_match
    cross_sheet: Type
    cross_field_lookup: Name
    cross_field_match: Category
    severity: WARNING
 
  # ── Completeness ─────────────────────────────────────────────────────────
  - rule_id: CP-001
    description: Type.WarrantyDurationLabor must not be blank or zero for plant
    sheet: Type
    field: WarrantyDurationLabor
    check_type: not_blank_for_category
    applicable_categories:
      - "Pr_65.*"  # All mechanical plant Uniclass prefixes
      - "Pr_70.*"
    severity: WARNING
 
  - rule_id: CP-002
    description: Component.SerialNumber must not be n/a for commissioned plant
    sheet: Component
    field: SerialNumber
    check_type: not_placeholder
    placeholder_values: ["n/a", "N/A", "TBC", "tbc", ""]
    applicable_type_categories:
      - "Pr_65.*"
      - "Pr_70.*"
    severity: WARNING
 
  - rule_id: CP-003
    description: Each Type must have at least one Job record
    check_type: type_has_related_rows
    reference_sheet: Job
    reference_field: TypeName
    severity: WARNING
 
  # ── Document links ────────────────────────────────────────────────────────
  - rule_id: DL-001
    description: Document.Reference must not be a URL to a project CDE domain
    sheet: Document
    field: Reference
    check_type: not_regex_match
    pattern: "^https?://(bim360|autodeskdocs|aconex|viewpoint|4projects)\\..*"
    severity: WARNING
    message: "CDE URLs will be dead links after project archive. Use relative file paths."
 
  - rule_id: DL-002
    description: Document.Reference must not reference an absolute local file path
    sheet: Document
    field: Reference
    check_type: not_regex_match
    pattern: "^[A-Z]:\\\\.*"
    severity: ERROR
    message: "Absolute local file paths are not portable. Use relative paths within the delivery package."
 
  # ── Coordinate bounds ─────────────────────────────────────────────────────
  - rule_id: CO-001
    description: Coordinate.XVal must be within project bounding box
    sheet: Coordinate
    field: XVal
    check_type: numeric_range
    min: -1000.0
    max: 1000.0   # Project-specific: replace with actual project extent
    severity: WARNING
 
  - rule_id: CO-002
    description: Coordinate.YVal must be within project bounding box
    sheet: Coordinate
    field: YVal
    check_type: numeric_range
    min: -1000.0
    max: 1000.0
    severity: WARNING

Anti-patterns

Every project that ends up in the situation the hospital project ended up in has followed a recognisable sequence of anti-patterns. The anti-patterns are individually understandable and each one feels like a defensible decision in the moment. Together they are catastrophic.

Anti-pattern 1: Retrofit COBie at handover

The single most common failure mode is treating COBie as a handover deliverable rather than a data management protocol. When COBie is understood as a deliverable, the natural inference is that it is produced at handover — by whoever is responsible for handover. In practice this means one of two things: either a BIM manager spends six to eight weeks in the final month of the project manually populating a spreadsheet from O&M manuals and commissioning records that are themselves incomplete, or a consultant exports COBie from a model that has not been kept up to date during construction and delivers data that reflects the design intent rather than the as-built condition.

Neither is acceptable. COBie is only as good as the data that goes into it, and the data that goes into it is only accurate if it has been maintained throughout the project lifecycle. Trying to retrofit accuracy into a COBie export at handover is like trying to write test coverage for code after the code is in production: theoretically possible, practically prohibitive, and a reliable way to miss the things that matter most.

Anti-pattern 2: Free-text type fields with no canonical list

The Type.Name field is a free-text string in the COBie specification. There is no schema-level enforcement of a canonical vocabulary. The specification leaves naming to project convention.

In practice, "project convention" without an explicit canonical list means individual author convention. On a project with four BIM-authoring organisations, four individual conventions, all internally consistent and all mutually incompatible, is the most likely outcome. Not because the teams are careless — because there was no shared reference point.

Free-text type fields are also a trap when products are substituted during construction. The specified product and the substitute are functionally equivalent. But the substitute has a different manufacturer, different model number, and possibly different maintenance requirements. The natural instinct is to create a new Type row with a new name. This is the correct decision for genuinely different maintenance regimes. It is the wrong decision for functionally identical substitutes that should map to the same canonical type and maintenance schedule. Without a canonical list that explicitly addresses substitutions, there is no guidance and the wrong decision gets made by default.

Anti-pattern 3: No interim validation

Running COBie validation only at handover is like running structural calculations only when the building is complete. The errors you find have been compounded over months. Their origins are obscure. The people who could fix them are off the project. The contractual levers to compel remediation are weak.

Validation should be automated and run at every data-drop milestone. A continuous integration approach — where COBie export is part of a model quality gate, and the quality gate includes validation checks — turns a six-week handover crisis into a routine ten-minute remediation that happens in week fourteen, when the responsible author is still working in the model, remembers the context, and can fix the naming in two minutes.

The resistance to interim validation is usually resource-based: "We don't have time to set up the automation." The hospital project's remediation cost more person-hours than setting up and running monthly validation for the entire three-year project would have cost. This is not a close call.

Anti-pattern 4: Manual COBie spreadsheets

Some smaller projects — or individual consultants on larger projects — still produce COBie data by manually populating an Excel spreadsheet from design drawings and schedules. This approach produces data that is:

• Disconnected from the model (any model update requires a manual update to the spreadsheet)
• Not validated at export (no tool checks whether the manual entries are internally consistent)
• Not traceable (there is no audit trail from a COBie row back to the model element that generated it)
• Brittle to transcription error (free-text entry into a spreadsheet with no pick lists produces whatever the person typing happened to type)

Manual COBie is occasionally unavoidable — for specialist subcontractors who do not have BIM tools, for legacy systems integration, for very small projects where the overhead of model- based export is disproportionate. When it is unavoidable, the mitigation is to validate the manually-produced spreadsheet against the same validation rule set as the model-based exports, and to run a cross-reference check against the federated dataset to catch naming divergence. A manually produced spreadsheet that is validated is better than a model-based export that is not.

Lessons learned and transferable patterns

Lesson 1: COBie is a data architecture problem, not a deliverable problem

The mental model shift that makes COBie work is from "we need to produce COBie at handover" to "we are managing an asset information database throughout the project, and COBie is the export format." This changes everything about how the work is organised.

In the database mental model, the data has owners at every stage. The architect owns the spatial hierarchy (Facility, Floor, Space, Zone). The M&E engineer owns the mechanical and electrical Type and Component records. The contractor owns the installation data (serial numbers, installation dates). The commissioning engineer owns the operational data (test results, performance parameters). The BIM manager is the database administrator: they run the federation, run the validation, manage the canonical list, and escalate issues to the data owners who have the authority and the model access to fix them.

In the deliverable mental model, nobody is the data owner during the project. Everybody owns the deliverable at the end. This is a recipe for exactly the situation the hospital project found itself in.

Lesson 2: Lock the type list at Stage 3 and treat changes as formal change requests

The canonical type list should be a controlled document from the first data drop. Changes to the list after Stage 3 — new types added, names changed, types merged or split — should require a formal change request process:

1. Identify the type requiring change.
2. Document the reason (product substitution, specification change, error correction).
3. Assess the impact on existing Component records that reference the old name.
4. Update the canonical list.
5. Issue an updated shared-parameter file to all authors.
6. Confirm that all authors have applied the update before the next data drop.

This is bureaucratic overhead on a small project. On a large project it is the difference between a controlled dataset and chaos. The overhead is proportional to the number of consultants and the frequency of product substitutions — exactly the variables that correlate with dataset complexity.

Lesson 3: Federation is a quality gate, not a file merge

BIM managers who treat federation as a file merge — combine the drops, issue the combined file, move on — are missing the main point of the process. Federation is the moment when cross-discipline consistency can be verified: when the M&E Component records are checked against the architectural Space records, when the contractor's Type records are checked against the consultant's canonical list, when the Coordinate records from all disciplines are checked for alignment.

A federation event that takes ten minutes is not doing quality assurance. A federation event that takes half a day — because it includes automated validation, issue logging, and sign-off from each discipline on their portion of the dataset — is doing its job.

Lesson 4: The BEP must specify COBie requirements at field level

Most BEPs that reference COBie do so in one or two sentences: "COBie data drops will be issued at each RIBA stage milestone" and "the final COBie deliverable will be issued at practical completion." This is not sufficient.

A BEP that enables clean COBie delivery specifies:

• Which sheets are required at which milestone (not all sixteen sheets are required at every data drop — define the progression)
• The canonical type list (by reference to an attached document, updated at each stage)
• The attribute vocabulary (a published list of approved Attribute.RowName keys)
• The classification system (Uniclass 2015 or OmniClass Table 23 — project must pick one)
• The document delivery method (relative file paths in a defined folder structure, not CDE URLs)
• The coordinate system reference (shared coordinates file, project survey point, units)
• The validation tool and rule set (define the checker, define the rules, define the pass/fail criteria for each milestone)
• Responsibility assignments (who owns which sheets, who runs validation, who signs off)

Writing this BEP section takes two to four hours at project start. Not writing it takes six weeks at project end.

Lesson 5: Engage the FM team before Stage 3

The FM team that receives the COBie data at handover is the only party in the project chain who can definitively specify what a valid COBie dataset looks like for their CAFM system. They know which attributes their system imports. They know which classification codes their asset categories expect. They know whether their CAFM is case-sensitive on Type.Name. They know whether they need System records or only Component records. They know the document format their DMS requires.

On the hospital project, the FM integrator was engaged for the first time in the week before practical completion. This is by far the most common pattern. It is also why the FM integrator's first action on receiving the COBie dataset was to run it through their validation tool and report 2,847 errors — because nobody had asked them what "valid" meant for their system before the dataset was built.

Engaging the FM team at Stage 2 or Stage 3 — before any COBie data is produced — takes one meeting. The outputs of that meeting (the CAFM import specification, the attribute vocabulary, the asset categorisation scheme) feed directly into the BEP requirements and the canonical type list. They cost nothing except the meeting time to elicit them.

Lesson 6: Test the CAFM import path with a pilot dataset

Before the final handover, generate a pilot COBie dataset covering a single floor or a single system — perhaps 50 to 100 Component records — and run it through the CAFM import path from end to end. This smoke test reveals:

• CAFM import errors that do not show up in the standard COBie validation tool
• Classification code mapping gaps (CAFM expects specific codes for specific asset categories)
• Attribute import behaviour (which keys are imported, which are silently dropped)
• Document link resolution (can the CAFM navigate to linked files from the import path?)
• Duplicate-handling logic (what happens when the CAFM encounters a Type.Name that already exists in its database from a previous import?)

Running this test at Stage 5 — construction phase — gives enough lead time to adjust the COBie production workflow if the import reveals issues. Running it for the first time on the full dataset at handover gives no time at all.

Transferable patterns

The lessons from the hospital project generalise to any project with multiple BIM-authoring organisations and a COBie handover requirement. The transferable patterns, in priority order:

1. Canonical type list, locked at Stage 3, version-controlled, distributed to all authors.
2. Automated referential integrity validation at every data-drop milestone.
3. FM team engaged at Stage 2 to define CAFM import requirements.
4. BEP at field level: sheet requirements by milestone, classification system, attribute vocabulary, document delivery method, validation tool and pass criteria.
5. Pilot CAFM import test at Stage 5.
6. Federation as a quality gate: automated validation, issue log, discipline sign-off.
7. Shared-parameter Dynamo validation gate preventing COBie export from non-conforming models.

Limits and caveats

This case study is a reconstruction

The hospital project described in this post is a composite reconstruction based on patterns that recur across multiple healthcare and large-infrastructure handover projects. Specific figures — 2,847 errors, 312 pumps, six weeks of remediation — are consistent with real projects of this scale and complexity, but do not correspond to a single identifiable project. They are illustrative, not documentary. The failure modes are real. The numbers are representative.

COBie is not the only failure mode

A clean COBie dataset is necessary but not sufficient for a successful FM handover. Assets can be correctly named and classified in COBie while the underlying physical records are wrong: serial numbers transposed, installation dates estimated, warranty documents missing. COBie validates the data structure. It does not validate the data's accuracy. Commissioning verification — checking that the COBie record matches the physical installation — is a separate workstream that COBie does not replace.

Tool landscape is fragmented

The validation tools referenced in this post — the buildingSMART Standard Checker, Solibri, the Viewpoint validation report, Dynamo scripts — represent one possible toolchain. Different organisations use different tools, and tool capability varies significantly. A validation tool that checks referential integrity but not near-duplicate names will miss the class of error that caused the hospital project's failure. Understanding what your validation tool checks — and what it does not — is part of the FM integrator engagement conversation.

COBie V3 changes the landscape

NIBS's COBie V3, developed from 2022 onwards and aligned with NBIMS-US V4, restructures the tables, adds Risk, Event, and Package sheets, and renames Floor to Level. Projects being procured now should clarify whether the EIR requires V2.4 or V3. The principles in this post apply to both, but the specific field names and sheet structures differ. Do not assume V2.4 tooling handles V3 data correctly.

Automation is not a substitute for agreement

The Dynamo validation gate, the canonical type list, the automated referential integrity checks — these are only useful if the canonical list is correct in the first place, and the canonical list is only correct if the project team has had the conversations needed to agree on it. Automation enforces agreements. It does not replace them. The most important part of the workflow described in this post is the Stage 2 meeting with the FM team, the Stage 3 canonical type list review, and the BEP language that makes those outputs contractually binding. The Python scripts and the YAML rule sets are tools for enforcing what the project team has already agreed on.

Sources and further reading

The technical content of this post draws on the following primary sources. All URLs were verified accessible at time of writing (June 2026).

COBie specification and data model:

1. NIBS, National BIM Standard – United States® Version 3, Chapter 4.2: COBie v2.4 The authoritative specification for COBie 2.4. Available from https://nibs.org/nbims/v3/cobie — registration required for download. The companion Annex A contains the mapping rules that define how COBie fields relate to IFC concepts.

2. NIBS, COBie V3 Data Fields Specification The field-by-field specification for the V3 data model, including table definitions, field naming conventions, data types, and picklist requirements. https://nibs.org/nbims/v3/cobie/4-3/

3. buildingSMART International, COBie Certified Professional Reading List The curriculum for the COBie CP examination, covering COBie 2.4 specification, Annex A mapping rules, and the buildingSMART MVD documentation. https://cobiecert.buildingsmart.org/reading-list/

4. NBS, "What is COBie?" A practitioner-accessible introduction to COBie structure, UK implementation context, and the relationship between COBie and BIM Level 2. https://www.thenbs.com/knowledge/what-is-cobie

5. Whole Building Design Guide (WBDG), "Construction-Operations Building Information Exchange (COBie)" The US federal context for COBie, including the GSA mandate and NIBS governance. https://www.wbdg.org/bim/cobie

6. Catenda, "Construction Operations and Building Information Exchange (COBie)" A clear explanation of the COBie data zones (Design, Build, Common) and the role of IFC as the underlying schema. https://catenda.com/glossary/construction-operations-and-building-information-exchange-cobie/

7. Autodesk, "COBie Extension for Revit — Parameter Mapping" Technical documentation for the Autodesk COBie Extension, covering shared parameter creation, mapping configuration, and export workflow. https://interoperability.autodesk.com/cobieextensionrevit.php

8. Viewpoint for Projects, "View COBie Validation Report" Documentation of the Viewpoint COBie validation tool, which generates error, warning, and information reports against the COBie 2.4 specification. https://vfpdocs.viewpoint.com/VfP_topics_user/t_view_cobie_validation_report.html

9. NBS, "Data exchange on BIM projects: What are data drops?" The UK BIM Level 2 framework for staged data exchanges, milestone definitions, and the relationship between data drops and EIR requirements. https://www.thenbs.com/knowledge/data-exchange-on-bim-projects-what-are-data-drops

10. GIRIH X Insights, "Data Classification in AECO: Uniclass, OmniClass, and What to Use When" A comparison of the major classification systems used in COBie, including Uniclass 2015 (UK), OmniClass (US), and their relationship to IFC classification references. https://girihx.com/knowledge/data-classification-aeco-uniclass-omniclass/

Further reading for practitioners:

• BS 1192-4:2014 — The UK code of practice for fulfilling employer's information exchange requirements using COBie. The authoritative reference for COBie in a UK ISO 19650 context. Available from BSI.

• Projectdesign.io, "COBie data drop" — A step-by-step guide to the Revit COBie Extension workflow, including common configuration errors. https://projectdesign.io/cobie-data-drop/

• eracore.com, "What is COBie in BIM? A Guide to Project Handover" — A practical guide to COBie data requirements, with a focus on data standardisation across trades. https://eracore.com/learn-about-cobie/

• buildingSMART International, Standard Checker — The automated COBie 2.4 validation tool referenced in this post. https://thechecker.io/products/standard/