Common Data Environment (CDE)

What is a Common Data Environment?

A Common Data Environment (CDE) is the single agreed place where the current version of every project document, model and drawing lives, so everyone works from the same information rather than whatever copy happens to be on their own machine. The concept is formalised in the ISO 19650 series on information management, which sets out how a CDE should organise documents by status rather than just by folder.

On a BIM project the CDE typically holds the coordinated model, the discipline models feeding into it (exchanged as IFC files where disciplines use different software), the drawings derived from the model, and the growing record of decisions and approvals around them. A CDE is not a piece of software in itself, it is a way of organising information; several commercial platforms implement it, but the discipline it enforces matters more than the brand of platform.

What problem does a CDE actually solve?

Without one, the same problem recurs on almost every project: two people work from two different revisions of the same drawing because each received their copy by email at a different time and neither knows a newer one exists. The contractor builds from a superseded layout, the architect finds out on site, and the fix is now a demolition and a delay rather than a five-minute correction.

A CDE removes the ambiguity by making "current" a property of the system rather than a matter of who remembered to forward the latest attachment. Exactly one version is marked as the one to build from at any given time, and everyone with access sees the same one.

What do work in progress, shared, published and archived mean?

ISO 19650 defines four states a document or model passes through, and the state tells anyone looking at it how much to trust it:

State	Meaning	Who should rely on it
Work in progress	Still being developed by the author; not checked, not for use by anyone else	The author only
Shared	Checked and released for other disciplines to coordinate against or comment on	Other disciplines, for coordination, not construction
Published	Formally approved for a defined purpose, such as construction or a permit submission	The contractor, the authority, anyone acting on the document
Archived	Superseded but retained as a record of how the project reached its current state	Nobody acting on it, but everyone who might need to prove what was known when

Moving between states requires a deliberate step: approval from work in progress to shared, authorisation from shared to published. Nothing reaches published without someone having actually signed off on it.

How is a CDE different from a shared cloud folder?

A shared folder solves storage, not trust: everyone sees the same files, but nothing in a folder structure tells a reader whether the drawing they opened is current, a draft, or superseded three revisions ago. Two files with almost the same name, one in a "final" folder and one in a "final v2" folder, are a shared-folder problem a CDE is specifically designed not to have.

A CDE adds three things a folder cannot: an enforced state for every document, so published actually means approved; a permission structure tied to those states, so a contractor cannot build from something still marked work in progress; and a permanent record of who changed what and when. A folder can approximate parts of this with naming conventions, but only a CDE enforces it structurally.

What does the audit trail actually record, and why does it matter later?

Every state change and revision in a CDE is logged: who issued a document, when, at what revision, and who approved the change that superseded it. This is not bureaucratic overhead, it is the record that settles a dispute months or years later about who knew what, and when. If a contractor claims they built from an out-of-date drawing because nobody told them it changed, the audit trail shows exactly when the new revision was published and who had access to it.

This is also where a clash-detection report belongs: not as an email attachment that gets lost, but as a record tied to the model revision that produced it, so a specific conflict's resolution traces back to the exact drawings in force when it was fixed.

Who should have access to the CDE, and at what level?

Access is not all-or-nothing. A typical residential project matches each party's level to their role:

Party	Typical access	Why
Architect and coordinating consultants	Full read and write to their own work in progress area	They are authoring the content
Other design disciplines	Read access to anything shared or published	They coordinate against it but do not own it
Contractor	Read access to published documents only	Building from anything still in review is exactly what a CDE exists to prevent
Client	Read access across the project, plus a full export at handover	They are paying for the building and outlast every consultant's subscription

Getting this wrong in either direction causes problems: too restrictive, and disciplines cannot see enough of each other's work to coordinate; too open, and an unchecked work-in-progress drawing gets treated as approved simply because someone could see it.

What should a private client insist on before signing off on a CDE setup?

Read access of their own, for the duration of the project, so the person paying for the building does not depend on asking a consultant to forward documents on request; this needs no technical understanding of the states above, only visibility into what is current.

More important, a complete export of the entire CDE at handover: every published document, the coordinated model, and ideally the audit trail, delivered to the client rather than left inside a subscription the consultant controls. A CDE hosted on a platform the architect pays for is only as permanent as that subscription; if it lapses and nobody exported the record first, the client's as-built documentation can effectively disappear with it. Asking for the export in writing, as a deliverable, is the practical way to avoid that.

How does the CDE connect to the construction diary and author's supervision on a Slovak site?

Two records required on a Slovak building site produce exactly the material a CDE is built to hold. The statutory construction diary (stavebný denník) is the daily, legally mandated record of site activity, inspections and instructions; author's supervision (autorský dozor) produces the architect's own record of site visits confirming the design intent is being built as intended. Neither is native to a 3D model, but both belong in the same audit trail as the drawings and model revisions they refer to, because a dispute about what was actually built rarely turns on the model alone: it turns on which drawing was current on the day of a particular diary entry.

Where a project keeps the diary, the supervision record and the model revisions in three unconnected places, reconstructing the as-built picture at handover means chasing emails and paper months later. Where they sit in the same CDE, referenced against the same revision history, the as-built documentation can be assembled directly from the record rather than reconstructed from memory and inboxes.