Common
data
environment.
A CDE is not a platform. It is an agreement: where each file lives, what state it is in and who lets it through.
Which one is right?
Emails, folders and local copies. Nobody knows which version is current or who signed it off.
An agreed source.
The common data environment is the agreed place where information is collected, managed and disseminated, always through a managed process.
Everything is a container.
A model, a drawing or a schedule: any named, retrievable set of information. It travels with its metadata.
Four states.
Every container is always in one: it is worked on, shared to coordinate, published to be used, and everything is recorded.
Work in progress.
The team's workshop. Its author produces it and no one outside sees it: it can be wrong, deleted and redone.
Shared.
Approved for other teams to see. It is for coordinating and commenting, not for building.
Published.
Authorized for use: in detailed design, in construction or in operation. It is the contractual version.
Archived.
It is not the end of the road: it is the logbook. It keeps every superseded version and every change of state, with who and when.
Nothing passes without permission.
Between states there are gates. The team itself opens the first; the second is opened by whoever is responsible for the appointment and then by the client.
The state is not the folder.
Every container carries three mandatory fields: status code, revision code and classification. Folders help, but they do not replace the tag.
P for preliminary, C for contractual.
Working versions carry decimals, shared ones do not, and published ones change letter.
A name that reads itself.
Fixed fields separated by hyphens: which project, who produces it, where it is, what it is, which discipline and what number it carries.
Who asks, who delivers.
The client appoints. A lead company answers for the whole delivery team, and each task team produces its part.
Permission depends on the state.
The author edits their work in progress. Other teams read what is shared. What is published is read-only.
| Who | WIP | Shared | Published |
|---|---|---|---|
| Its task team | Edits | Reads | Reads |
| Other teams | — | Reads | Reads |
| Lead appointed party | — | Reads and reviews | Authorizes |
| Client | — | Reads if shared with it | Accepts |
Link it, do not copy it.
Each team works on its own model and references the others from the shared state. That way everyone coordinates against the same version.
From project to asset.
What is published and accepted forms the project information model. At close-out it is archived and feeds the asset information model, the one the owner will use.
Six parts, one method.
The ISO 19650 series organises information management across the whole life cycle. The CDE is born in Part 1.
The CDE is set up before tendering.
Part 2 describes eight activities. The client establishes the CDE in the first one, before inviting anyone.
From requirement to plan.
The client says what information it needs. The team answers how, who and when. The CDE is where that promise is kept.
The codes are not ISO.
ISO 19650 asks for status and revision codes, but does not set them. Each country defines them in its national annex, and they do not match.
What it is for, in two characters.
The suitability code says what a shared or published container may be used for. The UK annex is the most copied, and it changed in 2021.
| Code | State | Suitable for |
|---|---|---|
| S0 | Work in progress | Task team work |
| S1 | Shared | Coordination |
| S2 | Shared | Information |
| S3 | Shared | Review and comment |
| S4 | Shared | Stage approval |
| A1…An | Published | Authorized and accepted |
Spain requires it in phases.
The BIM Plan for public procurement defines the CDE and requires it in line with UNE-EN ISO 19650 from the advanced level onwards.
Not everything is shared.
A police station, an airport or a power grid reveal too much. Part 5 requires a sensitivity assessment before deciding who gets access.
Second edition on the way.
Parts 1 and 2 are under revision. The new Part 2 will merge delivery and operation into a single process. Meanwhile, the 2018 editions remain in force.
Syncing is not sharing.
The central model in the cloud is the team's work in progress. Only an explicit step takes it out of there for others to see.
Version is not revision.
The platform numbers every save. The ISO revision is decided by a person when passing a gate. And the IFC is a different container from the native file.
Many brands, same states.
Each platform handles the four states in its own way. Define the workflow first; choose the tool afterwards.
State in a folder or in a label.
Some platforms move the file to another folder when its state changes; others change its label and leave it where it is. Both work if permissions follow.
The gate has a button.
A review workflow assigns reviewers, collects their decision and moves or relabels the container. Not every feature allows it.
Not all seals carry the same weight.
“ISO 19650 compliant” can be an external audit or a line in a brochure. Check who certifies it and against which parts.
Getting CDEs to talk to each other.
The OpenCDE APIs let you open and save containers from a CDE in any program, without downloading by hand.
A comment with coordinates.
BCF stores each issue with its view, its snapshot and the affected elements. It travels between programs and the CDE without touching the model.
Deliver with the links.
ICDD packages models, drawings and tables together with the links between them. DIN SPEC 91391 sets which functions a CDE must have and how to exchange between two.
Six questions at every gate.
Before sharing or publishing, the container is reviewed against six criteria. The first is the CDE itself: correct name and metadata.
Does it pass the gate?
Type a container name and check field by field whether it meets the 2018 UK convention, the most widely used.
The name is not enough.
The CDE checks the container; the IDS checks what is inside the IFC. Together they turn the gate into an automatic test.
A CDE nobody uses does not exist.
The most common failure is not technical: teams that keep sending things by email. You audit it with samples, not with the manual.