The foundation every other part rests on.

Part 1 doesn't tell you how to run a project, that's Part 2's job. It does something more important. It sets the vocabulary, the requirements hierarchy, the Common Data Environment, and the Level of Information Need that every other part of ISO 19650 depends on. Get Part 1 wrong and nothing else can hold.

Four ideas do most of the work: the cascade, the CDE, LOIN, and naming, plus the cast of parties who operate them. About eighteen minutes of reading.

How do we make sure the information produced on a project is actually useful?

The answer is a cascade. Requirements flow downward, from the owner's strategic needs, through what each asset and project requires, into a formal brief to the delivery team, which answers with a delivery plan. Each level translates broad goals into more specific instructions. Traceability runs from the owner's objectives at the top down to every individual file submitted at a stage gate.

OIR, Organisational Information Requirements

The OIR sits at the top. It states what an organisation needs from its information across every project and every asset it owns, not for one project, for the entire portfolio.

OIRs come from business objectives: cost benchmarking, maintenance strategy, regulatory compliance, ESG reporting, asset disposal planning. Senior leadership, asset management and the FM team define them, with BIM-consultant support.

Reviewed annually. Reused across every project.

AIR + PIR, per asset, per project

Below the OIR, the cascade splits in two.

AIR (Asset Information Requirements) translates the OIR into what a particular type of asset needs from handover onwards. A hospital is fundamentally different from a residential tower, different equipment data, compliance schedules, operational priorities. The AIR captures those differences once; every project of that asset type reuses it.

PIR (Project Information Requirements) runs alongside it but answers a different question: what does the client need to know to make the decisions at each project stage? Feasibility, concept, developed design, technical design, handover, each stage has a business question, and the PIR specifies what answers it.

EIR, Exchange Information Requirements

The EIR is the most operationally significant document in the cascade. It is the formal specification the appointing party issues to the delivery team, consultants, contractors, specialists, defining exactly what information they must produce, in what format, and when. Every downstream deliverable inherits its quality, which is why a vague EIR produces a vague project.

Issued at tender. Binding at appointment.

A complete EIR covers three areas. Technical: authoring software, file formats, model origin and coordinate system, units, naming convention, LOIN per stage. Management: CDE platform, information states and gateway approvals, roles, delivery milestones, MIDP expectations. Commercial: BEP submission requirements, QA procedures, deliverables per appointment stage, acceptance criteria.

BEP, MIDP, TIDP, the team responds

Level 4 is the delivery team's answer to the EIR.

BEP (BIM Execution Plan) is produced twice, first as a tender commitment showing capability, then post-appointment as the contractual delivery plan. Owned by the lead appointed party.

MIDP (Master Information Delivery Plan) is the consolidated register of every information container on the project: all teams, all deliverables, all dates, all formats. Owned and maintained by the lead appointed party throughout delivery.

TIDP (Task Information Delivery Plan) is each task team's own slice of the MIDP, their deliverables, reviewers and dates. Multiple TIDPs aggregate into the MIDP.

Deep diveWho creates what, the lifecycle it runs on, and three ways the cascade fails

Who creates what

Document	Owner	When
OIR	Senior leadership + asset management, with BIM consultant support	Once per organisation; reviewed annually
AIR	FM team + asset manager	Once per asset type; reused across projects
PIR	Client project team	At project initiation
EIR	Client BIM Manager or Information Manager	Issued at tender; binding at appointment
BEP	Lead appointed party	Pre-appointment (tender) + post-appointment (contract)
MIDP	Lead appointed party	Maintained continuously through delivery
TIDP	Each appointed party	At appointment; updated through delivery

The four lifecycle stages the cascade serves

The cascade isn't an end in itself, it feeds a lifecycle. ISO 19650 organises the asset's life into four working stages: Appoint (set the requirements before tender), Mobilise (configure the CDE, naming, responsibilities and security before delivery), Deliver (run the production cycle and audit every exchange), and Handover & Operate (accept the Project Information Model into the Asset Information Model and govern it in use). The information you specify at Appoint governs what you receive at Deliver and what you audit at Handover.

That last move has a name. During design and construction the deliverable is the PIM (Project Information Model). At handover it transforms into the AIM (Asset Information Model), the record the operations team runs the building from for the next fifty years. ISO 19650-3 governs that transition and the operational phase beyond it.

Three common failure modes

Skipping OIR and AIR. Many projects go straight to EIR. The result: an EIR that specifies technical outputs the FM team will never use, while missing data they desperately need. The symptom shows up after handover, when the FM team rebuilds the asset register from scratch.

A BEP that overpromises. The pre-appointment BEP commits to LOIN levels or delivery cadences the team cannot hit. By Stage 3 the team is missing milestones, and the contractual exposure was baked in at signing.

A static MIDP. The MIDP is produced at appointment and never updated. By month four nobody trusts it, the weekly delivery review reverts to email and WhatsApp, and the cascade collapses.

Who's who

The cascade tells you what gets produced. This tells you by whom. ISO 19650 names a small, deliberate cast, and the whole framework assumes you know which is which.

When nobody owns a process, it fails. When two parties both assume they own it, the work is either duplicated or dropped. So the standard fixes the hierarchy up front.

The organisational roles

• Appointing party, the client. Commissions the project, sets the requirements (OIR, PIR, AIR, EIR), selects the CDE, and holds final approval authority. On most projects the client delegates day-to-day duties to a PM consultant, but retains final say over approvals.
• Lead appointed party, the lead design consultant during design, the main contractor during construction. Holds primary contractual responsibility for delivering information, coordinates everyone below, and owns the BEP and MIDP.
• Appointed parties, sub-consultants and subcontractors. Deliver their information against the EIR; each owns its TIDP.
• Task teams, the discipline teams doing the production work.

The two functional roles

Two roles operate across that hierarchy rather than sitting inside it:

• Information Manager, owns the information-management process itself: CDE governance, data quality, the stage-gate approvals. On large programmes there are often two, one on the appointing-party side, one on the lead-appointed-party side.
• BIM Coordinator, owns day-to-day model coordination within and across disciplines, runs clash detection, and performs the Gate 1 checks before information is shared.

Accountability follows the hierarchy: the appointing party is accountable for requirements, approval and handover acceptance; the lead appointed party for delivery; the appointed parties and task teams for production. The full RACI matrices live in Part 2 and the role packs, Part 1 just fixes the vocabulary.

The Common Data Environment

The CDE replaces fragmented exchange, emailed attachments, USB drives, WhatsApp shares, personal folders, with a single governed platform where all project information is stored, controlled and distributed. The platform is the technology; the CDE is the technology plus the process.

The four states

Every information container exists in one of four states. The state controls who can see it and what it can be used for.

• WIP, work in progress. Private to the producing task team. May contain errors, placeholders, drafts. Not for external reliance.
• Shared, passed Gate 1. Visible to other project teams for coordination. Not for procurement or construction decisions.
• Published, passed Gate 2. The approved, current version of record. Contractual-grade. Used for construction, regulatory submission, commercial decisions.
• Archived, superseded by a newer version, or the as-built record. Retained for the audit trail. Historical, not current.

The two gates

The gates are what make the CDE governed. They are the quality controls that stop unreviewed information being used for coordination or construction.

Gate 1, WIP to Shared. Performed by the producing team's BIM coordinator. Checks naming convention, model health (no warnings, purged content, correct origin), and LOIN against spec. Failed submissions return for rework.

Gate 2, Shared to Published. Performed by the lead appointed party on behalf of the appointing party. Checks EIR compliance, coordination against the federated model, and formal sign-off. Approved information moves to Published with the appropriate suitability code.

Deep diveStatus codes, the approval workflow, and why a shared drive isn't a CDE

Suitability (status) codes

A document's state says where it lives; its status code says what it's approved for. The code travels with the container and changes at every transition. The standard set:

Code	Status	What it means	Who can rely on it
S0	Work in progress	Being developed; not for sharing	Author / originating team
S1	Suitable for coordination	Shared for design coordination	All design team
S2	Suitable for information	Shared for information only, no action	Full project team
S3	Suitable for review & comment	Issued for formal review, response required	Client / consultant reviewers
S4	Suitable for stage approval	Submitted for formal stage/gate approval	Approving authority
S5	Suitable for costing	Released for QS / cost estimation	QS + commercial
S6	Suitable for manufacture	Released for fabrication / procurement	Contractors / fabricators
S7	Suitable for construction	Approved for site construction use	Site teams / contractors
A1–An	Approved / accepted	Formally authorised; supersedes earlier revisions	Full team + client
CR	As-constructed record	Final record of what was built	Archived for FM / operations

A typical structural drawing runs S0 → S1 (coordinate with MEP) → S3 (client review) → S4 (stage approval) → A1 (approved) → S7 (released for construction). The CDE records who changed the status, when, and with what instruction, and the record cannot be altered after the fact.

The published/approved codes are defined in the EIR and vary by framework, some projects use A1–A5 for approval gradations plus B1 (construction) and B2 (as-built) instead of S7/CR. Pick one scheme per project and enforce it in the CDE.

Deep diveGo deeper

The approval workflow, three roles, one decision

Every document passes a structured review before it can be used. Three roles, kept deliberately separate:

• Author, creates and uploads the container with correct metadata, naming and status, and nominates the checker.
• Checker, a peer in the same discipline. Verifies technical accuracy, standards compliance and completeness; forwards if acceptable, returns with documented comments if not.
• Approver, lead designer, PM consultant or client representative. Makes the final call.

The approver's decision is itself coded: A approved (proceeds to Published) · B approved with comments (proceeds, comments resolved next revision) · C rejected, revise & resubmit · D rejected, do not resubmit (the concept must be reconsidered). The one rule underneath it all, separation of duties, is that an author can never approve their own document. The CDE enforces it.

Why a shared drive isn't a CDE

ISO 19650 doesn't mandate a product. Autodesk Construction Cloud, Oracle Aconex, Asite, Trimble Connect, a configured SharePoint, all are used in practice. What the standard requires is a set of non-negotiable capabilities:

• Four discrete state areas, WIP, Shared, Published, Archived enforced as states, not folders.
• Role-based access control, each user sees only what their role requires.
• Complete audit trail, every upload, download, state change and permission edit logged with user and timestamp.
• Version control, superseded versions archived, never overwritten; the current version always discoverable.
• Naming validation, non-compliant filenames rejected at upload.

Dropbox, Google Drive, OneDrive, without governance layered on top, they are shared folders. Adding subfolders named "WIP" and "Published" does not make a CDE; the states must be enforced, not just labelled. The discipline reduces to one rule worth posting on the wall: if it isn't in the CDE, it doesn't exist.

LOIN replaces LOD

The old Level of Development system blurred three distinct things into a single number. A door could be "LOD 400" in shape and carry zero useful data; a pump could be data-rich and geometrically too heavy for early coordination. The single number couldn't tell you which.

LOIN, defined in EN 17412-1:2020 and referenced by ISO 19650-1, separates the three explicitly. Each is specified per element, per stage, and audited against at every data drop.

Three dimensions

• Geometrical, the 3D shape, size and visual detail in the model. EN 17412-1 breaks this into five sub-aspects you can set independently: detail, dimensionality, location, appearance, parametric behaviour.
• Alphanumerical, the data attached to the element: identification, material, performance, classification (Uniclass / OmniClass), commercial and FM data.
• Documentation, the supporting files linked to the element in the CDE: datasheets, certificates, calculations, O&M manuals, warranties.

Specifying one without the others produces models that look right but can't be used downstream, or models that carry the data but are too heavy to coordinate.

Across stages, a door

At concept stage a door needs only a simple panel with overall dimensions, geometry is minimal, but it still needs fire-rating and acoustic data. Documentation: none.

At detailed design, geometry catches up: frame, swing, glazing, handles, hinges, threshold. Data deepens: material, U-value, manufacturer, model number. Documentation arrives: product datasheet, fire-test certificate.

Geometry and data develop on independent curves. LOIN tracks each one separately, so the EIR can demand the right amount of each at the right stage without forcing the other to keep pace.

Deep diveThe LOD bridge, the COBie boundary, and a worked example

If your BEP still speaks LOD

You don't have to choose. LOD maps onto LOIN closely enough to translate an existing BEP:

LOD	Geometrical	Alphanumerical	Documentation	RIBA stage
100	Symbolic / schematic; no measured geometry	Type identification only	None	1 Preparation & brief
200	Approximate; estimated size, shape, location	Basic, estimated area, indicative material	Concept sketches, area schedules	2 Concept
300	Precise, measured from design	Specified, grade, loading, fire, thermal	Specs, outline datasheets	3 Spatial coordination
350	300 + interfaces and coordination clearances	300 + coordination data	Coordination reports, clash log	4 Technical
400	Fabrication-level, connections, profiles, bolts	Full fabrication data	Shop drawings, fabrication schedules	4/5 Technical / construction
500	As-built, survey-verified	Verified as-installed, serials, commissioning	As-builts, O&M, certificates, warranties	6 Handover

The advantage of LOIN is precision. Instead of "LOD 300 for all walls," you can say "precise geometry and exact thermal properties, but no installation sequence or manufacturer datasheets until Technical Design", and teams produce only what's genuinely needed.

LOIN is not COBie

A common confusion: LOIN is the framework for specifying need across three dimensions. COBie, governed by ISO 19650-4, is a structured data schema for delivering asset data to FM systems at handover. COBie fields correspond to the alphanumerical and documentation LOIN defined for the handover stage. They're complementary, not interchangeable.

Worked example, Air Handling Unit across stages

The same element followed through every stage. Each row is what the LOIN specifies for that element at that stage.

Stage	Geometry	Data	Documentation
1 Feasibility	Placeholder volume representing plant-room allocation	Cooling capacity range, system type	,
2 Concept	Generic AHU shape, approximate dimensions and connection points	Capacity, airflow rate, supply/return duct sizes, power requirement	,
3 Developed design	Confirmed dimensions with coil positions, filter sections, fan locations	Manufacturer, model number, weight, acoustic data, BMS control points	Product datasheet, acoustic test report
4 Technical design	Fabrication-ready: exact dimensions, service-access zones, lifting points, connection specs	Stage 3 data plus installation sequence, commissioning parameters, spare-parts list	Installation manual, commissioning checklist
5–6 Handover	As-built verified: actual installed position, all site variations	Serial number, install date, warranty expiry, maintenance interval, filter-change schedule	O&M manual, warranty certificate, T&C report, BMS point schedule

Used to write EIR clauses directly: pick the stage row, list the dimensions, attach the table as an appendix.

Information containers and naming

Part 1 introduces information container as the term for anything managed in the CDE, a model, drawing, schedule, certificate or photograph. The term is deliberately generic.

Every container follows the naming convention agreed in the BEP. On a project of any scale the CDE holds ten thousand or more of them. Without consistent naming, finding the right file means asking the author, version conflicts go invisible, automated validation and search and reporting and quantity extraction become impractical, and the handover data is unusable by the FM team's CAFM or CMMS.

The standard eight-field convention, separated by hyphens:

[Project] - [Originator] - [Discipline] - [Zone] - [Type] - [Sequence] - [Status] - [Revision]

Example: DXB-MR-AEC-AR-ZZ-M3-0001-S2-P03

Read left to right, that name gives the project, the originator (the producing organisation), the discipline (Architecture), the zone (ZZ = all zones), the type (M3 = 3D model), the sequence number, the suitability status (S2 = shared for information), and the revision (P03). No one opens the file to know what it is.

Deep diveThe field codes and the rules that keep them machine-readable

Discipline codes

AR Architecture	ST Structural	ME Mechanical
EL Electrical	PL Plumbing	FP Fire protection
LN Landscape	CV Civil	GE Geotechnical
SV Survey	AC Acoustic	FA Façade
VT Vertical transport	EN Environmental	BM BIM management
PM Project management	QS Quantity surveying	ZZ Multiple / all

Container type codes

M3 3D model · M2 2D model · IF IFC · DR drawing · SP specification · SH schedule · RP report · VS visualisation · CR certificate · RI RFI · BQ bill of quantities · PC point cloud · PH photograph · FN file note.

Delimiter rules

Hyphen between fields; never a hyphen inside a field; everything UPPERCASE; no spaces; no special characters. A compound project code like DXB-MR counts as one field. The CDE enforces these at upload, a non-compliant name is rejected, not quietly accepted.

Some platforms use a nine-field variant that splits Zone and Level and adds a one-character role code. The eight-field convention above is the canonical one; whichever a project adopts goes in the BEP and into the CDE's validation rules.

Further reading

• ISO 19650-1:2018, Concepts and principles, the source standard for this part.
• UK BIM Framework, free implementation guidance, templates and the cascade explained.
• BSI, ISO 19650 / BIM, the full standard family.
• EN 17412-1:2020 defines the Level of Information Need (LOIN) referenced throughout this part.