A common data environment (CDE) is the agreed source of all information on a project: models, drawings, documents and data. Every file moves through four states, work in progress, shared, published and archived, and every transition has a person responsible and a date. It is not a piece of software: it is a set of rules, supported by one or more platforms.
This article covers what the standards say, what a public or private owner should require, how to choose a platform and the mistakes we see most often. We work mainly in Italy, so the Italian rules come first, but the principles are those of ISO 19650 and apply anywhere. For the wider ISO 19650 framework, see our article on ISO 19650 and information management.
What the standards say
ISO 19650-1 defines the CDE as the agreed source of information for a project or asset, used to collect, manage and disseminate each information container through a managed process. The same standard separates two things: the CDE workflow, meaning the rules, and the CDE solution, meaning the technology that makes them work.
In Italy, UNI 11337 uses the term ACDat and distinguishes it from the ACDoc, an archive of copies of models and drawings, including on paper. UNI 11337-5 describes the ACDat as an IT infrastructure that includes its own procedure of use.
For public contracts the reference is Legislative Decree 36/2023, amended by Legislative Decree 209/2024. Article 43 requires interoperable platforms and open, non-proprietary formats. Annex I.9 requires every contracting authority to have its own CDE, through which all deliverables pass, and to appoint a CDE manager at organisation level. The information requirements (capitolato informativo) must include the CDE specification.
| Term | Where it appears | What it means |
|---|---|---|
| CDE | ISO 19650-1 and -2 | Agreed source of information, with workflow and technical solution |
| ACDat | UNI 11337, Annex I.9 of Legislative Decree 36/2023 | Italian equivalent of the CDE |
| ACDoc | UNI 11337 | Archive of copies of models and drawings |
| CDE manager | UNI 11337-7, Annex I.9 | Role that runs structure, permissions and states |
Information container states
The value of a CDE lies in its states. A file is not just "uploaded": it is in a defined state, and whoever reads it knows how far they can rely on it.
| ISO 19650 | UNI 11337-4 | Who sees it | Permitted use |
|---|---|---|---|
| Work in progress | L0, being produced | Only the task team producing it | None outside the team |
| Shared | L1, being shared | Other teams on the project | Coordination, not construction |
| Published | L2, being published | Authorised users | The intended use: tender, construction, procurement |
| Archived | L3, archived (L3.V valid, L3.S superseded) | Authorised users | Project history and accountability |
UNI 11337 adds approval states: A0 to be approved, A1 approved, A2 approved with comments, A3 not approved. Combining the working state and the approval state prevents the most expensive misunderstanding: a model shared for coordination being used as if it were approved for construction.
Every transition is an action with an owner. Moving from work in progress to shared requires an internal check by the task team. Moving to published requires review and authorisation by the client or its delegate. Each container carries at least three metadata fields, status, revision and classification, on top of a name that follows the agreed naming convention.
What a CDE is not
A shared folder with "draft" and "final" subfolders is not a CDE. Three things are missing:
- a transaction log: who changed the state of what, when, with what outcome;
- permissions tied to states: a team working in progress should not see another team's work in progress, and site staff should see only published information;
- revisions: a superseded file must remain available, not be overwritten.
What the owner should require
The CDE is decided in the information requirements, not after award. This is what we write, or ask to be written, when we support an owner:
- Who owns the environment and the data: owner's or supplier's platform, final owner and custodian, retention period after handover.
- Container structure: breakdown by asset, stage, discipline and zone, with the file naming rule and examples of correct names.
- States and approvers: for each type of deliverable, who checks, who reviews, who authorises publication, and within how many days.
- A permission matrix: by role, not by person, with read, write and state-change rights for each state.
- Formats: IFC for models, BCF for coordination issues, PDF and open formats for documents and data, plus native files where whoever edits the models later needs them.
- Exit at end of contract: a full export with revision history and metadata, readable without the platform.
- Synchronisation: if the supplier works in its own environment, the rules and frequency for aligning it with the owner's.
- Security and confidentiality: named accounts, authentication, rules for sensitive information following the security-minded approach of ISO 19650-5.
- Checks before publication: the automated checks a model must pass before changing state.
How to choose a platform
On paper, most platforms on the market do the same things. The differences show when you test them on a real case. These are the points we check:
| Criterion | What to check | How to test it |
|---|---|---|
| States and workflows | Configurable ISO 19650 states, multi-step approvals | Run a full delivery, from upload to publication |
| Metadata | Mandatory fields for status, revision, classification | Upload a wrongly named file and see whether it is blocked |
| Open formats | IFC viewing, BCF handling | Import a BCF file produced by another tool |
| APIs | Documented APIs, support for buildingSMART OpenCDE APIs | Ask for the documentation before the offer |
| Audit trail | Exportable transaction log | Export the history of one container |
| Export | Complete archive readable outside the platform | Ask for a test export |
| Permissions | Permissions by role and by state | Log in as a user from another team |
| Site use | Tablet access to published information only | Test it on site, not in the office |
For public owners, continuity matters as well: the CDE has to serve many projects, for years, and must not depend on one supplier's contract. For contractors, what matters is being able to work inside the owner's environment without duplicating the archive.
The mistakes we see most often
- CDE as a file server: platform bought, rules never written. Without states and approvals there is no traceability.
- Everything published: for convenience every file ends up in the highest state, and the state stops meaning anything.
- Permissions by person: every time the team changes, someone is locked out or left in.
- Naming decided after start: renaming thousands of files mid-project costs weeks.
- Two environments with no sync rules: owner and contractor work on different versions and nobody knows which one is valid.
- No exit clause: at the end of the contract the data stays on the supplier's platform.
BIMON experience
At MIND Milano Innovation District, one million square metres on the former EXPO 2015 site, we run masterplan data management and BIM management for Lendlease. Data comes from many projects and many parties: our job is to make it consistent and verifiable, with custom business intelligence that validates all project data and presents it in dashboards readable by non-specialists.
On The Factory in Manchester, the cultural venue designed by OMA, we worked with Ryder Architecture on the multidisciplinary development and coordination of the project in BIM. Design issues were tracked and resolved before construction started, using Navisworks and BIM Track. It shows what a CDE needs beyond files: a shared issue register linked to the models.
What BIMON does
Through our CDE management service we set up container structure, naming, roles, permissions and approval workflows, and we can run the environment day to day with delivery status reports. Our BIM management team writes the CDE section of the information requirements with the owner, or reviews it before the tender. If you are choosing a platform or need one configured, get in touch.
