From PIM to AIM: the transition nobody owns

Six months after handover, two people from the FM team are walking a plant room with a torch and a clipboard, photographing nameplates. Somewhere on a server there is a beautifully coordinated model of that room. It knows the duct runs, the clearance zones, the position of every hanger. It does not know that the air-handling unit in front of them was a substitution agreed in week thirty-eight, or when the warranty on it runs out, or where the commissioning certificate ended up. So they are typing serial numbers into a spreadsheet, and that spreadsheet is going to become the asset register.

ISO 19650 names two information models. The project information model (PIM) is what delivery produces and uses: design, construction, coordination, commissioning, the decisions that get the works built. The asset information model (AIM) is what the operator is supposed to query: what is installed, where, how to maintain it, what residual risk remains, which warranty still runs. The industry talks as though one becomes the other at practical completion — a rename, a folder called Final, a spreadsheet at the end.

Converting one into the other is a job of work. It takes time, it costs money, and it requires somebody to decide what matters. On most projects nobody is appointed to do it, and operations end up inventing a third model instead.

Two models, not two folders

A PIM answers delivery questions. Can this duct pass the beam? Which revision was issued to the trade? Did the hold point pass? The actors are task teams, the information manager, the lead appointed party, the supervisor. The content is geometry that coordinates, programmes that sequence, requests for information, inspections filed by package, models at the level of information need for construction. Suitability is for sharing, for review, or for construction issue. The reader was on the job.

An AIM answers operational questions. Which unit is this? What was actually installed, rather than what was designed? Where is the certificate that accepted it? When does the warranty end? What residual hazard must a later maintainer manage? The actors are facilities, the asset owner, and a contractor who was nowhere near the coordination meeting. The content is unique identity, as-installed location, manufacturer and product, inspection interval, cause-and-effect, the document bound to the object. Suitability is for the register the operator will query. The reader was not on the job and never will be.

They share objects — the door, the damper, the air-handling unit. They do not share purpose, query or reader. A federation renamed "as-built" is still a PIM with a new label on it. Publishing the common data environment archive to the client is a delivery cupboard with the client's name on the door. A COBie sheet in a handover pack becomes an AIM only if the rows answer the operator's questions and somebody accepted them as the AIM.

UK practice already admits the split, quietly. National annex status codes distinguish authorisation of the project information model from authorisation of the asset information model. Two codes exist because there are two authorisations. A container suitable for construction issue is not, by that fact, suitable for the asset register. Treat the codes as a filing step — move the file, change the letter — and the transition gets performed on the label while the content stays exactly where it was.

The requirements chain says the same thing more formally. Organisational information requirements sit with the asset-owning organisation. Asset information requirements say what the AIM must contain. Project and exchange information requirements say what the PIM must produce so that the AIM can be populated. Write that chain as rows a task team can price, and the information exchange at handover has something definite to deliver against. Leave it as a heading in a tender document and the two models were never going to meet.

Who is paid for the cut

The standard is clear enough about roles. It is silent, in practice, about who pays for the conversion.

The appointing party is supposed to have set the asset information requirements before appointment, and to name who accepts the AIM — not who stores the pack, who accepts the model. The information manager coordinates the process. The lead appointed party delivers the PIM. Task teams produce containers against a named level of information need. Facilities, if they exist yet, are the AIM's reader. Soft landings, if anyone funded them, are a meeting structure rather than an authorship.

Watch how that dissolves on a mid-size job. The BIM manager treats the cut as work for the soft-landings or facilities consultant, to be started once the model is "done". Document control treats it as an operation-and-maintenance compilation in the last month. The contractor treats it as a schema dump at practical completion. The designer treats as-built as a redline of their own model. The FM team were invited to one workshop at an early stage and never given a row they could price. The owner believes they bought an AIM when they bought "BIM".

Nobody is paid for the cut itself. Delivery is paid to complete. Operations are paid to operate whatever they receive. The labour in the space between those two invoices belongs to nobody, and work that belongs to nobody gets performed as a rename.

That is the accountability vacuum, and it is not a failure of care. Every role can show you its own cupboard, neatly kept, and still nobody is responsible for the object operations will query. An appointing party closes it by writing asset information requirements a supply chain can price, and by naming a person — a role on the appointment, not a platform — who will accept or reject the AIM before the delivery team demobilises. Name one before practical completion. Where that acceptance is missing from the appointment, the vacuum is contractual rather than accidental, which at least means it can be fixed on the next one.

What gets dropped

What gets dropped is selected, rather than lost at random off a disk. Delivery keeps what it needed to build and to get paid, drops what it needed for neither, and operations inherit the remainder.

Identity. Asset tags, serial numbers, location codes the operator will search on. Inspections closed against a package, a gridline or a week. Models that know a type but not an instance. A register of names with no key.

As-installed fact. What was placed, substituted or left out. The PIM usually still holds the designed object; the AIM needs the installed one. Redlines on a phone, a substitution agreed by email, a "build as drawing" that was not built as drawing — none of these reach the model that will be queried.

The alphanumerical fields operations need. Warranty end date, inspection interval, filter type, duty as installed, cause-and-effect. Delivery's level of information need, where it was written at all, asked for geometry that coordinates. So the handsome family arrives and the fields the maintainer will need are blank.

Documents bound to the object. The certificate, the data sheet, the commissioning result. They exist as a binder, a mailbox, a folder called O and M. They do not exist as a pointer from the unit itself. A health and safety file that cannot find the residual risk on the object is a compilation rather than a thread.

Relationships. Which damper sits in which system. Which door sits in which compartment. Which circuit feeds which board. Delivery coordinated in space; operations query in systems. Where the relationship lived only in somebody's head, it demobilises with them.

Residual hazard and access. What later maintenance will need a platform for. What cannot be isolated. What remains because it could not be designed out. Construction Design and Management duties, and the golden thread on higher-risk buildings, assume that pointer already exists. Neither tells you how to manufacture it from a crate of unmarked sheets.

The wrong richness. Geometry nobody asked for is kept — every vane, every bolt group, a fabrication mesh that takes a minute to load. Data they did ask for is absent. It is the same inversion as a single "level of detail" applied across a whole model: plenty for the screenshot, not enough for anyone holding a spanner.

Status and people. Containers authorised for construction, never authorised for the AIM. The installer who knew which unit was which has gone to the next job. Photographs sit on phones. Serial numbers were written on a cardboard sleeve that went in a skip. You can copy a passed inspection; you cannot invent the identity it never carried.

Why operations inherit a vacuum

The vacuum is not an empty common data environment. The environment is full — folders, models, PDFs, a drawing register, a commissioning archive filed by system. Fullness is reassuring, which is precisely why the gap survives review after review. None of it answers an operator's query: show me this asset, the certificate that accepted it, the warranty still running, the residual I have to manage.

So operations invent a third model. A spreadsheet register typed from nameplates in a plant room. A maintenance system rebuilt from PDFs. A golden-thread file assembled after occupation, by people who were not there. A consultant paid to "structure the handover". That third model is the twelve-month wait everybody complains about, and it is why talk of lifecycle data being "lost at handover" never quite lands. The data was not lost from storage. It was never transferred into a model operations can query, because nobody owned the transfer.

Accountability follows whatever test was written. Delivery closed against completion — practical completion, a taking-over certificate, a folder named Handover. Operations opened against a building they could not find in the files. Nobody failed a test at the cut, because nobody wrote a pass or fail for the AIM. The appointing party received an archive and the operator received a vacuum, and both of those can be true of the same disk.

A compilation is not an information model. An information model is something a stranger to the job can query for a named purpose, months after everyone who built it has moved on. If the only person who can find the damper is the document controller who packed the crate, what you have is a PIM in a box.

A Monday ownership test

You do not need a consultant to find out whether the cut is owned.

Name the person — a role on the appointment, not a software product — who will accept the AIM. Not the pack. The model the operator will query. If the name is "document control at the end", the cut is unowned.
Produce the asset information requirements that said what "accepted" means. Purpose, objects, fields, documents, what is out of scope, a pass or fail a controller can actually run. If they read as slogans — "ISO 19650", "COBie", "as-built model" — the cut was never specified.
Pick five assets that will still need maintenance in two years. From the current PIM, produce the identity, the as-installed fact, the warranty or inspection interval, and the bound certificate the operator will need. Give it an hour and stop when the hour is up.
Ask who is paid to fill the blanks before practical completion. A shrug is the finding. "We will compile it later" is the vacuum, scheduled.
Ask what happens if those five fail. If nothing in the appointment lets anyone reject the PIM for failing to feed the AIM, there is no owner. There is only hope.

Five assets are enough. You are not completing the register; you are finding out whether anybody is responsible for the transition. It is worth doing while there is still a delivery team on site to answer.

Where the fix actually sits

It sits in the appointment, not in a better handover pack and not in a cleverer schema. Asset information requirements written early enough to be priced. An information exchange at handover with a named acceptor. A rejection route with some teeth in it while the delivery team is still mobilised. The federation, the COBie export, the health and safety file are all downstream of whether anybody was instructed to care about the operator's query.

Owners tend to work this out the second time round. The first building teaches them what they failed to ask for, and the second procurement is where they ask for it. That is an expensive way to learn, though it is at least a way. What never works is hoping a delivery team will hand over something nobody paid them to produce, and then paying somebody else, a year later, to rebuild it from nameplates.