An Asset Information Model is the information an owner operates a built asset from — graphical models, structured data and documentation, held and maintained through the asset’s life. Almost every guide describes it as what the project model becomes at handover. ISO 19650-3 does not say that. It says the Project Information Model contributes to the AIM, and information moves in both directions — including from an existing AIM into a new project. This guide covers what an AIM actually is, the two-way relationship most sources miss, why an as-built model is not an AIM, and what maintaining one requires.
- What an Asset Information Model is
- Asset Information Model vs PIM: the two-way relationship
- An as-built model is not an Asset Information Model
- What goes into an Asset Information Model
- AIR: where it all starts
- The link to ISO 55000
- Maintaining the Asset Information Model
- Who creates and uses it
- Formats and system integration
- The Asset Information Model as a project input
- Gulf handover and submission
- Seven Asset Information Model failures
- Frequently asked questions
What Is an Asset Information Model?
An Asset Information Model (AIM) is the information model that provides the data required to operate, maintain and manage a built asset — as distinct from the Project Information Model (PIM), which provides the data required to deliver it.
An Asset Information Model is not a file. It comprises graphical models, non-graphical data, and the documentation needed for the operation, maintenance and management of the objects it describes. In practice that means 3D models alongside equipment registers, maintenance schedules, warranty records, performance data and operating manuals, held in a structure the owner’s systems can use.
It is defined in ISO 19650-3, the part of the series covering the operational phase of assets, and it is created and used by the appointing party, end users and facility managers rather than by the project delivery team.
Asset Information Model vs PIM: The Two-Way Relationship
This is where most published guidance is incomplete, and the incompleteness matters commercially.
The common description is a one-way pipeline: the project team builds a PIM, and at handover it becomes the AIM. ISO 19650-3 describes something different. Its lifecycle diagram identifies four distinct moments:
| Point | What happens | Direction |
|---|---|---|
| A | Start of the delivery phase — transfer of relevant information into the project | AIM → PIM |
| B | Start of the operational phase — transfer of relevant information into operation | PIM → AIM |
| C | Post-occupancy evaluation or performance review | Assessment |
| D | Trigger events during the operational phase | Update |
Two consequences follow, and both are routinely missed:
- Point A exists. At the start of a project on an existing asset, the existing AIM is an input. The project team should be receiving information, not only producing it.
- Transfer is not limited to A and B. ISO 19650-3 notes explicitly that information can be transferred between PIM and AIM during the delivery phase as well. Waiting until handover to move anything is a choice, not a requirement.
Producing a handover model that has to become an AIM?
AMC Engineer delivers coordinated LOD 300–500 BIM models across Architecture, Structure, MEP, Electrical, Infrastructure and Landscape — classified, tagged and structured so information transfers into operation instead of stopping at handover. Free LOD 200 sample from your own drawings in 24 hours.
An As-Built Model Is Not an Asset Information Model
The most consequential misunderstanding in this subject, and it is worth being precise about.
ISO 19650 states that the Project Information Model contributes to the Asset Information Model. Contribution means input — not equivalence, not automatic transformation, and not completeness. An as-built PIM may be one source for the AIM. It does not become one by being relabelled.
Whether information from the as-built model belongs in the AIM depends on three things:
- The model uses the client actually wants to support. Not what BIM can theoretically do — what this owner will actually use.
- The asset management or facility management processes involved. The AIM has to serve real workflows, not an abstract idea of good information.
- The technological systems that will consume the information. Data the owner’s CAFM or maintenance system cannot ingest is data that will not be used.
The practical difference is direction of derivation. A PIM contains a great deal the operator will never need — temporary works, superseded design options, coordination history, construction sequencing. An AIM needs things the project may never have produced — serial numbers, warranty expiry dates, maintenance intervals, spare part references. Handing over the PIM and calling it an AIM delivers the wrong information in both directions.
Our guide to as-built versus record drawings covers the related terminology confusion on the drawing side.
What Goes Into an Asset Information Model
ISO 19650-3 gives examples of the kinds of information an AIM may be required to carry, and they span four categories that are worth separating because different people ask for them.
| Category | Examples | Who needs it |
|---|---|---|
| Managerial | High-level maintenance schedules, asset hierarchies, criticality | Asset and facility managers |
| Technical | Operational data such as equipment performance limits, capacities, settings | Operations and maintenance teams |
| Legal | Vendor data, warranties, compliance certificates, statutory inspection records | Compliance and legal |
| Commercial | Operating costs, downtime impact, replacement values, KPIs | Finance and portfolio management |
The range is the point. Asset management means a lot of things, and an AIM scoped only around geometry and equipment schedules will satisfy the maintenance team and nobody else in the organisation.
AIR: Where It All Starts
Everything above depends on one document that most projects never produce properly: the Asset Information Requirements.
The AIR states what information the owner needs to operate and maintain the asset. It is the source of what the AIM must contain, and it flows down into the project’s Exchange Information Requirements and from there into what the delivery team is contracted to produce.
The critical and frequently neglected step is defining the AIR based on real information needs rather than on a template. An AIR copied from another project asks for information this owner will not use, and omits information they will need — and neither gap appears until years later.
ISO 19650-3 also requires the appointing party to ensure that an existing or new AIM is aligned with the AIR defined for the process — which is an ongoing obligation, not a one-time check at handover.
Our guide to construction asset management covers how to write an AIR, what data each asset type needs, and the asset tagging alignment that makes any of it usable.
The Link to ISO 55000
A connection almost no commercial guidance makes, and one that changes who in an organisation cares about this.
The ISO 55000 series defines a management system for managing assets and portfolios of assets across their lives. In managing assets, asset information is a critical enabler — and ISO 55001 clause 7.5 requires an organisation to specify, implement and maintain processes for its asset information.
That matters for two reasons:
- The AIM is not a BIM topic. It is the built-asset expression of an asset management obligation that exists independently of whether the organisation uses BIM at all.
- The business case sits outside the project. An owner pursuing ISO 55001 already has a requirement to manage asset information. Framing the AIM as delivering against that requirement is a far stronger argument to a portfolio owner than framing it as a BIM deliverable.
Maintaining the Asset Information Model
An Asset Information Model that is created at handover and never updated becomes actively dangerous, because people continue to trust it.
ISO 19650-3 sets out the process for maintaining the AIM across the asset lifecycle, and the operative concept is the trigger event — point D in the lifecycle diagram. Information is updated not on a calendar but when something happens that changes the asset.
Typical triggers:
- Equipment replacement or major repair
- Fit-out, refurbishment or change of use
- Statutory inspection or recertification
- Change of tenant, operator or service provider
- Performance review or post-occupancy evaluation
- Any project on the asset — which returns to point A
Who Creates and Uses It
- The appointing party (owner) defines the AIR, owns the AIM, and is responsible for it being maintained.
- End users and facility managers use it daily and are the best source of what it actually needs to contain — which is why involving them at design stage rather than at handover changes the outcome.
- The delivery team contributes to it through the PIM, against requirements set in the EIR.
- An asset information manager — a named role on the owner’s side — maintains it. Where nobody holds this role, the AIM has no custodian and will decay.
Formats and System Integration
An Asset Information Model has value only inside the systems the owner actually uses. The structure of its data must therefore enable transfer into computer-aided facility management systems, maintenance management systems, or whatever else will consume it.
- IFC for the model, as an open and durable format that outlives software versions.
- COBie or an equivalent structured exchange for the asset data.
- The operator’s own import format, which may be neither of the above.
The requirement is that formats are agreed in advance in the Exchange Information Requirements. Discovering at handover that the CAFM system cannot ingest what was delivered is a scheduling problem disguised as a technical one — and it is entirely preventable by asking the operator’s system administrator during design.
Our guides to ISO 19650 and BIM standards and the common data environment cover the wider framework and where the AIM is held.
The Asset Information Model as a Project Input
Returning to point A, because this is the direction with the clearest commercial value and the least coverage anywhere.
When an owner starts a project on an existing asset, ISO 19650-3 anticipates relevant information transferring from the AIM into the PIM. In practice that means the project team begins with accurate documentation of what is there, rather than with a survey and a set of assumptions.
| Owner with a maintained AIM | Owner without one | |
|---|---|---|
| Project start | Existing conditions issued to the design team | Survey commissioned, weeks added |
| Cost | Already paid, once | Paid again on every project |
| Concealed services | Documented from when they were installed | Unknown — a survey cannot see them |
| Design risk | Designed against verified information | Assumptions discovered on site |
That last row is the one that compounds. A survey of a completed building captures visible geometry well and concealed services not at all. Information about what runs above a ceiling exists only if someone recorded it before the ceiling closed — which is a point A benefit that no amount of later spending recovers. Our guide to scan to BIM services covers that limitation in detail.
Gulf Handover and Submission
Two regional factors affect how an AIM is produced and what it has to satisfy.
The model may already be an authority deliverable
Dubai Municipality has required BIM on defined categories of project since 2013, and a circular issued in October 2023 introduced BIM model submission for new building permits with IFC as the format, from the start of 2024. Abu Dhabi Municipality publishes CAD and BIM submission requirements covering naming conventions, coordinate systems and file formats, referencing ISO 19650.
Projects already producing classified, correctly named, IFC-exportable models for permitting are structurally much closer to a usable AIM than projects that are not. The work of classification and naming has already been paid for; what remains is attaching the operational data.
Long-hold ownership changes the calculation
Much of the region’s commercial and institutional stock is held long term by developers, government entities and institutional owners rather than sold at completion. Where the party commissioning a project is also the party operating it for decades, the AIM is a direct investment rather than a cost passed to someone else — and point A pays back on every subsequent fit-out and refurbishment.
Want the handover model to serve operations, not just closeout?
We structure models for the life after construction — classification, asset parameters, structured data and open format delivery — alongside the coordination and documentation the project itself needs.
Seven Asset Information Model Failures
| Failure | What it causes | The fix |
|---|---|---|
| PIM relabelled as the AIM | Construction information the operator will never use, missing the data they need | Define the AIM as a distinct deliverable derived from the AIR |
| AIR never written, or copied from a template | Information nobody asked for, and gaps discovered years later | Base the AIR on the owner’s real information needs and processes |
| Point A ignored | Every project on the asset starts with a fresh survey | Issue existing AIM information to the delivery team at project start |
| Format not agreed in the EIR | A dataset the operator’s system cannot import | Confirm the import format with the system administrator during design |
| No named custodian | The AIM decays while people continue to trust it | Assign an asset information manager on the owner’s side |
| Updated on a calendar, not on events | Changes to the asset never reach the model | Define trigger events and update against them |
| Scoped around geometry only | Satisfies maintenance and nobody else in the organisation | Cover managerial, technical, legal and commercial information |
Frequently Asked Questions
What is an Asset Information Model?
The information model providing the data required to operate, maintain and manage a built asset, as distinct from the Project Information Model which supports delivery. It comprises graphical models, non-graphical data and the documentation needed for operation, maintenance and management, and it is defined in ISO 19650-3, the part of the series covering the operational phase.
What is the difference between an AIM and a PIM?
The PIM relates to the delivery phase and exists to get the asset built. The AIM relates to the operational phase and exists to keep it running. They contain substantially different information: a PIM carries temporary works, superseded options and coordination history the operator will never need, while an AIM needs serial numbers, warranties, maintenance intervals and spare part references the project may never have produced.
Does the PIM become the AIM at handover?
No. ISO 19650 states that the PIM contributes to the AIM — contribution meaning input, not equivalence, not automatic transformation and not completeness. An as-built PIM may be one source for the AIM but does not become one by being relabelled. What belongs in the AIM depends on the uses the client actually wants, the asset management processes involved, and the systems that will consume the information.
Is information only transferred at handover?
No. ISO 19650-3 identifies transfer from AIM to PIM at the start of the delivery phase and from PIM to AIM at the start of the operational phase, and notes explicitly that information can be transferred between them during the delivery phase as well. Waiting until handover to move anything is a project choice rather than a standard requirement.
How can an AIM be an input to a project?
When an owner starts a project on an existing asset, relevant information transfers from the AIM into the PIM. The delivery team begins with accurate documentation of existing conditions rather than commissioning a survey. This matters most for concealed services, which a survey of a completed building cannot capture at all — that information exists only if it was recorded before the ceiling closed.
What information should an AIM contain?
ISO 19650-3 gives examples spanning four categories: managerial, such as maintenance schedules and asset hierarchies; technical, such as equipment performance limits and capacities; legal, such as vendor data, warranties and compliance certificates; and commercial, such as operating costs, downtime impact and KPIs. An AIM scoped only around geometry satisfies the maintenance team and nobody else.
What are Asset Information Requirements?
The AIR states what information the owner needs to operate and maintain the asset. It is the source of what the AIM must contain and flows into the project’s Exchange Information Requirements. The critical and frequently neglected step is defining it from real information needs rather than from a template, since a copied AIR asks for information this owner will not use and omits what they will need.
How does the AIM relate to ISO 55000?
The ISO 55000 series defines a management system for managing assets across their lives, and asset information is a critical enabler within it — ISO 55001 clause 7.5 requires an organisation to specify, implement and maintain processes for asset information. That makes the AIM the built-asset expression of an asset management obligation that exists independently of BIM, which is a stronger argument to a portfolio owner than framing it as a BIM deliverable.
How is an AIM maintained?
Through trigger events rather than on a calendar. Typical triggers include equipment replacement or major repair, fit-out or change of use, statutory inspection or recertification, change of tenant or operator, performance review, and any project on the asset. The mindset that makes it work is treating the AIM as an asset in its own right with a named owner and a maintenance regime.
What formats should an AIM use?
Whatever the owner’s systems can actually consume — commonly IFC for the model as an open durable format, COBie or an equivalent structured exchange for asset data, and sometimes the operator’s own import format instead. The requirement is that formats are agreed in advance in the Exchange Information Requirements, because discovering at handover that the CAFM system cannot ingest what was delivered is entirely preventable.
Conclusion
The Asset Information Model is widely described as what a project model becomes. It is more useful to describe it as what an owner needs, which the project happens to be one source of.
Three things follow from reading ISO 19650-3 rather than summaries of it. The PIM contributes to the AIM rather than becoming it, so the AIM has to be defined from the owner’s requirements rather than assembled from whatever the project produced. Information flows both ways, so an owner with a maintained AIM starts every subsequent project ahead. And the AIM is maintained against trigger events, because a model created once and never updated is trusted long after it stopped being true.
Let’s build the model the operations team will actually use.
AMC Engineer delivers federated LOD 300–500 BIM modelling, clash detection and construction documentation for contractors, consultants and asset owners across Saudi Arabia and the UAE — classified, tagged and structured for the decades after handover.
