Parts 1 and 2 delivered the asset. Part 3 runs it for fifty years.

Part 1 set the vocabulary. Part 2 produced the building and the model that documents it. Part 3, ISO 19650-3, governs everything that happens after handover, across the asset's operational life. That life is measured in decades: a building handed over in 2026 may still be operated in 2076.

The whole part turns on one event and one habit. The event is the PIM-to-AIM transition, the moment the delivery model becomes the operational record. The habit is keeping that record current through trigger events for the rest of the asset's life. About seventeen minutes of reading.

How does the model you built turn into the model you operate?

During design and construction the deliverable is the PIM, the Project Information Model. It carries coordination geometry, temporary works, superseded design options, construction-only parameters, everything a project needs to get built. The operations team needs almost none of that. What they need is a clean, trustworthy record of what was actually installed, enriched with the data to maintain it.

So the PIM doesn't simply become the AIM. It is filtered, enriched and validated into it through five defined activities. ISO 19650-3 names them, and the order matters.

1, Data Audit

Review every category of PIM content against the AIR and OIR, the asset owner's operational information needs, and decide, for each, whether it transfers to the AIM, is excluded, or transfers in part.

The output is a categorised content inventory with a keep/exclude decision against each data type. Skip this and construction-phase noise leaks straight into the operational record. The audit defines the scope; everything downstream depends on it.

2, Data Cleansing

Strip out everything built for construction and useless for operations: coordination geometry, temporary works, superseded design iterations, duplicate files, unused views and families, construction-only parameters, orphaned elements.

Cleansing has a strict do-not-remove list too, all as-built geometry (LOD 500), every maintainable-asset parameter, the final approved documents, serial and warranty data, O&M files, test certificates, fire and life-safety information, and spatial data. Cleansing removes noise, never substance.

3, Data Enrichment

This is where the PIM becomes an AIM. You add the operational data the delivery phase never captured: site-verified serial numbers, actual installation dates, warranty expiry from commissioning records, maintenance intervals, spare-parts lists, supplier contacts, FM-specific parameters.

One detail decides the quality of the whole AIM: serial numbers must come off the physical equipment on site. Specification, procurement, and installed numbers are routinely different, and a procurement number in the asset register is a wrong number.

4, Validation

Three stages, all of which must pass before acceptance.

Automated, schema, naming, completeness, classification, duplicates, units, file formats, document links, all checked by tool. Manual, a 10–20% sample of maintainable assets verified against physical site conditions: serials, geometry, locations, document links. FM integration test, a trial import into the target CAFM/CMMS to confirm the data is actually usable.

Outcomes are coded: PASS, CONDITIONAL PASS (minor non-conformances with an agreed remediation timeline), or FAIL (critical deficiencies, returned for correction).

5, Platform Migration

Transfer the validated AIM from the delivery-phase CDE to the operational platform, the CAFM/CMMS and/or operational CDE. Document the migration steps and confirm data integrity afterwards.

The platform must be configured and tested in parallel with Activities 1–4, never started cold at the end. The migration is the last step, but the platform readiness is not.

Deep diveWho runs the transition, when it must start, and the five ways it fails

Who runs it

Role	Responsibility
Transition Lead (usually BIM Manager)	Owns and drives the plan; coordinates all five activities and all parties
BIM Manager	Validates model content, manages data quality, oversees migration
FM Representative	Defines operational data needs (AIR); confirms the AIM meets FM requirements; runs the FM integration test
Contractor Data Lead	Provides as-built data, equipment information, commissioning records, the enrichment inputs
CAFM/CMMS Administrator	Configures the target platform; performs and documents the import test
Client Representative	Final acceptance authority; signs off the AIM
MEP Coordinator	Validates MEP asset data and system definitions

When it must start

The transition is not a close-out activity. Draft the plan at the start of Stage 4 (Technical Design) and manage it actively from Stage 5 (Construction) onward. Retroactive data collection at handover is the single biggest cause of poor AIM quality, and starting at practical completion typically delays FM-system go-live by three to six months.

The five failure modes

Starting too late. The most common one. Build transition milestones into the construction programme from award, not at practical completion.

A rushed audit. Without a clear audit, construction-phase data leaks into the AIM and the operations team inherits the noise. The audit defines the scope, never skip or rush it.

Procurement serial numbers. Serials taken from the spec or the purchase order instead of the installed equipment. They are frequently wrong, and a wrong serial breaks every future work order against that asset.

No FM involvement. Engage the FM team by Activity 3 at the latest. If they don't validate the AIM before sign-off, it will not meet their operational needs, and they are the customer.

Platform not ready. CAFM setup left until migration. Do not start Activity 5 before the platform is configured and tested.

The handover checklist

The transition produces the AIM; the handover checklist proves it is fit to accept. The developer or FM team runs it against every deliverable the contractor submits, and the formal output is a signed PIM-to-AIM acceptance certificate (the gate that opens the operational phase).

ISO 19650-3 fixes seven mandatory deliverable categories. Everything in the checklist hangs off these.

The seven mandatory deliverables

1. As-built models, LOD 500, as-installed, all disciplines, native plus IFC.
2. COBie dataset, structured FM asset data: spaces, types, components, maintenance.
3. O&M manuals, product-specific (not generic templates), linked to model elements.
4. Test & commissioning certificates, proof of performance for every system.
5. Warranty information, durations, start dates, supplier contacts.
6. Room data sheets, environmental and functional data per space.
7. Health & safety file, residual risks, hazardous materials, safe access.

Every container in the package must have reached Published state in the CDE before it counts as delivered.

The acceptance workflow

The contractor submits; the developer or FM team runs the checklist; the outcome follows one of three paths.

All mandatory items pass → accept the handover and issue the PIM-to-AIM acceptance certificate. Failures exist → log each in the Deficiency Register with a responsible party and deadline; the contractor corrects and resubmits; re-validate the failed items only. Critical failures → reject the package; the contractor must resubmit in full.

Three thresholds govern the call: Full Acceptance (all of Sections 1–6 pass, ≥95% across mandatory sections), Conditional Acceptance (≥80% with all failures logged and remediation agreed within 30 days), and Rejection (below 80% on any mandatory section, or any critical item fails).

Deep diveThe score card and the items that catch real failures

The full checklist is 75 items across twelve sections. The structure, and where it bites:

Section	Items	What it catches
1A As-built model verification	8	All disciplines Published; as-built spot-check (10 elements/discipline); correct coordinate system; native + IFC 4.0; federated model
1B Model quality	6	Clean model audit (no critical warnings); zero unresolved hard clashes
2A Asset register completeness	4	Count plausible vs site (sample-verify 15%); unique IDs, no duplicates
2B Asset data quality	9	Real manufacturer/model (no "TBC"); serials spot-checked 15% vs physical labels; physical reality check 10–15%
3A COBie structure & schema	4	All worksheets present; schema validation; no blank required fields
3B COBie data integrity	9	Type and Component populated; logical systems; valid document links; FM platform import test passes
4A O&M manual delivery	5	Product-specific manuals; linked to model/COBie; emergency procedures
4B Certificates & records	7	Statutory test certs; commissioning data; warranties; as-built drawings; spare parts; BMS config; H&S file
5A CDE status & organisation	6	All handover containers Published; superseded versions archived not deleted; FM access transferred; MIDP shows 100% delivery
5B Information completeness	4	EIR compliance matrix; BEP close-out with deviations + lessons; LOIN verified at handover stage
6A Review & approval	6	Technical + FM review; physical walk-through; deficiency register cleared; PIM-to-AIM certificate signed
7A Digital twin readiness	7	Optional, assessed in Act V

Status codes and evidence

Each item is marked PASS (criteria met, evidence recorded), FAIL (logged in the Deficiency Register with a responsible party and deadline), PARTIAL (remediation plan required with a deadline), or N/A (justified in writing). Evidence is mandatory throughout, cite the document name, CDE path, or system record. A reviewer challenges every unexplained N/A.

The acceptance certificate is signed by the developer/asset-owner representative, the lead appointed party (BIM Manager), the FM team representative, the Information Manager, and the appointing-party authoriser.

The AIM Management Plan

At handover, the AIM Management Plan replaces the BEP as the project's primary information-management document. The BEP governed how a team would produce information; the AIM Management Plan governs how the owner will keep it, for the life of the asset.

It is drafted during Stage 5–6 so it is ready at practical completion, signed off alongside the COBie package and the as-built models, and approved by the asset-owner representative and the FM director. It is an operational governance document, not a construction one. It defines what is in the AIM, where it lives, who can touch it, how it stays current, and how it connects to the FM systems.

What the AIM contains

The AIM is the complete operational repository: as-built 3D models (Revit + IFC 4.0), the non-graphical asset data and COBie package, O&M documentation linked from COBie, spatial and room data, test and commissioning certificates, the warranty register, maintenance schedules, the health & safety file, the BMS point schedule, and the as-built 2D drawings.

Every "No" against a component is a gap that costs the owner later. The plan is where you push for completeness at handover, because after handover, filling a gap means going back to a contractor who has already been paid.

Who owns it, and the review cadence

The AIM needs a named owner, the AIM Manager, with the authority and the resource to keep it current. Around that role sits a fixed review cadence: an AIM currency review quarterly, a CAFM data reconciliation every six months, and a stakeholder review, security review, and plan review annually.

The operational CDE carries its own folder structure (as-built models, COBie, O&M, certificates, warranties, H&S, maintenance records, a trigger-events folder, tenant fit-outs, and a dated archive) and role-based access on the principle of least privilege, a maintenance contractor uploads but never edits the master; an external auditor only views.

Deep diveCAFM integration and the operational validation that never stops

The AIM only has value if it is connected

An AIM that sits in a CDE and never reaches the FM platform is a record nobody operates from. The plan defines how COBie data flows into the CAFM/CMMS, IBM Maximo, Planon, IFS, Facilio, by bulk Excel import, API, or ETL. The critical move is to confirm the COBie-to-CAFM field mapping before handover, not after. A worked extract of that mapping:

COBie field	COBie tab	CAFM field (example)	Purpose
Component.Name	Component	Asset.AssetNum	Unique identifier
Component.Space	Component	Asset.Location	Room / space reference
Type.Manufacturer	Type	Asset.Manufacturer	,
Type.ModelNumber	Type	Asset.ModelNum	,
Component.SerialNumber	Component	Asset.SerialNum	,
Component.InstallationDate	Component	Asset.InstallDate	,
Type.WarrantyDurationParts	Type	Asset.Warranty	Convert to expiry date
Type.ExpectedLife	Type	Asset.DesignLife	Lifecycle forecasting
Type.ReplacementCost	Type	Asset.ReplCost	Capital planning
System.Name	System	System.SystemID	Parent system grouping

COBie is referenced here as the handover data schema. The full COBie structure, every worksheet and field, is the subject of Part 4 (ISO 19650-4).

Validation continues for the life of the asset

Handover validation is not the last check; it is the first. The AIM is validated again at every trigger-event update, against six categories: completeness (100% required fields), accuracy (spot-check 10–20% against reality, 95%+), consistency (no duplicate IDs, valid classification), format compliance (zero schema errors), linkage integrity (every Component to a valid Type, every Document to a valid asset, zero orphans), and FM readiness (it still imports, work orders still generate).

How the AIM stays current

The AIM is built once at handover and then immediately starts to age. Equipment is serviced, fails, gets replaced; tenants fit out floors; inspectors issue certificates; a wing is refurbished. ISO 19650-3 calls each of these a trigger event, any operational event that generates new information and requires an AIM update. The trigger-event process is the entire mechanism by which the AIM stays alive instead of becoming a museum piece.

The trigger-event register

Each category of event has a defined response and a defined update scope.

The mini-EIR, a small contract for a small exchange

For routine events, the owner issues a mini-EIR: a brief information requirement that tells the contractor exactly what to capture and how to return it. It is the operational-phase echo of the EIR from Part 1, same logic, smaller scope.

A standard mini-EIR specifies the data to capture (date, technician, findings, parts, next-due), the delivery format (a service-report PDF plus an updated COBie row), the CDE upload location, the delivery deadline (e.g. within five working days), the AIM-update responsibility (the AIM Manager updates within ten working days), and the quality check (the FM Manager verifies completeness before acceptance).

For significant works, a refurbishment, a major upgrade, a mini-EIR isn't enough. You issue a full EIR, exactly as in Part 2, because you are effectively running a small delivery project that will hand a new slice of model back into the AIM.

Sustainability, and the digital twin

Two forward-looking concerns close the operational phase: keeping the information readable across decades, and the option to make it intelligent. The first is a duty under ISO 19650-4; the second is a choice ISO 19650-3 enables but never mandates.

Information sustainability, readable in fifty years

A 2026 handover may be operated in 2076. If the as-built model lives only in a proprietary format whose vendor drops support in fifteen years, the FM team loses its asset data. ISO 19650-4's principle of information sustainability answers this: for every critical proprietary file, archive an open-format equivalent, IFC (ISO 16739) for models, PDF/A (ISO 19005) for documents, CSV/XML for tabular data, COBie for asset data.

The rule is zero critical lock-in: no critical operational information exists only in a proprietary format. Back it with a long-term access strategy, redundant storage, file checksums, a format review every five years, a re-export schedule, and an open-format viewer the FM team can use without an authoring licence.

Digital-twin readiness, the four layers

A digital twin is a dynamic digital representation of the asset, continuously updated with real-world data and used for predictive decisions. ISO 19650-3 does not require one, but the AIM is the foundation any twin is built on. The path runs in four layers, and the order is not optional:

• Layer 1, AIM. The verified as-built model, asset register, O&M and COBie. ISO 19650-3 scope. The non-negotiable foundation.
• Layer 2, IoT / BMS. Live sensor data: energy meters, temperature, occupancy, equipment status.
• Layer 3, FM data. Operational history, work orders, maintenance logs, condition surveys, costs. Needs 6–12 months of structured CAFM data before analytics pay off.
• Layer 4, Analytics. Predictive insight: failure prediction, energy optimisation, lifecycle-cost forecasting. Requires the three layers beneath it to be mature.

The decision point is firm: do not proceed to Layers 2–4 until Layer 1 is Ready. Analytics built on an incomplete AIM produce unreliable results and erode confidence.

Deep diveThe Layer-1 gate and the maturity ladder

Layer 1 is ten mandatory criteria

Layer 1 is "Ready" only when all ten pass, and these are precisely the things the handover checklist already tested, which is why a clean handover is a head start on a twin:

1. Unique asset identifiers on all maintainable equipment
2. As-built model at LOD 500 with verified geometry
3. COBie dataset validated and accepted (all tabs)
4. AIM successfully imported to CAFM/CMMS
5. Asset classification standardised (Uniclass 2015 or agreed scheme)
6. O&M documentation linked to asset records
7. Warranty information populated with expiry dates and contacts
8. Spatial hierarchy intact (Facility → Floor → Space → Component)
9. Maintenance schedules populated and PPM programmes running
10. Health & safety file available and linked

The maturity ladder

Where an asset sits on the path to a predictive twin:

Level	State
0, Not Ready	No validated AIM; significant data gaps; no live data
1, Foundation Ready	AIM validated and in the CAFM; no live data integration yet
2, Connected	AIM + BMS/IoT feeding a platform; basic dashboards operational
3, Operational Twin	AIM + live data + FM history integrated; analytics use cases running
4, Predictive Twin	Full predictive analytics; AI/ML models operational; continuous optimisation

The implementation roadmap follows the same arc, Foundation, Connect, Operate, Predict, and platforms such as Autodesk Tandem, Azure Digital Twins, Bentley iTwin and Siemens Xcelerator ingest the AIM as their starting dataset. The point is unchanged from the start of this part: the twin is only ever as good as the AIM under it.

Further reading

• ISO 19650 series, BSI, Part 3 covers the operational phase in full.
• buildingSMART, COBie and openBIM for asset handover.