As-built model vs. AIM: two different things

Last month, I wrote a couple of things aimed at my local market, specifically on the updated norms on BIM for an Exchange Information Requirements and what should be specified inside. In one of those, I mentioned a principle in passing: that the as-built model isn’t necessarily the same as an Asset Information Model meant to support maintenance. This has been a complicated issue on many projects I faced recently, and I’m sure it isn’t just a local problem, so I thought I could expand a bit upon this, and if you have any thoughts, I’m here to hear them.

The point I’ll try to make: an as-built model and an Asset Information Model (AIM) are conceptually, contractually, and operationally different things, and treating them as interchangeable is a category error that creates real problems in projects.

What’s an AIM?

It’s one of the least-known acronyms in BIM, I think, which says something in itself. The AIM is the Asset Information Model, and it’s presented in this scheme. The scheme is so obscure, I usually have to animate in order to explain it to my students.

The basic concept is simple: there’s a dude (the client) who has a document specifying the information they need in order to operate their business, and that document is the Organizational Information Requirements (OIR). From that master specification, two different scenarios arise:

1. they need to specify the production of an information model for an asset that’s already built;
2. they need to produce specifications for the process of building a new asset.

The first row of the scheme, illustrates situation number 1: the asset already exists and needs to be surveyed, modelled, rendered into an Asset Information Model (AIM). This calls for Asset Information Requirements. Aswesome.

Situation number 2 descends from the same starting point (the dude knowing what they want), but we’re undertaking a project, so the specifications need a bit of work as our focus won’t just be how to produce what the dude wants but also how to manage the process of producing it. This means we’ll need general information requirements focusing on the overall project (the Project Information Requirements) and then, for each, stage, specific Exchange Information Requirements that will eventually result in what they call Project Information Model (PIM).

I swear I never encountered anyone actually using most of these acronyms, but that’s the way it is.

Now, if you look at the scheme, there’s a little arrow between the Project Information Model and the Asset Information Model, saying one contributes to the other.

Note: what does “contribute” mean?

ISOs use verbs in a very specific way. The key verbs in this context are:

• inform;
• generate;
• specify;
• contribute.

I wrote a little about it here.

The ISO itself specifies:

In this figure, “encapsulates” means “provides the input to”, “contributes to” means “provides an input to”, “specifies” means “determines the content, structure and methodology”.

In short, when something contributes to something else, it means it might be the basis for it, or constitute some part of it, but it doesn’t generate it, and by no means is it the same thing.

The as-built model

When you’re in the construction stage, you’re following the project up to a point (hopefully a very close point) but shit’s bound to happen. This is why no sane client would just rely on a very detailed design model at handoff: you’ll always have to verify measurements, and fill in information on what was really installed. Then, depending on the level of integration required, you’ll have to make sure that all portions of the handoff documentation talk to each other. In Italy, we have a thing called Maintenance Plan, developed in the second stage of design and it should explain:

• how to use portions of the asset;
• the maintenance procedures;
• the programme of such maintenance.

Now, the construction company is bound to update this information through a thing we call Building Dossier. But is it bound to integrate every piece of information into the information model in a way that cross-references documents, objects and attributes, and how?

• The as-built model is the end-state of the project information process. Its primary model use is record keeping: documenting what was actually delivered at handover, with verified geometry and installed components. It is a snapshot of reality at a specific moment in the asset’s lifecycle.
• The Asset Information Model, instead, is an information model designed to support asset and/or facility management activities over time. It exists to answer specific operational questions derived from Organizational and Asset Information Requirements, not to archive everything that happened during construction.
• ISO 19650 is very precise in stating 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, but it does not magically become one.
• Whether information from the as-built model should appear in the AIM depends on:
  • the model uses the client actually wants to support;
  • the asset management or facility management processes involved;
  • the technological systems that will consume that information.
• The critical (and often neglected) step is the definition of Asset Information Requirements based on real information needs. This step determines:
  • what information is transferred as-is from the as-built PIM,
  • what must be restructured or reclassified,
  • what information must be newly created or enriched post-handover.

Why this confusion keeps happening

If the distinction between as-built model and Asset Information Model is so clearly stated in the norms, a reasonable question is: why does this confusion persist so stubbornly in practice?

Part of the answer is historical, I think. BIM entered many markets as a design and construction optimization tool, not as an information management framework spanning the whole lifecycle, and when facility management was already in place, the management team was more than happy to disregard the unsuitable stuff that arrived from the construction site and to build their information models from scratch. I’ve seen this many times. The as-built model became, de facto, the final BIM deliverable, because it was the last thing produced by a project team that couldn’t talk with asset management teams: those people came into the picture later or, when there’s no such team in place, it’s tempting to treat that final model as good enough for operations.

Another part of the answer is contractual. In many tenders, clients ask for “the BIM model for maintenance” without ever defining:

• which maintenance activities they actually intend to support;
• who will perform them;
• with which tools;
• and at what level of reliability.

The result is a shortcut: as-built becomes shorthand for everything we might ever need later. This is convenient during procurement, but disastrous downstream.

Finally, there is a cultural bias that BIM itself has helped reinforce: the idea that a single model is the container of all truth throughout the phases. If the information model is sold as a single source of truth, then surely the most complete model must be the best one. But completeness is not the same as usefulness, and information without context is just noise with a storage cost.

The practical risks of equating as-built and AIM

Treating the as-built model as if it were an AIM produces very concrete problems.

First, it blurs responsibility.
Who is responsible for transforming construction information into operational information? The contractor? The designer? The client? If this is not explicitly addressed, everyone will assume it’s someone else’s problem, and the Asset Information Model will quietly never materialize.

Second, it leads to overloaded models that support no one well.
Construction-oriented attributes, temporary classifications, supplier-specific data, and documentation references end up sitting next to operational parameters, without a clear logic or hierarchy. Facility managers are handed a model that looks impressive to the untrained eye, but answers none of their daily questions efficiently.

Third, it locks clients into inappropriate technological choices.
An Asset Information Model is a dataset meant to be consumed by specific systems: Computerized Maintenance Management System (CMMS), Computer-aided facility management systems (CAFM), Integrated Workplace Management System (IWMS), Enterprise Resource Planning (ERP). Each of these expects information to be structured, linked, and updated in specific ways. An as-built model exported “as is” rarely fits any of them without costly rework.

Finally, it undermines trust in BIM altogether.
When clients realise that their expensive “model for maintenance” is unusable, the conclusion is not “we defined the wrong requirements”, but “BIM doesn’t work for operations”. This is how good standards get a bad reputation.

Model Uses and Information Need

The fact that you’ll have to do regular maintenance on your building, and that the construction company is obliged to give you all information on how to do that, doesn’t necessarily mean that the information model should support that activity. That’s what we call model use, and it’s the basis of BIM. There’s no such thing as One Model To Rule Them All, and you don’t stuff the model of every single piece of information known to man just because maybe one day someone will be able to use it. Skipping any analysis and assuming “more data in the model is always better” is explicitly anti-BIM, if you pardon my saying.

The model use of an as-built model is usually record keeping: you need to store it somewhere and testify that’s the state of the asset when it was handed over to you.

Appendix A.4 of the ISO 19650-3: 2020, the part of the ISO series that’s specifically connected with the management stage of assets, gives some examples of the kind of information that can be required in an Asset Information Model through the Asset Information Requirements, and they span from managerial to technical (the first being high-level information on the maintenance schedule, for instance, and the second one being operational data on the performance limits of equipment), from legal to commercial (the first one being vendor data or KPIs, and the second one being operating costs or downtime impacts). As you’ll see from a brief look at that list, Asset Management means a lot of things.

So what’s the iter? The norms clarified that between the Project Information Model and the Asset Information Model what happens is a transfer of information.

To complicate things, the norm says:

Asset management and facility management have developed as two distinct management disciplines, despite both of them being concerned with managing the physical assets and services of an organization.
Asset management and facility management have developed their own standards and language of preferred terms.
This document recognizes that both asset management and facility management play their own part in the lifecycle of an asset, but for simplicity the main body of this document use the term asset management to cover both disciplines.

Regardless of how you call it, my take is:

1. Among the many things you need to do when you manage an asset, you need to focus what specific activity you want to be supported through an information model;
2. Once you focused it, you need to identify the technological solution you’ll employ: too many clients skip this part, and it’s super-important because different technological solutions might want information packaged in different ways;
3. Based on the above exploration, you need to draft the Asset Information Requirements with your Information Need: some pieces of information might be transferred from the Project Information Model in the as-built state, some others will have to be reorganised, some others will have to be developed and inserted.

Point 3 is a stage that can’t be overlooked.

From handover to transfer: designing the AIM on purpose

The ISO is very careful in avoiding the word handover when discussing the transition from project to asset management. What happens is a transfer of information, and transfers imply transformation, if you read what we wrote last week about Simondon and transduction.

Designing an AIM means accepting three uncomfortable but necessary ideas:

1. Not all project information deserves to survive. Some data is essential during design coordination or construction sequencing and becomes irrelevant the moment the building is operational. Keeping it “just in case” is not neutral; it has a maintenance cost.
2. Some operational information does not exist at handover. Performance thresholds, maintenance strategies, KPIs, risk classifications, and cost indicators are often defined or refined only once the asset starts being used. Expecting the construction team to magically provide them is unrealistic.
3. The AIM is an operational tool, not a historical archive. Its structure should reflect how the asset is managed today and how it is expected to be managed tomorrow, not how it was built yesterday.

This is why Asset Information Requirements are not a clerical appendix to the Exchange Information Requirements, but a design activity in their own right. They sit at the intersection of organisational strategy, asset management practice, and technology.

What do we do? Stop asking for models, start asking for support

If there is one takeaway I would push hard, it’s this: clients do not need “more BIM”; they need better answers to specific operational questions. The Asset Information Requirements exist to provide those answers, and it must be designed accordingly.

That means:

• deciding which asset management activities actually need digital support;
• choosing the systems that will support them;
• and only then defining what information is required, in what form, and from whom.

Skipping this step and hoping the as-built model will somehow fill the gap is dumb. The standards already give us the language to make this distinction clear: what’s missing, more often than not, is the willingness to slow down, think operationally, and accept that information models are tools, not trophies to be put on your digital shelf.