ABOUT ISO 19650
01
What is ISO 19650?
ISO 19650 is the international standard for organising and managing information across the full lifecycle of a built asset using Building Information Modelling (BIM). It replaces BS 1192 and PAS 1192 as the globally harmonised framework — in Australia, it underpins the NATSPEC National BIM Guide, the ABAB BIM Framework, and the DExP (Digital Engineering Execution Plan) conventions used on most major infrastructure programmes.
The standard defines who produces what information, when, and to what quality — formalised through the Organisational Information Requirements (OIR), Asset Information Requirements (AIR), Project Information Requirements (PIR), and Exchange Information Requirements (EIR). Together these drive the BIM Execution Plan (BEP) that every project team delivers.
ISO 19650 is not just a documentation standard. It is an operating model for how the appointing party (the client), the lead appointed party (the principal consultant or contractor), and the appointed parties (the consultants and trades) exchange information through a Common Data Environment (CDE) in a way that preserves provenance, status, and suitability at every stage.
Objective: the right people working on the right information at the right time, with revisions, approvals, and information containers tracked to an auditable lifecycle.
Developed by: National Institute of Building Sciences (NIBS) and the Centre for Digital Built Britain (CDBB), aligned to ISO Technical Committee TC 59/SC 13.
Benefits: tighter programme control, fewer information loss points across the contract chain, cleaner handover, and — on projects operating at scale — a measurably smaller gap between design intent and as-built data.
In Practice
I don't treat ISO 19650 as a compliance document. I treat it as the operating system that lets automation run safely.
On a portfolio of 120+ master home designs and 347+ active Revit models at Rawson Group (Daiwa House), our internal CORE+KOP framework is essentially an ISO 19650-aligned CDE structure with extra layers for design option governance. Every takeoff pipeline, every schedule integration, every AI-assisted check I've built sits on top of that.
Strip the standard away and the automation stops being defensible — you lose the audit trail that tells you which container was extracted, from which revision, against which approval status.
The standard says "the right people working on the right information at the right time".
What I'd add from experience:
— and the right machines working on the right information at the right time.
That is exactly the expansion 2026 delivery needs.
Concepts and Principles
02
The Five Pillars
ISO 19650 rests on five interlocking concepts.
1. Information Containers — every piece of project information is wrapped in a container with a revision, a status code (S0 WIP, S2 Shared, A1 Published), and a suitability code.
2. Common Data Environment (CDE) — a single controlled location (Autodesk Forma, previously ACC / BIM 360; Aconex; ProjectWise; or equivalent) that enforces the WIP → Shared → Published → Archived flow.
3. Responsibility Matrix — every deliverable has a clear owner and reviewer. The BEP names who produces each model, who reviews it, who accepts it at each stage gate.
4. Level of Information Need (LOIN) — replaces the older LOD shorthand. Geometry and data are specified to what the client needs to decide at each stage, not to a generic maturity level.
5. Security-Minded Approach (ISO 19650-5) — information security, access control, and classification of sensitive asset data.
What Actually Breaks
On containers. The failure is not the standard, it is the discipline. On Mirvac's Vance at Harold Park, two consultants were exchanging WIP models over email and calling them "Issued for Coordination". The clash register looked clean until three weeks later when a published version surfaced a problem the WIPs had already fixed — but not in the CDE. The standard called this out in 2018; most teams still default to it.
On the CDE. The platform choice is usually made by procurement, not by delivery. At Mirvac I watched the CDE shift three times across concurrent projects; each shift cost a mobilisation. At Rawson, once Daiwa House standardised on Autodesk Forma, the downstream win was enormous — every automation I've built assumes one CDE, one auth model, one set of APIs.
On the responsibility matrix. Automation makes this awkward. If a script produces a BOQ, who owns it — the Digital Engineer who wrote it, or the estimator who consumes it? At Rawson we resolved this by treating the pipeline itself as an "appointed party" in the BEP — named inputs, named outputs, a version, an owner. The standard doesn't cover this yet, but it should.
On LOIN. On Woods Bagot's Central Station + Metro Connection detail design, the original information requirement specified very high LOD for every structural connection. Reframing to LOIN thinking cut modelling scope substantially — full-fidelity connection geometry was needed at fabrication handoff, not at design intent. Months saved.
On Part 5. Everyone skips it until they try to deploy AI. At DesignInc I delivered BIM on defence projects (Myambat, RAAF Base Williamtown, F-35 MRO&U, SOER, REDFIN, Garden Island) where Part 5 was mandatory from day one. At Rawson, deploying the takeoff pipeline meant redesigning the APS token architecture so service accounts, user-facing scopes, and audit logs all met Part 5 expectations. Invisible to users — and the reason IT sanctioned the pipeline.
ISO 19650 Details · Parts 1–5
03
What Each Part Covers
Part 1 — Concepts and Principles (ISO 19650-1:2018). Vocabulary and framework. Defines containers, CDE states, appointing / appointed party model. Every other part refers back.
Part 2 — Delivery Phase of Assets (ISO 19650-2:2018). The eight-step information management process from tender through handover. This is where the BEP sits.
Part 3 — Operational Phase of Assets (ISO 19650-3:2020). Extends into operations and maintenance. Defines how the Asset Information Model (AIM) is maintained post-handover.
Part 4 — Information Exchange (ISO 19650-4:2022). Technical specifications for how information actually transfers between parties and CDEs — formats, metadata, verification.
Part 5 — Security-Minded Approach (ISO 19650-5:2020). Risk assessment, access control, information classification. Mandatory thinking on any project touching critical infrastructure, defence, or government assets.
Where I've Delivered Under Each
Part 2 — every project since 2018. Woods Bagot (Central Station + Metro Connection, MLC Shopping Centre for Dexus, West Village Parramatta for Ecoworld), Mirvac (Vance at Harold Park, Epping, multiple residential), and the full Rawson portfolio.
Part 2 is the part that separates a BEP author who has read the standard from one who has tendered, mobilised, delivered, and closed out under it.
Part 3 — where volume builders and infrastructure operators diverge. Rawson has a fast handover cadence — hundreds of homes a year — so the AIM design is about repeatability and data consistency across homes. A major operator cares about portfolio asset intelligence over decades. Same standard, two very different implementations.
Part 4 — central to my takeoff work. The APS Model Derivative exchange, the PropDB extraction, and the Forma Takeoff POST all preserve enough metadata to verify that a takeoff package maps back to a specific Revit model version. Part 4 is why this is auditable.
Part 5 — DesignInc defence work first (compulsory), then at Rawson for the AI automation design document and the three-tier account architecture IT sanctioned the pipeline under.
Part 5 is the paragraph that makes Automation + ISO 19650 coherent rather than contradictory.
Working knowledge of all five parts — not just Part 2 — is what separates a BIM Coordinator from a Digital Engineering Manager.
Procurement Phase
04
The Principle
Procurement is where ISO 19650 pays the biggest dividend.
The appointing party produces the OIR / AIR / PIR, issues the EIR with the tender, specifies the CDE, naming conventions, software versions, and coordination rules (worksets, shared coordinates, georeferencing).
The lead appointed party's tender response includes:
-
A pre-appointment BEP demonstrating capability and approach
-
A resource plan identifying named roles (Information Manager, BIM Manager, Task Team leads)
-
A Mobilisation Plan describing how the CDE will be populated, how naming will be enforced, and how the information production schedule aligns with the programme
Get procurement right and the rest of the project is about execution, not renegotiation.
Three Failure Modes I See Repeatedly
1. EIR written by a standards consultant who has never delivered the specified CDE. The requirements read well but don't map onto how Forma / Aconex / ProjectWise actually operates. An experienced Digital Engineer reads every EIR with the question: "can this actually be enforced in the platform we're using?" If not, the BEP needs to flag the deviation explicitly — before award.
2. "BIM 360" clauses surviving into post-ACC / Forma projects. The migration from BIM 360 → ACC → Forma is still incomplete in many organisations' template documents. I've seen 2024 EIRs that still reference "BIM 360 Glue workflows" for a project being delivered entirely on Forma. The BEP author has to harmonise this before mobilisation, or it becomes a renegotiation during delivery.
3. Automation dependencies not declared. If a project intends to use scripted takeoff, AI-assisted checking, or any pipeline touching project data, the EIR should say so and the BEP should respond. If it doesn't, IT and security teams find out at deployment time — six months too late.
At Rawson this is now a standing section of the BEP: Scripted Data Access — every pipeline listed with its scopes, logging, and owner.
Planning Phase
05
Mobilisation Deliverables
Between contract award and the first information exchange, the project is most vulnerable.
Required deliverables:
-
MIDP (Master Information Delivery Plan) — single source of truth for what each task team delivers and when
-
TIDPs — one per appointed party, cascading down from the MIDP
-
CDE setup — folder structures, permission groups, workflow rules, naming enforcement
-
Federated model structure — agreed worksets, shared coordinates, origin points, units, north orientation
-
Quality and approval protocols — model audit checks, clash routines, status-code escalation path
A good mobilisation is invisible to the client. A bad one shows up as a six-week delay before the first proper Shared-status exchange.
What I've Learnt Doing It Repeatedly
The federated model structure has to be agreed in week one. Worksets, shared coordinate systems, origin points, units, north orientation. On Woods Bagot's Central Station work, the project-base vs shared-coordinates dance alone justified a full day of every consultant in the room. Cheaper than unwinding alignment issues twelve weeks in.
Naming enforcement is not manual. I've moved every project I've run since 2023 to template-driven or script-enforced naming. Manual review scales to about 50 models; above that, it fails quietly. At Rawson with 347+ active models, automated enforcement is mandatory.
Automation is mobilisation-relevant. If the project will use scripted takeoff, Schedule integration, or AI-assisted checks, those pipelines and their data access rights are declared in the BEP and security-assessed under Part 5 — at mobilisation, not mid-production.
Clash platform chosen once. Revizto, Solibri, Navisworks Manager, BIMTrack — pick one, align everyone to it, document the workflow. Changing this later loses three weeks.
My practical 2026 stack: Autodesk Forma as CDE (nearly universal on recent Australian projects), Revizto for live coordination, Aconex for document control on larger consortia, ProjectWise still appearing on some government programmes. The choice matters less than the discipline of sticking to it.
Production Phase
06
The Core Loop
For every information container:
1. Work in Progress (WIP) — task team produces it in their own environment.
2. Check, Review, Approve internally — audited against BEP quality protocol.
3. Shared (S2 or equivalent) — crosses into the project CDE. Other task teams can coordinate against it, but not yet client-approved.
4. Published (e.g., A1 for construction) — appointing party accepts it for a specific purpose. Contractually binding.
5. Archived — frozen with metadata for future retrieval.
Production is the long phase — design development through construction documentation through to handover. ISO 19650's value shows up in the quiet efficiency gains that compound over months.
What Matters Day to Day
Automation only reads from Shared and above. Non-negotiable. Our Rawson takeoff pipeline refuses to touch WIP containers. Not a technical choice — an ISO 19650 conformance choice. If a model is still WIP, nobody outside the task team (including my automation) should be extracting quantities from it. The pipeline's first check on any model is its status code.
The federated model cadence is the heartbeat. On concurrent Mirvac projects I defaulted to weekly federation; on Rawson's volume builder cadence it's daily for active masters and weekly for the stable portfolio. Too slow and task teams drift; too fast and reviewers burn out.
Clashes are logged against owners and deadlines, not against meetings. The weekly coordination session works through the live clash register — not through drawings. This only works if the CDE and the coordination platform are actually synchronised.
Warning signs during production — every one of these is an ISO 19650 non-conformance:
-
containers exchanged outside the CDE (email, shared drives)
-
status codes used inconsistently (S2 and A1 treated as interchangeable)
-
federated model lagging WIPs by more than two weeks
-
clash register items older than three cycles without movement
The discipline is dull, and it compounds.
Project Close-out
07
AIM Handover
Close-out is where the Project Information Model (PIM) transitions to the Asset Information Model (AIM) — the information package the owner uses to operate and maintain the asset for its design life.
The appointing party receives:
-
The as-built federated model with all agreed LOIN preserved
-
Archived containers for every contractually required deliverable, with full revision history and suitability codes
-
COBie (or equivalent) data export for asset registers, consumed by the client's CAFM / IWMS system
-
AIR responses — what the client specifically asked for, mapped to the containers that satisfy each requirement
-
O&M manuals, warranties, and commissioning records linked to the relevant model elements
ISO 19650-3 is explicit that the AIM is verified against the AIR. If an AIR specified "every FCU must have manufacturer, model number, commissioning date, and linked maintenance schedule", the handover audit confirms that every FCU in the model has those fields populated. Missing data is a defect.
Why I Design Automation Around Close-Out
Every takeoff we automate today will be consumed by someone at close-out — the estimator, the client cost team, the portfolio analytics stack.
This is why our Rawson pipeline uses rule-based classification rather than LLM classification.
COBie-grade asset data has to be auditable back to the rule that produced it. You can't defend "the LLM decided this is a door" in an asset audit.
You can defend "the element matched regex pattern X in rule set Y version 1.3, classified as BOQ code Z".
Portfolio scale is where close-out compounds. For a client with a portfolio — a volume builder like Rawson, a major operator, a government department — ISO 19650-compliant handovers accumulate. Each project adds high-quality, standardised data to the organisational asset database. Over five or ten projects that database becomes strategically valuable: portfolio-level analysis, predictive maintenance, AI-assisted operations.
Without ISO 19650, every handover is an island — and organisational knowledge compounds far more slowly.
Close-out is not an afterthought. It is the primary reason ISO 19650 exists. The rest of the standard is there to make sure close-out actually delivers what the owner needs to run their asset — and increasingly, what the owner needs to run AI against their asset.