The pretty model problem: what BIM and IFC actually are — and where their unrealised value sits.

A BIM model is not a picture of a building. It is a database that happens to be viewable in three dimensions, and almost every misunderstanding about BIM starts with looking at the picture instead of the database.

The insurance market has been hearing the word for well over a decade, usually in a sentence promising it will change everything. It has changed a great deal, though not always the things people expected. What follows is the plain version: what these things are, what they are genuinely good for, and the one structural limit that matters most to anyone assessing risk.

BIM, without the acronym

Building Information Modelling is the practice of describing a building as a set of objects with properties and relationships, rather than as a set of lines on a drawing.

A wall in a BIM model is not two parallel lines. It is an object that knows it is a wall, knows which floor it sits on and which rooms it separates, can carry its material, fire rating and thermal performance, and knows which drawings it appears on. Change it once and every drawing that shows it changes too.

That is the whole idea. The value is not the three-dimensional view — that is a by-product. The value is that the information about a building lives in one structured place, rather than being redrawn by hand in thirty documents that then disagree with each other.

IFC, without the acronym

The obvious problem with a structured database is that everybody's is different. Architects work in one package, structural engineers in another, services engineers in a third, and the contractor in a fourth.

IFC — Industry Foundation Classes — is the open, vendor-neutral data standard for exchanging that information between them. It is an international standard, ISO 16739-1, maintained by buildingSMART rather than by any software vendor.

That last part is why it matters. A project that hands over its model in a proprietary format has handed over something readable for as long as somebody keeps paying for that software. A project that hands over IFC has handed over something readable in twenty years. For a structure with a fifty-year design life, that distinction is not academic.

What the models are genuinely good for

Quite a lot, and it is worth being specific rather than dismissive.

Clash detection is the obvious one: finding the places where the ductwork runs through the beam before either has been ordered. Quantities come out of the model, which makes the amount of concrete in the building closer to a query than an estimate. Sequencing works because objects can be tied to programme activities. And handover changes character — the facilities team inherits a structured description of the asset rather than a room full of drawings.

These are real gains and they are not controversial. The industry adopted BIM because it works.

The limit that matters

Here is the part that gets lost.

A model records intent. It does not record fact.

Every object in a BIM model describes something that is meant to exist, in a state it is meant to be in, at a position it is meant to occupy. That is true on the day it is issued for construction and it remains true every day afterwards. The model is a statement about the future, written in a format so precise that it reads like a statement about the present.

The divergence starts immediately. Sequences change because a delivery is late. Temporary works go up that are in no model at all. Site logistics move. A detail gets resolved differently on the third floor than it was drawn. Substitutions happen. Some of this flows back into the model, eventually, in a revision. A great deal of it does not, because nobody's job is to model what actually happened and the project has moved on.

So there are two buildings by the end. The one in the model and the one on the site. They are close, usually. They are never the same, and only one of them is the asset anybody is carrying risk on.

"That's what as-built models are for"

This is the fair objection, and it deserves a straight answer rather than a dodge.

Two different things are being described, though.

A digital twin maintained through the build is the right instinct, and on projects that run one it is genuinely updated as work proceeds. But a twin is only ever as current as the observation feeding it, and what feeds it is capture from the site. The twin is the structure; the capture is what makes it true.

An as-built model is a different animal. It is produced at or near handover, which is to say at the end. It is a corrected statement of the finished thing, and it is silent on the three years in between — the sequence, the conditions, the temporary states, the fortnight the third floor stood open to the weather. Those are the years in which almost everything that concerns a risk engineer actually happens.

An as-built model also inherits the same character as the model it replaces: it is a description, compiled by someone, after the fact. It tells you the conclusion. It does not tell you what the site looked like on any particular Tuesday, and it cannot be interrogated about a day nobody thought to ask about at the time.

Only observation does that. Photographs, walk-throughs, capture with a timestamp on it. Models and reality capture need each other, and it is worth being clear about which is which: the model is the plan, the capture is the evidence.

Where the models live

Follow the model to where it sits and you arrive somewhere more interesting than the model itself.

Under ISO 19650, project information lives in a Common Data Environment — the CDE, the agreed source of information for the project, holding each version alongside the record of who changed it and when, as information moves from work in progress to shared to published. Models, drawings, schedules, specifications, correspondence, and the revision history running through all of it.

So a good deal of what changes a project's risk picture is already in the CDE — dated, version-controlled and attributable, on the project itself. And because the models in it can be exchanged as IFC, reading them does not depend on owning the software that made them: the format is open, and what an object is, where it sits and what it is made of are structured facts, not marks on a drawing that need a practised eye.

That matters more than it first appears, because access is only half of the problem. The other half is knowing what you are looking at. Data that arrives in a proprietary format, or as a thousand-sheet drawing set, is technically shared and practically unread. Data that arrives structured and open can be read by any party with a reason to read it — which is what gives the same information a second value beyond the team that made it. The project paid for this data once, to build with. Its worth to anyone else turns entirely on whether they can reach it and make sense of it.

Almost none of it goes anywhere near the people carrying the risk.

What does reach them is compiled by hand at the outset: a picture of the project on one particular day, accurate that day, and then unchanged while the project it describes carries on moving for the next three years. Scope and programme shift through a long build, and the picture gathered at the beginning is not revisited as they do.

That is not anyone's negligence. It is a reporting habit formed when gathering the information was genuinely expensive. On a project running a CDE, it is not expensive any more.

There is a version of this that is simply better, and it is not complicated. Where a project already reports to its insurers, a good deal of what those reports describe is sitting in the CDE — dated, versioned and already assembled. The information exists. The only question is whether it reaches anyone while it still matters.

The model's second life

The argument does not stop at practical completion, and neither does the data.

At handover, a well-run project passes its structured information to whoever will operate the building. UK practice has a named vehicle for this: COBie — the Construction Operations Building information exchange, first codified in BS 1192-4 and now carried under the ISO 19650 series. Strip away the acronym and it is a structured register of what the building contains: spaces, systems, components, what they are, who made them, their warranties and their maintenance requirements.

For the facilities team, that is the difference between inheriting an asset and inheriting a room of boxes. But the same register is a description of the thing every subsequent party manages risk on. The building that gets insured, surveyed, maintained and eventually altered over fifty years is the building in that data — and an operational risk conversation that starts from a structured, accurate asset register is a different conversation from one that starts from a lever-arch file and an estate manager's memory.

Here is the part that gets missed: none of that can be bolted on at the end. COBie deliverables are specified at the start, in the information requirements the client sets before design begins, or they do not exist. The quality of the information an owner holds in year ten is decided at design, by people thinking about a handover most of a decade away. Data bought once, for one purpose, keeps paying for the life of the asset — but only if someone set it up to.

That is the same lesson the construction phase teaches, played at longer duration. The project's information is worth more than the use it was bought for, to more parties than the one that bought it, for longer than anyone budgets for — provided it is structured, provided it is reachable, and provided somebody thought about the second reader before the first one was finished.

Two halves of one picture

The CDE holds what the project says about itself. Reality capture holds what the site actually is.

Neither is sufficient alone. A model with no observation is intent with nothing to check it against. Observation with no model is a great deal of imagery and no structure. The interesting position is being able to see the distance between the two.

Pikt does the observation. It gives risk engineers continuous visibility of the projects they oversee, connecting to the reality capture and sensing already running on site — cameras, 360° walk-throughs, environmental sensors, progress tracking — and turning it into one time-stamped view of each project.

Not what the project was meant to be. What it is, this week.