What belongs in COBie?

Start with the scheduled assets

NBIMS-US V3 defines Types as the different products and equipment to be installed in the facility, and Components as the individual installed instances of those Types (§4.2.3.2.2.54 and §4.2.3.2.2.85). Type and Component names must match the design drawing schedules for the same project stage (§4.2.3.2.2.55 and §4.2.3.2.2.86).

The schedules are the anchor. The standard says drawing-schedule information should be included in COBie and that comparing the schedules with the COBie file is the basis for assessing its quality (§4.2.5.2.4.9). Its summary of the COBie Guide calls that match the only non-negotiable quality standard for design COBie. Construction COBie then updates the same assets with construction and commissioning information consistent with the contractor's submittals (§4.2.9.1.1).

Early architectural drawings already schedule spaces, doors, windows, plumbing fixtures, and lighting fixtures, and the standard expects that information in COBie (§4.2.5.2.4.8). Equipment and fixture schedules from the engineering disciplines follow as the design develops.

What the US exclusion lists leave out

Section 4.2.7.15 lists the IFC entities to filter out when producing the generic US COBie data set: Table 101 covers the Type and Component worksheets, and Table 102 covers every worksheet. Annex A §A.4 shows the same lists on the IFC4 inheritance tree in Table 58 for types and Table 59 for instances. The COBie Responsibility Matrix describes these entities as not considered managed assets (§4.2.9.1.2).

Buildings, storeys, and spaces are not Types or Components either. COBie records them on the Facility, Floor, and Space worksheets.

What stays eligible

Everything not on the lists remains eligible, which covers much more than mechanical plant. The table above gives examples; Annex A Tables 58 and 59 list every entity. Building element proxies are not excluded either, so generic modeled objects need a decision based on what they actually are.

Eligible is not the same as required. The exclusion lists say what is not a managed asset in the generic US data set; the owner's requirements decide which eligible products a project must deliver. Revit categories do not map one-to-one to IFC entities, so judge each type by its function rather than its category name.

Types also record whether a product is fixed or movable through Type.AssetType (§4.2.3.2.2.58), and Annex A Table 44 maps furniture types to Moveable.

The owner sets the final scope

The US lists are a baseline. Section 4.2.7.15 notes that owners may extend COBie to non-managed facility assets and advises software vendors to support contract-specific exclusion lists. Annex A adds that regional or contract-based lists are at the discretion of those regions or owners.

Section 4.2.9.1.1 describes COBie as designed for customization through owner-specific classifications, commonly required property sets, and space and product requirements, which owners document in Appendix A of the COBie Guide. Table 4 of the standard says the generic COBie Guide should be updated for an owner's requirements before COBie is specified.

Before setting the scope, ask for the owner's COBie requirements, responsibility matrix, or asset list. Where the contract adds items the generic lists leave out, or omits eligible items, the contract governs that project.

Every Component needs a Type and a Space

COBie's business rules check that product assets have a valid Type and that every Component is assigned to a Space (§4.2.6.2.3). The quality-control rules require Component.TypeName and Component.Space to reference existing rows, and the Type rules include a check named AComponentForEachType, so a Type without installed Components is flagged (§4.2.8.1.3).

• Equipment that is not contained in a single space uses the Space from which it is most likely to be maintained (§4.2.3.2.2.88).
• Products scheduled only by type still need a unique name for every Component, using a naming rule the contract specifies (§4.2.3.2.2.86).
• A Type with no Components, or a Component without a Space, usually points to a scope or modeling gap rather than a data-entry task.

Which attributes belong

COBie does not define a universal property set for each kind of equipment. Section 4.2.6.2.1.34 places the standardization of property sets outside the COBie effort, and §4.2.6.2.1.35 notes that attribute sets for standard equipment types were not submitted for consensus review. In their absence, the COBie Guide says Attributes should match the product data properties on the associated contract deliverables, such as design schedules and manufacturers' data sheets.

Annex A §A.5 then lists properties that should not become Attribute rows when COBie is produced from IFC:

• Modeling and layout metadata: Host, Phase, Phase Created, Mark, Symbol, Line Pattern, levels, offsets, and zones (§A.5.1).
• Classification bookkeeping: Assembly, Category, Classification, OmniClass, and Uniclass codes and descriptions (§A.5.1).
• Raw dimensions: Property names containing Height, Length, Radius, or Size, or starting with Width (§A.5.1).
• Values with their own COBie fields: Serial number, installation date, warranty start date, tag number, bar code, and asset identifier, plus circuit number and system name and type (§A.5.2).
• Values with dedicated Type columns: Manufacturer, model number, warranty terms, expected life, replacement cost, nominal dimensions, color, finish, material, and similar product fields (§A.5.3).
• Space, Floor, and Facility fields: Space area, number, and zone name; Floor elevation; and Facility phase (§A.5.3).
• Placeholder values: Any property whose value is "default" or matches its own name (§A.5).

These rules were written for IFC exports. In a Revit workflow, treat them as guidance rather than a literal name filter: check whether the information already has a dedicated COBie field before dropping it, and keep operating characteristics such as rated capacity even when every instance of a type shares the same value.

A practical scope checklist

• Get the owner's COBie requirements, responsibility matrix, and any required asset list before modeling decisions are locked.
• Start from the design schedules: every scheduled product should appear as a Type, with names that match the schedule.
• Leave out walls, slabs, roofs, and structural framing; stairs, ramps, and railings; duct, pipe, and cable runs with their fittings; fasteners; and openings, unless the contract adds them.
• Decide eligible but optional categories, such as coverings and furniture, against the owner's list.
• Check that every Component references an existing Type and Space, using the maintenance access space for equipment that serves several rooms.
• Keep Attributes that match schedules and data sheets; remove modeling metadata and values that belong in dedicated fields.
• Review the scope again after each model update, when new families and types appear.

How BIMRelay applies this

In BIMRelay, asset rules decide which Revit categories, families, and types become Type and Component rows, and attribute settings decide which Revit parameters become Attribute rows. After each model extraction, Asset review compares that selection with the guidance above and recommends what to include or exclude, with the evidence behind each suggestion. A project manager previews and confirms any change.