# Building asset handover: check equipment data before the facility team accepts it > A proposed handover workflow using a COBie-style structure: data needs per asset type, schedule matching, sourced attributes and owner-recorded acceptance. Canonical URL: https://techtideai.io/blog/building-asset-handover-data-review Markdown URL: https://techtideai.io/blog/building-asset-handover-data-review.md Publisher: TechTide AI, Columbus, Ohio (https://techtideai.io) Author: Alex Cinovoj, Founder & CTO, TechTide AI ยท CTO & Co-Founder, CPG Playbook Type: Field Note Published: 2026-10-29 Collection: October 2026 editorial collection (a label, not the publication date) Reading time: 4 min Topics: COBie data, asset handover data, facility handover checklist, O&M data review Site index: https://techtideai.io/llms.txt Offer summary: https://techtideai.io/offers.md --- At the end of a construction project, the facility team receives a large collection of documents: equipment schedules, operation and maintenance manuals, warranties, commissioning reports and as-built drawings. Somewhere in that collection is the information needed to maintain the building. Turning it into usable records in a maintenance system often takes months, and gaps are discovered only when equipment fails. Checking handover data before acceptance is a good fit for assisted review. A workflow can compare the delivered equipment data with the design schedules and O&M documents and list what is missing or inconsistent. Accepting the handover, and resolving what the contractor still owes, remains with the owner's team and the people responsible under the contract. This is a proposed workflow. Handover requirements are set by each project's contract and specifications, and the owner's facility team defines what data its maintenance system needs. ## Know the structure you are checking against The National Institute of Building Sciences describes [COBie](https://nibs.org/nbims/v3/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](https://nibs.org/nbims/v3/cobie/4-1/) 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. ## Define what the maintenance team needs 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. ## Compare delivered data with the design schedules 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. ## Check attributes and documents 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. ## Route findings to the people who can fix them 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. ## Load only confirmed records 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. ## Keep project data access controlled 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. ## Measure against the facility team's experience 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. [Send the project brief](https://techtideai.io/contact). ## Sources - [COBie](https://nibs.org/nbims/v3/cobie) - [COBie data schema overview](https://nibs.org/nbims/v3/cobie/4-1/) ## Related Field Notes - [Engineering delivery packets: make every issued file traceable](https://techtideai.io/blog/engineering-delivery-evidence-packet) ([Markdown](https://techtideai.io/blog/engineering-delivery-evidence-packet.md)): A proposed delivery-packet workflow that checks issued files against reviewed revisions, approvals and the transmittal so the package can be reconstructed. - [Submittal review preparation: check the package against the spec before the engineer opens it](https://techtideai.io/blog/engineering-submittal-review-preparation) ([Markdown](https://techtideai.io/blog/engineering-submittal-review-preparation.md)): A proposed submittal workflow: confirmed spec checklists, sourced completeness findings, original files intact and engineering judgment kept with reviewers. - [Claude Code vs GitHub Copilot: which one belongs in your stack.](https://techtideai.io/blog/claude-code-vs-github-copilot) ([Markdown](https://techtideai.io/blog/claude-code-vs-github-copilot.md)): Claude Code vs GitHub Copilot: both now run agents and call MCP tools. Where each one fits, how they differ on review, cost and control, and when to run both. - [Tenant estoppel certificates: compare every response with the lease file](https://techtideai.io/blog/tenant-estoppel-certificate-review) ([Markdown](https://techtideai.io/blog/tenant-estoppel-certificate-review.md)): A proposed estoppel workflow for sales and refinancings: a sourced lease baseline, field-by-field comparison of returned certificates and recorded decisions. All Field Notes: https://techtideai.io/blog