Lesson 5.1Lesson 5.1 · Managing the Information (ISO 19650)
The Common Data Environment
The single agreed place where information lives — and moves through states of trust
A shared drive holds files. A CDE knows which files you are allowed to trust.
Give a project team a shared folder and you have solved storage. You have not solved the real problem, which is *trust*: on any live project, some information is a half-finished draft, some is ready for others to coordinate against, and some is formally approved to build from — and a plain folder cannot tell them apart. People end up building from a superseded drawing, or coordinating against someone's rough draft, because nothing marks what is safe to use.
The Common Data Environment (CDE) solves exactly this. It is the single agreed place where all project information lives — but its defining feature is not storage, it is a status workflow: every piece of information sits in a known state (work-in-progress, shared, published, archived), and moving between states requires a check. The CDE does not just hold the information; it tells you, at every moment, how far you can trust each piece of it. That is why it, not any modelling tool, is the backbone of managed BIM.
Four states, and a gate between each. That is a CDE. Everything else is just a folder with hope.
Not a place, a process: the four states
The heart of a CDE is that information moves through defined states, each with a clear meaning and clear rules about who can see and use it.
Work-in-progress (WIP) is information still being developed by the team that owns it — private to them, not yet fit for anyone else to rely on. Shared is information a team has deliberately released for others to see and coordinate against — visible across disciplines, but not yet approved; you can design against it, not build from it. Published is information that has been formally checked and authorised for a purpose — this is what you build from, the trustworthy record. Archived keeps every superseded version, so there is always a traceable history of what was current when.
The transitions between these states are the real work: information does not drift from WIP to Shared to Published on its own — it is *moved*, deliberately, through a check at each gate. That controlled progression is what turns a pile of files into a managed source of truth where the status of every item is always known.
The gates are where quality lives
A CDE's value comes from what happens *between* the states. Promoting information from WIP to Shared is a decision — this is good enough for others to coordinate against. Promoting from Shared to Published is a stronger decision, usually with a formal check and approval — this is authorised to build from. Each gate is a checkpoint where someone takes responsibility for the information's fitness.
This is why a CDE is a *process*, not a product. You can run a disciplined CDE on fairly ordinary software if the states and gates are respected; you can have expensive software and no real CDE if everyone dumps files anywhere and 'shares' means emailing a copy. The gates enforce the single-source-of-truth promise from Module 1: because published information is the only thing anyone builds from, and it got there through a check, the whole team is working from one authorised reality instead of a scatter of private versions. Remove the gates and you are back to a shared drive — storage without trust.
The folder answers 'where is the file?'. The CDE answers 'can I trust this file yet?'.
Why the CDE is the backbone of ISO 19650
Everything else in this module hangs off the CDE. The information requirements (the EIR) say what must arrive and to what standard; the execution plan (the BEP) says how the team will produce it; the naming and container discipline (lesson 5.4) makes each item findable and sortable *inside* the CDE; and the handover (5.5) draws the operational record *out* of it. The CDE is the shared stage on which the whole ISO 19650 process (next lesson) is performed.
It is also where the collaboration of Module 1's 'people' leg becomes concrete: many parties, each owning their WIP, deliberately sharing and publishing to common rules, in one place, with one history. On Indian public projects an ISO-19650-aligned CDE is expected precisely because a large, multi-firm job cannot otherwise keep its information trustworthy. The practical test of whether a team is really 'doing BIM' is often simply this: is there one CDE, with real states and gates, that everyone actually works through — or are there private folders and emailed files pretending to be coordination?
Move a container through the CDE states
Move one information container through the CDE states
Work in Progress
Who sees it · Only the authoring team
May do · Develop it — it is not yet fit for anyone else to rely on.
The status — not the folder — tells you how far to trust each piece. Only Published is safe to build from; a shared drive has no gates at all.
Three altitudes on the same idea
Read the band that fits you — or all three.
Learn the CDE as states, not storage. A Common Data Environment is the single agreed place all project information lives — but its point is a status workflow, not the folder. Information moves through four states: work-in-progress (private, still being made), shared (released for others to coordinate against, not yet approved), published (formally checked and authorised — what you build from), and archived (superseded versions kept for history). Moving between states requires a check at each gate. That controlled progression is what tells everyone how far to trust each piece of information — which a plain shared drive never can.
Work through the states, not around them. Keep your developing work in WIP; deliberately promote to Shared when it is fit for others to coordinate against; rely only on Published information when you build or take-off. Never email a copy as a substitute for sharing through the CDE, and never build from a Shared (unapproved) file. Respect the gates — they are where someone takes responsibility for fitness — and use the archive to check what was current when. Your discipline in moving information through its states is what keeps the single source of truth actually single.
Set up the CDE as a governed process, and enforce the gates. Choosing software is the easy part; defining the states, the approval gates, who can promote information and on what check is the real design — and it belongs in the BEP. A CDE without enforced gates is just a shared drive with ambitions. Insist that Published is the only build-from source, that sharing happens through the CDE (not email), and that the archive preserves a full history for audit and the golden thread (lesson 5.4). On large or public projects (India's CPWD/ISO-19650-aligned expectations included), a real CDE is the precondition for trustworthy multi-firm delivery — treat it as core governance, not IT plumbing.
“A CDE is basically a shared drive or cloud folder for the project's files.”
Do it yourself
Trace one drawing through the states — the point is to feel the gates.
- 1Take one deliverable — say a coordinated floor plan. Write the four states as a track: WIP → Shared → Published → Archived.
- 2For each state, answer two questions: who can see it, and what may they do with it? (WIP: only the authoring team, develop it. Shared: all disciplines, coordinate against it. Published: everyone, build from it. Archived: everyone, reference the history.)
- 3Now describe the gate between Shared and Published: who checks what, and what responsibility do they take by approving it? Notice that this decision — not the storage — is where trust is created.
- 4Finally, imagine someone builds from a Shared (not yet Published) file, or emails a copy that bypasses the CDE entirely. Write one line on what goes wrong — and why 'it's on the shared drive' is not the same as 'it's safe to use'.
The one line to carry out
The CDE is the stage; ISO 19650 is the script it performs. Next: the international standard that codifies the CDE, the roles and the whole information-management process — and where India actually stands with it.
The author
Amogh N P
Architect, interior designer, and creative polymath. Studio Matrx began in his notebooks — his vision of design made honest, useful, and open to everyone. Its Academy is written and taught in his memory, and free, forever.
More about Amogh →