The BIM Execution Plan is the document where ISO-19650 stops being abstract and starts being real.

It's the delivery team's answer to one question from the client: 'How exactly are you going to manage information on this project?'

There are two versions. They are not the same document, and conflating them is the first mistake a reviewer spots.

• Pre-appointment BEP — written 'before' the contract is awarded, as part of the tender response. A proposal, not a promise. The prospective lead appointed party uses it to say: 'If you appoint us, here's our approach, our team's capability, our proposed CDE, our mobilisation plan.' Its whole job is to demonstrate capability and prove the team understood the question. Under ISO 19650-2 it's assessed as a procurement criterion. Information management is scored, not assumed.

• Post-appointment BEP — the live document, developed after appointment. Kept current for the life of the project. This is the project's operating system. It defines, in enforceable detail, who manages information, the standards and methods the team follows, the naming codes for 'this' project, the CDE structure and workflows, the software stack, the Level of Information Need at each stage, the responsibility matrix, and the delivery milestones.

The test for the post-appointment version is blunt:

> Hand the BEP to a new consultant on day one. If they can work out what they produce, in what format, by when, and where it goes — without six phone calls — the BEP works. If they can't, it doesn't.

A good BEP kills tribal knowledge. A bad one is a placeholder that gets filed after sign-off and never opened again.

You can't write a BEP that survives review without knowing what it answers to. The information requirements run downhill, and the BEP sits near the bottom, catching everything above it.

• OIR — Organisational Information Requirements. What the client's organisation needs from its assets to run the business.
• PIR — Project Information Requirements. What this project needs at each key decision point.
• AIR — Asset Information Requirements. What the asset needs once it's handed over and in operation.
• EIR — Exchange Information Requirements. What *you* are contracted to deliver — when, in what format, to what level. The contractual translation of everything above.
• BEP — your reply. How the delivery team will meet the EIR.
• MIDP / TIDP — the schedule. Who produces what, and when.

The BEP is the hinge. Above it sits what the client wants. Below it sits the plan to deliver it.

If you don't understand the chain, your BEP answers a question nobody asked. If you want the full breakdown of OIR, PIR, AIR and EIR — and the party structure that hangs off them. It's covered end to end in the [ISO 19650 guide] - https://bimcopilot.com/blog/iso-19650-made-simple-bim-2026. This guide assumes you know the chain and focuses on the document that answers it.

Before anything else, understand this. The single biggest reason BEPs get rejected isn't formatting or a missing section. It's that the BEP doesn't respond to the Exchange Information Requirements [EIR].

The EIR is the question. The BEP is the answer. The reviewer's first job is to put them side by side and check whether you replied.

If the EIR asks for IFC at every data drop and your BEP talks only about native Revit files, you've failed. If the EIR demands COBie at handover and your BEP doesn't mention it, you've failed. If the EIR sets a Level of Information Need by stage and your BEP waves at "LOD 300," you've failed.

The fix is unglamorous: open the EIR, go through it line by line, and make sure every requirement has a matching answer in your BEP. The cleanest way to prove it.

The move that ends the argument before it starts.

Is there a traceability table that maps each EIR clause to your response?

-----------------------------------------------

-----------------------------------------------

A reviewer who can trace every requirement to a response in one table has nothing left to reject. This is the part where most teams bluff. They write a generic BEP and hope nobody cross-references. An experienced reviewer cross-references first.

A reviewer doesn't read a BEP front to back on the first pass. They triage it. Knowing what they look for — and in what order — lets you write the document so it passes the triage instead of failing it.

The fast scan, in order:

• Is it the right type? Pre-appointment or post-appointment, stated up front, with content that matches. A post-appointment BEP that reads like a tender brochure is an instant flag.
• Does it answer the EIR? They look for traceability. Or its absence. No link to the requirements, no confidence.
• Is there a responsibility matrix, and is it specific? One named owner per container, per stage. This is the section they jump to. More on it below.
• Are the data drops real? Tied to the programme, with format and sign-off. Not "at the end of each stage."
• Is the CDE mapped to a platform, or just described? A definition of "what a CDE is" tells them you padded.
• Are the codes 'this' project's codes? Generic naming and copied status tables read as a recycled document.

If the first three fail, they don't read section four. That's the whole game on the first pass. Everything in this guide is aimed at surviving it.

Most BEPs are rejected for the same handful of reasons. They're predictable, which means they're preventable.

• 1. They don't match the EIR. The cardinal sin, covered above. A BEP that doesn't answer the requirements is rejected on principle, however polished it looks.

• 2. They're generic. A BEP that could apply to any project applies to none. Reviewers want 'this' project's naming codes, 'this' project's responsibilities, 'this' project's information routes, 'this' project's model ownership. Generic is a synonym for lazy in a reviewer's notebook.

• 3. They skip deliverables and data drops. If what you're delivering — and when — is unclear, every discipline fills the gap differently. The project drifts apart before it starts.

• 4. They confuse ISO-19650 theory with project execution. A BEP is a 'plan', not a textbook. Three pages explaining what a Common Data Environment is, with no statement of how 'yours' is configured, tells the reviewer you padded instead of planned. They want workflow, not philosophy.

• 5. They don't define measurable information needs. If you can't measure information, you can't deliver it or enforce it. 'High-quality models' is not a requirement. It's a wish.

• 6. They're a wall of text. Past thirty pages of unbroken prose, the odds of anyone reading it — including the reviewer — collapse. Tables, matrices and diagrams exist for a reason.

• 7. They were written in isolation. A BEP drafted by one person with no input from the disciplines, the client, or the contractor commits everyone to a workflow nobody agreed to. It falls apart the moment production starts.

• 8. They run on yesterday's codes. Status codes, naming syntax and published-state conventions get copied from a 2017 template. The standard moved. The template didn't. A reviewer who knows the current National Annex spots it on sight (Section 10).

None of these are about capability. They're about discipline. Everything is fixable before you hit submit.

Reviewers expect a recognisable set of sections.

Think of them in three families — commercial, management and technical — and lay them out cleanly. Leave one out, and you've invited a rejection.

Here is the structure that gets approved.

1. Project Information

• Project name and code, client and key contacts
• Project description and key milestones
• CDE platform and access details

2. Standards, Methods and Procedures

• ISO 19650 and any project or organisational standards
• Naming convention — the full syntax, with this project's codes
• Classification system (Uniclass 2015 in the UK, OmniClass in North America)
• Status and revision conventions, to the current National Annex

3. Roles and Responsibilities

• Information Manager, BIM/information lead, task team managers, authors, reviewers
• A model responsibility matrix — where most BEPs fail (Section 7)
• Clear lines of accountability mapped to the party structure

4. Information Delivery Cycle

• The CDE workflow: WIP → Shared → Published → Archive
• Review, approval and authorisation stages
• Who checks, who authorises, who accepts

5. Deliverables and Information Containers

• Models, drawings, schedules, specifications, reports
• Data exports (IFC, COBie or equivalent), PDFs, native files
• The format and structure for each

6. Data Drops / Information Delivery Milestones (Section 8)

7. Level of Information Need (LOIN) (Section 9)

8. Information Exchange and Federation

• File formats, linking and federation strategy
• Coordinates, georeferencing, shared coordinate setup
• Version and software-version control

9. Quality Assurance

• Model audit and checking routines
• Clash detection schedule and coordination cycles
• Naming, standards and completeness checks

10. CDE Structure (Section 10)

• Folder structure, access permissions, status codes
• The workflow mapped to *your specific platform*

When these are clear, specific and answer the EIR, approval becomes a formality. When they're vague, the reviewer doesn't read past section three.

If one section decides a BEP, it's this one.

A responsibility matrix says, without ambiguity, who produces what, who checks it, and who owns it at each stage. No matrix, no clarity. No clarity, and the same model element gets built three times by three disciplines. Or not at all, because everyone assumed someone else had it.

ISO-19650 builds it up in layers. The lead-appointed party starts with a high-level matrix at tender, then refines it into a detailed responsibility matrix after appointment. The detailed version identifies what information is produced, when it's exchanged, with whom, and which task team is on the hook.

A reviewer reading your matrix should never have to ask 'who owns the structural model at Stage 4?' The answer should be sitting in a cell.

Here's the shape of a strong one:

--------------------------------------------------------------------

--------------------------------------------------------------------

What a strong matrix nails:

• Every model and information container has one — and only one — owner
• Author, reviewer and approver are different named roles, not the same overloaded person
• Responsibilities map to stages, not to "the project" in the abstract
• The boundaries between disciplines are explicit. The ceiling void row is there for a reason: it's the classic gap where the architect assumes MEP owns it and MEP assumes the architect does. Name it, or fight about it at Stage 4.
• It reconciles with the MIDP. The matrix says *who*. The delivery plan says *when*. They must agree.

People do not follow what they cannot see. A responsibility matrix is how you make accountability visible. Skip it, bury it, or keep it generic, and you've handed the reviewer the easiest rejection of their week.

Data drops — properly, information delivery milestones — are the heartbeat of the delivery schedule. They define the moments information formally moves: from one party to another, from one stage to the next, from delivery into the client's hands.

BEPs get rejected here because data drops are vague, misaligned with the programme, unrealistic, or undefined. "We'll deliver at the end of each stage" is not a data drop. It's an aspiration.

A strong BEP pins down, for every milestone, what moves and on whose authority:

--------------------------------------------------------------------

--------------------------------------------------------------------

This is what the MIDP and TIDP exist to capture. Each task team produces a **TIDP** — its own schedule of deliverables. The lead appointed party consolidates every TIDP into the **MIDP** — the single master schedule for everything the delivery team will produce. The MIDP is the project's source of truth for *when* information arrives, and it must reconcile with the responsibility matrix that says *who* produces it.

A reviewer should never finish your BEP still wondering:

> "So… what exactly are we delivering at Stage 3, and who signs it off?"

If they have to ask, the data drops aren't done.

Here's a fight that happens on every project:

the architect says 'LOD 300', the MEP engineer hears 'LOD 200', and the structural team works to a scale they invented in 2019. Everyone uses the words. None of them means the same thing.

ISO-19650 replaced LOD and LOI with Level of Information Need (LOIN) to kill exactly this ambiguity, and the concept is defined in its own standard — EN 17412-1. LOD/LOI was supply-side thinking: a number stamped on a model that rarely matched what was inside it. LOIN is demand-side. It asks 'what information do you need, and why, at this point?' The requirement is driven by the use — a design decision, a coordination check, a planning submission. Not by a generic numeric scale.

LOIN is defined across three dimensions:

• Geometrical information — how precisely the element is modelled in space: detail, dimensionality, location, appearance
• Alphanumerical information — the data and properties attached to it
• Documentation — supporting documents: specifications, certificates, calculations, O&M references

Your BEP must define, for this project, what each level means *here* — not a generic LOD table lifted off a forum — with required geometry and data fields by stage. The same element, two stages apart, makes the point:

-------------------------------------------------------------

-------------------------------------------------------------

And the discipline most teams forget: LOIN is a ceiling, not a floor. It should be no more than what's needed. Over-specifying wastes time and money. A column at concept needs an approximate size and material. The same column at technical design needs precise dimensions, a fire rating and a calculation reference. Different stages, different needs — made explicit, not assumed.

Consistency equals approval. Ambiguity equals a project that implodes at the first coordination meeting.

Most teams treat the Common Data Environment section as a place to explain what a CDE is. That's the tell of a bluffed BEP.

The reviewer already knows what a CDE is. They want to know how 'yours' works on 'this' project. The CDE is not a software product — it's the workflow that moves information through four states:

WIP → Shared → Published → Archive.

The platform (Autodesk Docs / ACC, Asite, Revizto, ProjectWise, SharePoint, or anything else) is the tool that hosts the workflow.

The workflow is what ISO-19650 specifies. The platform is your choice.

Your BEP must show:

• The platform, and how access is structured
• The four-state workflow mapped to that platform
• The status (suitability) codes, and what each one authorises
• Revision conventions in each state
• The gates: who approves WIP → Shared, who authorises Shared → Published, who verifies Published → Archive

The part that separates an authoritative BEP from a recycled one. The status codes changed. The UK National Annex to BS EN ISO 19650-2 was revised in 2021, and if your codes were copied from a 2018 template — or worse, a PAS 1192 cheat sheet — they're wrong. Here's the current shape:

-------------------------------------------------------------

-------------------------------------------------------------

Three things the 2021 revision changed that catch people out:

• S1 and S2 were realigned. The 2021 National Annex redefined the shared codes, and S1/S2 no longer mean what 2018 and PAS 1192 templates assume — it's the single most-copied status-code error in circulation. Don't trust an old cheat sheet. Confirm every code against the National Annex edition your project's information standard names.
• S6 and S7 were retired, and S5 (appointing party review and acceptance) was added to separate it from S4 (submission for lead appointed party authorisation).
• The old published codes are gone. A = construction, B = tender, D = design" was PAS 1192. The current Annex uses `A1–An` and `B1–Bn`, and the meaning of each numbered code is set by 'your' project's information standard. The standalone `CR` as-built code was removed to stop it from duplicating an A-code.

This is the detail that proves you run ISO-19650 rather than quote it. A messy CDE section signals a messy project. A precise one, built on current codes, tells the reviewer the right information will always be in the right place. And that nobody is building off a superseded file. On a live project, that's the difference between coordination and chaos.

A correctly named file tells you what it is, who made it, where it sits, and what it's for — without asking anyone. A wrongly named file creates a question, and questions at scale create chaos.

The ISO 19650 file name is a string of fields, separated by hyphens, each carrying one piece of meaning:

```

Project – Originator – Volume/System – Level/Location – Type – Role – Number

```

…with suitability and revision held as metadata alongside it. The rules are non-negotiable: hyphens between fields only, underscores within a field, no spaces, no special characters, and a name that makes sense on its own without the folder it sits in.

What gets a BEP rejected here isn't the syntax — it's leaving the codes generic. The reviewer wants *this* project's originator codes, *this* project's volume breakdown, *this* project's type and role registers. A naming section that reads like the example off a standards body's website is a naming section nobody configured. The full field-by-field syntax, with worked examples and the complete code tables, is laid out in the [ISO 19650 guide](https://bimcopilot.com/blog/iso-19650-made-simple-bim-2026) — your BEP's job is to instantiate it for the project in front of you.

This earns its own section because it's where experienced reviewers separate the teams who *get it* from the teams who *winged it*.

Your BEP must show you understand four things about the client's information:

• What information they want
• When they want it
• How they want it — format, structure, naming
• What they'll use it for — the purpose behind the requirement

That last one is the giveaway. A team that grasps *why* the client wants room data formatted a certain way — because their FM system ingests it at handover — writes a sharper BEP than a team ticking a box. Purpose is what turns a compliant document into a credible one.

This section must lock down file naming with this project's codes, delivery formats matched to each requirement, geolocation and shared coordinate setup, the model linking and federation structure, and version and software-version management. This is where most teams bluff hardest, and where a reviewer can tell instantly. Don't decorate it. Answer it.

Each of these is a rejection waiting to happen.

• Using another project's BEP. It looks lazy because it is, and it collapses under the lightest cross-reference against the EIR. Templates are a starting structure, not a finished document.

• Writing too much theory. A BEP is operational, not academic. Nobody scores you for explaining ISO 19650 back to the people who wrote the EIR.

• No responsibility matrix. People won't follow what they can't see. The most common fatal omission.

• Ambiguous LOD/LOIN. Architect says 300, MEP thinks 200, project implodes. Define it for this project, with examples.

• Zero version control. Manual, hand-maintained BEPs go stale within weeks. State how the document — and the information it governs — stays current.

• A software stack nobody owns. Your BEP must reflect what the team will use — Revit, ArchiCAD, ACC, Revizto, Navisworks, Solibri. A BEP describing tools nobody on the team has is fiction.

• Unclear CDE workflows. If people don't know how to use the CDE, they won't. Then your beautifully named files end up in the wrong state at the wrong time.

• A 120-page PDF. Length is not rigour. A tight forty-page BEP with strong matrices beats a rambling hundred-pager every time. The one that gets read is the one that gets followed.

ISO 19650 is being revised, and some of it lands on the BEP. Here's what's real, and what it means for you.

The **Draft International Standard (DIS)** for Parts 1 and 2 went out for public consultation on 10 March 2026, with Part 3 following from early June. This is a *consultation draft*, not the final standard. Final publication is expected in 2027. **The 2018 editions remain in force until then** — so write to them, and do not rebuild live templates around the draft.

What's proposed:

• "BIM" is being de-emphasised in favour of "Information Management." The standard is broadening beyond building information modelling to information management across the full asset lifecycle.

• The BIM Execution Plan is being renamed the Information Production Plan (IPP). Same document, same job, new label. If your client starts talking about an IPP, they mean the BEP.

• MIDP and TIDP are consolidating into a single Information Production Schedule (IPS). Conceptually identical — a scheduled list of what gets produced, by whom, and when — with less duplication.

• The delivery phase (Part 2) and operational phase (Part 3) are merging into a single, continuous nine-step process covering the whole lifecycle.

• The appointing party's responsibilities are sharpened. Asset owners are pushed to define structured information requirements from the outset, with clearer, plainer language aimed at smaller firms and newcomers.

What's *not* changing: the core logic. Information requirements, the CDE workflow, naming conventions, the party structure, and the need for a plan that says who does what, when, and how. Those are foundational. They're getting renamed and tidied, not removed.

The practical takeaway: write your BEP to the 2018 editions today, but write it cleanly enough that swapping "BEP" for "IPP" and "MIDP/TIDP" for "IPS" in 2027 is a find-and-replace, not a rewrite.

Before the BEP leaves your hands, run it against this. If you can't tick every box, it's not ready.

• Every EIR requirement has a traceable answer in the BEP — in one table where you can
• The naming convention uses *this project's* codes, not a generic example
• The responsibility matrix names a single owner for every container, at every stage
• Author, reviewer and approver are distinct roles
• Data drops are tied to the actual programme, with format, LOIN, checker and sign-off for each
• The MIDP reconciles with the responsibility matrix
• LOIN is defined for this project, by stage, with examples
• The CDE workflow is mapped to your actual platform, with current status codes and gates
• Status and published codes match the National Annex edition your project cites — not a 2018 or PAS 1192 template
• The software stack matches what the team will really use
• QA/QC routines and a clash detection schedule are specified, not implied
• It's been seen by the disciplines, not written in a vacuum
• It's readable — tables and matrices over walls of text
• Pre- or post-appointment status is stated, and the content matches that status

That's the list a reviewer is working from, more or less. Run it yourself first.

Is a BEP a legal requirement?

Not in statute. But under ISO-19650-2 it's the contractual mechanism for information delivery, and on any project that names ISO-19650 in its appointment documents, a compliant BEP is a contractual obligation. On UK public work and most framework appointments, no BEP means no appointment.

Who writes the BEP?

The lead appointed party — usually the lead consultant or main contractor — owns it and consolidates input from every appointed party. The pre-appointment version is written by the prospective lead appointed party as part of tender. The appointing party (the client) sets the EIR the BEP answers, but does not write the BEP.

What's the difference between a pre-appointment and post-appointment BEP?

The pre-appointment BEP is a proposal submitted at tender to prove capability. The post-appointment BEP is the live, enforceable document developed after the contract is awarded and kept current for the life of the project. Same family, different jobs (Section 1).

What's the difference between the EIR and the BEP?

The EIR is the client's question — what information they need, when, in what format. The BEP is the delivery team's answer — how they'll produce it. The EIR comes first and the BEP responds to it, clause by clause.

How long should a BEP be?

As long as it needs to be and no longer. A tight, well-structured forty-page document built on matrices and tables beats a hundred pages of prose. Reviewers reward clarity, not page count.

What's the difference between a BEP and a BIM protocol?

The BIM protocol is a contractual appendix that sets out legal obligations and priorities for information. The BEP is the operational plan for delivering that information. The protocol is the law; the BEP is how you obey it.

Is the BEP being renamed in 2026?

Under the draft revision, yes — to the Information Production Plan (IPP). It's a consultation draft, final publication is expected in 2027, and the 2018 editions remain in force until then. The document and its purpose don't change (Section 14).

Does ISO-19650 require a BEP?

Yes. The BIM Execution Plan is a defined deliverable of the ISO-19650-2 delivery process — produced at tender (pre-appointment) and developed after award (post-appointment). It's the document where the standard becomes a working plan.

The AI-Assisted BEP Toolkit kills 90% of the pain. Stop rewriting the same document for every project, and stop collecting rejections.

It includes:

• A complete ISO 19650-aligned BEP template (pre- and post-appointment)
• Automated naming and classification tables
• A data drop / information delivery milestone schedule
• A LOIN matrix and a model responsibility matrix
• CDE workflow diagrams with current status codes
• QA/QC and checking sheets
• AI prompts that generate project-specific content from your EIR
• A Notion automation engine that keeps the BEP live as the project changes

Deliver BEPs at 10× speed — with 0× the stress.

Prefer it done for you? The BIMcopilot ISO 19650 Setup Service builds the full system around your project — BEP, naming register, CDE workflow, MIDP/TIDP, responsibility matrix, approval workflow and team training. Compliance without the overhead.

→ [Get the AI-Assisted BEP Toolkit](https://bimcopilot.com/shop) or [book a setup call with BIMcopilot](https://bimcopilot.com/services)

The AI-Assisted BEP Toolkit kills 90% of the pain. Stop rewriting the same document for every project, and stop collecting rejections.

It includes:

• A complete ISO 19650-aligned BEP template (pre- and post-appointment)
• Automated naming and classification tables
• A data drop / information delivery milestone schedule
• A LOIN matrix and a model responsibility matrix
• CDE workflow diagrams with current status codes
• QA/QC and checking sheets
• AI prompts that generate project-specific content from your EIR
• A Notion automation engine that keeps the BEP live as the project changes

Deliver BEPs at 10× speed — with 0× the stress.

Prefer it done for you? The BIMcopilot ISO 19650 Setup Service builds the full system around your project — BEP, naming register, CDE workflow, MIDP/TIDP, responsibility matrix, approval workflow and team training. Compliance without the overhead.

→ [Get the AI-Assisted BEP Toolkit](https://bimcopilot.com/shop) or [book a setup call with BIMcopilot](https://bimcopilot.com/services)