"CDE" gets used interchangeably with whatever software a project happens to be running, ProjectWise, BIM 360, Trimble Connect, a shared drive with some folders in it. That's a misreading worth correcting immediately, the same way "ISO 19650 is the BIM standard" needed correcting in the last lesson. A Common Data Environment isn't a product. ISO 19650-1 defines it, in clause 3.3.15, as an agreed source of information for a project or asset, used for collecting, managing, and disseminating each information container through a managed process. The emphasis sits on managed process. The software is just whatever tool happens to enforce that process on a given project. Two projects running completely different platforms can both be running a compliant CDE, and one project running an expensive platform badly can fail to have one at all.
This lesson covers what that managed process actually consists of: the four states every piece of information moves through, the finer-grained status codes that sit underneath those states in UK practice, and where the CDE's authority stops.
The unit the CDE manages isn't a file in the everyday sense. It's an information container, ISO 19650's term for any structured or unstructured set of information treated as a single, trackable thing, a model, a drawing, a spreadsheet, a report. Every container carries metadata, and the standard sets out what that metadata has to include at minimum: which state the container is in, a status or suitability code describing what it's currently fit to be used for, a revision, and a classification.
That last point matters more than it looks. A CDE isn't a passive archive that happens to have folders labeled by project stage. It's an active system that tracks where each container sits in a trust lifecycle, and that lifecycle is the actual subject of this lesson.
Every information container moves through up to four states, defined originally in BS 1192:2007 and carried into ISO 19650-1.
Work in Progress is where a container starts. Only the team producing it can see or touch it. Nothing here has been checked by anyone outside that team, and nothing here should be treated as fit for any purpose beyond the author's own drafting.
Shared is where a container goes once its own team has checked it internally and it's ready for other disciplines to see. This is a deliberately non-contractual state. Other teams can coordinate against it, design around it, flag problems with it, but nobody is entitled to treat it as final.
Published is where a container goes once it's been formally reviewed and authorized by the appointing party, or on their behalf. This is the first point at which the container becomes genuinely contractual, something the wider project is entitled to build from.
Archive holds every superseded version once a newer one replaces it, kept as a permanent, read-only record for audit and legal purposes.
The reason Shared exists as its own state, rather than skipping straight from private drafting to formal publication, comes down to timing. Without it, other disciplines would either have to wait for full sign-off before doing any of their own coordination, which is slow, or guess at unshared work, which produces expensive rework once real geometry finally appears. Shared lets coordination happen against real, current information before that information is guaranteed correct, and the explicit non-contractual label is what makes that safe. Not all information ever reaches Published. Some containers, an early planning sketch, a rough coordination pass, are genuinely disposable and never need to leave the Shared state at all.
The four states above are the international base standard. What most practitioners actually see stamped in a title block or a document register, codes like S2 or A1, comes from somewhere more specific: the UK National Annex to BS EN ISO 19650-2. This is worth being precise about, because the base ISO 19650 series itself only defines the four states. The detailed S, A, B, and CR codes are a UK addition, and other countries adopting ISO 19650 either build their own national annex or borrow the UK one informally.
Within the Shared state, the UK annex defines a progression of finer codes. S0 marks initial work still inside the authoring environment. S1 means suitable for coordination, other disciplines may design against it to check spatial fit. S2 means suitable for information only, shared for reference rather than active coordination, and it's the code seen most often in day-to-day practice. S3 means suitable for review and comment, the first formal step toward sign-off. S4 marks the point where a container goes to authorising individuals for stage approval. S6 and S7 apply specifically to whole model authorization rather than individual deliverables, suitable for PIM authorization and suitable for AIM authorization respectively.
Within Published, the codes shift from a trust gradient to a contractual record. A1, A2, and onward mark information formally authorized and accepted for a specific named purpose, and a container can hold more than one A-code at once for different uses, authorized for costing but not yet for construction, for instance. B1, B2, and onward mark partial sign-off, accepted with comments the recipient still needs to address.
Here's where it's worth being honest rather than tidy. The UK National Annex was revised in 2021, and guidance material written before and after that revision doesn't fully agree on two points: what S5 means, and whether CR still exists as a separate published code or was folded into the A-codes as a duplicate. Some sources still describe S5 as simply withdrawn and CR as a standalone as-constructed record code. Others, describing the 2021 revision specifically, describe S5 as repurposed for appointing party review and acceptance, with CR removed entirely. In practice, plenty of live projects still run on the pre-2021 definitions out of habit. The honest takeaway isn't to memorize one fixed table. It's to check the specific project's own information standard for which version it's using, because this is exactly the kind of detail a national annex is built to let projects pin down locally rather than assume globally.
The CDE's entire job is tracking where a container sits in a trust lifecycle: who can see it, what it's currently fit for, and whether it's been formally authorized. That's a real and valuable job. It is not the same job as checking whether the information inside that container is correct.
A structural model can carry a fully authorized A1 status code, meaning it's passed every review and authorization gate the project defined, and still contain a wrong volume on a specific element. Nothing in the CDE's own mechanics catches that, because the CDE was never built to look inside the container's actual content. It tracks the container's position in a process, not the truth of what's written on it. This is the same boundary the last lesson drew around ISO 19650 as a whole, showing up again at a more granular level: a container being Published and A1-coded tells you it was checked and signed off by the people responsible for checking it. It doesn't tell you their check caught everything, or that the underlying data was right to begin with.
A steel frame contractor is developing the primary structure model for a new warehouse. Early on, the model sits in Work in Progress, visible only to the contractor's own structural team, full of placeholder connections and unresolved member sizes.
Once the team has a coordinated first pass, they move it to Shared at S2, suitable for information, so the architect and the MEP consultant can see roughly where the steel sits without treating any of it as settled. A few weeks later, once connection design has firmed up and the model needs active coordination against the MEP routing, it moves to S1, suitable for coordination, and the MEP team starts designing duct runs around real steel geometry rather than a placeholder.
At the end of the design stage, the model goes to S4 for formal review by the project's authorising individuals. Once it clears that review, the appointing party authorizes it for construction, and it becomes Published at A1, the version the site team is now contractually entitled to build from.
Partway through construction, a late design change means a new revision is needed. The A1 version doesn't get deleted. It moves to Archive, preserved as a permanent record of what was authorized and when, while the revised model works back through WIP and Shared before reaching its own Published state.
At no point in that entire sequence did anything check whether the tonnage the model reports for a specific beam is the real tonnage. The CDE tracked exactly who could see the model and what it was authorized for, at every stage, correctly. Whether the numbers inside it were right the whole time is a separate question, sitting outside what any of this was built to answer.
Comments use a free GitHub account — takes under a minute to create, and keeps discussions spam-free and permanently archived.