PIM to AIM

The distinction is really about *purpose*. The PIM exists to deliver the project — it carries design intent, analysis, coordination, options explored and abandoned, construction detail. It is large, detailed, and oriented toward *creating* the building. Much of it is irrelevant the day the building opens.

The AIM exists to operate the asset — it carries only the information an owner and facility manager need to run, maintain and modify the building: the spaces, systems and components, with their identity, location, warranties, and maintenance requirements, verified as built. It is leaner, focused, and oriented toward *keeping the building working*. The handover is the act of producing the AIM *from* the PIM: selecting the operationally relevant information, verifying it against the real constructed building, and structuring it so the owner's systems can use it. This is exactly where COBie (Module 4) does its work — as the structured vehicle carrying the asset data across — and where the progressive filling of that data through the project finally pays off.

Two things must happen in the PIM-to-AIM transition, and skipping either wastes it. The first is distillation: the AIM is not the whole PIM dumped on the operator — it is the *relevant* information, selected. Handing over everything is as useless as handing over nothing, because the operator drowns. The second is verification: the AIM must reflect the building *as actually built*, not as designed, because construction always deviates from the model in ways that matter to whoever maintains it. An AIM that still describes the design intent, not the installed reality, will mislead the facility manager for decades.

Done well, this is the moment the whole information discipline of the course delivers its return. Because the data was required in the EIR, produced through the CDE, named and traced as containers, and verified along the way, the AIM can be assembled as a trustworthy, structured record rather than reconstructed in panic at the end. Done badly — as a last-minute scramble to compile data nobody captured — the handover produces an AIM the operator cannot trust, and the building's fifty-year information asset is stillborn. The quality of the AIM is the verdict on everything upstream.

The handover is not the end of the AIM's life — it is the start of it. A building changes: components are replaced, systems altered, spaces refitted. An AIM that is captured at handover and then left to rot becomes steadily wrong, until it is as untrustworthy as no information at all. So the AIM must be maintained through operation, updated as the building changes, kept as a living record. This is Part 3 of ISO 19650 — the operational phase — and it is the difference between an asset information model and an expensive snapshot.

And here the whole course quietly comes full circle. A well-maintained AIM does not just serve today's operation; it becomes the reliable *starting information* for the building's next project — the refit, the extension, the major maintenance. The owner who wants that work done issues an EIR (lesson 5.3) — and the best possible input to it is a trustworthy AIM from the last cycle. The loop closes: require, produce, manage, hand over, operate, and require again, each turn standing on the verified information of the last. That closed loop, across a building's whole life, is the largest thing BIM is for — and it is why managing the information well, which this module has been about, is not overhead but the entire point.