Somewhere on every gigaproject there is a document controller keeping a spreadsheet nobody asked for. Column A is the package. Column B is the platform that package actually issues from. Column C is the mobile number of whoever will send you the drawing when the platform will not let you in. That spreadsheet is the honest picture of the programme, and it exists because the official answer — one common data environment for everything — stopped being true somewhere around the third package award.
A CDE is an agreed source of information for one appointment. A gigaproject is rarely one appointment. It is a delivery authority, a masterplan consultant, enabling-works contractors and a row of package joint ventures, each with its own contract, its own BIM execution plan and, more often than the slide admits, its own CDE.
Which is why the question that opens most workshops — which platform will be the CDE? — is the wrong place to start. When one CDE is not enough, what does federated actually mean, and who owns the issued set across packages?
When one CDE is enough, and when it stops being
One CDE is plenty when a single appointing party can name the information manager, one naming convention survives contact with site, and one document-control desk can produce the set the works are allowed to build from. That describes a great many good projects. It does not describe a programme.
At giga scale it tends to fail for reasons that have nothing to do with licence count.
Appointing parties multiply. A delivery authority lets packages. Each package contractor is then an appointing party to its own supply chain, and the masterplan designer is appointed by somebody else. ISO 19650 does not ask those appointments to share a database; it asks each to manage its information containers through a defined process. Force every work-in-progress model into one library and what you have built is less a common data environment than a common leak.
Commercial boundaries multiply with them. Two package contractors on adjacent plots are usually competitors on the next tender. Their own CDEs were priced into their bids, and their lawyers will not accept "everyone gets a login". Permissions inside a platform can hide a folder; they cannot change the fact that the folder sits on a rival's tenant, which commercial directors understand even when the BIM workshop declines to raise it.
The objects multiply. Permit BIM for a municipality or a ministry is a different object from the construction published set. Interface drawings for utilities, roads and energy belong to no single package's shop drawing pack. Programme-level instruction — grid, levels, control points, corridor widths, enabling-works as-builts — has to live somewhere more definite than "search three platforms and hope".
Scale finishes the argument. Two hundred firms will not complete the same onboarding, in the same language, on the same tenant, in the first ninety days. Some never get access. Some get access and carry on issuing by email, because that is what they have always done. A CDE that exists as a political preference and a field of dormant user accounts is still only a preference.
Federation is more than opening the models together
Ask around and federation usually means several IFC models loaded into one viewer on a Thursday afternoon. That is coordination — genuinely useful, and no sort of architecture for issuing information.
A federated CDE architecture is several systems of record, each authoritative for the containers of one appointment, plus a written exchange into whichever environment is allowed to hold what other appointments may rely on.
Each package CDE keeps its own work in progress, keeps shared-for-coordination inside that appointment, and publishes and issues for that contract. The receiving environment — programme, employer's, or the adjacent package — does not become a mirror of those libraries. It receives a bounded set: these containers, this revision, this state, this suitability, this purpose, this transmittal, this date. Where the exchange is a weekly zip or an assurance that the BIM coordinator will federate it, you have a courier service with a diagram drawn on top.
Any BIM manager who has run a multi-package job will tell you the coordination view was never the hard part. The hard part comes afterwards, in writing, with a date on it.
So the exchange has to answer the questions a single CDE answers without being asked. What was sent, and who authorised sending it? What state did it occupy on arrival? Did it enter as shared for coordination, or as published for construction? Who may supersede it? When those answers live in a messaging group and a set of meeting minutes, the federation is social, and social arrangements rarely survive a claim.
Who owns the issued set across packages
This is the sentence the organogram skips. The package issued set belongs to the appointed party that issued it, under that contract — ordinary document control, no argument.
The interface issued set is the problem. Grids, levels, plot limits, shared utilities, temporary works crossing a hoarding, the masterplan drawing two towers both build from: relied on by more than one appointment. If each package publishes its own copy, three published truths go out and site picks whichever plotter tray it trusts, usually the one nearest the cabin door.
Somebody has to be named as owner of the cross-package issued set. Not "the BIM team". Not "the PMC". A role with authority to accept a container into the programme published state, to refuse a suitability that still says coordination, and to answer on a named date what the adjacent package was authorised to build from. Until that name exists, federation is a diagram of arrows, and arrows do not issue.
A useful test: package A changes a shared grid while package B is already in the ground. Which record is the instruction? If the answer is a coordination model federated last Thursday and circulated as a screenshot, nobody owns the issued set. You own a meeting.
What Gulf programmes make unavoidable
Gulf giga-programmes did not invent any of this. They make it impossible to ignore, because delivery authorities there appoint many packages at once. International consultants arrive with a CDE already priced into the fee; local contractors arrive with another. Government and municipal permit routes — MOMRA in the Kingdom, Dubai Municipality and the Abu Dhabi systems next door — share a portal neither with the construction library nor with each other. A model that satisfied a permit is not, by that fact, the published construction set; treating them as one object is how a programme discovers at inspection that it has been running two truths in parallel.
Data residency and tenant politics are not footnotes either. A package whose records must sit in-country, on a named platform, will not merge quietly into a programme tenant procured two years earlier for a different appointment. Federation is then the only honest architecture on the table: keep the package CDE, write the exchange, name who accepts the programme issued set.
A Monday test
An owner's information manager with a free morning can establish where the programme actually stands.
- List every appointing party and the CDE each appointment names in its execution plan. If the list says "the project CDE" and three contracts name something else, you have a federation.
- For each package, ask who can move a container to published and who can issue. Missing names mean the package CDE is storage.
- Name the containers two or more packages must rely on. If no such list exists, the interface is folklore.
- Name the person who owns the issued set for those containers. If you cannot, stop drawing arrows.
- Write the exchange down: which state the file leaves in, which state it arrives in, which suitability is acceptable, what transmittal gets filed. A zip called federation_week_12 is not an exchange.
- Ask for the programme issued set as it stood on a named Tuesday. If producing it takes three exports and a reconstruction, you have archaeology.
- Separate the permit object from the construction object. If they are copies of each other, say so, and say which one site is allowed to build from.
Seven answers pointing at appointments, states and a named owner of the cross-package set amount to an architecture. Seven pointing at one logo and a hope that everybody will eventually log in amount to a preference with a budget attached.
The standards were never asking for a platform
This gets lost between procurement and the kick-off deck, so it is worth saying plainly. ISO 19650, CDM, the Building Safety Act, NEC, FIDIC, JCT, COBie and the Gulf mandates all assume a managed process for information containers. None requires a single platform, and none will accept a diagram of federated CDEs as evidence that the process exists.
Which is oddly liberating. If the obligation is the process rather than the product, the delivery authority can stop waiting for the platform argument to be settled. Before the next package award, name the person who owns the cross-package issued set and write the exchange into the appointments: which package sends which containers, in which state they arrive, and who on the receiving side may accept them. Price the hours — programme information-management time, and package controllers paid to run the exchange instead of keeping a private spreadsheet. That will cost more than one tenant and a kick-off slide. It will cost less than reconstructing a programme issued set from three exports when two packages disagree about a shared grid. Give the unofficial spreadsheet a mandate, or accept that it remains the architecture.
Read next: Migrating a live project to a new CDE without losing the audit trail, Monthly Register — January 2025, Everyone says they have a CDE. Most have a shared drive with permissions..