Asset Information, Handover & Lifecycle Data Management

From Requirements to Lifecycle Management

Asset information is not a document produced at the end of a project. It is a sequence that begins before design and continues for as long as the asset is operated:

APP works across the whole sequence, or on the single step where a project is stuck — most often validation, where data has been produced but nobody can say whether it is right.

Asset Information Management

Asset information fails for a predictable reason: nobody defined what was needed before the project started producing it. APP begins from the operational decisions the data has to support — maintenance, replacement, compliance, performance — and works backwards to the requirements.

We define and align:

• Organizational and asset information requirements (OIR, AIR)
• Exchange information requirements for each appointment (EIR)
• The asset breakdown and which items are actually maintainable
• Attributes required per asset type, and who supplies each one
• Information delivery milestones tied to project stages
• Responsibilities across designer, contractor, supplier and operator

Requirements are written to be verifiable. If an attribute cannot be checked at handover, it does not belong in the specification.

Data Standards and Structure

Consistent structure is what makes asset data usable years after the people who created it have moved on. APP establishes the conventions and keeps them enforced through delivery, in line with ISO 19650-3 for the operational phase.

This covers classification and naming, asset and space identification, and the relationships between equipment, systems, locations and facilities. Documentation is linked to the assets it belongs to — submittals, datasheets, specifications, warranties, test certificates and O&M manuals — so that a maintenance technician reaches the right document from the asset record rather than from a folder tree.

Standards are set against the systems that will actually receive the data, and the delivery format — COBie or a structured equivalent — is agreed with the operator before production starts, not after.

COBie Delivery and Validation

COBie remains the most widely specified format for handing structured asset data from a project to the people who will operate it. It is not a model format and not a replacement for one: it carries the subset of information an operator needs — what the asset is, what type of product it is, where it sits, what system it belongs to, who supplied it, what documents describe it, and what it needs in service.

APP specifies, produces and validates COBie deliverables covering the parts that carry operational meaning: facilities, floors, spaces and zones; product types and the individual installed components; systems, assemblies and connections; attributes, documents and coordinates; and the spares, resources and maintenance jobs that make the data usable on day one.

Two failures account for most rejected COBie deliverables, and both are avoidable:

• Type and Component confused. Type describes the product specified; Component is the individual item installed. When suppliers populate one and not the other, the operator can see what was bought but not what is where.
• COBie treated as a closing task. Produced once at the end, it reflects procurement records rather than the asset as built. APP sets exchanges at stage boundaries — design, construction, commissioning, handover — so each drop is checked while the information can still be corrected on site.

Validation runs at three levels: schema conformance, content quality (population, plausibility, units, classification) and cross-reference integrity between sheets, the model and the document set. Results are reported as a non-conformance list against named responsibilities, not as a pass or fail file.

Where COBie does not fit — and for rail, road, water, energy and industrial assets it often does not, because facility, floor and space do not describe the asset — APP defines a structured equivalent on the same principles, aligned with the operator’s own asset hierarchy. The exchange requirement matters; the spreadsheet is only one way of meeting it.

Information exchange is set up in line with BS EN ISO 19650-4, which now governs the exchange process that the withdrawn BS 1192-4 code of practice used to cover.

Verification and Handover

This is where most asset information programs fail, and it is the part APP treats as the core of the service. A delivered data set is not a compliant one.

Before acceptance, APP checks:

• Completeness against the agreed asset register
• Attribute population and value plausibility
• Correct classification and identification
• Consistency between model, documents and register
• Traceability from each record back to its source
• Alignment with commissioning and O&M documentation
• Readiness for import into the receiving system

Where requirements are defined precisely enough, checks are run as automated rules and reported quantitatively; where judgment is required, they are reviewed manually. Findings are returned to the supply chain with enough specificity to be corrected, and re-checked before handover is signed off. The operator receives data that has been tested, not data that has been submitted.

Existing Assets and As-Built Data

Not every asset arrives with usable information. For operating assets, refurbishments and portfolios inherited without records, APP establishes what data exists, what is missing and what is worth capturing — then defines a proportionate route to close the gap through surveys, as-built verification, commissioning records and supplier information.

The test is the same as on a new project: capture what supports an operational decision, and leave out what will never be maintained.

From Handover into Operation

Asset information loses value the moment it stops matching the asset. APP supports the transition into operational use and the routines that keep the data current: structuring and importing data into the operator’s CMMS, CAFM or IWMS, aligning it with the existing asset hierarchy, and connecting it where relevant to building management and automation systems and to GIS, so that assets can be located and managed across a portfolio rather than one building at a time.

Once the data is in place it can answer operational questions directly — which doors and walls carry which fire rating and where they are, what surface areas a planned refurbishment covers, which assets are approaching end of life. APP defines which of these questions the data must answer, and the change process that keeps the answers true as equipment is replaced, modified or decommissioned.

Where a digital twin is in scope, the model is treated as an operational tool rather than a visualization — connected to the asset register, the maintenance regime and, where available, live data.

Digital Twin Readiness

A digital twin is only as good as the asset data beneath it. Twin programs rarely fail on the platform; they fail on the data — assets without persistent identifiers, relationships that were never modeled, attributes nobody specified, documents that sit beside the equipment record instead of being linked to it. The visualization looks convincing long before the data can support a decision.

APP prepares an asset for twin adoption and defines what the twin has to answer before anything is procured:

• Persistent, unique identification for every maintainable asset
• Consistent classification across model, register and operations
• System, space and location relationships that hold over time
• Attributes driven by operational use cases, not by the model author
• Documents and certificates linked at asset level
• Connection points to building management, metering and monitoring data
• Named ownership of updates once the asset starts changing

A twin can be a verified as-built record, an operational view connected to live data, or an environment for testing decisions before they are made. Each level asks more of the data underneath it, and each is worth reaching only if the operator will use it. APP defines the level that is justified for a given asset, the data required to sustain it, and the process that keeps it true after handover.

The test is not how the twin looks. It is whether someone responsible for the asset can act on what it shows.

Typical Services and Deliverables

Depending on the appointment, APP’s scope may include:

• Asset information requirements (OIR, AIR, EIR)
• Asset breakdown and maintainable-item registers
• Attribute schedules by asset type
• Classification, naming and identification conventions
• Information delivery plans and milestone definitions
• Supply-chain guidance and training on data requirements
• Progressive data reviews during design and construction
• As-built data capture and gap assessment for existing assets
• Handover data verification and non-conformance reporting
• COBie or structured data set preparation and validation
• Import and structuring into CMMS, CAFM, IWMS or digital twin platforms
• Asset data change and update procedures
• Operational readiness and portfolio data reporting

Technology Applied to the Method

APP works across the platforms used to author, verify and operate asset information: common data environments in line with ISO 19650, Autodesk Tandem and Autodesk Construction Cloud, COBie toolsets, GIS environments, and the CMMS, CAFM and IWMS platforms already in use by the operator.

The requirements, the verification and the operator’s ability to use the data matter more than the platform that stores it.