ISO 19650, without the jargon.

If somebody has told you a project needs to be "ISO 19650-compliant" and you nodded politely without knowing what that means in practice, this guide is for you. No clause numbers, no acronyms without an explanation, no theatre. Just what the standard actually asks for, and what tends to go wrong.

What ISO 19650 actually is

ISO 19650 is an international standard for managing information across a built-asset project, from the early brief through design, construction, and into operation. It tells you who is supposed to ask for what information, who is supposed to produce it, where it lives, and when it has to be handed over.

It is not a software product. It is not a Revit setting. It is not a certification that a model is "good." It is a way of agreeing, in writing, what information will change hands and on what terms. The deliverables, models, drawings, data, are the same things you would produce anyway; ISO 19650 is the contract layer that sits over the top of them.

The standard grew out of the UK's PAS 1192 series, which was developed around BIM Level 2 mandates in the 2010s. ISO 19650 internationalised that work. In the Gulf, it is increasingly being written into employer requirements by developers and authorities, sometimes thoroughly, often not. That gap between the standard cited and the standard enforced is where most projects come unstuck.

The parts that matter

ISO 19650 is published as a series of parts. You will hear all of them referenced; only some of them will be relevant on any given project.

Part 1: Concepts and principles

The vocabulary and the frame. Defines what is meant by an "information model," an "appointment," a "common data environment," and so on. Worth a single careful read at the start of a project, then largely a reference for resolving disputes about what a term means.

Part 2: Delivery phase of the assets

The one most people mean when they say "ISO 19650." Covers how information is managed during design and construction. This is where the BEP, EIR, MIDP, and TIDP live, the documents you will spend the project writing, signing, and arguing about.

Part 3: Operational phase of the assets

What happens after handover. How the asset information model is maintained, updated, and used by facilities management. Relevant if the developer is keeping the asset; less relevant if it is being sold or transferred immediately.

Part 5: Security-minded approach

For sensitive assets, government, defence, critical infrastructure. Sets out how to protect information that could be misused. Most commercial projects in the Gulf treat Part 5 as optional, which is increasingly a mistake as cloud-based CDEs become standard.

You may also see Part 4 referenced, it covers information exchange and is published as a technical specification rather than a full part. Part 6 (health and safety) is in development.

Five roles you need to understand

ISO 19650 reorganises the project around five roles. The names are unfamiliar; the people are the same ones you already work with.

• Appointing Party. The client. The one paying for the information and writing the requirements. In Gulf practice this is usually the developer; on public projects it is the authority.
• Lead Appointed Party. The party directly contracted to the Appointing Party for a particular scope, often the lead consultant in design, or the main contractor in construction. They aggregate information from everyone below them.
• Appointed Party. Anyone else contracted into the project, sub-consultants, specialist trades, façade designers, MEP coordinators. Each is an Appointed Party in their own right with their own scope of information.
• Task Team. The actual humans doing the modelling and producing the drawings on a given package. Sits inside an Appointed Party.
• Information Manager. The role responsible for the rules, naming, exchanges, CDE governance, audit. Can sit with the Appointing Party, the Lead Appointed Party, or be appointed independently. Often the source of friction when nobody is sure who owns it.

The role you play depends on the contract, not the company. A consultant can be a Lead Appointed Party on one project and an Appointed Party on the next. Roles are scope-specific, not firm-specific.

The information lifecycle

The standard imagines information moving through a single shared environment, the Common Data Environment, or CDE, in four states. Files do not just sit in a folder; they progress through gates.

• Work in Progress (WIP). Files being authored inside a single Task Team. Not visible to anyone outside that team. Nobody is meant to coordinate against WIP content.
• Shared. Files released by a Task Team to other Task Teams for coordination. Still draft, still subject to change, but visible across disciplines. Most cross-discipline clash detection happens here.
• Published. Files approved by the Appointing Party for use, for construction, for procurement, for authority submission. These are the contractual deliverables.
• Archived. A read-only snapshot of what was Published, kept for traceability. Each Published state generates an Archive.

The states are separated by gate reviews, explicit acceptance steps where someone signs off that information has met its quality criteria before moving forward. The gate is the point. Without it, the four states are just folder names.

The deliverables you actually produce

Six documents do most of the work in a Part 2 engagement. Knowing what each is for matters more than memorising the acronyms.

EIR: Exchange Information Requirements

Issued by the Appointing Party. Says what information they want, in what format, at what milestones, and why. The EIR is the brief for the information side of the project, separate from, and ideally aligned with, the design brief. A weak EIR will produce a weak BEP, and a weak BEP will produce a weak project.

BEP: BIM Execution Plan

The response to the EIR. Says how the Appointed Parties will deliver what was asked for, what software, what naming, what coordination cadence, what gates. Issued in two stages: a pre-appointment BEP (pBEP) at tender, then a confirmed BEP after appointment, with the actual team named.

MIDP: Master Information Delivery Plan

The aggregated programme of every information deliverable across the project, with dates and responsible parties. Owned by the Lead Appointed Party. The single source of truth for what is being delivered when.

TIDP: Task Information Delivery Plan

The MIDP, broken down by Task Team. Each Task Team's slice of the deliverables, with their own internal dates that feed into the MIDP. One MIDP, many TIDPs.

PIM: Project Information Model

The complete federated information set produced during design and construction. Models, drawings, schedules, documents, everything the project generates, in its accepted state. The PIM is what gets handed over.

AIM: Asset Information Model

A curated subset of the PIM, kept current after handover for operations. Only the information FM and the owner need to run the building. The AIM lives in operation; the PIM is the project record.

Common mistakes

The same patterns recur on most projects. None of them are exotic. All of them are avoidable if you know to look.

• The standard is cited but never enforced. The contract says "deliverables to comply with ISO 19650." Nobody on either side has read it carefully. The CDE has the right folder names; the gate reviews never happen. By the time anyone notices, the project is already non-compliant in everything but the cover page.
• There is no MIDP. Each consultant has their own deliverables list. There is no aggregated view, no single dated programme. When milestones slip, nobody can see the knock-on effects until they show up on site.
• Acceptance gates are skipped. Files move from Shared to Published because somebody needs them, not because they have passed a defined quality check. Published files turn out to be wrong, get republished, get re-issued, and the audit trail is meaningless.
• Security is ignored. Part 5 is treated as optional even on sensitive projects. CDE permissions are over-broad, file naming leaks intent, and the project's information surface is wider than anyone realises.

None of these are failures of the standard. They are failures of operation, of treating ISO 19650 as a label rather than a working system.

How JES applies it

Every engagement we take on is ISO 19650-native by default. That means the BEP and the EIR are aligned before a single model is opened, not retrofitted at the end. The gate reviews are run on the CDE, with named approvers and dated acceptance. The MIDP is one document, not a spreadsheet per consultant. The Information Manager role is filled, even when the contract is silent about who fills it.

The standard is not the deliverable. The coordinated, accepted, audit-trailed information is the deliverable. ISO 19650 just makes sure everyone agrees, in advance, what "accepted" means.