Understand COBie V3 in BIM: structured asset data, handover, AIR/PIM/AIM, IFC, CMMS/EAM, data drops, validation, import testing and Facility Management integration.
Check it out!
COBie — Construction to Operations Building information exchange — is an information-exchange specification created to organize and transfer data required for the operation and maintenance of facilities and assets. Its value is not in “generating a BIM spreadsheet,” but in reducing one of the most recurring lifecycle losses: the project is physically complete, yet the operations team receives scattered documents, incomplete registers, and information that must be manually reconstructed.
The current version of the standard is COBie V3, published in the context of NBIMS-US V4. It modernizes the traditional COBie structure, retains the principle of organizing non-graphical information associated with spaces, products, equipment, and operations, and supports different exchange formats. The standard remains handover-oriented, but its application is broader: data can be progressively produced and verified from design onward, pass through procurement, manufacturing, installation, and commissioning, and reach operations in a usable condition.
COBie also needs to be positioned correctly within the BIM architecture. It does not replace IFC, PIM, AIM, BIM 7D, CMMS, CAFM/IWMS, or Facility Management. COBie is a data-delivery structure. The BIM model may be one of the sources; the AIM organizes operational asset information; the CMMS executes maintenance processes; FM governs services and performance. Value emerges when these layers have compatible identifiers, requirements, responsibilities, and systems of record.
The premise of this article is that COBie should be treated as an information-engineering process and a handover requirement, not as an administrative closeout activity. The organization needs to define in advance which assets matter, which data have operational use, who produces each piece of information, at which milestone it is verified, how the installed condition is reconciled, and how the result will be accepted in the target system. Without this, it is possible to deliver a formally completed file that is operationally useless.
What is COBie and why does it exist?
COBie organizes data that would otherwise be fragmented across drawings, models, specifications, datasheets, submittals, commissioning reports, warranties, and operation and maintenance manuals. The principle is to turn these records into structured, relational, and reusable information at handover.
The problem COBie is designed to solve
In the traditional delivery model, many important pieces of information are known by different parties at different times. The designer defines type and performance; the manufacturer provides model and documentation; the supplier confirms commercial data; construction records the installed equipment; commissioning produces tests and parameters; and operations ultimately needs to register the asset and organize its maintenance.
When there is no structured flow, these data arrive at the end as independent files. The operations team has to determine which manual corresponds to which piece of equipment, verify which model was actually installed, locate serial numbers, enter records into the CMMS, and rebuild links among spaces, systems, and assets. The cost is not merely data entry: identification errors affect warranties, maintenance, spares, traceability, and lifecycle decisions.
COBie operates precisely at this interface between construction and operations. The intention is to capture data at the source and preserve their relationships through transfer.
COBie is a data deliverable, not software
Distinguishing the concepts prevents confusing specifications.
| Element | Primary function | Relationship to COBie |
| BIM model | represent objects, spaces, systems, properties, and relationships | may produce or receive part of the COBie data |
| IFC | open schema for exchanging built-environment information | COBie has a historical relationship with an IFC MVD and may be delivered in IFC format |
| COBie | structure handover and maintainable-asset data | exchange and delivery mechanism |
| PIM | information produced and managed during the asset delivery phase | source of some information that may survive handover |
| AIM | information required to manage the operational phase | may receive information transferred through COBie, but is broader |
| CMMS | work orders, plans, failures, history, resources, and maintenance | may consume COBie data for initial load or register updates |
| CAFM/IWMS | facilities, spaces, workplace, services, and portfolio | may consume spatial and asset data according to the adopted architecture |
| Facility Management | govern the built environment, services, and business support | defines operational needs that justify the data |
This architecture shows why the question “are we going to use COBie or BIM?” is inappropriate. COBie is one possible part of the information ecosystem, not an alternative to BIM.
Not every model object should become a COBie asset
The modeled object and the managed asset are not automatically the same thing. A lighting family may need to exist in the model for coordination and quantities, while operations may have no interest in controlling each unit individually. A UPS, chiller, critical pump, or switchboard, on the other hand, may require identification, serial number, warranty, documentation, maintenance, and individual history.
The decision should be driven by operational use. Criticality, warranty, scheduled maintenance, statutory inspection, cost, replacement, traceability, and consequence of failure help define the required level of information.
| Situation | Typical treatment |
| critical asset with individual maintenance | detailed register by component |
| equipment with material warranty | manufacturer, model, serial, dates, and controlled documents |
| replaceable item without individual traceability | data may remain at type/class level |
| component with no operational use | may be excluded from the COBie scope |
| asset subject to inspection or legal obligation | identification, documents, and evidence tend to be essential |
A good specification therefore begins with the question “what does operations need to do with this data?”, not with the question “which parameters exist in the BIM family?”
COBie should start from operational use, not from the model. The fact that a parameter exists in BIM does not mean it should be required at handover.
COBie is not limited to new buildings
The standard can support delivery at the end of new construction, renovations, changes of owner or operator, and other transfer events. The evolution of COBie V3 itself broadened the language to better accommodate infrastructure situations and relationships among elements. This does not mean COBie is a universal solution for every asset; it means its structured-handover logic can be applied outside conventional building projects when it fits the use case.
COBie V3 structure: tables, fields, relationships, and formats
COBie V3 is richer than the popular image of a “spreadsheet with Equipment and Space.” It organizes information into logical groups covering the facility, spaces, products, assets, operational processes, and supplementary records.
COBie V3 information families
The structure published by NIBS groups tables into five main families:
| Family | COBie V3 tables | Primary purpose |
| General information | Company, Facility | identify the project/facility and related organizations |
| Spatial information | Level, SpaceType, Space, Zone, Coordinate | structure location and spatial context |
| Product and asset information | Type, Component, System, Attribute | describe types, instances, systems, properties, and relationships |
| Operational information | Instruction, Job, Event, Package, Risk | record instructions, activities, events, packages, and applicable risks |
| Supplementary information | Resource, Document, PickList | link resources, documents, and controlled values |
This division matters because COBie is not only about “equipment.” Operations needs to understand where the asset is, which system it belongs to, which documents apply, what activities may exist, and which relationships provide context to the record.
Facility, Level, Space, and Zone: context before equipment
The quality of the asset register depends on a coherent spatial structure. A component without a valid location is difficult to find physically, inspect, assign to a team, or relate to a space.
Facility establishes the main delivery unit. Level organizes relevant levels or strata. SpaceType allows spaces of a similar nature to be grouped, Space identifies spaces and Zone allows functional groupings that do not need to coincide with floors or physical compartments.
In COBie V3, the adoption of Level instead of the historical logic centered only on “Floor” helps accommodate contexts that are not exclusively conventional buildings.
Type and Component: class and instance need to be separated
One of the most important relationships is to distinguish Type from Component.
Type represents characteristics common to a set of products or equipment: manufacturer, model, description, reference, performance, and shared attributes. Component represents an installed instance, with its own identity and relationship to a space, system, or other records.
Separating the two levels reduces duplication. It makes no sense to repeat the same datasheet across hundreds of components when the information belongs to the type. Conversely, serial number, final location, or asset tag may be instance-specific data.
| Data | Typically associated with | Example |
| manufacturer | Type | Schneider Electric |
| model | Type | commercial equipment model |
| rated power | Type/Attribute, depending on the rule | 30 kW |
| asset tag | Component | CH-01 |
| serial number | Component | individual serial |
| installed location | Component/Space | specific technical room |
| product manual | Type/Document | manual common to the product line |
| test report for the installed equipment | Component/Document | evidence specific to that unit |
The rule needs to be defined contractually; the table illustrates data-normalization logic rather than imposing a single modeling approach on every project.
System and functional relationships
Operations and maintenance often think in terms of systems, not only isolated components. A piece of equipment may depend on power, communication, HVAC, water, control, or other interfaces. System allows components to be organized into relevant functional contexts.
COBie V3 also incorporated improvements for representing relationships among records, including the field PartOf in certain structures. This improves the ability to express hierarchy and composition without relying solely on informal names.
Modeling these relationships should be proportional to use. Creating an extremely detailed structure with no process that uses it increases data-maintenance cost. However, ignoring critical dependencies reduces the operational value of handover.
Document, Job, Event, Instruction, and Risk extend the operational context
One difference between an asset list and an information deliverable is the ability to connect use context.
Document allows documentation to be associated; Job may represent relevant activities; Event records events; Instruction provides instructions and general submittal information; Risk allows risk information to be structured within the standard’s scope. These elements do not turn COBie into a CMMS or risk-management system. They provide an exchange structure for information that may be needed by downstream processes.
The engineering point is to keep the relationship traceable. A manual delivered in a generic folder has far less value than a document linked to the correct type or component. A warranty without a related asset, date, and supplier loses operational usefulness.
Required, If Specified fields, and references
COBie distinguishes field mandatory status. There are minimum standard requirements and fields that become mandatory when specified by the contracting party. There are also reference relationships among tables.
This creates an important contractual consequence: the owner needs to define what is required beyond the minimum, especially when it intends to feed specific processes.
| Situation | Specification consequence |
| field always required by the standard | must comply with the applicable COBie rules |
| field required when specified | should only be required if the requirement is clearly defined |
| reference between tables | depends on referential integrity and consistent keys |
| additional owner data | needs definition, source, format, owner, and quality criterion |
Requiring “complete COBie” without identifying version, fields, assets, and use creates room for incompatible interpretations.
COBie V3 is not only XLSX
The spreadsheet is the best-known representation, but COBie V3 supports multiple approved formats, including SpreadsheetML, JSON, and IFC-based representations, in addition to exchange formats related to the specification.
This evolution is important for automation. JSON facilitates machine-to-machine workflows; IFC can keep COBie within an openBIM ecosystem; SpreadsheetML remains useful for human review, filters, and workflows in tabular tools.
Format selection should consider who produces, who validates, and who consumes. A technically elegant format that cannot be imported into the target system creates an additional conversion step and risk.
COBie V3 is not synonymous with Excel. SpreadsheetML remains useful for human review, but JSON and IFC broaden automation and integration possibilities.
COBie in the information architecture: AIR, PIM, AIM, IFC, BIM 7D, and CMMS
A robust COBie deliverable originates from the project’s information architecture. The final file is only one manifestation of the process.
AIR should justify operational content
In the ISO 19650 logic, information requirements need to be linked to decisions and objectives. For the operational phase, the Asset Information Requirements (AIR) is especially relevant because it defines the information required to support asset management.
The AIR does not need to be “a COBie list.” It should express organizational needs. Those needs can then be mapped to COBie fields, IFC properties, documents, or other structures.
A requirement such as “manage warranties for critical equipment” may require asset identification, type, manufacturer, model, serial number, installation date, warranty period, supplier, and associated document. COBie is one possible mechanism for transferring this dataset.
PIM is a source; AIM is the broader operational destination
During the delivery phase, information is produced and managed in the Project Information Model (PIM)At handover, part of this content will have operational value and should contribute to the Asset Information Model (AIM).
The transition does not consist of copying the entire PIM. Temporary studies, rejected alternatives, objects with no operational relevance, and duplicated information may have no value in the AIM. The information that survives needs to be selected, reconciled with the installed condition, and validated against asset requirements.
COBie can act as one of the bridges between these environments, especially for structured asset, space, and documentation data.
IFC and COBie operate at different levels
IFC is a broad schema for digital representation of the built environment. COBie is an information view oriented toward handover and operations. The historical relationship between COBie and IFC remains important: COBie was defined as an IFC Model View Definition, and COBie V3 maintains representations aligned with this ecosystem.
In practice, a workflow may produce COBie from IFC models, export both as deliverables, or use intermediate systems. What matters is avoiding the assumption that “having IFC” automatically means “having correct COBie.” The model may have perfect geometry and still lack serial number, warranty, or final documentation; conversely, a COBie dataset may have adequate tabular data without representing all the geometric and relational richness of the model.
BIM 7D is a use; COBie is an exchange
BIM 7D is a market convention associated with BIM uses in operations and maintenance. COBie can support these uses, but it is not synonymous with BIM 7D.
BIM 7D may include spatial navigation, assets, documents, condition, maintenance integration, sensors, and other use cases. COBie has a much more specific scope: structuring information that can be transferred and consumed.
CMMS needs common identity
The CMMS provides processes that COBie does not: work orders, plans, scheduling, resources, parts, failures, history, and maintenance indicators. To import COBie data, the target system needs to map classes, hierarchies, tags, fields, and relationships.
BIM/AIM may provide location, classification, and documentation; the CMMS records operational history. Integration is sustainable only when there is a common asset identity.
| Information | Possible system of record | Typical integrations |
| geometry and spatial context | BIM/AIM | CMMS, CAFM/IWMS, Digital Twin |
| operational asset register | CMMS/EAM or AIM, depending on the architecture | BIM, ERP, BMS |
| work orders and maintenance history | CMMS | AIM, analytics, ERP |
| alarms and real-time state | BMS/SCADA/IoT | CMMS, Digital Twin, analytics |
| controlled documents | DMS/CDE/AIM | CMMS, BIM, operations |
| procurement and financial information | ERP | EAM/CMMS, asset management |
| handover dataset | COBie | import/update of the systems above |
There is no requirement to adopt exactly this distribution. The organization needs to define its systems of record and prevent five platforms from maintaining competing versions of the same data without synchronization rules.
Handover starts during the project, not at closeout
Manufacturer, model, serial number, warranty, documentation, parameters, tests, spares, and relationships do not all emerge at the same time. Design defines some; procurement confirms others; installation creates individual identity; commissioning produces evidence and final parameters.
Therefore, requiring full completion in the final month of construction is structurally inadequate. Information needs to be collected when a reliable source exists and verified before the responsible party leaves the project.
Handover is the consequence of a well-governed information process. Attempting to reconstruct manufacturer, model, serial, warranty, and documents at closeout transfers cost and risk to operations.
How to specify and procure a COBie deliverable
The requirement “deliver COBie” is insufficient. A contractual specification needs to define version, scope, assets, fields, sources, responsibilities, milestones, format, quality, and acceptance.
Start with the end use
The process recommended by COBie itself is to define what is wanted, when it will be delivered, and who will produce and review it. This aligns with good information-management practice: start with the end use.
A requirements matrix can relate the operational need to the requested data.
| Operational use case | Assets covered | Data required | Evidence/consumption |
| warranty management | equipment with controlled warranty | manufacturer, model, serial, dates, supplier, document | CMMS/EAM + warranty |
| preventive maintenance | individually planned assets | tag, type, location, parameters, documents, activities | CMMS |
| regulatory inspection | systems subject to specific obligations | identification, certificate, dates, and current document | CMMS/DMS |
| spare-parts management | critical equipment | manufacturer, model, specification, and associated resources | CMMS/ERP |
| equipment location | distributed assets | facility, level, space, zone, coordinate where applicable | CAFM/BIM/CMMS |
| risk analysis | critical assets/systems | criticality, relationships, risks, and documentation | asset management |
This mapping prevents data from being collected merely “because the template has a column.”
Define the Asset Register before discussing fields
One of the most critical decisions is to define which types and components will be controlled. The inventory needs to be governed by rules, not by each discipline’s opinion.
Criteria may include criticality, cost, legal obligation, individual maintenance, warranty, service life, replacement, need for physical identification, and failure impact. The result may be a matrix by asset class indicating whether there should be Type, Component, documentation, serialization, warranty, and a maintenance plan.
Specify version and format
The contract should state which COBie version applies and in which format it will be accepted. This is especially important because workflows and materials based on COBie 2.4 still exist, while COBie V3 introduced material structural changes.
It is also necessary to define conventions: coding, language, units, dates, null values, characters, names, classifications, attachments, and external references.
Information responsibility matrix
No single party knows all the data. Responsibility needs to follow the source of the information.
| Information | Likely source | Typical production responsibility | Typical verification |
| spaces and zones | design/architecture | designer/BIM coordinator | coordination + owner |
| specified type and performance | design/specification | discipline designer | owner’s engineering |
| manufacturer and procured model | procurement/submittal | supplier/contractor | inspection/engineering |
| serial number | installation | installer/supplier | field/commissioning |
| final location | as-built | contractor/modeling | inspection + BIM |
| warranty | contract/supplier | procurement/supplier | contract management |
| test report | commissioning | executor/Cx agent | commissioning authority/owner |
| operational plan | operations/maintenance | FM/maintenance | owner |
Actual role titles vary by contract. What matters is that someone is clearly responsible for creating, updating, verifying, and accepting.
Data drops turn COBie into a process
Intermediate deliveries are strongly recommended on larger projects because they allow structure and quality to be progressively verified. They do not need to contain all final data.
| Milestone | Content that may mature |
| concept / early design | Facility, levels, spaces, zones, classes, and asset strategy |
| design development | types, systems, attributes, and information requirements |
| procurement documentation | consolidated COBie scope, classes, responsibilities, and criteria |
| procurement | manufacturer, model, submittals, documentation, and expected warranty |
| installation | components, tags, serials, final location, and installed relationships |
| commissioning | results, documents, configurations, open items, and evidence |
| handover | reconciled, validated, and accepted dataset |
| operations | updates to AIM/systems as changes and new events occur |
The objective is not to burden the project with duplicate deliveries. It is to detect problems while there is still an opportunity to correct them at the source.
Data drops are quality control, not additional bureaucracy. They distribute information production throughout the project and allow errors to be corrected before handover.
BEP, TIDP, and MIDP need to reflect data delivery
If COBie is contractual, the BIM Execution Plan should explain how the process will be executed. Delivery plans need to indicate when information sets are produced, by whom, and how they integrate with the master plan.
This includes tools, exporters, validations, environments, responsibilities, naming criteria, coordination between models and data, version control, and treatment of nonconformities.
Acceptance criteria should be defined before the first delivery
It is not possible to objectively assess a dataset if the project discovers the quality criteria at closeout. The contracting party should establish in advance:
- applicable version and schema;
- required tables and fields;
- asset classes covered;
- rules for completion, identifiers, units, and values;
- relationships that need to exist between tables;
- validations against model, field, documents, and target system;
- tolerance and treatment of nonconformities;
- import evidence when integration is involved.
This is one of the few points where a list is useful: it is an explicit set of contractual controls.
How to validate, accept, and import COBie
A COBie dataset should not be accepted simply because it opens without error in a spreadsheet. Quality has different dimensions, and some can only be verified against other sources.
Structural validation is only the first layer
The first layer verifies schema conformance: tables, fields, types, valid values, references, and keys. It is a necessary but insufficient condition.
The second layer verifies semantics and consistency: whether the component belongs to the correct type, whether the space exists, whether the system relationship is valid, whether the document applies, and whether units and classifications are correct.
The third layer compares with reality: whether manufacturer, model, serial, location, and documentation correspond to what was actually installed and accepted.
A quality model for COBie
| Dimension | Validation question | Example failure |
| structural conformance | does the dataset follow the schema and rules? | required field missing |
| completeness | are the required records present? | critical equipment not registered |
| uniqueness | are identifiers unique where required? | two pumps with the same tag |
| referential integrity | do relationships point to valid records? | component references a nonexistent space |
| consistency | do related values agree? | model incompatible with the associated type |
| validity | are format and domain allowed? | invalid unit or date |
| accuracy | does the data represent the actual condition? | serial number entered incorrectly |
| currency | does it correspond to the installed/accepted revision? | superseded document |
| traceability | can source and evidence be identified? | warranty without supplier/document |
| consumability | can the target system use it? | import loses relationships or fields |
Treating “100% of fields filled” as synonymous with quality creates a false sense of control.
Reconcile with procurement and as-built
Substitutions are normal. The problem is not changing the equipment; it is allowing the register to continue reflecting the previous version.
Reconciliation should compare design, approved submittal, procured material, installed tag, commissioning, and as-built condition. Changes need to update the model, COBie, and relevant documents according to project governance.
Documents need to be verifiable
A Document field being filled is not enough if the link does not open, the file does not correspond to the asset, or the revision is incorrect. Acceptance should test samples and, for critical documentation, may require full coverage.
It is also necessary to define how the reference will work after closeout. Temporary links from a construction platform may cease to exist; local paths may lose meaning; permissions may prevent operational access.
Import testing is an integration test
When the objective is to populate CMMS, EAM, CAFM, or IWMS, import should be treated as a test. A small pilot dataset needs to be loaded before final delivery to verify mapping and behavior.
| Aspect | What to test |
| asset creation | number of records and identity |
| hierarchy | site, facility, system, space, and asset |
| fields | types, units, limits, and null values |
| documents | association and access |
| classes | correspondence with system taxonomy |
| duplicates | rule for an existing asset |
| update | behavior on second import |
| errors | log, rejection, and correction capability |
| rollback | recovery when a load produces an incorrect result |
| reconciliation | post-import count and sampling |
File acceptance and integration acceptance are different decisions, but they need to be coordinated when one depends on the other.
The owner needs to participate in acceptance
The BIM team can validate structure; engineering can validate technical data; commissioning can validate evidence; IT can test integration; maintenance and Facility Management need to verify that the information supports real processes.
This multidisciplinary review prevents handover from being approved by those who produce the file but not by those who will depend on it for years.
COBie acceptance needs to prove use, not just format. When the dataset will feed CMMS, EAM, CAFM, or IWMS, import and data reconciliation form part of the readiness evidence.
How to implement COBie from project delivery to operations
A robust implementation needs to be treated as a lifecycle information flow. The process below is intentionally sequential to make dependencies clear.
Recommended implementation process
- Define operational outcomes. Identify decisions, maintenance processes, warranties, inspections, space management, and other uses that depend on structured information.
- Define the asset scope. Establish classes and criteria for deciding what will be controlled as a type and component.
- Map information requirements. Translate AIR and owner needs into applicable COBie fields, relationships, and documents.
- Select version and format. Define COBie V3 or another contractually applicable version, format, units, and conventions.
- Define taxonomies and identifiers. Establish tags, classifications, spaces, systems, and keys before production at scale.
- Define systems of record. Determine where each data item will be maintained after handover and how COBie will feed those systems.
- Build the responsibility matrix. Define who creates, updates, verifies, and accepts each information group.
- Incorporate into the BEP and delivery plans. Record tools, workflows, data drops, validations, and coordination.
- Run an early pilot. Produce a small representative sample and test export, validation, and import.
- Capture data progressively. Update types and components as design, procurement, manufacturing, and installation mature.
- Connect documentation and commissioning. Associate manuals, warranties, tests, certificates, parameters, and evidence with the correct records.
- Control changes. Ensure substitutions, RFIs, changes, and as-built are reflected in the dataset and related sources.
- Run automated validation. Verify schema, fields, values, uniqueness, and references.
- Perform technical and field review. Compare samples or defined coverage against the installed asset, documents, and test results.
- Test the target system. Import, reconcile counts, verify links, and handle exceptions before handover.
- Formalize acceptance and transfer governance. Record open items, accepted baseline, responsibilities, and the operational update process.
The pilot should represent real complexity
A pilot consisting only of five simple pieces of equipment can create a false impression of success. It is better to select a sample containing shared types, individual components, spaces, systems, documents, warranties, attributes, and at least one complex integration situation.
The objective of the pilot is not to prove that the tool “exports COBie.” It is to discover incompatibilities in requirements, naming, modeling, and the target system while correction cost is still low.
Commissioning is a data source, not just a physical milestone
Commissioning produces relevant operational information: test results, setpoints, configurations, certificates, punch lists, final parameters, and performance evidence. When these records have operational value, they need to be related to the correct assets and systems.
This creates a direct interface between the commissioning plan and the handover plan. A system may be physically tested and still lack sufficient documentation to be accepted by operations.
Handover is not a “final upload”
Successful handover transfers the ability to operate. Dataset, documents, models, procedures, access, training, configurations, warranties, open items, and systems need to converge on an operational baseline.
COBie solves only part of this problem, but a critical part: it helps make asset data structured and consumable.
After handover, COBie ceases to be the primary source of truth
After the data are accepted and loaded, the selected operational system governs ongoing changes. Equipment replacement, warranty revision, space change, maintenance, or modernization need to follow update processes for the AIM, CMMS, CAFM, ERP, or other systems of record.
Maintaining a frozen COBie file as a “parallel register” creates divergence. It should be preserved as a handover record or used in new exchanges according to the defined architecture, but it should not compete for data ownership with operational systems without an explicit rule.
The expected outcome is information readiness
A mature COBie implementation is not the one that delivers the largest spreadsheet. It is one in which the organization can confidently answer: which assets were delivered, where they are, what types they are, which documents and warranties apply, how they relate to systems and spaces, and how these data enter maintenance and Facility Management processes.
The final indicator is simple: operations should not need to manually reconstruct information that the project already knew. COBie creates value when it turns knowledge produced during design and construction into structured, validated, governable operational information.
Technical references
[1] NATIONAL INSTITUTE OF BUILDING SCIENCES. Construction to Operations Building Information Exchange (COBie) V3 — NBIMS-US V4. Washington, DC: NIBS.
[2] NATIONAL INSTITUTE OF BUILDING SCIENCES. COBie V3 — Overall Process and Interim Deliverables. Washington, DC: NIBS.
[3] NATIONAL INSTITUTE OF BUILDING SCIENCES. COBie V3 — Specifying Deliverables. Washington, DC: NIBS.
[4] NATIONAL INSTITUTE OF BUILDING SCIENCES. COBie V3 — Content Considerations. Washington, DC: NIBS.
[5] NATIONAL INSTITUTE OF BUILDING SCIENCES. COBie V3 — Data Tables. Washington, DC: NIBS.
[6] NATIONAL INSTITUTE OF BUILDING SCIENCES. COBie V3 — Structure and Format. Washington, DC: NIBS.
[7] BUILDINGSMART INTERNATIONAL. COBie Professional Certification — Resources and learning objectives.
[8] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 19650-3:2020 — Information management using BIM — Operational phase of the assets. Geneva: ISO, 2020.
Frequently asked questions
COBie is an information-exchange specification that organizes data on facilities, spaces, products, components, systems, documents, and operational information to support handover and asset management.
COBie V3 is the version published in the context of NBIMS-US V4. Projects should contractually declare the applicable version because workflows based on earlier versions, especially COBie 2.4, still exist.
No. The tabular representation is widely known, but COBie V3 supports formats such as SpreadsheetML, JSON, and IFC-related representations. COBie is a data structure and delivery process, not software or an isolated spreadsheet.
No. IFC is a broad schema for exchanging built-environment information, while COBie has a specific focus on handover and operational data. Both can coexist in the same process.
The Asset Information Model brings together the information needed for the operational phase and is broader. COBie can be used to transfer part of the data that will form or update the AIM.
No. COBie can provide register data to the CMMS, but the CMMS executes processes such as plans, work orders, history, failures, resources, and maintenance.
No. Scope should be defined by operational value, considering criticality, individual maintenance, warranty, legal obligation, replacement, and other use cases. Objects with no operational need may be excluded.
Progressively. Information can mature during design, procurement, installation, and commissioning. Intermediate data drops allow quality to be validated before final handover.
Validation should verify schema, completeness, uniqueness, referential integrity, consistency, validity, accuracy, currency, traceability, and consumability by the target system.
When COBie will be used to populate CMMS, EAM, CAFM, or IWMS, it is advisable to test import in a controlled environment and reconcile records, relationships, documents, and exceptions before final acceptance.
Additional technical resources
Operations, assets, and handover
- Facility Management
- BIM 7D
- PIM and AIM in BIM
- CMMS
- ISO 55000 and Asset Management
- Engineering Asset Management
- Maintenance Engineering
