Building asset handover: check equipment data before the facility team accepts it

The National Institute of Building Sciences describes COBie, the Construction to Operations Building information exchange, as a standard organization of data used to manage and maintain facility assets. It combines space, product and equipment schedules from the design drawings with as-built, O&M and commissioning information captured during construction, and can be used at the end of new construction, a renovation, or a change in ownership or management.

The COBie data schema overview describes a relational structure of data tables, including facility, space, type, component, system, job and document, with defined unique keys for each table. Whether or not your project requires COBie, that structure is a useful model: assets have types, components sit in spaces, and documents attach to the things they describe.

Before checking anything, agree with the facility team which assets matter and which attributes they need. Typical needs include asset tag, location, manufacturer, model, serial number, install date, warranty start and end dates, and links to the O&M manual and maintenance tasks. Not every light fixture needs the same depth as a chiller.

Write this as a data requirement per asset type. It becomes the checklist the workflow uses, and it should be traceable to the project's handover specification.

The workflow can match each delivered component to the equipment schedules on the design drawings. It lists scheduled items with no delivered record, delivered records with no scheduled item, and records whose type or location does not match the schedule.

Each finding should cite both sides: the schedule entry and sheet, and the delivered record. A mismatch may be a legitimate change made during construction, so findings are questions for the project team, not conclusions.

For each delivered record, the workflow checks required attributes for presence and plausibility: a serial number field that contains a model number, a warranty end date before the start date, or an install date after the handover date. A model can help find values in O&M manuals and warranty letters when they are missing from the data file, but every extracted value must link to its source page for a person to confirm.

Document links matter as much as fields. An asset record pointing to a manual for a different model is worse than a missing link, because a technician may trust it.

Group findings by responsible party: the contractor, a specific subcontractor, the commissioning agent or the design team. Each group receives a list with references, so they can correct the data rather than reread the whole package.

Track each finding to resolution. The owner's team decides when the remaining open items are acceptable and records that decision as part of handover acceptance.

Once records are confirmed, they can be prepared for import into the maintenance system. I would load a confirmed set rather than everything delivered, keep the source identifiers, and record which version of the handover data each asset came from. Later corrections should go through the same check.

Handover data can include security system details, access control equipment and building layouts. Keep the review within the owner's approved environment, limit access to those working on the handover, and confirm a model service's data terms before sending project documents to it.

In a pilot, run the check on a recently handed-over building and compare its findings with the problems the facility team has already found. Track findings confirmed, findings dismissed and problems the check missed.

The acceptance condition I would agree: every asset type has a written data requirement, every finding cites its sources on both sides, every loaded record links to its source documents, and the handover acceptance decision and open items are recorded by the owner's team.

Bring a sample of handover data, the equipment schedules and the attributes your maintenance team uses.