{"id":81691,"date":"2026-09-19T14:42:10","date_gmt":"2026-09-19T17:42:10","guid":{"rendered":"https:\/\/a3aengenharia.com\/?post_type=articles&p=81691"},"modified":"2026-09-19T14:42:36","modified_gmt":"2026-09-19T17:42:36","slug":"pim-aim-bim-project-information-model-asset-information-model-transition-operations","status":"publish","type":"articles","link":"https:\/\/a3aengenharia.com\/en-us\/content\/technical-articles\/pim-aim-bim-project-information-model-asset-information-model-transition-operations\/","title":{"rendered":"PIM and AIM in BIM: Project Information Model, Asset Information Model and the Transition to Operations"},"content":{"rendered":"\n

PIM and AIM are two information models with different purposes throughout an asset’s lifecycle. The Project Information Model (PIM)<\/strong> supports the delivery phase\u2014design, coordination, procurement, construction, testing, and handover\u2014while the Asset Information Model (AIM)<\/strong> 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.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

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<\/strong>, 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.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

PIM and AIM are information models, not BIM files<\/h2>\n\n\n\n

The first necessary distinction is between information model<\/strong> and a geometric model. An information model can combine multiple information containers<\/em>: 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.<\/p>\n\n\n\n

What characterizes the PIM<\/h3>\n\n\n\n

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.<\/p>\n\n\n\n

PIM element<\/td>Typical use during delivery<\/td>Must it necessarily go to the AIM?<\/td><\/tr>
discipline models<\/td>authoring and technical development<\/td>not in full<\/td><\/tr>
federated model<\/td>coordination and interface analysis<\/td>only if it has a defined operational use<\/td><\/tr>
drawings and specifications<\/td>procurement and execution<\/td>only versions relevant to the delivered asset<\/td><\/tr>
clash\/BCF reports<\/td>coordination and issue resolution<\/td>usually as records, not active operational data<\/td><\/tr>
quantities and studies<\/td>estimating and design decision-making<\/td>only when there is later use<\/td><\/tr>
supplier submittals<\/td>technical validation<\/td>yes, when linked to maintained assets<\/td><\/tr>
change records<\/td>traceability<\/td>yes, when they explain the final configuration<\/td><\/tr>
as-built<\/td>delivered condition<\/td>usually a critical source for the AIM<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

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.<\/p>\n\n\n\n

What characterizes the AIM<\/h3>\n\n\n\n

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<\/strong>.<\/p>\n\n\n\n

AIM dimension<\/td>Examples of information<\/td><\/tr>
identity<\/td>asset tag, asset code, GUID, corporate identifier<\/td><\/tr>
location<\/td>site, building, floor, room, coordinate, or zone<\/td><\/tr>
classification<\/td>system, discipline, asset class, criticality<\/td><\/tr>
configuration<\/td>type, manufacturer, model, capacity, parameters, and setpoints<\/td><\/tr>
lifecycle<\/td>manufacturing, installation, commissioning, warranty, replacement<\/td><\/tr>
documentation<\/td>manuals, certificates, drawings, reports, datasheets<\/td><\/tr>
maintenance<\/td>frequencies, tasks, strategy, resources, and history<\/td><\/tr>
condition and performance<\/td>inspections, failures, measurements, and indicators<\/td><\/tr>
relationships<\/td>system membership, upstream\/downstream, served spaces<\/td><\/tr>
governance<\/td>data owner, system of record, status, version, and last validation<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

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.<\/p>\n\n\n\n

PIM and AIM can coexist<\/h3>\n\n\n\n

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.<\/p>\n\n\n\n

This creates a cycle, not a simple one-way arrow:<\/p>\n\n\n\n

existing AIM \u2192 requirements and starting information \u2192 new PIM \u2192 execution and commissioning \u2192 validated information \u2192 AIM update.<\/strong><\/p>\n\n\n\n

As-built is not the AIM<\/h3>\n\n\n\n

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.<\/p>\n\n\n\n

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.<\/p>\n\n

\n

As-built is not AIM.<\/strong> The executed condition is an essential source, but the asset information model needs to add identity, documentation, relationships, governance, and information required for operations.<\/p>\n\n\n

As-Built in Engineering<\/a> \u00b7 BIM 7D<\/a><\/p>\n<\/div>\n\n\n\n\n

Information requirements determine what belongs in the PIM and AIM<\/h2>\n\n\n\n

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.<\/p>\n\n\n\n

OIR connects information to organizational objectives<\/h3>\n\n\n\n

The Organizational Information Requirements (OIR)<\/strong> 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.<\/p>\n\n\n\n

AIR defines what asset management needs to know<\/h3>\n\n\n\n

The Asset Information Requirements (AIR)<\/strong> 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.<\/p>\n\n\n\n

A useful AIR does not ask for \u201call available data.\u201d It relates information to decisions and processes.<\/p>\n\n\n\n

Operational decision<\/td>Information required<\/td>Possible consuming system<\/td><\/tr>
schedule preventive maintenance<\/td>asset, class, criticality, task, frequency<\/td>CMMS\/EAM<\/td><\/tr>
manage warranty<\/td>manufacturer, model, serial, start\/end, conditions<\/td>CMMS\/ERP\/document system<\/td><\/tr>
locate equipment<\/td>identifier, space, system, and position<\/td>AIM\/CAFM\/IWMS\/BIM<\/td><\/tr>
assess replacement<\/td>age, failures, maintenance, performance, and cost<\/td>EAM\/BI\/asset management<\/td><\/tr>
investigate failure<\/td>configuration, history, documents, and relationships<\/td>CMMS\/AIM\/CDE<\/td><\/tr>
plan renovation<\/td>current condition, space, interfaces, and documentation<\/td>AIM\/PIM\/CDE<\/td><\/tr>
audit compliance<\/td>certificates, inspections, dates, and evidence<\/td>DMS\/CDE\/CMMS<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

This approach reduces two opposite losses: excess information with no use<\/strong> and absence of required data when operations need it<\/strong>.<\/p>\n\n

\n

The AIM should be derived from operational decisions, not from everything the project can produce.<\/strong> OIR and AIR help turn real needs into verifiable information requirements.<\/p>\n\n\n

OIR, AIR, PIR, and EIR<\/a> \u00b7 LOIN in BIM<\/a><\/p>\n<\/div>\n\n\n\n\n

PIR organizes project needs<\/h3>\n\n\n\n

The Project Information Requirements (PIR)<\/strong> 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\u2014solution alternatives, temporary studies, constructability analyses\u2014and information that needs to survive the project because it will be used during operations.<\/p>\n\n\n\n

EIR turns need into an exchange obligation<\/h3>\n\n\n\n

The Exchange Information Requirements (EIR)<\/strong> 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.<\/p>\n\n\n\n

A handover requirement that only says \u201cdeliver BIM as-built\u201d 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.<\/p>\n\n\n\n

LOIN prevents excessive modeling and insufficient data<\/h3>\n\n\n\n

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.<\/p>\n\n\n\n

A requirements matrix can combine asset class \u00d7 milestone \u00d7 use \u00d7 geometric information \u00d7 alphanumeric information \u00d7 documentation<\/strong>. This structure allows progressive planning of what must be produced and when each field becomes required.<\/p>\n\n\n\n

The PIM \u2192 AIM transition needs to be treated as an engineering process<\/h2>\n\n\n\n

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.<\/p>\n\n\n\n

Not everything in the PIM should survive<\/h3>\n\n\n\n

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.<\/p>\n\n\n\n

The decision should answer three questions:<\/p>\n\n\n\n