Coulter BIM Information Management

The term “Common Data Environment” gets repeated endlessly in digital construction. We talk about single sources of truth, ISO 19650 compliance, OpenBIM, structured data delivery, and lifecycle information. CDEs are supposed to be the centrepiece of all of this — a reliable, neutral, interoperable information hub.

But the reality is very different.

Most CDEs are not open, not interoperable, and barely “common” at all. And one of the clearest signs of this failure is how impossible it still is to move a simple PDF — with its metadata — from one CDE to another without rebuilding everything manually.

As someone who works with information management every day, this is one of my biggest frustrations.

Moving a PDF Between CDEs Should Be Simple — Yet It Isn’t

Right now, if you want to transfer a document between two major CDEs, you have to:

download it to your computer

lose all metadata in the process

upload it manually to the new CDE

recreate naming, metadata, revision numbers, status codes, workflow stages, and permissions

And if you’re unlucky — and most of us are — you have to rebuild the folder structure as well.

This is not interoperability.
This is rework.
This is inefficiency.

It’s astonishing that in 2025, with all the standards, schemas, and “digital transformation” talk, we still cannot perform basic cross-platform transfers between CDEs.

Imagine this happening in banking

Imagine if:

A Santander customer couldn’t send money to Lloyds

A Bank of Ireland customer couldn’t pay someone with an AIB account

Or you were told: “To transfer money, withdraw it as cash, walk it over to the other bank, and deposit it manually.”

That’s exactly what CDEs make us do — only with PDFs instead of money.

It would be unacceptable in finance.
But apparently acceptable in construction.

Why is the industry stuck in this mess?

1. Vendors don’t want to lose customers easily

Open transfers = easy to leave = less lock-in.
CDEs are subscription businesses.
They benefit when it’s hard to migrate.

2. Metadata standards exist — but vendors avoid implementing them

buildingSMART’s openCDE APIs exist.
Metadata schemas exist.
Transfer container concepts exist.

But none of them are implemented consistently.

3. No regulatory pressure

Financial interoperability was fixed by regulators.
Construction has nothing similar for CDEs.
ISO 19650 defines the process — not the mechanism.

4. Vendors are building walled gardens

CDEs increasingly operate like closed ecosystems with their own “mini-platforms” and proprietary app layers.
Genuine openness dilutes their commercial model.

And so the status quo remains, because it works well for vendors and badly for users — especially Information Managers.

IFC Has Been Suggested as the Answer — But It Isn’t

Whenever interoperability is discussed, IFC often gets proposed as the solution: “Just use IFC as the exchange format.”

That sounds good in theory, but in practice it falls apart.

IFC is a model-based schema

Yes, IFC is much broader than just geometry. It supports processes, resources, properties, classifications, and non-graphical data. But its heart is still model-centric.

Which means:

It doesn’t naturally handle PDFs

It doesn’t represent raw reports

It doesn’t bundle handover documents

It isn’t designed for contract files, safety certificates, or correspondence

It doesn’t replicate folder structures or revision workflows across CDEs

Trying to use IFC as a universal container for a project’s complete document set is like trying to use a blueprint as a filing cabinet. It wasn’t designed for that.

IFC excellence ≠ CDE interoperability

Even if Revit exported perfect IFC (it doesn’t), and even if every vendor fully supported IFC4.3 (they don’t), it would still not solve the movement of ordinary files, documents, approvals, and records.

IFC solves model exchange.
CDE interoperability is a completely different problem.

COBie — And Especially COBieOM — Is the Closest Thing We Have

If there’s one structured-data format that actually helps bridge the gap between models and documents, it’s COBie.

But my personal favourite, by far, is COBieOM.

Why COBieOM deserves more attention

COBieOM is a toolset created specifically for asset operators that produces a single, self-contained ZIP file containing:

COBie spreadsheets

linked documents

O&M manuals

warranties

drawings

certificates

product information

all neatly referenced and packaged

It doesn’t replace a CDE — but it is brilliant for:

structured handover

milestone information drops

transferring asset data between systems

long-term archiving

giving FM teams something portable, open, and self-describing

COBieOM is the closest thing we have to a “neutral project container.”

Is it perfect? No.
Does it solve interoperability of live CDE workflows? No.
But does it give asset owners something they can open in 30 years without needing a subscription? Yes.

And that already puts it ahead of most CDEs.

CDEs Are the Single Biggest Obstacle to OpenBIM

When you combine all of this, the picture becomes clear:

IFC can’t solve CDE interoperability

COBie helps, but doesn’t replace CDE workflows

Vendors resist open exchange

Metadata is trapped

Revision history is trapped

Workflows are trapped

Projects cannot move freely

Clients are locked in long-term

This is the exact opposite of what OpenBIM is supposed to be.

You can move models.
You can move data.
You can move classifications.

But you cannot move a PDF properly.
That’s the absurdity.

What Needs to Happen

CDE interoperability will not be solved by vendors voluntarily.
There is no incentive.

What we need is:

1. A mandatory openCDE transfer specification

2. Government-level pressure, especially for public-sector projects

3. BuildingSMART enforcement that openBIM includes CDE interoperability

4. Clients demanding open exchange by contract

5. Industry refusing to accept closed systems

Until that happens, information managers will continue doing the same painful, manual, error-prone document migration tasks that should have been automated years ago.

Final Thoughts

CDEs are supposed to be the foundation of information management. But until they support genuine, open exchange between systems — including metadata, revision history, workflows, and linked documents — they remain proprietary silos.

IFC isn’t the solution to the CDE problem.
COBieOM helps, but doesn’t replace a CDE.
And vendors have little incentive to change.

If we are serious about OpenBIM, the Golden Thread, asset lifecycle management, and digital transformation, then CDE interoperability needs to be treated as a priority — not an afterthought.

Because until the “common” part of Common Data Environment is actually common, the rest of our digital ambitions remain limited.