What ISO 19650 actually requires of a common data environment, clause by clause

Open the standards for the first time after a fortnight of vendor demos and the surprise is how little of the text looks like the slides. Search the question online and you are shown the same four things: the common data environment called a "single source of truth", four coloured folders, a status-code table presented as though it were the international text, and then a product. That is an explainer of a licence, not of the standard.

ISO 19650-1:2018 and ISO 19650-2:2018 are more specific than any of it, and they are not the same kind of document. Part 1 sets concepts and principles; its verbal form is should. Part 2 sets the delivery-phase process; its verbal form is shall. The consequence catches people out in both directions. A CDE that satisfies a marketing checklist can still fail the shall list in clause 5.1.7, and a project that implements 5.1.7 as folders can still fail the concepts in Part 1 clause 12. So it is worth walking the clauses in order — containers, states, suitability, information requirements — and stopping where the published text stops. UK National Annex recommendations are flagged as such below, because they are not core ISO and the difference tends to surface about eighteen months later, in a meeting nobody enjoys.

Two documents, two verbs

Part 1 is titled Concepts and principles. It defines the CDE, the information container, the status code, the cascade of information requirements, and the four container states. Clause 12 is the CDE chapter. Nothing in Part 1 obliges you to apply Part 2; the introduction says so. If you do apply Part 2, you inherit Part 1's terms.

Part 2 is titled Delivery phase of the assets. Clause 5 is a process: assessment and need, invitation to tender, tender response, appointment, mobilisation, collaborative production, information model delivery, project close-out. The CDE is not a side topic in that process. It is established in 5.1.7, written into the information protocol in 5.1.8, used to share tender information in 5.2, configured and tested in 5.5, and used as the place where containers are checked, shared, authorised, accepted and archived in 5.6 to 5.8.

Vendor explainers compress both documents into one diagram. The diagram is useful, right up to the moment somebody in a workshop starts quoting it as the requirement.

Part 1: the definitions the CDE sits on

3.3.15 — agreed source, not a logo

ISO 19650-1 clause 3.3.15 defines a common data environment as an agreed source of information for a project or asset, for collecting, managing and disseminating each information container through a managed process. Note 1 to that definition is the sentence most product pages skip: a CDE workflow describes the processes; a CDE solution can provide the technology to support those processes.

Three consequences follow.

First, "agreed source" is not "single source of truth". The older PAS 1192 and BIM Wiki wording still circulates on vendor pages, and it is weaker on process than what replaced it. The ISO wording is quieter in marketing terms and stronger in operational ones: the source is agreed, the process is managed, and the thing being managed is the container. A project can run more than one technical solution inside one agreed workflow. Part 2 later calls the appointing party's environment the project CDE and allows a delivery team a distributed CDE connected to it. That is still one CDE in the ISO sense if the workflow is shared. It is two products.

Second, a hard-copy cabinet with a managed process can be a CDE solution. So can a postal exchange on a security-minded job that forbids digital methods. The usual case is an electronic document management system, and nobody is arguing for the cabinet. The definition simply does not prefer a logo.

Third, software is not "ISO 19650 certified". The series governs the appointing party's process and the appointments that implement it. A platform can enable the mechanics. It cannot hold the stamp, whatever the footer of the brochure says.

3.3.12 — a container is not a file

Clause 3.3.12 defines an information container as a named, persistent set of information retrievable from within a file, system or application storage hierarchy. The examples in the standard include a file, a sub-directory, a model, a document, a table, a schedule, and a distinct subset of a file — a chapter, a layer, a symbol. Structured containers include geometrical models, schedules and databases. Unstructured containers include documents, video and sound. Transient search results are out.

Read that definition carefully and an environment that only stores PDFs is already a partial implementation. The container is the unit of management: it has a name, it persists long enough to be managed, and it must be retrievable. Naming should follow an agreed convention (note 3 to 3.3.12). Part 2 will require the CDE to enable a unique ID built from delimited fields. The convention itself lives in the project's information standard, not in whatever folder tree the software shipped with.

3.3.13 — status is suitability, not state

Clause 3.3.13 defines a status code as metadata describing the suitability of the content of an information container. Suitability answers "what may this be used for?" State answers "where is this in the workflow?" Vendor pages treat S1, Shared and "for coordination" as one badge. They are three different facts: a UK code, a Part 1 state, and a permitted use.

A container in Shared can be S1 (coordination) or S3 (review and comment). A container that is Published is not automatically suitable for construction if the status still says it is for information. Misuse of suitability is how a shop drawing becomes, in a dispute two years later, "the construction drawing", and how a perfectly honest engineer ends up defending a decision they never made. The clause-level point is narrower than the argument it causes: Part 1 requires a status attribute. It does not publish S0–S7. Those codes live in a national annex.

Clause 5 — information requirements are why the CDE exists

Part 1 clause 5 is the cascade most CDE pages never reach. Without it the four states have nothing to satisfy.

5.2 Organizational information requirements (OIR) — what the organisation needs to meet its objectives.
5.3 Asset information requirements (AIR) — what is needed to operate an asset.
5.4 Project information requirements (PIR) — what is needed to deliver an asset.
5.5 Exchange information requirements (EIR) — what is needed in relation to an appointment.
5.6 Asset information model (AIM) and 5.7 Project information model (PIM) — the information models those requirements produce. A PIM can be a design-intent model or a virtual construction model. An AIM is the operational model.

Clause 3.3.2 defines an information requirement as a specification of what, when, how and for whom information is to be produced. Clause 3.3.7 defines information exchange as the act of satisfying a requirement. The CDE is the agreed source through which those exchanges are collected, managed and disseminated. Which means an environment that cannot show which container satisfied which EIR at which milestone is a store, however good the interface is. The requirement cascade is the reason the store was specified in the first place.

Part 2 turns this into process: the appointing party establishes project information requirements (5.1.2) against key decision points, then appointment-level EIRs (5.2.1), then the lead appointed party cascades EIRs to appointed parties (5.4.3). The CDE is the environment in which those deliveries are planned (TIDP, MIDP), produced, reviewed and accepted.

Clauses 9 to 11 — containers have to be planned

Clause 9 is information container-based collaborative working. Clause 10 is information delivery planning: timing, a responsibility matrix, and a federation strategy with a container breakdown structure (10.3, 10.4). Clause 11 is the collaborative production of information, including level of information need (11.2) and information quality (11.3). Level of information need exists to prevent delivery of too much information (3.3.16). Federation is the creation of a composite information model from separate containers, often from different task teams (3.3.11).

A CDE with states but no container breakdown, no responsibility for each element of the model and no agreed level of information need will still fill up. It fills up with the wrong things, at the wrong granularity, owned by nobody in particular.

Part 1 clause 12: CDE solution and workflow

Clause 12 is the CDE chapter. It is recommendations (should), not Part 2 requirements (shall). It is also the chapter every vendor diagram is quietly lifting.

12.1 Principles

Clause 12.1 sets the principle that the CDE is a solution and a workflow, and that containers in that workflow carry metadata. The UK BIM Framework reading of 12.1 — consistent with Part 2 5.1.7 — is that each container should carry a revision code, a status (suitability) code, and a classification code. Classification, when required by Part 2, follows the framework in ISO 12006-2. In the UK that implementation is Uniclass 2015, via the National Annex, not via the core ISO text.

Far from decoration, that metadata is how an author keeps control of a container as it develops, and how a recipient knows which revision they are holding and what they are allowed to do with it. Colour-coding the folder does none of that.

12.2 Work in progress

WIP is information being developed by its originator or task team. It is not visible to, or accessible by, other task teams. Diagrams that implement WIP as a shared project folder with "don't look yet" etiquette have not implemented 12.2 — the state is a matter of access, not manners, and etiquette has never survived a coordination deadline.

WIP is also where revision control earns its keep. The UK National Annex (not core ISO) recommends a preliminary revision with a WIP version suffix — P01.01, P01.02 — so an author can revert without inventing filenames. That scheme is national practice. The Part 1 requirement is the state itself: private development, then a controlled transition.

12.3 The check / review / approve transition

Containers do not drift from WIP to Shared. They pass a check/review/approve transition. Part 2 later splits the practical work: a quality-assurance check against the information standard (5.6.3), then a review of the content and an approval for sharing (5.6.4). 5.6.3 is explicit that a compliance check does not replace review. A CDE that auto-promotes a file because the filename matched a pattern is not performing 12.3.

12.4 Shared

Shared is information approved for sharing with other appropriate task teams, delivery teams, or the appointing party. It is the coordination state. In the UK National Annex it is also the non-contractual state. You may coordinate from it. You should not procure materials, agree contract costs, or construct the works from it. When a site pack gets printed from Shared because Published was "a week behind", that is a process failure rather than a limitation of the software, and it is usually a failure everybody in the room could see coming.

12.5 The review / authorize transition

Shared does not become Published by ageing. It passes a review/authorize transition. Part 2 names two subsequent human acts that vendor pages often merge: the lead appointed party authorises the information model (5.7.2); the appointing party accepts it (5.7.4). Authorisation and acceptance are not the same signature.

12.6 Published

Published is information authorised for use — further detailed design, construction, manufacture, or asset management, according to the appointment. It is the contractual issued set. If a superseded published revision can still be plotted as though it were current, what you have is a folder named Published rather than clause 12.6 in operation.

12.7 Archive

Archive is the journal of information transactions: an audit trail of container development, including who checked, when, and with what outcome. It holds superseded Shared and Published revisions and the snapshot at a close-out. A recycle bin is not Archive. A hidden previous-version flag that only the application administrator can query is a weak reading of it. The honest test is whether the project can still name the revision that left the environment, the organisations that received it, the state it was in and the date it moved — years later, with the original team dispersed across three other jobs.

Part 1 Figure 10 — the four-state diagram every explainer reprints — is a simplification. Containers can take different paths through different solutions. The states still have to behave as states rather than as labels on directories.

Part 2: the delivery process the CDE has to serve

5.1 Assessment and need — the CDE is the appointing party's job

Clause 5.1 is work the appointing party does before inviting tenders. It is the section vendor pages skip, because there is no feature in it to photograph.

5.1.1 Appoint individuals to undertake the information management function. The function can be delegated. Accountability does not travel with the licence.
5.1.2 Establish the project's information requirements so the appointing party can answer the questions it must answer at each key decision point. Part 2 points this activity at ISO 19650-1:2018, 5.3. In Part 1's published headings, 5.3 is asset information requirements and 5.4 is project information requirements; the substance of 5.1.2 is the project-level questions at key decision points. Do not pretend the cross-reference and the Part 1 headings line up cleanly — vendor pages never notice, and a controller should.
5.1.3 Establish information delivery milestones against the plan of work.
5.1.4 Establish the project's information standard — including how information is structured and classified, how level of information need is assigned, and how information will be used in the operational phase.
5.1.5 Establish information production methods and procedures: capture, generation, review, approval, security, distribution, delivery.
5.1.6 Establish reference information and shared resources, using open data standards where possible.
5.1.7 Establish the project's common data environment.
5.1.8 Establish the project's information protocol.

The CDE is item seven, not item one. It is configured to serve 5.1.2 to 5.1.6, then bound by 5.1.8. Buying the platform first and writing the EIR afterwards runs the clause order backwards, which is how most of us met it.

5.1.7 — the six things a CDE shall enable

This is the only clause in the series that tells you, in a shall list, what the project CDE must be able to do. The appointing party shall establish (implement, configure and support) the CDE to serve the project and to support collaborative production (5.6). The CDE shall enable:

A unique ID for each information container, from an agreed, documented convention of fields separated by a delimiter.
Codified fields — each field taken from an agreed, documented codification standard.
Three attributes on every container: status (suitability); revision; classification in accordance with ISO 12006-2.
Transition between states — the Part 1 clause 12 workflow, as a system behaviour, not as a naming habit.
A recorded user and date whenever a revision of a container transitions between states.
Controlled access at information-container level — not only at folder or project level.

01
1
The CDE shall enable...A unique ID for each containerfrom an agreeddocumented field convention
02
2
The CDE shall enable...Codified fieldseach taken from an agreed codification standard
03
3
The CDE shall enable...Three attributes on every container: status (suitability), revision, classification (ISO 12006-2)
04
4
The CDE shall enable...Transition between statesas a system behaviour rather than a naming habit
05
5
The CDE shall enable...A recorded user and date whenever a revision transitions between states
06
6
The CDE shall enable...Controlled access at container levelnot only at folder or project level

That list is the whole gap between a shared drive with permissions and a CDE. A drive can restrict a folder. It does not, by itself, give every container a unique delimited ID, a status distinct from a state, a classification, a recorded state transition, and access that follows the container rather than the directory.

Two notes in 5.1.7 matter as much as the list. The CDE should be in place before the invitation to tender, so tender information can be shared securely. Hosting, management or support may be given to a third party — as a separate appointment, preferably before any other appointed party is procured — or later transferred to an appointed party. In either case the appointing party should write a functional and non-functional specification. Which is worth remembering the next time a tender report says the contractor will bring the CDE: that only satisfies 5.1.7 if the environment already exists, can receive tender information, and will survive a later transfer of hosting without breaking the audit trail.

5.1.8 — the information protocol

The protocol is the appointment text that makes the CDE obligatory. The appointing party shall establish it, including associated licence agreements, and incorporate it into appointments. It must consider the parties' obligations for managing and producing information, including use of the project CDE; warranties and liabilities attached to the PIM; background and foreground intellectual property; use of existing asset information and shared resources; use of information during the project; and reuse after appointment or on termination.

A CDE that lives in the BEP but never reaches the protocol is a preference. Clause 5.1.8 is the step that turns it into an obligation.

5.2 to 5.4 — tender and appointment still run through the CDE

5.2.1 The appointing party establishes exchange information requirements for the prospective lead appointed party — the appointment-level EIR.

5.2.2 Reference information and shared resources are assembled for tender. The clause recommends they be made available in a secure environment such as the project CDE, and that each container carry a status code stating the suitability of that information for tendering organisations. Tender packs dumped on a file-share with no status are a 5.2.2 miss.

5.3.2 The pre-appointment BIM execution plan includes the delivery team's information delivery strategy, federation strategy, high-level responsibility matrix, and any proposed amendments to the project information standard and production methods.

5.3.5 The mobilisation plan must include configuring and testing the project CDE in accordance with 5.1.7, and configuring and testing any distributed CDE and its connectivity to the project CDE.

5.4.3 to 5.4.5 The lead appointed party writes EIRs for appointed parties (what, level of information need, acceptance criteria, dates). Each task team maintains a task information delivery plan listing each container: name, predecessors, level of information need, duration, author, milestones. The lead appointed party aggregates those into the master information delivery plan, baselines it, and tells the appointing party about risks to delivery milestones.

The TIDP and MIDP are the CDE's worklist. An environment that cannot list the containers the MIDP promised, in the states they have reached, is not serving 5.4.

5.5 Mobilisation — configure and test, do not assume

5.5.2 The lead appointed party shall configure and test the project CDE, and any distributed CDE, in accordance with 5.1.7; test exchanges between task teams; and test delivery to the appointing party. 5.5.3 tests the production methods and verifies that the container breakdown structure is workable.

If mobilisation never tested a state transition, a unique ID, a status change and a delivery into the appointing party's environment, the CDE was installed. It was not mobilised.

5.6 Collaborative production — check is not review

5.6.1 Check that reference information and shared resources are available. 5.6.2 Generate information. 5.6.3 Each task team quality-assures each container against the project information standard before reviewing content. Success is recorded; failure rejects the container and tells the author what to correct. The note in the clause matters: checks may be automated in the CDE; a compliance check still does not replace 5.6.4.

5.6.4 Review the information inside the container against the lead appointed party's information requirements, the level of information need, and what other task teams need for coordination. On success, assign the suitability for which the content may be used, and approve the container for sharing. On failure, record why, record the amendments, reject the container.

That is the Part 2 implementation of 12.3 and 12.4. Suitability gets assigned at the point of sharing, by a person, against a requirement — not chosen from a drop-down by whoever happened to be uploading at half past five.

5.6.5 The information model is reviewed as a model, not only as a pile of containers.

5.7 Information model delivery — authorise, then accept

5.7.1–5.7.2 Task teams submit the information model for lead appointed party authorisation. The lead appointed party reviews it against the MIDP, both sets of EIRs, acceptance criteria and level of information need. Success: authorise, and instruct submission for appointing party acceptance within the project CDE. Failure: reject and send it back. Partial acceptance of the MIDP set is discouraged because it creates coordination gaps; the recommendation is to authorise or reject the entire information model.

5.7.3–5.7.4 The appointing party reviews against the same kind of criteria and either accepts the model as a deliverable in the project CDE or rejects it. Same warning about partial acceptance.

Two signatures, one environment. A CDE with a single "approved" flag, drawing no distinction between lead-appointed-party authorisation and appointing-party acceptance, is flattening 5.7 into something the standard deliberately kept apart.

5.8 Project close-out

5.8.1 Archive the project information model. 5.8.2 Capture lessons learned. Archive here is the Part 1 12.7 state applied to the PIM at the end of delivery — the point at which a PIM is supposed to inform an AIM rather than vanish into a zip file on a leaver's laptop. ISO 19650-3 covers the operational phase and is a separate reading; the delivery CDE still has to hand over a model that can be found.

The UK National Annex is not the international text

BS EN ISO 19650-2 includes a UK National Annex, and it is informative national practice rather than clause 5.1.7. Vendor pages that present S0–S7 as "what ISO 19650 requires" are describing the annex, often the 2018 table, and calling it the standard.

What the annex actually does:

NA.2 / NA.3 recommend a unique-ID field order for UK projects (project, originator, volume/system, level/location, type, role, number), a hyphen delimiter, and standard codes for some of those fields. If a container leaves the CDE, status and revision should be suffixed onto the ID so the file still carries them.
NA.4.1 restates 5.1.7(c): status, revision and classification are attributes inside the CDE, not fields inside the unique ID.
NA.4.2 Table NA.1 is the UK status-code list. The 2018 table — the one most explainers still reprint — placed S0 in WIP; S1–S4 and S6–S7 in Shared (S5 already marked withdrawn); A and B codes in Published; and CR for as-constructed records. A February 2021 revision of the annex changed several of those codes. Do not learn the table from a vendor PDF dated from the first printing. Read the National Annex in the BS EN you hold, and fix the project information standard to that list, or to a documented project expansion of it (the annex allows expansion).
NA.4.3 recommends P revisions (preliminary, with a WIP version suffix) and C revisions (contractual). That is how Shared and Published stay distinguishable when a file is exported.
NA.4.4 points classification at Uniclass 2015 as the UK implementation of ISO 12006-2.
NA.5 recommends open formats for exchanges with the appointing party unless the information standard says otherwise — geometrical information, structured non-geometrical information (the UK text points at COBie / BS 1192-4), and documentation (PDF). That is national exchange practice, not a CDE product feature.

Other countries may publish their own annex, or none at all. A Gulf or European job that imports S0–S7 because a UK vendor template included them has adopted a national recommendation, not an ISO clause, and it should at least know that it has.

What the standard does not require

It does not require one commercial platform. It does not require four folders with those names. It does not require S-codes outside a national annex that chose them. It does not require BIM authoring, clash detection, or a model viewer — those may be good, and they are not in 5.1.7. It does not certify software. It does not replace the appointment, the information protocol, or the EIR.

It does require an agreed source, a managed process, containers that can be identified and retrieved, states with recorded transitions, suitability that is assigned rather than assumed, and information requirements that the CDE is there to satisfy.

All of that comes from Parts 1 and 2. ISO 19650-3 (operational phase), ISO 19650-4 (information exchange) and ISO 19650-5 (security-minded approach) carry their own requirements, and none of the clauses above stands in for them.

A Monday test

You do not need a consultant to see whether a claimed CDE meets the clauses above. Take one live container and one closed milestone, and give it half an hour with whoever administers the system.

Identity. Does the container have a unique ID whose fields come from a documented convention (5.1.7 a–b)? If you export it, do status and revision still travel with it?
Three attributes. Can you show status (suitability), revision, and an ISO 12006-2 classification as attributes, not as a comment in the filename (5.1.7 c; Part 1 12.1)?
State versus suitability. Name the state (WIP, Shared, Published, Archive) and the suitability separately. If you cannot, one badge is doing two jobs (3.3.13; clause 12).
Transition record. Who moved it between states, and on what date (5.1.7 d–e)? If the answer is "the upload", 12.3 and 12.5 have not happened.
Access. Can access be controlled on this container, not only on its folder (5.1.7 f)? Can other task teams see WIP (they should not, 12.2)?
Requirement. Which EIR, and which MIDP line, does this container satisfy (Part 1 clause 5; Part 2 5.4.4–5.4.5, 5.7)? If nobody can point to one, the CDE is not serving the cascade.
Tender and protocol. Was this environment available before the first invitation to tender (5.1.7 note)? Is use of it an obligation in the information protocol (5.1.8)?
Two signatures. For a Published deliverable, can you show lead appointed party authorisation and appointing party acceptance as distinct acts in the project CDE (5.7.2, 5.7.4)?
Archive. For a superseded published revision, can you name the organisations that received it, the state it was in and the date it went out, without anyone opening a personal mailbox (12.7; 5.8.1)?

Whatever you cannot answer is the clause you have not implemented. A shared drive with permissions typically fails 3, 4, 5, 6 and 9 before lunch. A well-sold platform that was never mobilised against 5.1.7 fails the same list with better graphics.

Who has to act, and what it costs

Almost none of this is the software's fault, and almost all of it is buyable. The appointing party is the party the clauses name, which means a client's project director — the one asking what they are actually buying — holds most of the levers.

Four of them are worth pulling before the next tender goes out. Write the functional and non-functional specification for the CDE that 5.1.7 asks for, rather than accepting a demo as a specification. Stand the environment up before the invitation to tender, and price the hosting as a separate appointment if that is what it takes to keep the audit trail across a later transfer. Put the information protocol into the appointments under 5.1.8, with a lawyer's eye on reuse and termination, because a preference in a BEP will not be enforceable when the delivery team demobilises. And fund mobilisation properly under 5.5.2 — a fortnight of somebody's time to test a unique ID, a state transition, container-level access and a real delivery into the client's environment, before the first drawing needs issuing.

Then stop accepting the answer that it is all in the platform. Ask a vendor, or your own team, to walk items 1 to 9 above on a live container while you watch. Half an hour, one screen, no slides. The clauses will do the rest of the arguing.