How to Define Useful Asset Information Before BIM Handover

A large model is not the same as a useful handover

A project can deliver millions of model properties, drawings, certificates, photographs, manuals, and schedules while leaving the facilities team unable to answer a basic question: which maintainable asset is installed here, what does it serve, what evidence proves acceptance, and who must keep its record current? Volume can disguise incompleteness. The goal of BIM handover is not to preserve every piece of project data forever; it is to transfer trustworthy information that supports the owner's real operational, safety, maintenance, financial, and future-change decisions.

ISO 19650-3 specifies an information-management process for the operational phase of assets and the exchanges of information within it [1]. The UK BIM Framework explains that asset information requirements, or AIR, set out what the owner or operator needs and should be defined before related appointments [2]. Together they point to the right starting question: not "what can the model contain?" but "what information will a named person use, for which asset-management purpose, at what decision point?"

Do not ask the project to hand over everything the model can hold; ask it to deliver what an operator must trust, test, and maintain.

Start with operational decisions, not available fields

Interview the people who will operate the asset: facilities management, maintenance, engineering, health and safety, sustainability, finance, security, workplace, estates, procurement, and the teams that administer the receiving systems. Ask what they decide repeatedly, what triggers work, which evidence they must retrieve, where poor information creates delay or risk, and which system is authoritative after handover. Typical purposes include locating an isolation point, planning preventive maintenance, checking warranty coverage, ordering a replacement, demonstrating commissioning, preparing statutory inspection, analysing energy, managing space, or scoping a future alteration.

The UK's Government Functional Standard for Property says transitions into operation should be planned from project outset and maintained throughout delivery; it also frames BIM as a basis for decisions across development, operation, and maintenance [3]. That requirement applies to UK central government, not every project, but the management lesson is widely useful. Operational input cannot be a final export review. If the receiving team's decisions are discovered after construction, the project will be collecting missing identifiers and evidence when the people who know their origin are already demobilising.

Decide which things deserve managed asset records

Not every modeled object needs an operational record. Owners usually need deliberate scope rules for maintainable equipment, regulated systems, spaces, critical assemblies, warranty-bearing products, replaceable components, metered assets, safety devices, and any item whose identity affects planned work or risk. A ceiling tile may need a product reference at type level; an air-handling unit may need a unique instance, location, system relationship, serial number, commissioning result, warranty, maintenance plan, spares, and linked documents. The required granularity follows the decision and the operating model.

COBie is a performance-based specification for exchanging facility asset information, particularly equipment and spaces. WBDG guidance tells owners to choose the classifications they use, limit scheduled information to assets actually managed or maintained, and identify the properties required for those assets [4]. COBie can be useful, but it is not a reason to request every possible worksheet or field. A format is an exchange mechanism. The owner's scoped, purposeful information requirement must come first.

Use the E2W asset-information decision matrix

For every required information item, record eight fields: **operational user**, **decision or task**, **asset scope**, **required value and definition**, **authoritative source and producer**, **exchange format and destination**, **acceptance test and delivery stage**, and **maintenance owner after handover**. One row might state that the maintenance planner needs the manufacturer's exact model reference for every maintainable pump to select parts; the approved equipment submittal is the source; the contractor provides the value in the agreed exchange; it must match the installed nameplate at commissioning; it is loaded into the CMMS before practical completion; and the facilities data steward owns later changes.

This matrix is an E2W professional framework, not an ISO form. Its value is traceability. It prevents a field such as "installation date" from floating without meaning: who uses it, whether it means delivered, installed, commissioned, or accepted, where the verified date originates, which assets require it, and who updates it after replacement. It also exposes requirements that belong in a document, drawing, photograph, test result, or operating procedure rather than forcing every piece of meaning into an object property.

Assign each value to the party and stage that can produce it

Information matures across the project. Designers can establish spaces, systems, design performance, type requirements, and classification. Contractors and specialists can confirm selected products, suppliers, installation dates, serial numbers, and access needs. Commissioning teams can add test evidence, setpoints, results, and acceptance status. Owners and operators provide enterprise identifiers, maintenance strategies, cost centres, criticality rules, receiving-system constraints, and future stewardship. Requirements should flow to the party closest to the reliable source instead of asking one coordinator to reconstruct everything at the end.

The UK BIM Framework says AIR are led by the appointing party, normally the owner or its representative, with asset and facilities management involvement where those teams exist [2]. Government Soft Landings guidance likewise treats engagement as a lifecycle activity spanning inception, design, construction, and pre-handover, with explicit attention to facilities management, training, commissioning, and effective day-one operation [5]. A useful delivery schedule therefore has progressive exchanges and review gates, not one final drop.

Separate required meaning from file format and software

Three choices are often collapsed into one: the information the owner needs, the structure used to exchange it, and the system that will maintain it. Keep them distinct. The same operational requirement might be exchanged through COBie, IFC, a controlled spreadsheet, an API, or a platform-specific import, then stored in a CMMS, CAFM, asset register, document system, digital twin, or several governed systems. The contract should identify the target schema, identifiers, units, classifications, document links, security constraints, and import rules without assuming that a federated design model will become the operational source of truth unchanged.

buildingSMART describes IFC as an open, vendor-neutral standard for standardized digital descriptions of built assets and machine-interpretable information [6]. IFC can support interoperability, but a syntactically valid IFC file may still omit the fields an operator needs or include values the receiving system cannot use. Conversely, operational records may legitimately live outside IFC. Test the end-to-end exchange: export, validate, import into a safe environment, preserve identifiers and relationships, retrieve linked evidence, and have the intended user perform the decision the information was commissioned to support.

Turn every material requirement into an acceptance test

Avoid vague requirements such as "all asset data complete" or "BIM model suitable for FM". Define measurable rules: which asset classes must appear; which fields are mandatory, conditional, or prohibited; permitted classifications and units; uniqueness and naming rules; relationship checks between component, type, system, space, document, and task; evidence-link behaviour; allowed null reasons; coordinate or location conventions; and the tolerance for exceptions. Then state who checks the rule, with which tool or review method, against which source, at which gate, and what happens when it fails.

buildingSMART's Information Delivery Specification can express IFC information requirements in a computer-interpretable form and support automated compliance checking for objects, classifications, materials, properties, and values [7]. Automation is valuable for repeatable structural tests, but it does not decide whether a value is true. A pump can have a valid serial-number field containing the wrong serial number. Combine machine checks with sampling against approved submittals, physical labels, commissioning records, and user acceptance in the receiving system.

Protect identifiers, relationships, and evidence

Stable identifiers are the spine of handover. Define how assets, spaces, systems, documents, types, and locations are identified; who issues identifiers; how duplicates and replacements are handled; and which identifier persists across the model, commissioning platform, asset register, maintenance system, drawings, and physical labels. Names written for visual coordination are not always durable operational keys. An asset moved, replaced, split, or merged after handover needs a controlled history rather than a silent overwrite.

Documents need the same discipline. Link an O&M manual, warranty, certificate, test result, photograph, or commissioning sheet to the asset or system it supports; include revision, status, origin, date, and permitted use; and keep the link resolvable after project accounts close. The Environment Agency's Data Requirements Library illustrates a maintained catalogue of asset, element, and information attributes, including commissioning and performance-evaluation information [8]. Its content is organization-specific, but the pattern is strong: govern definitions and their history as reusable data requirements rather than rebuilding an inconsistent spreadsheet for every project.

Prepare the receiving operation as carefully as the deliverable

Even accurate handover data fails when there is nowhere responsible for it to land. Before acceptance, confirm the receiving system, data owner, steward, administrators, role-based access, import mapping, document repository, backup, integration dependencies, support route, and change process. Define which system is authoritative for each information domain and how updates flow when an asset is maintained, relocated, replaced, renamed, decommissioned, or added outside a capital project. Include security classification and avoid exposing sensitive location, access, or infrastructure details more widely than operational need permits.

Run rehearsals with real users before the final gate. Ask a maintenance planner to find a component and its isolation information, a technician to locate the current manual, an asset manager to identify warranty and replacement context, and a project team to update a record after a simulated replacement. Record whether the information was present, correct, reachable, understandable, and actionable. A successful import proves that rows entered a database; operational rehearsal shows whether the handover can support work.

Accept information with exceptions visible—and keep it alive

At each delivery gate, classify requirements as accepted, accepted with a bounded exception, or held. For every exception, name the affected assets and decisions, corrective owner, due date, temporary control, evidence required, and authority that can close it. Do not use an overall completeness percentage to hide a missing critical record. One absent fire-system certificate or inaccessible isolation schedule can matter more than thousands of populated low-consequence fields.

Handover is the start of operational information management, not the finish. ISO 19650-3 applies its management process during operation and to information exchanges within that phase [1]. The owner therefore needs triggers for maintaining the asset information model: inspection, planned maintenance, fault, replacement, alteration, new project, change of use, regulatory review, or disposal. This is where [better project documentation](/insights/the-quiet-value-of-better-project-documentation), [operational clarity in architecture](/insights/designing-architecture-for-operational-clarity), disciplined [data ownership](/insights/planning-data-ownership-across-business-systems), and E2W's [web and software systems service](/services/web-software) meet. Useful asset information is defined by the decisions it supports, proven by the evidence behind it, and sustained by the people who own it next.