Before any information is produced, someone has to say what they need.

That's what the information requirements chain is for. It runs from the broadest organisational level down to the specific exchange between parties on a project. Each layer feeds the next.

OIR — Organisational Information Requirements

The highest level. Defines what information an organisation needs to manage its portfolio of assets effectively. This sits within the client or asset owner's business. It's strategic, not project-specific.

Example: A hospital trust needs to know room areas, material specifications, and M&E system locations for every building it operates. That's an OIR.

PIR — Project Information Requirements

Breaks the OIR down for a specific project. Defines the information the appointing party needs at key decision points during design and construction. Milestone-driven.

Example: At RIBA Stage 3, the client needs confirmed floor areas, structural grid, and cost plan data to make a go/no-go investment decision. That requirement belongs in the PIR.

AIR — Asset Information Requirements

The operational twin of the PIR. Defines what information the client needs to operate and maintain the asset once it's built. It's the specification for the handover model.

Example: For every piece of mechanical plant, the AIR might require: manufacturer, model number, maintenance schedule, warranty period, and O&M manual reference.

EIR — Exchange Information Requirements

The contractual mechanism. Sits inside the appointment documents. Translates the OIR, PIR, and AIR into specific, enforceable requirements: who produces what, when, in what format, and to what level of detail.

If the EIR is absent or vague, the rest of the chain collapses. No team knows what they're actually being asked to deliver.

The chain in plain English:

OIR → "Here's what our organisation needs"

PIR → "Here's what this project needs at key decisions"

AIR → "Here's what the asset needs for operations"

EIR → "Here's exactly what you're contracted to deliver, and when"

ISO19650 defines three types of party. Get these confused, and the responsibility chain breaks down completely.

Appointing Party

The client, or whoever is commissioning the work. They set the information requirements (via the EIR), appoint the lead appointed party, and ultimately accept or reject the information delivered.

They don't produce information. They define what information they need, and they hold others accountable for producing it.

Lead Appointed Party

Usually, the main contractor or lead consultant. whoever has the primary appointment from the client. They are accountable for coordinating the information delivery process across the entire delivery team.

Their responsibilities include: establishing the post-contract BEP, managing the MIDP, coordinating all appointed parties, reviewing information before it goes to the appointing party, and managing the CDE.

On a typical design project, this is often the architect. On a D&B project, it's usually the contractor.

Appointed Party

Everyone else on the delivery team. structural engineers, MEP consultants, specialist subcontractors. Each appointed party is responsible for producing and delivering their own information in line with the BEP and their TIDP.

They report to the lead appointed party, not directly to the client.

Why this matters:

It's a clean chain of custody for information. The appointing party defines requirements → the lead appointed party coordinates delivery → appointed parties produce information. When something goes wrong — a model clash, a missed deliverable, a naming violation - you know exactly who is accountable at each level.

Part 2 defines an 8-step process for managing information during the delivery phase. These steps aren't optional extras — they're the backbone of a compliant project.

Step 1 — Assessment and Need

The appointing party assesses their information needs and establishes the OIR, PIR, and AIR. They prepare the EIR and decide on the appointing party's information standard and the CDE solution they'll use.

This is where the project's information foundations are set. A weak EIR at this point creates problems at every subsequent step.

Step 2 — Tender

Prospective lead appointed parties respond to the EIR with a pre-appointment BEP. This is their proposal for managing information delivery. Their approach, team capability, proposed CDE, and mobilisation plan.

The pre-appointment BEP is evaluated as part of the tender assessment. Information management capability is a procurement criterion, not an afterthought.

Step 3 — Appointment

Contract awarded. The information standard and information protocol are embedded in the appointment documents. The EIR becomes contractually binding.

Step 4 — Mobilisation

Before any production work starts, the delivery team gets set up properly. The CDE is established and tested. Naming conventions are agreed. The BEP is updated to post-appointment status. TIDPs are drafted. Everyone is trained.

Mobilisation is where most teams cut corners - and where most information management problems start.

Step 5 — Collaborative Production

The actual work. Information is produced in WIP, checked, shared for coordination, reviewed, authorised, and published. This step runs in cycles throughout the project.

Step 6 — Information Model Delivery

The delivery team submits the project information model to the appointing party for acceptance. This happens at key project milestones (RIBA stages, gateways, etc.).

Step 7 — Project Close-out

Final deliverables are locked. The project information model transitions to the asset information model. The archive is frozen. The CDE audit trail is preserved.

Step 8 — Asset Information Management (Part 3)

The handover to facilities management. The asset information model becomes the operational reference for the building's lifecycle.

Most projects stop at Step 7. That's the gap ISO19650 Part 3 exists to close.

The BIM Execution Plan is where the standard stops being abstract and starts being real.

There are two versions. They're not the same thing, and conflating them is a common mistake.

Pre-Appointment BEP

Produced before the contract is awarded. Written by the prospective lead appointed party as part of their tender response.

It's a proposal, not a commitment. It says: "If you appoint us, here's how we'll manage information delivery."

It typically covers: team capability and capacity, high-level approach to the CDE, proposed standards and methods, and a preliminary responsibility matrix.

Post-Appointment BEP

The live document. Developed after appointment, kept current throughout the project.

This is your project's operating system. It defines, in enforceable detail:

- Who manages information (the information manager and their team)

- The standards, methods, and procedures the delivery team will follow

- Naming conventions and their specific codes for this project

- CDE structure, access controls, and workflows

- Software and file format requirements

- Level of Information Need at each project stage

- Coordination process and clash detection approach

- Model and drawing responsibility matrix

- Information delivery milestones (the MIDP)

- Approval and authorisation workflows

A good BEP eliminates tribal knowledge. A bad one is a placeholder document that nobody reads after it's written.

The test: hand your BEP to a new team member on day one. If they can understand what they're supposed to produce, in what format, by when, and where it goes — your BEP is working. If they need six conversations to figure it out, it isn't.

The BEP tells everyone how information will be managed. The MIDP and TIDP tell everyone what information will be produced and when.

TIDP — Task Information Delivery Plan

Every appointed party (structural engineer, MEP consultant, etc.) produces a TIDP. It's their individual schedule of deliverables — every model, drawing, document, and data set they're responsible for producing. For each item, the TIDP records: what it is, who produces it, what format it comes in, what Level of Information Need applies, and when it's due.

MIDP — Master Information Delivery Plan

The lead appointed party consolidates all TIDPs into a single MIDP. It becomes the master schedule for everything the delivery team will produce — the single source of truth for information delivery across the project.

The 2026 update:

Under the proposed revisions, MIDP and TIDP are being consolidated into a single document called the Information Production Schedule (IPS). The concept remains the same — a scheduled list of what gets produced, by whom, and when. The document gets simpler.

This is where most teams either get it right or get it completely wrong.

Good naming is not bureaucracy. It's clarity. A correctly named file tells you exactly what it is, who made it, where it lives in the project, and what it's for — without asking anyone.

A wrongly named file creates a question. And questions at scale create chaos.

The ISO19650 naming structure:

```

[Project]-[Originator]-[Volume/Function]-[Level/Location]-[Type]-[Role]-[Number]-[Suitability]-[Revision]

```

Formatting rules — non-negotiable:

- Separate fields with a hyphen ( - ) only

- Never use a hyphen inside a field — use an underscore ( _ ) if you need to separate words within a field

- Use a dot ( . ) only before the file extension

- No spaces in file names

- No special characters

- Keep the total length under 260 characters

- The file name must be self-describing — it should not rely on the folder it sits in to make sense

Breaking down each field:

[Project] — 2 to 6 characters. The project identifier. Should be consistent across all parties and independent of any individual firm's internal project code. If you're on a multi-firm project, this code is set by the appointing party.

Example: KSTN (Kensington Station), MTC01 (Manchester Tower Contract 1)

[Originator] — 2 to 6 characters. The organisation that created the file. Each firm on the project has a unique originator code defined in the BEP.

Example: ARC (Architect), BIMCP (BIMcopilot), WSP

[Volume/Function] — Divides the project spatially or functionally. On a single building, this might represent a wing, phase, or building within a masterplan. Use ZZ when the content applies to the whole project.

Example: ZZ (whole project), A (Block A), PH1 (Phase 1)

[Level/Location] — The spatial location within the building. Uses a 2-digit code per the project's spatial breakdown structure. 00 typically means not level-specific or applies to all levels.

Example: 00 (all levels / not level-specific), 01 (Ground Floor), B1 (Basement 1)

[Type] — What kind of information container this is. Standard codes include:

| Code | Meaning |

|------|---------|

| DR | Drawing |

| M3 | 3D model |

| M2 | 2D model |

| SH | Schedule |

| SP | Specification |

| RP | Report |

| CA | Calculation |

| CO | Correspondence |

| BQ | Bill of Quantities |

[Role/Discipline] — The discipline responsible for the content. Standard codes include:

| Code | Discipline |

|------|-----------|

| A | Architecture |

| S | Structural Engineering |

| M | Mechanical Engineering |

| E | Electrical Engineering |

| P | Plumbing |

| C | Civil Engineering |

| L | Landscape |

| X | General / Multi-discipline |

[Number] — A sequential number, 4 to 6 digits, zero-padded. Assigned when other fields alone don't distinguish between information containers of the same type.

Example: 0001, 0042, 001500

[Suitability] — The status code. Indicates the current state of the information and what it can be used for. This is where S-codes come in (covered in detail in the next section). Optional in the file name but often included.

[Revision] — Tracks iteration within a status. WIP and Shared use preliminary revisions (P01, P02…). Published information uses contractual revisions (C01, C02…).

A complete example:

```

KSTN-ARC-ZZ-01-DR-A-0047-S2-P03.pdf

```

Decoded:

- KSTN — Kensington Station project

- ARC — Architect as originator

- ZZ — Applies to the whole project / not zone-specific

- 01 — First floor

- DR — Drawing

- A — Architecture discipline

- 0047 — Sequential number 47

- S2 — Shared for coordination (S2 status)

- P03 — Preliminary revision 3

Anyone on the project — from the site manager to the client's PM — can decode that file name without opening it. That's the point.

Status codes are how you control the movement of information through the CDE. They communicate, at a glance, what an information container is authorised for at any given moment.

These are defined in the UK National Annex to ISO19650-2, Annex A. They apply across the WIP → Shared → Published → Archive workflow.

Work in Progress:

| Code | Meaning |

|------|---------|

| S0 | Work in Progress. Draft only. Not for sharing outside the authoring team. |

Shared (Non-Contractual):

| Code | Meaning |

|------|---------|

| S1 | Shared for information and reference. Other teams can see it, but it's not for coordination use. |

| S2 | Shared for coordination and development. Other disciplines can use this as a geometrical or data reference for their own work. |

| S3 | Shared for review and comment. Seeking feedback before formal sign-off. |

| S4 | Shared for approval. Issued to the authorising party for final sign-off before publication. |

| S5 | Withdrawn. No longer in use. |

| S6 | Shared for sign-off prior to Project Information Model issue. Typically applied to models before handover at project completion. |

| S7 | Shared for sign-off prior to Asset Information Model issue. Applied before handover to facilities management. |

Published (Contractual):

Published information uses different codes that indicate its authorised use:

| Code | Meaning |

|------|---------|

| A | Authorised for construction |

| B | Authorised for tender / procurement |

| D | Authorised for design use |

Revision codes run in parallel:

- Preliminary revisions (in WIP and Shared states): P01, P02, P03...

- Contractual revisions (in Published state): C01, C02, C03...

The revision code resets to C01 the moment information moves from Shared to Published.

Why this matters in practice:

Without status codes, a contractor has no idea whether the drawing they're looking at is a preliminary coordination issue or an approved-for-construction release. That ambiguity costs money. Status codes eliminate it.

The Common Data Environment is not a software product. That's the most important thing to understand about it.

The CDE is a workflow. It's the defined process by which information moves through four states: Work in Progress → Shared → Published → Archive.

The software platform you use to host it — Asite, BIM 360 / ACC, Autodesk Docs, Revizto, SharePoint, ProjectWise, or anything else — is just the technical solution that facilitates the CDE workflow. The workflow is what ISO19650 specifies. The platform is your choice.

The four states in detail:

Work in Progress (WIP)

Information is live, being actively created or revised. It lives in the task team's own space within the CDE. Other disciplines cannot see it — or shouldn't be able to. No approval needed. No gatekeeping. This is the scratchpad.

The WIP state is the only state where information is editable. Once it leaves WIP, it should be read-only.

Shared

Information that has passed internal checking and is ready for use by other task teams. Moving from WIP to Shared requires a deliberate approval — a quality check within the authoring team. Shared information is read-only.

Different S-codes define the level of sharing. S1 is informational. S2 is for coordination. S3 is for review. S4 is for final approval. The information can move back and forth between WIP and Shared multiple times as coordination evolves.

Published

Formally authorised information — contractual, locked, and issued for a specific purpose (construction, tender, client approval). Moving from Shared to Published requires authorisation from the lead appointed party (and sometimes the appointing party).

Published information does not get edited. If something changes post-publication, a new revision is issued — which means back through WIP and Shared before a new published issue.

Archive

The audit trail. Everything significant in the project's information history is frozen in the archive. Published information at milestones, project history, metadata, decision records. Nothing is deleted. Nothing is edited.

The archive is the legal record. In a dispute, it's what you point to.

The gated workflow:

WIP → Shared requires: internal discipline check and approval

Shared → Published requires: lead appointed party authorisation (and potentially appointing party acceptance)

Published → Archive requires: verification at milestone close

A messy CDE is a sign of a project that's in trouble. When files sit in WIP indefinitely, when Shared folders contain outdated versions, when Published releases aren't locked — coordination breaks down, RFIs spike, and blame gets distributed liberally.

A clean CDE means the right information is always in the right place. Everyone knows what they can use and what they can't. That's not a nice-to-have. That's project survival.

This is one of the most misunderstood shifts in ISO19650.

For years, BIM projects used LOD (Level of Detail or Level of Development) and LOI (Level of Information) — typically on a scale of 100 to 500 — to define how much information an element needed to contain at any given stage.

ISO19650 replaces these with Level of Information Need (LOIN).

The shift isn't just terminological. It's conceptual.

LOD and LOI were supply-side thinking. They defined what the model contained. The problem was that different organisations used different LOD scales, applied them inconsistently, and the number on the model rarely matched the actual information quality inside it.

LOIN is demand-side thinking. Instead of saying "this model should be at LOD 350," it asks: "What information do you need, and why do you need it, at this specific point in time?" The requirement is driven by the use case. A design decision, a coordination check, a planning submission, a cost plan. Not by a generic numeric scale.

Under LOIN, information requirements are defined across three dimensions:

Geometry — The spatial accuracy and detail of the 3D representation. How precisely does this element need to be modelled in space?

Alphanumeric (Non-Graphical Information) — The data attributes attached to the element. What properties, values, and metadata does it need to carry?

Documentation — Any supporting documents associated with the element: specifications, certificates, test reports, O&M manuals.

The EIR should specify LOIN requirements for each key deliverable at each project stage. And critically — LOIN requirements should be no more than what's needed. Over-specifying information need wastes time and money.

Practical example:

At RIBA Stage 2 (Concept Design), a structural column might need:

- Geometry: Approximate size and position in space (±150mm accuracy)

- Alphanumeric: Material type, approximate load capacity

- Documentation: None required yet

At RIBA Stage 4 (Technical Design), the same column needs:

- Geometry: Precise dimensions, section profile, connection details

- Alphanumeric: Full specification reference, fire rating, finish

- Documentation: Structural calculation reference

Different stages. Different needs. LOIN makes this explicit rather than implied.

Classification is the invisible layer that makes information useful at scale.

ISO19650 requires that information is classified in accordance with ISO12006-2. The international standard for the organisation of information about construction works. It doesn't specify which classification system you use. That's decided by the national annex applicable to your project.

Uniclass 2015:

Used in the UK. A unified classification system covering all construction sectors. Organised into tables that classify work results, entities, activities, products, and more. Required by the UK National Annex to ISO19650-2.

OmniClass:

Used in North America. Also compliant with ISO12006-2. Organised into 15 tables covering different aspects of the built environment.

Why classification matters:

Without classification, information containers exist in isolation. With it, you can aggregate, query, filter, and report across the entire asset. Every room, system, component, and activity sits within a defined taxonomy. That taxonomy is what makes the model useful in operations, not just in design and construction.

Classification codes typically appear as metadata on information containers and on model elements. In a well-structured project, they're also embedded in the naming convention.

Most teams skip Part 5 entirely.

For certain projects, that's not a mistake, it's a liability.

ISO19650-5 addresses the security risks that come from digitising information about built assets. When you create a detailed BIM model of a hospital, a data centre, a government building, a power plant, or a transport hub, you're also creating a detailed intelligence document about that asset.

The standard requires organisations to treat information security as a deliberate management function, not an afterthought.

The core framework:

Built Asset Security Strategy — The organisation's overarching approach to managing information security risks across its asset portfolio.

Sensitivity Assessment — Before a project starts, classify the information it will generate: is it sensitive? Could it be used to cause harm if it fell into the wrong hands? What threat level applies?

Built Asset Security Manager — A nominated individual responsible for managing security requirements on the project.

Built Asset Security Management Plan — The project-level document that defines how security requirements will be implemented: access controls, data handling procedures, CDE security configuration, collaboration protocols.

Built Asset Security Information Requirements (BSIR) — Equivalent to the EIR, but for security information specifically.

Breach Management Plan — What happens if sensitive information is compromised. Who gets notified. What gets locked down. How you contain and investigate.

Who needs Part 5:

Any project involving: government buildings, defence facilities, critical national infrastructure, higher-risk residential buildings (under the Building Safety Act), hospitals, transport hubs, data centres, or financial institutions.

If your project scope includes any of these, Part 5 is not optional.

Published in 2025, Part 6 is the newest addition to the family.

It exists to solve a specific problem: health and safety information has historically been created, filed, and then lost. Contractors produce H&S files at handover. They end up in a drawer. Nobody reads them. Nobody maintains them. A decade later, someone starts renovation work and doesn't know where the asbestos is.

Part 6 changes this by treating health and safety information as a first-class citizen of the information model, not an appendix to it.

What it covers:

- Classification and structure of health and safety information

- How H&S information is delivered throughout the project and asset lifecycle

- Alignment with the "golden thread" concept for higher-risk buildings under UK Building Safety legislation

- Integration with the processes defined in Parts 2 and 3

The golden thread:

The Building Safety Act 2022 (UK) requires a "golden thread" of information to be maintained for higher-risk buildings. A continuous, accessible, and accurate record of the building's design, specification, and changes throughout its life. Part 6 provides the information management framework to support that requirement.

Just like in part-5, for higher-risk residential buildings in the UK, Part 6 is not optional.

ISO 19650 Parts 1, 2, and 3 are currently being revised. Here's what's proposed and where it stands.

Draft International Standard (DIS) for Parts 1 and 2: Published early 2026. Consultation closed May 2026. Final publication expected 2027.

What's changing:

The word "BIM" is being removed from the title and central framework. The standard is becoming explicitly about information management, not building information modelling specifically. The logic is sound: the principles apply beyond buildings, beyond Revit, beyond 3D modelling.

The separation between delivery phase (Part 2) and operational phase (Part 3) is being removed. A single, unified 9-step information management process will cover the full asset lifecycle from inception to decommission.

MIDP and TIDP are being consolidated into a single Information Production Schedule (IPS). Simpler, but conceptually identical.

Stronger emphasis on whole-life information value. The standard is pushing harder on the operational phase. The thing most teams have been quietly ignoring since 2018.

What's not changing:

The core logic of information requirements, the CDE workflow, naming conventions, and the party structure remain. These are foundational. They're not going anywhere.

The 2018 editions remain in force. Do not change your project templates based on draft DIS. Wait for the final publication.

These aren't theoretical. They happen on real projects, every week.

1. Writing a BEP that nobody reads

The BEP gets written, approved, filed, and forgotten. Three months into the project, half the team doesn't know the naming convention, the CDE is a mess, and the BEP is irrelevant.

The fix: The BEP is a living document. Review it at every project milestone. Make it the reference point for onboarding every new consultant.

2. Confusing the CDE platform with the CDE workflow

Teams buy a platform, call it their CDE, and assume compliance. But if the WIP/Shared/Published/Archive workflow isn't being enforced, you're just using expensive file storage.

The fix: Define the workflow explicitly in the BEP. Map it to your specific platform. Train your team on it before production starts.

3. An EIR that's too vague

A generic EIR that doesn't specify LOIN, format, delivery schedule, or naming conventions produces a generic BEP in response — which produces generic, uncoordinated deliverables.

The fix: Invest time in the EIR upfront. The specificity you put in determines the quality you get out.

4. Skipping mobilisation

Mobilisation is treated as admin overhead. Teams skip it and go straight into production. Then the naming conventions haven't been agreed, the CDE isn't configured properly, and every team is working to different assumptions.

The fix: Mobilisation is not optional. Set up the CDE properly. Test it. Agree all codes. Run a workshop. Then start producing.

5. Forgetting the operational phase

Handover happens. The model gets delivered. Nobody in the FM team knows how to use it. The asset information model collects digital dust.

The fix: AIR and Part 3 requirements should be defined before design starts — not as an afterthought at Stage 6. The FM team should be involved in EIR development.

6. Naming convention violations at subcontractor level

Lead consultants get the naming right. Subcontractors and specialists don't comply. The MIDP becomes inconsistent. Searching the CDE becomes a guessing game.

The fix: Naming compliance is a contractual requirement. The BEP must state it. The CDE should enforce it where possible. Non-compliance should be flagged early.

7. Treating ISO 19650 as a UK/European standard

It's an international standard. It applies globally. The UK National Annex adds UK-specific detail, but the core standard is in use across the Middle East, Asia-Pacific, Australia, and increasingly North America.

If you're working internationally, check the applicable national annex. The framework is the same. The specific codes and annexes may differ.

You don't need ISO19650 certification to implement it properly. You need the right documents, set up correctly, before the project starts.

Essential documents:

- EIR — Written by the appointing party before tender. Non-negotiable.

- Pre-appointment BEP — Submitted at tender. Outlines your approach.

- Post-appointment BEP — The live project document. Covers everything.

- MIDP — Master schedule of all information deliverables.

- TIDP — Each task team's individual delivery schedule.

- Model Responsibility Matrix — Who produces what model content.

- Naming Convention Register — All codes defined for this specific project.

- CDE Workflow Diagram — Mapped to your specific platform and team.

- Approval Workflow — Who checks, who authorises, who accepts.

- Information Manager's Log — Tracking outstanding approvals and deliverables.

Platforms worth knowing:

Autodesk Construction Cloud / BIM 360 - https://construction.autodesk.com — Widely used, good integration with Revit workflows

Asite - https://www.asite.com — Purpose-built CDE, strong in UK and Middle East

Revizto - https://revizto.com — Strong for issue tracking and model coordination

Plannerly - https://plannerly.com — Specifically built around ISO 19650 compliance — BEP, MIDP, TIDP management

ProjectWise - https://www.bentley.com/software/projectwise/ — Enterprise-grade, widely used in infrastructure

SharePoint - https://www.microsoft.com/en-us/microsoft-365/sharepoint/collaboration — Not purpose-built, but workable if the workflow is enforced

Useful references:

UK BIM Framework Guidance - https://www.ukbimframework.org — Free guidance documents on all aspects of ISO 19650 implementation. The most practically useful reference material available.

ISO 19650 official standards - https://www.iso.org/committee/49070.html — The standards themselves (paid access).

Plannerly ISO 19650 overview - https://plannerly.com/what-is-iso-19650/ — Good plain-language overview with templates.

BIM Corner on ISO 19650 terminology - https://bimcorner.com/iso-19650-terms-explained-in-this-simple-way/ — Useful for explaining the vocabulary to new team members.

CDBB Guidance — BEP, EIR, PIR - https://www.cdbb.cam.ac.uk — Cambridge Centre for Digital Built Britain, now archived but still the authoritative guidance.

For those who need to explain this to a client or a senior partner in under two minutes:

ISO19650 is a framework that ensures everyone on a project manages information the same way, from the first brief to the last handover.

It defines who is responsible for information at each level. It specifies how information is named, so any file can be identified without asking anyone. It structures a Common Data Environment so information moves through a controlled, auditable process. It requires a BEP so everyone knows the rules before work starts. And it defines the Level of Information Need (LOIN), so teams produce only what's required Nothing more, nothing less.

Done well, it reduces rework, eliminates version confusion, protects against disputes, and produces a handover model that's actually useful.

Done badly, or not at all. It produces exactly the problems it was designed to prevent.

The good news is that implementing it well doesn't require a team of consultants or a certification programme. It requires clear documents, configured early, with consistent enforcement throughout the project.

That's all it is.

UK BIM Framework — ISO 19650 Guidance Documents https://www.ukbimframework.org

12d Synergy — Ultimate ISO 19650 Guide https://www.12dsynergy.com/iso-19650-guide/

BIM Corner — ISO 19650 Terms Explained https://bimcorner.com/iso-19650-terms-explained-in-this-simple-way/

BIM Corner — Explaining Information Requirements in ISO 19650 https://bimcorner.com/explaining-information-requirements-in-iso-19650/

Man and Machine — Understanding Status Codes https://www.manandmachine.co.uk/understanding-status-codes-bs-en-iso-19650-2-national-annex-a/

Plannerly — ISO 19650 Templates and Overview https://plannerly.com/what-is-iso-19650/

ISO19650-6:2025 Official Standard https://www.iso.org/standard/82705.html

Plannerly — 2026 ISO 19650 Update Explained https://help.plannerly.com/en/article/137-understanding-the-proposed-iso-19650-revisions

GlobalCAD — CDE Status Codes and Workflow https://globalcad.co.uk/common-data-environment-cde-status-codes-and-workflow/

BIMicon — Naming Convention Based on ISO 19650 https://www.bimicon.com/bim-naming-convention-based-on-iso19650-part1/

Artisan BIM — Decoding ISO 19650 https://artisanbim.com/blog/decoding-ISO-19650

CDBB — BEP Guidance https://www.cdbb.cam.ac.uk/files/bep_guidance.pdf