COBie 2.4 · Asset guide
Type
Describes repeatable product and equipment types before individual installed assets are recorded.
Is shared manufacturer, model, warranty, and specification data held once?
Store shared product information once
The Type worksheet describes repeatable products and equipment before the workbook identifies each installed instance. Type.Name is the primary key, and every Component.TypeName should point to one of these records. Holding shared information at Type level avoids repeating the same manufacturer, model, warranty, expected life, and specification values for every installed asset.
A useful Type is neither too broad nor unnecessarily specific. Combining materially different products under one name hides information the operator needs, while creating a separate Type for every identical instance defeats the purpose of the worksheet. The naming convention should correspond to the type labels used in schedules and remain stable across project exchanges.
Type data changes as the project matures
During planning and design, a Type may describe performance requirements, dimensions, material, finish, accessibility, code, and sustainability constraints. Manufacturer, model number, replacement cost, warranty guarantors, and final product references normally become relevant after selection and installation. The workbook should reflect the actual delivery stage instead of filling future handover fields with guesses.
Warranty and expected-life fields also carry units, contacts, and business meaning that must agree. A duration without its unit is ambiguous, and a warranty contact must resolve to a Contact record. Teams should compare final Type rows with approved product data and submittals before treating model parameters as authoritative.
Consolidating Revit types for COBie
Revit family types are a natural source for Type rows, but authoring practices can create duplicates across disciplines and linked models. Two model types with different internal names may represent the same procured product, while one generic model type may later need to split after submittal approval. Asset inclusion rules and source mappings must therefore be explicit.
BIMRelay generates Type rows from the selected Revit evidence, links them to their Component instances, and keeps the originating model identity available for review. Teams can configure source priorities using the model's real parameter names, inspect the related assets in the viewer, and retain approved workbook edits through regeneration when identity still matches.
Key relationships
Parent of Component
Referenced by Spare, Job, Document, and Attribute
Practical quality checks
- Keep type names unique
- Separate type data from instance data
- Resolve manufacturer references
Type worksheet FAQ
- What is the COBie Type worksheet?
- The Type worksheet stores information shared by a repeatable product or equipment class, such as category, manufacturer, model, warranty, expected life, dimensions, and performance data.
- What is the difference between Type and Component in COBie?
- Type describes the shared product definition. Component describes each individual installed instance and references its parent Type through Component.TypeName.
- Should design-stage Type rows include final manufacturer data?
- Only when a product has actually been selected or the contract requires it. Unknown handover values should not be replaced with unverified manufacturer, model, cost, or warranty data.
- How does BIMRelay create Types from Revit?
- BIMRelay uses configured Revit family and type evidence, asset scope, and parameter priorities to generate Type rows and connect them to the appropriate Component instances for review.
This is an independent practical summary, not a reproduction of the COBie specification. Refer to the official standard for normative definitions and field requirements.
Reviewed against the official NIBS COBie 2.4 publication and Annex A worksheet schemas.
Where the official documents, contract-issued workbook, and project validator differ, follow the contract requirements and accepted validation process.
Open the official COBie 2.4 publicationOpen the official COBie 2.4 Annex A worksheet schemas