Understand PIM and AIM in BIM: ISO 19650 information requirements, handover, Asset Register, persistent identity, COBie, systems of record, trigger events and transition to operations.
Check it out!
PIM and AIM are two information models with different purposes throughout an asset’s lifecycle. The Project Information Model (PIM) supports the delivery phase—design, coordination, procurement, construction, testing, and handover—while the Asset Information Model (AIM) supports asset management and operations. The difference is not the use of different software or a different file format, but a change in purpose, users, supported decisions, requirements, and information governance.
This distinction matters because a project may complete construction with thousands of documents, models, and records and still begin operations without usable information. Projects generate large volumes of knowledge, but operations only needs part of that content and, at the same time, needs information that often emerges after design: actual installed manufacturer, serial number, warranty, in-service date, test results, final configuration, maintenance plan, criticality, supplier documents, and links to operational systems.
Handover, therefore, should not be treated as a transfer of folders or a complete copy of the PIM into an operations repository. It is a controlled information transition, in which data are selected, reconciled with the installed condition, validated against asset requirements, connected to persistent identifiers, and routed to the systems that will maintain them. What has no operational value may remain as a project record; what does have value needs to reach operations with demonstrable quality.
This process connects the requirements and processes defined by ISO 19650. It also connects OIR/AIR/PIR/EIR, LOIN, CDE, COBie, commissioning, as-built, BIM 7D, Facility Management, CMMS/EAM, asset management, and Digital Twin. The earlier the owner or operator defines the decisions that will depend on information, the lower the cost of rebuilding registers after handover and the greater the chance that the AIM begins its life as a reliable source of asset context.
PIM and AIM are information models, not BIM files
The first necessary distinction is between information model and a geometric model. An information model can combine multiple information containers: discipline and federated models, drawings, documents, structured databases, records, specifications, reports, asset lists, test evidence, photographs, certificates, and other information sets related to a purpose.
What characterizes the PIM
The PIM is delivery-phase oriented. Its content is produced and organized to develop, coordinate, verify, procure, construct, and deliver the project. It may contain information that will never have operational use but was necessary for a design decision or to demonstrate compliance during execution.
| PIM element | Typical use during delivery | Must it necessarily go to the AIM? |
| discipline models | authoring and technical development | not in full |
| federated model | coordination and interface analysis | only if it has a defined operational use |
| drawings and specifications | procurement and execution | only versions relevant to the delivered asset |
| clash/BCF reports | coordination and issue resolution | usually as records, not active operational data |
| quantities and studies | estimating and design decision-making | only when there is later use |
| supplier submittals | technical validation | yes, when linked to maintained assets |
| change records | traceability | yes, when they explain the final configuration |
| as-built | delivered condition | usually a critical source for the AIM |
The PIM changes intensively. Alternatives are created and discarded, models are revised, specifications are replaced, and decisions evolve. This volatility is normal for the delivery phase but should not be transferred indiscriminately into operations.
What characterizes the AIM
The AIM is asset-management oriented. Its content needs to answer operational questions: what exists, where it is, what its function is, how it was configured, which documents apply, who is responsible, when it needs maintenance, what changes have occurred, and which risks or requirements are associated.
| AIM dimension | Examples of information |
| identity | asset tag, asset code, GUID, corporate identifier |
| location | site, building, floor, room, coordinate, or zone |
| classification | system, discipline, asset class, criticality |
| configuration | type, manufacturer, model, capacity, parameters, and setpoints |
| lifecycle | manufacturing, installation, commissioning, warranty, replacement |
| documentation | manuals, certificates, drawings, reports, datasheets |
| maintenance | frequencies, tasks, strategy, resources, and history |
| condition and performance | inspections, failures, measurements, and indicators |
| relationships | system membership, upstream/downstream, served spaces |
| governance | data owner, system of record, status, version, and last validation |
ISO 19650-3 structures information management during the operational phase. This reinforces that the AIM is not a one-time deliverable: it is an information capability that must continue to be updated as the asset undergoes maintenance, replacements, expansions, changes of use, and new projects.
PIM and AIM can coexist
The transition is not necessarily a single moment. During execution, the PIM may continue evolving while portions of asset information are already being prepared, validated, or incorporated into the operational environment. In expansions of an existing asset, an existing AIM may also provide input information for a new PIM; at the end of that new project, validated information returns to update the AIM.
This creates a cycle, not a simple one-way arrow:
existing AIM → requirements and starting information → new PIM → execution and commissioning → validated information → AIM update.
As-built is not the AIM
As-built describes the executed condition at a given documentation level. AIM is broader. It can use as-built as a source, but it also needs non-geometric information, governance rules, operational records, and connections to systems that will continue changing throughout the asset’s life.
Confusing as-built with AIM creates a recurring problem: a geometrically updated model is delivered, yet serial numbers, warranties, document links, maintenance plans, and corporate identifiers are still missing.
As-built is not AIM. The executed condition is an essential source, but the asset information model needs to add identity, documentation, relationships, governance, and information required for operations.
Information requirements determine what belongs in the PIM and AIM
PIM and AIM should not be assembled by accumulation. The correct logic begins with the decisions that need support and derives information requirements from them.
OIR connects information to organizational objectives
The Organizational Information Requirements (OIR) describe information needs associated with the organization’s objectives and functions. A company may need to know unavailability risk, installed capacity, lifecycle cost, energy consumption, warranty status, space occupancy, or regulatory exposure. These objectives help determine which asset information needs to exist and be reliable.
AIR defines what asset management needs to know
The Asset Information Requirements (AIR) turn organizational needs into asset-related requirements. They are decisive for the AIM because they specify which data, documents, and relationships will be required during operations.
A useful AIR does not ask for “all available data.” It relates information to decisions and processes.
| Operational decision | Information required | Possible consuming system |
| schedule preventive maintenance | asset, class, criticality, task, frequency | CMMS/EAM |
| manage warranty | manufacturer, model, serial, start/end, conditions | CMMS/ERP/document system |
| locate equipment | identifier, space, system, and position | AIM/CAFM/IWMS/BIM |
| assess replacement | age, failures, maintenance, performance, and cost | EAM/BI/asset management |
| investigate failure | configuration, history, documents, and relationships | CMMS/AIM/CDE |
| plan renovation | current condition, space, interfaces, and documentation | AIM/PIM/CDE |
| audit compliance | certificates, inspections, dates, and evidence | DMS/CDE/CMMS |
This approach reduces two opposite losses: excess information with no use and absence of required data when operations need it.
The AIM should be derived from operational decisions, not from everything the project can produce. OIR and AIR help turn real needs into verifiable information requirements.
PIR organizes project needs
The Project Information Requirements (PIR) establish what the organization needs to know to make decisions on a specific project. They may generate information that belongs only to the delivery phase—solution alternatives, temporary studies, constructability analyses—and information that needs to survive the project because it will be used during operations.
EIR turns need into an exchange obligation
The Exchange Information Requirements (EIR) specify information to be exchanged at appointments and milestones. They connect requirements to the teams responsible for production and need to state content, format, timing, acceptance criteria, and responsibilities.
A handover requirement that only says “deliver BIM as-built” is insufficient. The team needs to know which assets must have registers, which properties are mandatory, how documents will be linked, which identifiers must be preserved, which format will be accepted, and how operations will verify the result.
LOIN prevents excessive modeling and insufficient data
The level of information need should be defined according to purpose. Critical assets may require much more complete properties, documentation, and relationships than components with no need for individual maintenance. Applying the same information level to all objects increases cost without necessarily increasing AIM value.
A requirements matrix can combine asset class × milestone × use × geometric information × alphanumeric information × documentation. This structure allows progressive planning of what must be produced and when each field becomes required.
The PIM → AIM transition needs to be treated as an engineering process
Handover is the point at which information quality begins to directly affect maintenance and operations. Therefore, the transition should have readiness criteria, evidence, and acceptance just like other technical deliverables.
Not everything in the PIM should survive
Temporary content may have historical or contractual value without becoming part of the operational AIM. Rejected studies, intermediate versions, simulations with no future use, auxiliary objects, and resolved coordination records may remain in the project archive without occupying the active asset-information layer.
The decision should answer three questions:
- does this information support any operational decision, obligation, or process?
- does it need to remain accessible as a record, but not as active operational data?
- is there another authoritative source better suited to maintain it?
Not everything in the AIM originates in design
Many of the most important maintenance attributes can only be known after procurement and installation. A design may specify a “30 m³/h centrifugal pump,” while the AIM needs to know which unit was actually purchased and installed, its manufacturer, model, serial, start-up date, warranty, associated motor, final configuration, and specific documentation.
This means procurement, suppliers, execution, and commissioning are producers of AIM information. If the contract only requires data at closeout, the organization loses the opportunity to progressively validate quality and ends up rebuilding registers at a moment of intense delivery pressure.
The Asset Register should be defined before large-scale data collection
Before requiring dozens of properties, it is necessary to decide what constitutes an individually controlled asset. Not every BIM object needs an asset tag or needs to exist as an item in the CMMS.
Common criteria include individual maintenance, criticality, warranty, replacement, legal obligation, inspection needs, material value, operational risk, or the need for its own history.
| Element | Treat as an individual asset? | Typical rationale |
| UPS | yes | criticality, maintenance, warranty, and history |
| IP camera | often yes | serial, maintenance, firmware, and location |
| standard luminaire | depends on the strategy | may be maintained by batch/area |
| critical isolation valve | often yes | isolation and maintenance |
| bolt or fitting | usually no | absence of an individual operational process |
| fire detector | depends on the system and requirements | inspection and identification may require unit-level control |
This decision precedes COBie, CMMS, or any register format. Otherwise, the organization digitizes an asset taxonomy that was never defined.
Persistent identity is the backbone of the transition
The same piece of equipment may appear in a BIM model, procurement spreadsheet, commissioning report, CMMS, ERP, and BMS. If each system uses a different identifier without governed mapping, information fragments.
The identification strategy needs to define primary identifiers, aliases, and change rules. An IFC GUID or internal software identifier may be useful, but should not be assumed to be the only corporate key. What matters is that the organization can unambiguously reconcile records across systems.
Without persistent identity, there is no information continuity. BIM, procurement, commissioning, CMMS, and ERP need to recognize the same asset even when they use different systems and technical identifiers.
Reconcile design, procurement, and installed condition
The transition should address discrepancies among specified, procured, installed, tested, and accepted states. The chain can be represented as follows:
| State | Control question |
| designed | what was technically specified? |
| approved | which supplier/product was accepted? |
| procured | which item was actually purchased? |
| installed | which unit is physically on site? |
| configured | which parameters and adjustments were applied? |
| tested | which results demonstrate performance? |
| accepted | which open items or reservations remain? |
| operational | which system will maintain the record? |
A reliable AIM needs to reflect the accepted state, not merely the state anticipated in design.
Commissioning completes information that the model cannot produce on its own
Functional and integrated tests may generate setpoints, curves, results, evidence, configurations, certificates, punch lists, and acceptance conditions. When these elements are needed for maintenance or operations, they need to be associated with the corresponding assets and systems.
Commissioning, therefore, is not merely a physical stage before handover; it is a source of operational information.
COBie can structure part of the transfer
COBie can organize data on facilities, spaces, types, components, systems, documents, warranties, and other handover information. It is useful when the contract and target systems adopt that structure, but it should not be confused with the complete AIM.
The AIM is broader and can be realized through different combinations of systems and information containers. COBie is a structured exchange mechanism and may be one of the inputs used to build or update this environment.
Operations needs to perform information acceptance
AIM validation cannot be limited to checking whether a file opens or fields are filled. It is necessary to test whether the information supports the real process.
An acceptance test set may verify asset location, codes, relationships, documents, warranties, CMMS import, association of maintenance plans, user access, system queries, change traceability, and ability to retrieve evidence.
The most important indicator is simple: can the operations team work with the data without manually rebuilding them?
AIM is a governed architecture, not necessarily a single system
In practice, asset information is distributed. ISO 19650-3 allows the AIM to be realized through a combination of new and existing systems that are properly connected and governed. This is more realistic than imagining a single software platform containing the entire operational truth.
Define systems of record by information domain
The concept of system of record helps determine which platform is authoritative for each data class.
| Domain | Possible authoritative source | Consuming systems |
| technical asset register | EAM/CMMS or asset master data | BIM, BI, mobile, ERP |
| controlled documents | CDE/DMS | CMMS, BIM, technical portal |
| geometry and spatial location | AIM/BIM/GIS | maintenance, engineering, emergency |
| work orders and maintenance history | CMMS/EAM | BI, asset management |
| cost and financial register | ERP | EAM, BI |
| telemetry | BMS/SCADA/historian/IoT | Digital Twin, BI, maintenance |
| occupancy and spaces | CAFM/IWMS | FM, BIM, BI |
| automation configuration | control system + documentation | maintenance, engineering |
No architecture is universal. What matters is declaring who maintains each data item and how other systems consume it.
The AIM does not need to live in a single software platform. The requirement is governance: each information domain needs an authoritative source, owner, and integration rule with the other systems.
AIM is not synonymous with CDE
The CDE may control documents, models, and information states, but many operational data have specialist systems. Work orders, failure histories, telemetry, or asset movements may not belong in the CDE as the primary source.
The CDE remains important as a governance and access mechanism for information containers, but the architecture needs to recognize that operations is heterogeneous.
AIM is not synonymous with CMMS or EAM
CMMS/EAM executes maintenance and asset-management processes: plans, orders, history, resources, costs, failures, backlog, and indicators. It may store a significant portion of AIM data but usually does not replace models, drawings, complex documents, spatial records, or other specialist systems.
The best integration avoids unnecessary data duplication. Instead of copying manuals into several systems, for example, the CMMS may maintain a controlled link to the official document in the corporate repository.
AIM is not synonymous with BIM 7D
“BIM 7D” is a market term for uses related to operations, maintenance, and Facility Management. AIM is a formal information-management concept defined within ISO 19650. A project may use BIM 7D as commercial or functional language while structuring the AIM with consistent requirements and governance.
AIM is not a Digital Twin
A Digital Twin typically adds synchronization with the real state, telemetry, events, analytics, or behavior models to support specific use cases. An AIM can exist without a Digital Twin and remains essential because it provides the identity, context, documentation, and relationships needed to connect real-time data to a known asset.
A twin built without a reliable asset register merely associates measurements with poorly governed entities.
Facility Management and asset management use the AIM differently
Facility Management may use information on spaces, services, occupancy, contracts, and built-environment performance. Asset management may focus on value, risk, performance, and lifecycle. Maintenance may focus on tasks, failures, and availability. The same AIM can support these processes provided the requirements have been structured for them.
Quality, change, and governance keep the AIM reliable after handover
An AIM may be correct on the day of handover and become obsolete within a few months if the organization has no update process. The operational phase is dynamic: equipment fails, is replaced, parameters change, spaces are renovated, and new projects alter the asset configuration.
Trigger events should initiate information processes
Operational management needs to define events that require review or updating of information containers. Examples include equipment replacement, critical-setpoint modification, renovation, occupancy change, maintenance that changes configuration, regulatory updates, incidents, expansion, or a new project.
| Trigger event | Possible updates |
| equipment replacement | tag, serial, manufacturer, model, warranty, documents, model |
| space renovation | geometry, space, assets, documentation, and classification |
| automation change | logic, setpoints, narrative, screens, and documentation |
| material maintenance | condition, configuration, evidence, and history |
| new project | creation of a PIM and later reconciliation with the existing AIM |
| decommissioning | status, location, history, and decommissioning documentation |
The event needs an owner and a closure criterion. Without this, the physical asset changes while the digital information remains frozen.
The AIM needs to be maintained, not just delivered. Replacements, renovations, configuration changes, and new projects should trigger controlled information updates to avoid divergence between the digital record and the physical asset.
Engineering Change Management · ISO 55000 and Asset Management
Change management connects ECM, as-built, and AIM
Technical changes need to leave a trail: origin, analysis, approval, implementation, testing, and document updates. Engineering Change Management is an important discipline in this continuity because it reduces the risk of the actual configuration silently diverging from records.
In critical environments, a change may require coordinated updates to the model, diagrams, asset list, parameters, procedures, CMMS, and operations documents.
Information quality needs explicit dimensions
“Complete” does not mean “correct.” AIM quality should assess different dimensions.
| Dimension | Example check |
| completeness | do all critical assets have mandatory fields? |
| validity | do values follow permitted format, unit, and domain? |
| uniqueness | are there duplicate tags? |
| referential integrity | do documents and systems point to valid records? |
| consistency | are manufacturer/model the same across related databases? |
| accuracy | does the record correspond to the installed equipment? |
| currency | was the latest asset change reflected? |
| traceability | can the source and approval of the data be identified? |
| usability | can the target system consume the information? |
Automation can verify part of this quality, but technical inspection and field reconciliation remain necessary for attributes that depend on the installed reality.
Security and access need to be proportional to risk
An AIM may contain sensitive information: topologies, critical systems, access, equipment locations, configurations, or operational data. The organization needs to classify information and define privileges, sharing, and audit controls compatible with risk.
Not all users need access to all information containers. Proper governance separates operational availability from unnecessary exposure.
Metrics help measure AIM readiness and maintenance
Indicators can reveal whether the information model remains reliable: percentage of assets with accepted records, rate of linked documents, discrepancies between CMMS and field, update backlog, time to incorporate a change, duplicate-tag rate, integration failures, and percentage of work orders opened against assets without valid documentation.
The metric should not incentivize data quantity. The objective is to measure the ability to find and use reliable information in the correct process.
Recommended process for structuring PIM, transition, and AIM
- Define organizational objectives and operational use cases. Identify decisions that will depend on asset information.
- Structure OIR and AIR. Translate objectives into operational information requirements.
- Define PIR and EIR for each project. Specify information required during delivery and exchanges.
- Define the Asset Register. Establish classes and criteria for individually controlled assets.
- Define identifiers and taxonomies. Create persistent keys across BIM, procurement, and operations.
- Map systems of record. Determine which platform will be authoritative for each data domain.
- Plan the PIM and information deliveries. Integrate BEP, TIDP, MIDP, CDE, and quality criteria.
- Define LOIN and attributes by milestone. Avoid requiring information before it exists or detail with no use.
- Capture information progressively. Incorporate design, supplier, procurement, and execution data as they mature.
- Control changes and substitutions. Maintain relationships among designed, approved, procured, and installed states.
- Incorporate commissioning. Associate tests, configurations, certificates, and evidence with the correct assets.
- Reconcile with the as-built condition. Verify identification, location, relationships, and documentation against the delivered asset.
- Validate quality and integrity. Run automated checks and technical/operational review.
- Test target systems. Import data, reconcile counts, links, and exceptions before acceptance.
- Formalize handover and governance transfer. Record the accepted baseline, open items, and operational responsibilities.
- Maintain the AIM through trigger events and change control. Update information whenever the physical asset or its requirements change.
The expected result is not a heavier “final BIM model.” It is information continuity: knowledge produced during design and implementation reaches operations in the required form, in governed systems, with persistent identity, verifiable quality, and an update process. The AIM only creates value when it continues to represent the asset the organization actually owns and operates.
Technical references
[1] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 19650-1:2018 — Organization and digitization of information about buildings and civil engineering works, including BIM — Information management using BIM — Part 1: Concepts and principles. Geneva: ISO, 2018. Available at: ISO.
[2] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 19650-2:2018 — Information management using BIM — Part 2: Delivery phase of the assets. Geneva: ISO, 2018. Available at: ISO.
[3] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 19650-3:2020 — Information management using BIM — Part 3: Operational phase of the assets. Geneva: ISO, 2020. Available at: ISO.
[4] UK BIM FRAMEWORK. Guidance and resources for information management using the ISO 19650 series. Available at: UK BIM Framework.
[5] NATIONAL INSTITUTE OF BUILDING SCIENCES. Construction to Operations Building Information Exchange — COBie V3. Available at: NIBS.
Frequently asked questions
PIM is the Project Information Model, the information model used primarily during the delivery phase to develop, coordinate, verify, construct, and deliver the project.
AIM is the Asset Information Model, the information model that supports asset management and operations throughout the operational phase.
No. They are information models and may bring together geometric models, documents, structured data, records, and other information containers.
No. The transition should select information with operational value, preserve what needs to remain as a record, and avoid carrying temporary content with no use.
No. Information such as serial number, warranty, installation, tests, configuration, and maintenance may emerge during procurement, execution, commissioning, and operations.
No. As-built records the executed condition at a given level. AIM is broader and includes data, documents, relationships, governance, and operational information.
No. COBie is an exchange structure that can carry part of the data needed to build or update an AIM.
No. CMMS executes maintenance processes and may be the system of record for part of the asset information, but the AIM may involve multiple systems and containers.
Not exactly. BIM 7D is a market term for BIM uses in operations; AIM is an asset-related information-management concept in the ISO 19650 series.
By defining systems of record, trigger events, responsibilities, change management, persistent identifiers, integrations, and validation criteria after asset changes.
Additional technical resources
Information requirements and management
- BIM Information Management: ISO 19650
- BIM Information Requirements: OIR, AIR, PIR, and EIR
- BIM BEP
- MIDP and TIDP in BIM
- LOIN in BIM
- BIM CDE
- BIM IDS
- BIM Management and Engineering Information
Handover, operations, and asset management
- COBie in BIM
- BIM 7D
- Facility Management
- CMMS
- ISO 55000 and Asset Management
- Engineering Asset Management
- Maintenance Engineering
Architecture, interoperability, and integration
- IFC File in BIM
- Open BIM
- bSDD in BIM
- Digital Twin
- Systems Integration, APIs, and Connectors
- Common Data Environment and BIM Information Management
- Document Governance
