10. Connected CDEs and ISO 19650: Compliance Across Multiple Platforms
An ISO 19650 connected CDE is an arrangement in which two or more Common Data Environments (CDEs) operate as a single information management process, with the state of every information container preserved as it crosses between them. The standard sets out how information is produced, checked, reviewed, approved and authorised. It does not require that all of it happens inside one product.
Multiple platforms on one project is the ordinary situation in Architecture, Engineering, Construction and Operations (AECO) delivery. A client mandates one CDE, a joint venture partner runs another, and a design consultant works in a third. Compliance then depends on what survives the boundaries between them.
This article covers:
What ISO 19650 requires of a CDE
The information container and its attributes
The four CDE states and what each one signals
Suitability codes and revision codes
What commonly fails at a platform boundary
What to specify in the exchange information requirements
What ISO 19650 requires of a CDE
ISO 19650 requires an agreed source of information for a project or asset, together with a defined workflow for collecting, managing and disseminating information containers through it. The requirement is a process with defined states, defined transitions and defined responsibilities.
The standard does not name a product, certify software or require a particular file format. A platform can be built to support the workflow well or badly, but the compliance obligation sits with the appointing party and the appointed parties. The vendor carries none of it.
Utopia Digital holds a board position at buildingSMART Australasia, and the openBIM position taken there is consistent with the standard's own approach. Information is managed by its attributes and its state, not by the software that happens to hold it.
The information container and its attributes
ISO 19650-1 defines an information container as a named persistent set of information retrievable from within a file, system or application storage hierarchy. A federated model, a drawing, a schedule, a specification and a folder can each be an information container.
What makes a container manageable is its attributes. ISO 19650-2 expects a structured identifier assembled from fields covering project, originator, functional breakdown, spatial breakdown, form, discipline and number, with revision, status and classification held as separate attributes. Folding them into the filename loses that structure.
Those attributes are the compliance surface. Two containers holding identical geometry are different obligations if one is at a review status and the other is authorised, and only the attributes carry that difference. Large public sector projects routinely require in excess of a hundred individual metadata fields per document, so the surface being carried across a boundary is substantial.
The four CDE states and what each one signals
ISO 19650 describes four states in the CDE workflow, and each transition between them is a controlled act.
Work in progress holds information owned by a single task team, developed under its own internal checks and not visible to anyone else. Shared holds information that the task team has checked, reviewed and approved for others to use, subject to a status code that limits what it may be used for. Published holds information that the appointing party has authorised, and construction and procurement decisions should be taken from this state alone. Archive retains everything that came before, including superseded revisions and the journal recording who moved what, when and on whose authority.
The workflow depends on those states remaining distinguishable to everyone using them. Where a receiving platform infers state from which folder a file happens to sit in, the distinction is held by convention alone and nothing enforces it.
Suitability codes and revision codes
A status code, still widely called a suitability code, tells the recipient what a container may be used for. Under the national annex convention to BS EN ISO 19650-2, which many Australian and UK projects adopt through a client template, S codes cover work in progress and shared information: S0 for an initial status, S1 for suitable for coordination, S2 for suitable for information and S3 for suitable for review and comment. A and B codes cover published information, with A for authorised and B for authorised with comments outstanding.
Revision codes carry the other half of the meaning. The same convention uses P01, P02 and onwards for preliminary revisions and C01, C02 and onwards for contractual revisions. C01 at status A2 places a different obligation on the recipient from P04 at status S2, and a system that preserves one attribute while dropping the other has carried half a container state across.
The base ISO 19650 text does not itself prescribe these code sets. Australian projects vary in which national annex or client template they adopt, so the mapping between two platforms has to be written against the codes the project is actually using.
Multiple CDEs on one project under ISO 19650
Most teams ask whether their platform is ISO 19650 compliant. The standard describes a process and a set of states rather than a product, so the question has no answer at the level it is asked.
Under ISO 19650 at BIM Stage 2, the level at which most projects operate, multiple CDE solutions are permitted on a single project. Only Stage 3 envisages one unified collaborative CDE, and few projects have reached that maturity. A mixed estate is therefore a compliant arrangement rather than a deviation to be explained.
The question that carries the compliance risk is narrower. Does the state of an information container survive the boundary between one platform and the next? An ISO 19650 connected CDE is working when the answer is yes for every attribute the project relies on.
What commonly fails at a platform boundary
Suitability codes with no equivalent field. The sending platform holds suitability as a controlled list and the receiving platform holds a free text box or nothing at all. The value is dropped without warning and the container arrives with no statement of what it may be used for.
Revision codes flattened into filenames. The revision survives only as characters in a string, so nothing on the receiving side can sort, filter, report or validate on it.
Approval history that does not travel. The reviewer, the date and the revision approved against stay inside the sending platform's review module, and what crosses is a file with no evidence of authorisation attached.
Container identifiers regenerated on receipt. The receiving system mints its own document number, the link between the two records breaks, and the audit trail ends up in two halves that nobody can rejoin later.
Work in progress crossing by default. A folder level connection configured without reference to the CDE states exposes unchecked work to parties who are entitled to see shared information only.
Volume turns each of these into a systemic problem. A large infrastructure project moves 50 to several thousand models and documents a week between CDEs, which is well past the point where manual correction is realistic. NIST put the cost of inadequate software interoperability in the US capital facilities industry at US$15.8 billion a year, two thirds of it borne by owners and operators during operations and maintenance.
Preserving the four CDE states across a platform boundary
What to specify in the exchange information requirements
The exchange information requirements are where a boundary is controlled, and the information manager should be explicit. Name the CDE solutions in use and identify each boundary between them. State that container identifiers are preserved on receipt and never regenerated. Provide the status code map between platforms, including the behaviour when no equivalent field exists, and set holding the container back as the default where no equivalent field exists.
Require revision codes to sit in a queryable metadata attribute as well as in any filename convention, and require authorisation events to cross as metadata so they do not stay locked inside a review module. Name the party that owns each boundary and state where its audit log is held. Then require a test drop of representative containers before the first real exchange. How to Validate a CDE Migration (and Prove the Record Came Across) sets out a validation method that transfers directly to this purpose, and the field level detail of what each platform supports is in ISO 19650 Metadata Compliance Across Multiple CDEs: What the Tools Actually Support.
All of this belongs at EIR and BEP stage, well before the first data drop. Boundary rules written before mobilisation are inexpensive. Reconstructing three months of status and revision history by hand while the design programme continues is not, and the work falls on the document control team at the point they have least capacity for it.
Does ISO 19650 allow more than one CDE on a project?
Yes. At BIM Stage 2, the level most projects operate at, multiple CDE solutions are permitted on a single project. The obligation is that the CDE workflow and the four container states operate consistently across whichever solutions are in use, and that the appointing party can see the state of any container regardless of where it is held.
What happens if a suitability code has no matching field in the other CDE?
The mapping has to decide, and the decision belongs in the exchange information requirements, where an information manager makes it deliberately. The safer default is to hold the container back, because a container with no status sitting in a shared area tends to be read as usable. Adding a custom field on the receiving side is the better fix.
How do you prove an ISO 19650 connected CDE is working?
Sample containers on both sides of the boundary and compare them attribute by attribute: identifier, revision, status, originator, date and approval record. Run the comparison on a test drop before go-live and on a schedule afterwards. Automated audit logs from the connection layer provide an evidence trail that a manual spot check cannot.
CDE Sync™ maps metadata between platforms with different schemas and preserves version history and workflow state across the connection, with automated audit logging behind it for compliance reporting. Background material on ISO 19650 and CDE workflows sits in our learning resources. For a boundary review against your own exchange information requirements, get in touch.