Buying a COBie Asset Exchange: Follow Types, Components and Spaces

Define the maintainable assets the recipient must find

A data-center owner receiving asset information needs to answer a practical question: which individual unit is this, what product type does it belong to, and which location record describes it? An equipment-model list answers only part of that question. A file named COBie, a blank spreadsheet or a successful opening supplies no evidence that the necessary relationships arrived.

Construction to Operations Building information exchange, or COBie, is a data format and process standard for delivering maintainable-asset information. NIBS defines that asset population around what the facility owner will manage in an operations and maintenance system. Decide the intended population with that recipient; the label does not automatically include every server, GPU or internal part.

This article uses NIBS's public COBie v3 definitions, read on October 20, 2026. Its buying decision concerns a discrete asset exchange and the receiver's use of it.

References: [CB1]

Follow the individual Component to its Type and Space

Type holds information about a product or equipment type, including manufacturer and model fields. Component describes an individual instance and references its Type through Type.Name. Several Components can therefore share one Type without becoming the same unit. A shared model description is useful precisely because each instance need not become another product definition.

Component.Space.Name references a separate Space record. Space in turn carries Level.Name. The recipient follows these relationships to recover shared product information and spatial context from an individual unit's record. A room name supplies a location reference, rather than replacing the unit's identity. NIBS also allows the Component's Space to be where the asset is found or from which it is operated; the agreed location meaning matters.

This organization makes a missing link consequential. A readable Component name can survive while its referenced location record is unavailable. Counting equipment rows will not reveal whether the recipient can complete that lookup.

References: [CB2]

Keep row keys, physical identifiers and receiver identities distinct

Component.Name is unique within the Component table. NIBS's overall structure defines keys in their table context, with compound keys for some other tables; it does not make every Name a universal asset identifier. Always-required fields and references differ from contract-specified and owner-specific requirements.

SerialNumber means the serial on the installed product nameplate; TagNumber means the affixed asset tag. InstallationDate means when the asset reached its final location. These Component fields are If Specified for construction and handover, and not applicable in planning and design. ExtIdentifier relates a record back to its originating software object. AssetIdentifier is an alternative component identifier whose use is defined by the associated contract.

Those roles leave the recipient's matching decision to establish. A Component key need not equal its tag, serial, model-object ID or existing operations ID. Request the correspondence required for your task; do not assume it from similar strings.

A named field is also not an observed value. Define phase, applicability and evidence when requesting it. NIBS directs additional custom fields to Attribute rather than added native-table columns.

References: [CB3][CB4]

Work two units through four selected references

Fictional case CB-OP113 starts with an owner choosing exactly two individually maintained environmental-monitoring units for this teaching population. Type ENV-T1 describes their shared fictional product type. Component records MON-01 and MON-02 both reference ENV-T1. Space records ROOM-A and ROOM-B each reference the separately stipulated Level L1.

In the first return, D1, MON-01 references ROOM-A. MON-02 references ROOM-X, which is absent from the supplied Space records. The compact extract below shows only the relationships needed for this explanation. It is neither a complete COBie payload nor a standard template; other required tables and fields, including SpaceType information, are outside the extract. All identifiers and inputs are invented. No product, installed observation or software execution is represented.

There are two Components, one Type and two Spaces: five records across those three populations, representing two selected maintainable units. The stipulated Level is separate. Adding Type and Space rows to Component rows does not produce five physical units.

References: [CB2][CB4]

Repair the missing reference without guessing the room

D1 cannot supply the Space record referenced by MON-02. ROOM-B exists, but its presence does not establish that it was the intended target. Neither the expected two-unit population nor a similar room name justifies silently substituting it. Return the unresolved MON-02 to ROOM-X relationship to the party responsible for the location information.

For the next issue, D2, the example adds a separate source decision: ROOM-B is MON-02's intended location. Using that supplied decision, D2 changes MON-02's Space.Name to ROOM-B and identifies the decision behind the change. All four selected references now resolve. This result follows from the example's inputs, rather than a validator or import test.

The repaired relationship still describes what the issued data says. It supplies no observation that MON-02 was installed in ROOM-B, no observed serial number, no account of every required asset or field, and no maintenance-system acceptance. Those questions remain unanswered because D2 added a location-reference decision, not the evidence needed to answer them. Report the four lookups as four lookups, rather than a compliance percentage.

Carry the same two units into the receiver's existing records

Now retain D2 and add the recipient's required task in the fictional case: its operations register already contains OPS-501 and OPS-502. Receiving two Component records does not show which existing record each should correspond to. Equal counts and a shared Type are insufficient: swapping the two locations could leave both counts unchanged while giving each receiver record the wrong relationship.

The case therefore adds an explicit proposed correspondence: MON-01 to OPS-501 and MON-02 to OPS-502. This is an additional recipient requirement and example premise. It is neither an automatic COBie obligation nor a result produced by an importer. If the engagement uses AssetIdentifier or another agreed exchange mechanism to carry that correspondence, its meaning still needs to be defined with the receiver.

An exchange-only return can deliver the agreed Component, Type and Space information while leaving this reconciliation to the owner or another provider. A separately scoped receiver demonstration must return evidence of the requested correspondence in the identified receiving environment. For this case, the recipient should be able to follow OPS-501 to MON-01, ENV-T1 and ROOM-A, and OPS-502 to MON-02, ENV-T1 and ROOM-B, within the agreed result.

Require unresolved or conflicting correspondence to remain visible. A second newly created record is not evidence that an existing OPS record was matched. This article prescribes no merge method or product-specific import behavior; the proposed demonstration must establish what actually happened to the selected population.

References: [CB3]

Compare the delivered exchange with the requested recipient result

Compare proposals against the same two-component task. For an exchange-only offer, the output being compared is the identified data issue: can its recipient retrieve MON-01 and MON-02, follow each intended Type and Space reference, and identify the source decision that repaired D1? Keep the original two-component population in view so that removing MON-02 cannot make the missing relationship disappear from the result.

For an offer including recipient reconciliation, the additional output is a returned account from the intended receiving environment. It should identify the exchange issue and receiver-record basis, show the proposed MON-to-OPS correspondence, recover the intended product and location relationships for both units, and expose missing or conflicting information. If the scope includes an actual system update, ask the appointed provider to distinguish the agreed update result from a proposed mapping or preview. No such transaction has been performed in this example.

NIBS's process guidance calls for specifying the data, timing, deliverer and reviewer, selecting phase-appropriate tables and fields with their prerequisites. Apply that guidance to this case: nominate who supplies the ROOM-B source decision, who assesses the asset correspondence and who reviews the returned spatial information. Its review guidance supports content reviewers alongside tools that check formatting, structure or project requirements.

A standards-organized exchange may be the required delivery while receiver reconciliation and system integration are assigned elsewhere. They can be purchased together, with each result identified. Work-order or Job content is another selected requirement; two Component records do not automatically create maintenance work. A representative receiver return supports the scope it demonstrates, rather than interoperability with every maintenance platform.

References: [CB2][CB5][CB6]

Connect the asset exchange to the physical records it needs

Use the physical installation handoff guide for the observations, identity sources and closeout records that can substantiate an installed-state claim. Use the IFC and IDS guide when the separate question is whether a model meets stated information requirements. The Revit component-schedule guide addresses instance and quantity reporting; the operational digital-twin guide addresses continuing observation and time relationships. Those related tasks can supply context without changing what this static exchange establishes.

If your project needs physical-documentation inputs or outputs for an appointed asset-information team, Leviathan's Physical Infrastructure Planning and CAD service is the relevant scope discussion. It can discuss selected layouts, schedules, labels and engagement-defined documentation, with authoring resources, reviewers and supported formats confirmed for the engagement. COBie generation, software checking or import, CMMS integration and maintained digital twins require separately established responsibility; this educational comparison does not establish those as Leviathan services.

Use the related project inquiry to describe the corresponding task in your project: which physical records are available, which relationships the appointed recipient needs, and which documentation output you want to discuss.

References: [L1]