COBie has a reputation for being difficult. In practice it is not conceptually hard — it is a structured spreadsheet describing the managed assets in a facility and the spaces they serve. What makes it painful is timing. Teams that treat COBie as a document produced at practical completion discover, six weeks before handover, that thousands of parameters were never populated and the people who knew the answers have demobilized.
Handled as a running obligation from design onward, COBie is routine. This article explains the structure and the planning that makes it so.
What COBie is
COBie — Construction Operations Building Information Exchange — is a specification for delivering asset information in a neutral, structured format. It does not carry geometry. It carries the non-graphical information a facilities team needs: what assets exist, where they are, who made them, what warranties apply, what spare parts and maintenance jobs are associated, and what documents relate to them.
It is delivered most commonly as a multi-worksheet spreadsheet, and is also expressible as an IFC subset. The spreadsheet form is what most projects exchange.
The worksheet structure
The sheets follow the physical and organizational logic of a building.
Contact — every organization and individual referenced anywhere in the file, keyed by email address. Every other sheet points back here for authorship and responsibility.
Facility — the project, site, and building, with units and the project coordinate reference.
Floor — levels, with elevation and height.
Space — rooms and areas, with name, number, category, and usable area. Spaces belong to floors.
Zone — logical groupings of spaces: fire compartments, HVAC zones, security zones, occupancy zones. A space may belong to several zones.
Type — the product types installed. A rooftop unit model, a door type, a luminaire type. Manufacturer, model number, warranty durations, expected life, replacement cost, and nominal dimensions sit here.
Component — the individual installed instances of each type, with a unique name, serial number, installation date, and the space it serves. This is where quantity lives.
System — functional groupings of components: chilled water system, fire alarm system, lighting circuit.
Assembly, Connection, Spare, Resource, Job — the maintenance layer: what a job consists of, what parts and skills it needs, and how often it recurs.
Document, Attribute, Coordinate, Issue — supporting information: O&M manuals, test certificates, additional properties, locations, and outstanding matters.
The critical relationship to understand is Type-to-Component. Information that is true of every unit of a product goes on Type. Information unique to an installed instance goes on Component. Duplicating type data onto every component is the most common structural error and produces files that are enormous and impossible to maintain.
Who populates what, and when
COBie fails when population is assumed to be one party's job at one moment. It is a relay.
Design stage. The design team establishes the space and zone structure, the floor list, and the type placeholders for specified equipment. Room numbering and space naming set here will propagate through every downstream sheet, so it must be agreed with the client's facilities team early — not renumbered at handover.
Construction stage. Contractors and subcontractors populate manufacturer, model, serial numbers, installation dates, and warranty data as installation proceeds. This is the largest volume of data and the part most often deferred.
Commissioning and handover. Test certificates, O&M documents, spare part lists, and maintenance job definitions are attached, and the file is validated.
A simple rule prevents most of the pain: data is captured when it is created, by whoever creates it. A serial number recorded at installation costs nothing; the same number recovered eight months later requires someone on a ladder.
Planning COBie in the BEP
The BIM Execution Plan should carry a COBie section stating:
- Which asset classes are in scope (usually maintainable assets only, not every element)
- The classification system used — Uniclass, OmniClass, or a client-specific code
- The parameter-to-field mapping from the authoring tool to each COBie column
- Who owns each sheet, per stage
- Validation frequency — quarterly, not once
- The delivery format and the acceptance criteria
The scope line matters most. "All assets" is not a scope. A facilities team needs the chiller, not the ceiling tile. Agreeing an asset scope list early can reduce the deliverable by an order of magnitude with no loss of usefulness.
Getting data out of the model cleanly
If parameters are mapped correctly, most of the Type and Component data can be exported directly from the authoring model. That depends on content discipline:
- Shared parameters must be used for anything scheduled, since family parameters cannot be exported reliably
- Data types must be correct — a warranty duration stored as text cannot be validated
- Naming must be unique per component; duplicate names invalidate the file
- Classification codes should be applied as parameters, not written into names
This is the point where poorly constructed families become an expensive problem, since remapping content late is far harder than building it correctly.
Validation
Validate early and repeatedly. Free and commercial validators check structural integrity: required fields present, referential integrity between sheets, unique keys, valid contact references, and correctly formatted dates.
Structural validity is necessary but not sufficient. A file can pass validation and still be useless — for example, if every component is named with a system default, or every warranty duration is zero. A human review against a sample of real assets should accompany every validation cycle.
Run validation at least at each stage gate, and monthly during construction. Files validated for the first time at handover are, in the general case, not deliverable.
Common failure modes
Room renumbering late in the project. Every space reference in the file breaks. Freeze the numbering scheme with the client early.
Type data duplicated onto components. Creates files with tens of thousands of redundant rows and no single source of truth.
Manufacturer data collected by email. Unstructured collection guarantees inconsistency. Provide subcontractors with a fixed template mapped to the COBie columns.
No named owner. COBie without a single accountable owner across stages will not be delivered.
Is COBie still the right format?
Some clients now specify asset information through IFC-based requirements, proprietary CAFM import formats, or bespoke parameter schedules rather than COBie spreadsheets. The underlying discipline is identical in every case: define the asset scope, map the parameters, assign population responsibility by stage, and validate continuously. Projects that do that can produce any of these formats. Projects that do not cannot produce any of them.
Defining an asset scope that serves the operator
The scope decision determines the size, cost and usefulness of the entire deliverable, and it should be made by the people who will maintain the building rather than by the delivery team.
A workable method is to include an asset if any of the following is true:
- It requires scheduled maintenance
- It has a warranty the operator will need to claim against
- It will be replaced within the building's life and requires a replacement budget
- It requires statutory inspection or certification
- Its failure would interrupt operations
- It has spare parts held or ordered against it
An asset that meets none of these — a ceiling tile, a skirting board, a light switch — adds rows without adding capability. Applying this test typically reduces a proposed asset list substantially, and every row removed is population effort saved across three stages.
Agree the list in writing, by element category, before design stage ends.
Running COBie as a continuous obligation
The practices that separate projects delivering COBie routinely from those delivering it in panic:
A single named owner across all stages. Not a role that changes hands at each contract boundary.
A population tracker. A simple dashboard showing percentage complete per sheet and per asset category, reviewed monthly. Visibility is most of the discipline.
Subcontractor templates. Each trade receives a fixed spreadsheet mapped to the COBie columns, issued with their subcontract, with population dates tied to payment milestones. This is the single most effective mechanism available for getting manufacturer and serial data captured on time.
Validation from the first stage gate. Structural validation of a partially populated file catches mapping and referential errors while they are cheap.
A handover rehearsal. Two to three months before completion, produce the full file as though delivering it. Whatever is missing then is recoverable; whatever is missing at completion generally is not.
Frequently asked questions
Does COBie require a full BIM model? No. COBie can be produced from schedules and structured data alone. A model makes it far more efficient and reduces transcription error.
How large is a typical COBie file? For a mid-size commercial building with a sensible asset scope, a few thousand component rows. Files with hundreds of thousands of rows almost always indicate a scope or structure problem.
Who signs off the file? The appointing party's facilities or asset management representative, against acceptance criteria stated in the information requirements.
Related reading: Scan to BIM: Turning Point Clouds Into Usable Revit Models · Revit Family Creation: Why Custom Content Decides Model Performance
Vantage CAD Services supports asset data structuring, parameter mapping, and COBie preparation alongside BIM delivery. Contact info@vantagecadservices.com or +1 (512) 543-0831.