I know, I know, the new ISO is out and bla bla bla, but I gave you a week of mournful silence last week and, for now, let me quote you Nick Fury.
Some weeks ago, I wrote an article on “advanced BIM,” whatever that means, and I mentioned in passing how BIM Level 3 was discovered to be a bad idea. Some of you wanted to know more. So this week, we focus on what BIM Level 3 actually meant (spoiler: integrated collaboration) and why it was superseded in the subsequent maturity model of ISO 19650. Up until we have no stages anymore but I believe we covered that topic on Wednesday.
To understand why Level 3 reflects a problematic approach, we first need to understand why its appeal was so successful to begin with.
1.1 The Bew–Richards Maturity Triangle
The Bew–Richards diagram — that now-iconic triangle we’ve been fed for years at BIM conferences — gave the construction industry something it sorely needed and never truly had before: a visual narrative of progress.
The ladder pretty much went:
- Level 0: unmanaged CAD;
- Level 1: managed CAD in 2D or 3D;
- Level 2: collaborative working with federated models;
- Level 3: full integration, a shared project model.
The simplicity was intoxicating: it framed digital transformation as a linear ascent toward coordination heaven (queue the Led Zeppelin). The metaphor was powerful: climb high enough and fragmentation disappears. Climb high enough, and the fragmentation of the industry goes away. Now, the problem is, nobody really knew what integrated BIM meant.
Level 2 already represented a significant shift. It formalised federation, structured information exchanges, defined responsibility boundaries, and introduced the discipline of the Common Data Environment. It acknowledged a crucial truth: collaboration comes through structured exchange.
Level 3, however, promised something more radical. It suggested that federation — periodic, governed coordination — was an intermediate state. The destination was full integration.
The idea was seductive. Why wait for exchanges if we can remove the waiting? Why coordinate at intervals if we can eliminate intervals altogether? If integration is good, then total integration must be better.
But here is where the conceptual slippage occurred. Nobody really knew what “integrated BIM” meant in operational terms, and the vacuum was quickly filled with the most intuitive interpretation available: instead of federating models at regular intervals, let’s just share them continuously. That certainly sounded integrated.
Going forward, we need to separate two ideas that were quietly conflated: integration and exposure.
2. Integration or Exposure?
2.1 The Semantic Confusion
So, let’s recap: “full integration” sounded like a natural evolutionary step, and promised to go beyond coordination, beyond periodic alignment, toward something seamless. The problem is that no one ever defined, with precision, what that “something” was supposed to be.
Integration of what, exactly? Geometry? Data environments? Workflows? God forbid it was contractual responsibility and decision-making authority? The term travelled easily across conference stages and policy documents, but it rarely descended into operational clarity. And in that ambiguity, as it often happens, a shortcut interpretation took hold.
In other industries, integration often implies unified control within a stable organisational structure. In construction, however, projects are what project management says they are: temporary assemblies of independent actors — designers, consultants, contractors — each with distinct liabilities and scopes of work. There is no single authorial mind behind the model. And, since project management in construction is all around the place, there is no unified command structure. At best, there are negotiated responsibilities.
In that context, it goes without saying, integration cannot simply mean that everyone sees everything at all times. Yet this is precisely where the idea drifted: in the absence of a rigorous definition, integration became equated with real-time sharing. If models are accessible continuously, if changes are instantly visible across disciplines, then surely we have achieved a higher form of collaboration, haven’t we?
Spoiler, we haven’t.
Visibility is not the same as coordination. Access is not the same as alignment.
Level 2, for all its supposed limitations, rested on a disciplined premise: information moves through stages. Models are developed within defined spaces, reviewed internally, then shared in a controlled manner through the Common Data Environment. Status codes, approval workflows and responsibility matrices are mechanisms that protect both quality and accountability.
Federation was a governance model.
Level 3, as it was commonly interpreted, blurred that logic by privileging uninterrupted exposure over structured exchange, and suggested that removing intervals automatically increases maturity and, if we can eliminate waiting, we eliminate inefficiency. In one word: it promised to remove friction by dissolving gates.
But friction is not always the enemy.
In complex projects, friction often signals validation and ownership. When integration is reduced to simultaneity, we do not necessarily gain coherence: we simply accelerate visibility. Of stuff that was best to leave unseen.
3. Real-Time Without Filters: a Governance Problem
If Level 3 equated integration with uninterrupted visibility, let’s start with a simple question: what happens to governance when everything is visible all the time?
Construction projects are not social media feeds (and we should have a moment of reflection on those too): they are structured environments of responsibility, risk, and staged decision-making. When real-time sharing is introduced without filters, the issue is reliability.
3.1 The Difference Between Visibility and Reliability
One of the most persistent confusions in digital collaboration is the belief that access equals empowerment. If everyone can open the model, inspect it, and see changes in real time, then they’re entitled to take action upon what they’re seeing. It’s a misconception suitability codes (may they rest in peace) tried to set right.
Access does not grant authority.
Authority is contractual, it’s disciplinary, it’s earned through scope and responsibility. In a coordinated environment, each discipline develops its information within defined boundaries and releases it at agreed milestones. That release carries weight and passes through gates of internal approval: its appearance in the shared state signals a level of internal validation and readiness for coordination.
When visibility becomes continuous, that signal explodes in a thousand tiny fragments. If every intermediate step is exposed, the distinction between work-in-progress and coordinated output blurs. The model ceases to communicate status clearly. Observers see change, but they do not necessarily understand maturity, reliability, or intent.
3.2 Why Disciplines Require Protected Spaces
Design is iterative. Engineering is exploratory. Architecture evolves through hypothesis and refinement. None of these processes are linear, and none benefit from constant external scrutiny at every micro-step. Protected spaces aren’t silos we should seek to tear down, but laboratories that need to stay protected. A structural engineer testing load paths, an MEP designer adjusting routing strategies, or an architect refining spatial relationships needs room to experiment before exposing proposals to coordination, and that internal iteration is where quality is built. Aggregation, as conceived in Level 2, acknowledged this reality: develop internally, validate, then exchange.
Remove the staging, and you introduce subtle distortions: teams begin to design defensively, adjusting decisions not because they are technically resolved, but because they are prematurely visible, as the pressure of constant exposure alters behaviour, discourages exploration and encourages performative stability. As it happens with constant exposure on social media, honey. Total transparency reduces intellectual risk-taking.
3.3 The Risk of Premature Visibility
If real-time sharing collapses temporal boundaries, a change intended as a hypothesis or a provisional adjustment might appear, to others, as a committed move. A test becomes a statement. An exploration becomes a decision. In a federated model exchanged at defined intervals, this doesn’t happen or, at least, it just happens by mistake: information is shared to signal a readiness for coordination. In a continuously exposed model, timing loses semantic value. Everything is present, but not everything is ready.
This creates confusion, overhead, coordination noise: when teams react to changes that were never meant for reaction, when questions are raised on decisions that are still under development, the project begins to operate in a state of permanent uneasiness and uncertainty, consuming energy without necessarily improving outcomes.
3.4 Information Overload Kills
Construction projects already generate enormous volumes of data, and not everything is always necessary. Real-time sharing increases not just the quantity of information, but its volatility. Every adjustment, every parameter tweak, every routing test becomes instantly observable. Without filters — approval gates, status codes, release protocols — the Common Data Environment risks becoming a continuous stream rather than a structured sharing space. And the signal-to-noise ratio drops, if stakeholders struggle to distinguish validated information from transient iteration.
In such an environment, the speed that was originally the point for removing barriers has become a liability, because precious decisions are made on unstable data, coordination meetings respond to fluctuations rather than consolidated positions, and – most importantly – accountability becomes harder to trace because the boundary between proposal and commitment is blurred.
This is why real-time exposure is not a neutral technical upgrade, but a governance shift, and a shitty one. Governance, just like geometry and data, doesn’t improve by moving faster.
4. Digital Stewardship
So, if you’re thinking “everything will go smoother and we’ll go faster if we share continuously and without boundaries,” think again: what you’re underestimating is the necessity of stewardship. Connectivity is a technical condition. Stewardship is an organisational one. And without the latter, the former quickly becomes amplification for a bunch of monkeys making noise.
4.1 The Need for Curators, Not Just Contributors
We already talked about this: in a real-time environment, everyone can contribute but fewer people can curate information that’s in constant flow. As a coordinator, you’re ridicously outnumbered and you risk micromanaging you’re team. You’re a polar bear in a global warming documentary, hanging onto a tiny piece of ice in the middle of the sea, waiting to die.
The CDE, as conceived in Level 2 and formalised in ISO 19650, was never just a storage solution but functions as a staging system: work in Progress, shared, published (and archived) are states that carry meaning and, most importantly, each transition required validation. Each approval gate is a moment of responsibility.
Those gates sometimes look like bureaucratic obstacles, but they’re important, they matter, they tell the project that this information is ready for coordination, that package has been internally checked, this model can now influence others, and you can spend your valuable time doing work based upon stuff that’s reasonably verified, and I’ll refrain from changing it whimsically.
So maybe that’s the problem. Continuous share is suggested in situations where I don’t care if you base your work upon something that changes because I will change it, I have no respect for your time or your work, so we might as well cut a stewardship that won’t be allowed to verify and guarantee shit.
The request for continuous sharing (the Level 3 that never was), in this scenario is more than a bad idea: it’s a red flag.
No Comments