Subscribe
Share
Share
Embed
Reimagining AEC is Dr Sepehr Abrishami's independent podcast on how the built environment handles information. Each episode takes one subject from digital construction, from the ISO 19650 series and the common data environment to the golden thread, soft landings and the arrival of artificial intelligence in design and surveying practice, and tells it as a single argument built on the published standards, guidance and evidence. Sepehr is a researcher and former architect who leads the Centre for AI in Construction and teaches building information modelling at master's level. The episodes are written for postgraduate students and practitioners who want the reasoning behind the rules, not a summary of them.
Of two copies of one drawing, only one may be relied on. Dr Sepehr Abrishami here, on Reimagining AEC. Blockchain, a branch of my research framework, keeps a single record that every party can trust, and in this episode I turn to a plainer answer to the same need, the common data environment, or CDE. A CDE is the set of workflows and tools through which a project using building information modelling, or BIM, develops, shares and keeps its information.
Consider two copies of the same general arrangement drawing. One carries the revision P zero two. The other carries C zero one. The second copy has the smaller number, yet it was produced later, and it is the only one of the two that the contract allows anyone to rely on. Even that copy may be used only for the purpose its status code records, and on this drawing that purpose stops short of construction. The drawing comes from the worked example in Guidance Part C of the UK BIM Framework, on facilitating the CDE, written by John Ford and published in 2020. A task team produces it. A task team is the group of people who carry out one specific task. The work falls in Stage 3, Spatial Coordination, of the Royal Institute of British Architects, or RIBA, Plan of Work 2020. I will follow the drawing from its first saved version to the moment it is published.
So the question for this episode is how a project makes it possible for anyone who opens an information container to tell which version it is and what it may be used for. ISO 19650-1 calls an information container a named, persistent set of information, so a drawing, a model and a letter all count. Answering that question builds four capabilities. The first two are a view of the CDE as a workflow before it is any software, and the vocabulary of the four states and the metadata a container carries. The third is the skill of reading and assigning revision and status codes under the current UK National Annex to ISO 19650-2. The fourth is a way of judging whether that metadata survives a move between systems.
One point of currency comes first. Guidance Part C was written to the 2018 version of that National Annex, which the British Standards Institution, or BSI, revised in February 2021 through a corrigendum to BS EN ISO 19650-2. Wherever the codes changed, I will give you the current ones and say so. As nima, formerly the UK BIM Alliance, announced in May 2025, the UK BIM Framework has since been renamed the IMI Framework. The name comes from the Information Management Initiative, which the Construction Leadership Council launched with nima's backing. Guidance Part C now sits among the framework's archived documents. The route runs in five steps. I start with what a CDE is and who provides it, then states and metadata, then the codes themselves. After that comes the drawing's full passage through them, and last what happens when a container crosses from one CDE solution into another.
Start with what a CDE is. Guidance Part C opens by correcting what it calls a potential misconception, that the CDE is more about technology than about workflows. Workflows, it says, are developed first, and solutions are selected to serve them. The guidance takes a broad view of what counts as a solution. On a sensitive project where digital methods are not permitted, a postal service and an organised cabinet of paper records can be the CDE solution, provided a workflow governs them. Most projects rely on electronic document management systems, but rarely on one tool alone. The guidance names document management for design files, contract management for commercial information, email management for correspondence and mobile tools for quality data from site. So when a client asks which CDE you use, the better answer begins with how information moves, and the product name comes later.
Who provides the solutions is the next matter. Under clause five point one point seven of ISO 19650-2, the appointing party, which is the client, establishes the project CDE, itself or through a third party acting for it. The companion UK guidance on the delivery phase, edited by David Churcher, Sarah Davidson and Anne Kemp and published in 2020, adds that the project CDE must be working before tender information is issued. A lead appointed party is the organisation that receives its appointment directly from the client and leads a delivery team. After appointment, hosting can pass to it, provided the CDE is functional before the transition. A delivery team is that organisation together with the organisations it appoints in turn.
ISO 19650-2 also allows delivery teams to run distributed CDEs of their own, as well as the project CDE but never in place of it. Our drawing shows what that looks like. The task team develops its model in a local solution. It shares the model through a solution that the lead appointed party manages for its delivery team. The accepted drawing then reaches the client's project CDE. That makes three solutions and one workflow, and it is the workflow that keeps the drawing's history in one continuous record. To follow that history, we need the language of states and metadata.
States and metadata come second. ISO 19650-1 describes four states, and Guidance Part C reproduces them. A container begins in work in progress, where only its author or task team can see it. To enter the shared state it must be checked, reviewed and approved, and it then becomes visible to other task teams, to other delivery teams or to the appointing party. To enter the published state it must be reviewed and authorised by the lead appointed party and then accepted by the appointing party. ISO 19650-1 names only review and authorisation at this point, and the acceptance step comes from ISO 19650-2. Published information may be used for more detailed design, for construction or for asset management. The fourth state, archived, is not a step in that sequence. It runs alongside the other three as a journal of every transaction, so that a container's development can be audited later. The guidance adds that a container can cycle between work in progress and shared many times before it is published, and our drawing will do so more than once.
The guidance makes the states easy to remember with an email. Drafting it is work in progress. If the message is sensitive and your manager approves it before you press send, that is close to the shared state. Sending it to its proper recipient is publishing it, and both mail tools archive each step of the trail. From this the guidance suggests that any correspondence with a contractual implication, including email, is always managed through the CDE using the same states. Keep one more feature of email in mind, because it returns when our drawing changes systems. Messages pass between different mail tools because the providers adopted a standard exchange protocol.
The states describe where a container is. Metadata tells every user which state that is, and what the container may be used for. The ISO 19650 standards give no formal definition of metadata, so Guidance Part C borrows a dictionary definition, a set of data that describes and gives information about other data. On that definition the container's unique identifier is itself metadata. ISO 19650-1 recommends two further items, a revision code and a status code, and ISO 19650-2 requires the CDE to support both and a third, a classification code. The guidance is firm that these codes sit alongside the unique identifier, never inside it, because metadata is how authors keep strict control of their information while it develops. In its example from a cloud-based system, a first floor plan carries status S three and revision P zero four beside its name, with a description, an author, a submittal date and a classification code.
Four of the unique identifier's seven fields were renamed in 2021. Volume or system became functional breakdown, level or location became spatial breakdown, type became form, and role became discipline. The fields are still separated by a delimiter, in a fixed order. Read in that order, the guidance's example gives the project as seven zero zero one and the originator as B B H. The functional and spatial breakdowns are both Z Z, the form is D R, the discipline is A, and the number is zero zero three zero one. The values come from the project's codification standard, the agreed list of permitted values for each field, not from an earlier project. One rule matters for our drawing. An export, such as a Portable Document Format, or PDF, copy or an Industry Foundation Classes, or IFC, file, needs an identifier of its own, distinct from its native source.
Classification must follow ISO 12006-2, the international framework for classifying construction information. In the UK the preferred system is Uniclass, published by NBS, which complies with that framework and which the guidance calls Uniclass 2015. The appointing party sets the method in the project's information standard, its rules for how information is named, coded and exchanged, including which sets of Uniclass codes apply. Where the client has no preference, the lead appointed party defines it. Classification should describe what a container holds, not what kind of container it is, because the form field already records that. Uniclass is also updated regularly, so the detail available may shift during a project. Used consistently, it lets every user filter, for instance to see only design drawings. So four items travel with every container, and two of them, the revision and the status, carry most of the answer to our question.
Third come the revision and status codes, starting with the revision code. It has three parts, and the 2021 annex keeps them as they were. The first is a letter, P for preliminary information, which is not contractual, or C for contractual information. Next come two digits, the primary revision, which will eventually be shared beyond the task team. After a point come two more digits, the work in progress version of that revision. So P zero one point zero one is the first working version of the first preliminary revision. The guidance explains the version digits with a small story. You draw a square, fill it with a texture, change the fill to a solid colour, and then draw a circle instead. Then you decide you wanted the textured square after all. Without version control you start again. With it, you revert to P zero one point zero two and amend that.
When the container is ready to leave the task team, it is shared as P zero one, and the version digits fall away. Comments come back, the team decides to develop the container further, and work resumes at P zero two point zero one. That cycle can repeat, and in the guidance's general account P zero three is the revision shared for authorisation, although the worked example is authorised at P zero two. Only when the lead appointed party has authorised the container and the appointing party has accepted it does the letter change from P to C, giving C zero one. Contractual revisions keep a count of their own, starting again at zero one, which is why the later copy in the opening carries the smaller number. Not every container makes that change. A structural geometrical model used only for coordination may stay preliminary, while the drawings and schedules generated from it are needed for appointment and contract purposes.
The revision code tells you which version you hold. The status code tells you what you may do with it, and by extension what you may not, and it shows where the container sits in the workflow without separate folders. Older practice under BS 1192 of 2007 and PAS 1192-2, where PAS stands for Publicly Available Specification, divided a CDE into areas held in separate folders. That language now belongs to history.
The current status codes rest on three principles. The first is that a single code, S zero, marks work in progress, for use inside the task team only. The second is that each shared code states the response the author wants. S one, S two and S three share a container for coordination, for information, or for review and comment, and none permits contractual use. In the 2021 annex, S four asks the lead appointed party to review and authorise, and S five asks the appointing party to review and accept. The third is that publication carries its own letter. The A codes mark information that has been authorised and accepted and carries a contractual revision, and the B codes, once used for partial sign-off, are deprecated. Guidance Part C prints the 2018 codes, which you will still meet on older projects. There, S four meant stage approval, S five had been withdrawn, and S six and S seven covered authorisation of the project information model and the asset information model. Remember too that a status code is not a purpose of issue, although information issued for construction should always carry a published status code. Read together, the revision says which version you hold, and the status says what that version is for.
Now the drawing itself, followed through the steps the guidance numbers from nought to eighteen. The story begins with the model. A task team appointed at Stage 3 collates its reference information and starts producing a geometrical model. By step two the model is at P zero one point zero five with status S zero, and it passes a quality assurance check of the container, not its contents, against the information standard. At steps three and four the team shares it as P zero one with status S one, suitable for coordination only, through the lead appointed party's solution. The delivery team then coordinates it with the other models. The team has decided not to export drawings until that review is complete.
At step five the model returns to work in progress as P zero two point zero one, and the general arrangement drawing is exported. From here the codes follow the drawing, which begins at P zero one point zero one with status S zero. At steps seven and eight it is shared as P zero one with status S three, directly to the lead appointed party, because it is issued for comment rather than coordination. The lead appointed party comments and asks for a reissue for authorisation.
From here I have updated the codes to the 2021 annex, because the guidance used S six, S four and A three at these points. At steps nine and ten the team updates the model and re-exports the drawing as P zero two point zero one. At steps eleven and twelve the drawing is shared as P zero two with status S four, and the lead appointed party reviews it against the appointment requirements and authorises it. At steps thirteen and fourteen it goes to the appointing party with status S five and is accepted. The guidance adds that the lead appointed party may issue directly to the client on the task team's behalf, where the task team gives permission and the CDE records it.
Because the drawing itself must now show a contractual revision, it returns briefly to work in progress as P zero three point zero one. After its check it is published as C zero one with an A code. The guidance used A three, tying the number to the project stage, but under the current annex the meaning of that number comes from your project's information standard. At step eighteen the drawing serves Stage 4, as reference information or by returning to work in progress at the next preliminary revision with status S zero. Notice what the codes would cost if they lived only as text on the sheet. The guidance points out that a printed status means more work in progress every time it changes, while a status held as metadata changes without touching the drawing.
The fifth and last step returns to the email. The drawing has passed through three solutions, and its metadata had to survive each crossing. When Guidance Part C was written, construction had no equivalent of the email protocol in common use, so moving a container between CDE solutions often meant entering its metadata again by hand. The guidance shows the difficulty with two solutions. In its account, one lead appointed party's distributed CDE keeps every container in one group, holds status, revision and classification in separate fields, and lets users filter by any of them. An appointing party's project CDE mixes folders with metadata and has no classification field, so the client uses folder names to carry classification. Some fields, such as the author and the submittal date, do not transfer at all. If the client's solution worked like the one in the guidance, our drawing's classification would become a folder name, and part of its record would stay behind. The guidance's advice is to agree, before any transfer, how each item of metadata will be kept or accommodated, and to make folders complement the metadata rather than duplicate it.
Since then, buildingSMART International's Documents API, where API stands for application programming interface, a standard for sharing documents across software platforms, reached final standard status in December 2023. Check whether your solutions support it, and test the transfer either way. The episode on open data and buildingSMART takes that organisation's work further.
The guidance's closing checklist reduces to three things a project settles before work begins. The first is agreement on codes and names. The appointing party defines the status, revision, classification and identifier codes in the project's information standard, under clause five point one point four of ISO 19650-2. Each lead appointed party reviews and agrees them. Exports are named apart from their native containers, so that no two containers share an identifier. Every update to a native file is carried through to its exports, as the PDF copy of our drawing requires. The second is proof that the software can carry the workflow. Every candidate solution is checked for the agreed metadata. Access can be set for individuals and for organisations, which links to the security-minded approach of ISO 19650-5, published in 2020. Where several solutions run one workflow, the metadata transfer is tested and the route, manual or automatic, is agreed. The third is a written workflow for each type of container, from development through checking, sharing, authorisation, acceptance and publication to archiving. Documented methods and procedures under clause five point five point three back it, showing how each code is assigned in each solution. With those three settled, the drawing's metadata arrives in the client's CDE meaning what it meant when it left the task team.
That completes the drawing's passage, and with it the answer to the question I opened with. A project makes the right version recognisable by holding revision and status codes as metadata on every container. A workflow moves each container from work in progress to shared to published, while the archive records each step. P zero two is a preliminary revision, shared so that the lead appointed party and the client could make their decisions. C zero one, with its A code, has been authorised, accepted and published. Only C zero one may be relied on, and only for its Stage 3 purpose, as reference for the work that follows rather than as an instruction to build.
Begin any CDE with the workflow, choose the software to serve it, and settle how metadata will cross between solutions before anything moves. Read every container by its state, with the archive running beside the states and keeping the trail an audit will ask for. Treat revision and status codes as metadata rather than folder names or text on a sheet, and set them to the 2021 National Annex, keeping the 2018 codes for reading older projects. On currency, BSI opened revised drafts of ISO 19650 Parts 1 and 2 for UK public comment in March 2026, as nima reported at the time. The 2018 editions stay in force until new ones are published.
For reading, start with Guidance Part C by John Ford, 2020, beside ISO 19650-2 with its 2021 National Annex, which supersedes the codes the guidance prints. The episode on parties, teams and processes in the delivery phase follows authorisation and acceptance from the client's side, and the episode on information delivery planning shows where a container's delivery date is first promised.
When you next inherit a set of project files, at work or in a research dataset, pick one container and see how much of its history its codes alone can tell you. I make that suggestion in my own name, Dr Sepehr Abrishami, as host of Reimagining AEC.