What information should a COBie deliverable contain?

Enough to identify, locate and maintain the assets in scope, and no more. The COBie standard sets a floor: required tables and required fields that every deliverable must populate. Everything above that floor is for the owner to specify, and NIBS, which maintains the standard, notes that COBie gives the best results when owners do exactly that. A good deliverable is complete for its intended use, internally consistent and backed by evidence from the installed equipment.

The tables that do most of the work

For most owners, the heart of a COBie deliverable is a handful of tables (field names here are from COBie version 3; earlier versions differ):

One rule in the standard carries particular weight: every component must be located in the space where it is found or from which it is operated. That is what lets a technician find a fan coil unit by room number instead of searching drawings.

Let maintenance tasks set the field list

For each asset type, the question is what the operator needs in order to identify the item, understand what it is, find it and maintain it under warranty. The answer defines the fields to require. It also defines what to leave out: purchase cost or nominal dimensions, for instance, may be of no use to a particular operator.

Timing belongs in the requirement too. Serial numbers and installation dates cannot exist during design, and COBie's own field definitions say that serial numbers are not applicable at planning and design stages. Information that legitimately arrives later should not be treated as a design-stage defect, but nor should placeholders be allowed to survive into final acceptance.

Rules that make a deliverable checkable

COBie includes several rules that help turn requirements into tests, and each needs a decision from the owner.

Blank fields are not allowed. Text fields that do not apply take "n/a" and numeric fields take "0". The owner should say where "n/a" is acceptable, because a deliverable full of "n/a" can pass a format check while missing the information the operator needs.

Some fields must use values from defined pick lists, while others, such as classification, depend on regional or owner choices, for example OmniClass in the US or Uniclass in the UK. The requirement should name the system that applies.

Records need unique names. NIBS gives the example of a pump schedule and a plumbing fixture schedule that both use "P-1", so names have to be made unique when schedules are combined. A specified naming convention prevents the clash.

Finally, additional properties belong in the Attribute table. Extra columns added to the standard tables will not be recognised by asset-management systems unless their import is customised.

Passing these rules is still not the end of checking. A technically valid file can omit an entire equipment package, or list products that were never installed, so the deliverable must also be compared with the installed scope.