The moment everything is staked on.

Parts 1 to 3 set up the whole machine: what information is needed, who produces it, when it's due, where it lives, and how it carries through to operation. Part 4 governs the one event all of that exists for, the moment a container actually moves from one party to the next, and someone has to decide whether to accept it.

ISO 19650-4 is the quality standard for that moment. It exists because the process built in Parts 1–3 can still break at the point of transfer: a model exported wrong, data lost in translation, a non-compliant format waved through because nobody checked. Part 4 closes that gap with two named decisions, five quality criteria, and a record that can't be edited after the fact. About eleven minutes.

What actually happens at a data drop?

An information exchange, a "data drop", is any formal movement of an information container at a milestone: a single model, a set of drawings, a COBie data drop, or a package of documents. The MIDP already said what moves and when. Part 4 governs how it's checked before anyone relies on it.

The mechanism is two gates, each owned by a named person. Nothing crosses a gate by free transfer, it crosses only by passing a decision. This is the same two-gate structure from Part 1's CDE, named for the people who make the call: Decision A is the producer checking their own work before sharing; Decision B is the receiver accepting it before it's published.

Produce, the container in WIP

The task team authors the information in its private Work-in-Progress state. It may still contain errors, placeholders and drafts. Nothing leaves WIP until it has passed its first decision, the producer is not allowed to share poor-quality information into a state other teams will rely on.

Decision A, the internal check (Gate 1)

The producing team checks its own output before sharing it. The architect verifies their IFC export; the contractor verifies the COBie package before submitting. The transition is WIP → Shared.

Decision A is performed by a named checker identified in the TIDP, a specific person, never "the team." They are certifying the information is ready for other teams to see. Anything that fails is fixed before sharing.

Decision B, acceptance (Gate 2)

The receiving party, typically the appointing party's information manager or BIM lead, the FM team at handover, formally reviews and accepts. The transition is Shared → Published.

This is where the full Five Cs are applied, alongside EIR-compliance and MIDP-completeness checks. The receiver is certifying the information is fit for its intended purpose. Decision B is the gate that turns Shared information into the contractual record.

Accept or reject, the coded outcome

Decision B ends in one of four coded outcomes, the same approval codes Part 1 defines:

• A, Accepted. All criteria met. Moves to Published with its status code (A1, S7).
• B, Accepted with conditions. Minor issues; publish, resolve in the next revision.
• C, Rejected, revise & resubmit. One or more criteria failed; returned with reasons.
• D, Rejected, do not resubmit. A fundamental problem with scope or approach; the work must be reconsidered before any resubmission.

Whatever the outcome, it is recorded with a named individual, a date, and a result. Anonymous or undated acceptances are not valid under ISO 19650-4.

Deep diveThe ten Decision-A checks, the audit trail, and three ways an exchange fails

Decision A, the ten internal checks

Before a container leaves WIP, the named checker confirms each of these. Failing any one returns the container to the producer with a deficiency list and a correction deadline.

#	Check	What it confirms
1	Schema conformance	Valid IFC structure, correct COBie schema version, correct native file version
2	Naming compliance	File and container names follow the agreed convention exactly
3	Metadata compliance	Discipline, zone, level, type, status, revision all populated
4	Internal consistency	Dimensions match schedules, classifications uniform, no contradictory parameters
5	LOIN compliance	Geometry, data and documentation meet the Level of Information Need for this stage
6	Completeness	No blank, placeholder or default values in required fields
7	No internal clashes	No spatial clashes within the discipline's own model
8	Classification compliance	Every element classified per the agreed system (e.g. Uniclass 2015)
9	Format export test	If conversion is required (Revit → IFC), the export is tested, data and geometry survive
10	Documentation linked	Every supporting document referenced is present and accessible

The exchange audit trail

One review form per container (or package) per exchange. Part A (Decision A) and Part B (Decision B) travel together as a single record, an unbroken chain from production to publication:

Production complete → Decision A (Approved / Returned) → uploaded to Shared (auto-validation pass/fail) → coordination period → Decision B (Accepted / Conditional / Rejected) → Published with status code → resubmission if needed.

The CDE records who set each status, when, and on what instruction, and the record cannot be altered after the fact. This is Part 1's audit-trail rule applied at the exact point of exchange.

Three common failure modes

The blank checker. Decision A or B is left to "the team" with no named individual. When quality slips, nobody is accountable, and the gate was never really a gate. The fix is in the TIDP: every gate names a person and a backup before the first exchange.

The waved-through format. A non-compliant export is accepted because checking it was tedious and the deadline was close. The data loss surfaces at handover, when the FM team can't import the model, weeks of rework for a check that would have taken an hour.

The undated acceptance. Information is published, but the record doesn't say who accepted it or when. Under ISO 19650-4 that acceptance is invalid; in a dispute, there is no defensible audit trail. The record is the deliverable as much as the model is.

The Five Cs, what "good" looks like at the point of transfer

ISO 19650-4 Clause 5 names five quality criteria, applied at every exchange. They are the substance behind Decision B: the receiver isn't accepting on a feeling, they're testing the container against five specific questions. Each criterion has its own checklist of sub-checks, but the five headlines carry the idea.

Conformance, does it comply with the agreed standard?

Correct file format, naming convention, schema version, classification system, metadata, status code. A COBie file that fails schema validation, or a model named outside the convention, fails conformance. This is the criterion automation catches best, most of it can be enforced at upload.

Continuity, does it follow on from last time?

Entity and asset identifiers stay persistent; changes from the previous version are traceable and justified; no elements vanish without a documented reason; GUIDs aren't silently regenerated; versioning is sequential. A Stage 4 model must be traceable to the Stage 3 model it grew from. (N/A at the very first exchange.)

Communication, can the receiver actually use it?

Has the data survived format conversion? Geometry, units, character encoding, shared parameters, the coordinate system, the COBie field mappings, all intact after export and import. An IFC that looks correct but loses half its data on import fails communication. The defence is the round-trip test, run before production, not at handover.

Consistency, does it agree with itself and the others?

Internally consistent and consistent across disciplines: no element duplicated across federated models, spatial and coordinate alignment correct, attribute values matching the schedules and specs, no conflicting data, units and classification uniform, and clashes, both within the discipline and against other Shared models, resolved.

Completeness, is everything there?

Everything the LOIN requires at this stage is present: all geometry, all data attributes, all linked documents, all COBie fields for this drop, every container the MIDP lists for the milestone, no orphaned records, and the whole thing fit for its intended purpose.

Deep diveProportionate rigour, and the Information Exchange Plan that sets it

The Five Cs scale with the stage

You do not apply the same depth of checking at concept that you apply at handover. Over-checking early wastes resource; under-checking late creates risk. ISO 19650-4 requires the rigour to be proportionate, and the Information Exchange Plan sets the level per criterion per stage.

Criterion	Concept	Developed	Technical	Construction	Handover
Conformance	Basic schema check	Schema + naming	Full compliance	Full compliance	Full compliance
Continuity	N/A (first exchange)	Vs concept models	Vs previous stage	Vs technical models	Full lifecycle continuity
Communication	Format test	Full export test	Full + sample validation	Full + IFC round-trip	Full + FM import test
Consistency	Internal only	Cross-discipline	Federation + spatial	Federation + site verification	Full federation + as-built survey
Completeness	Per LOIN	Per LOIN + COBie Drop 1–2	Per LOIN + COBie Drop 3	Full COBie + documentation	100% COBie + all O&M docs

The Information Exchange Plan (IEP)

The IEP is ISO 19650-4's quality-strategy document. The MIDP says what is delivered and when; the IEP says how each exchange is checked before acceptance, the agreed formats, the Five Cs rigour schedule above, the named Decision A and B for each exchange, and the automated validation configured in the CDE.

It's written at mobilisation, alongside the post-appointment BEP, before the first formal exchange. Crucially it must be agreed between the appointing party and the lead appointed party, both sign it off. It cannot be imposed unilaterally, and it's referenced from or appended to the BEP so it becomes part of the contractual framework.

Automated validation does the first pass

The CDE catches conformance and naming issues at upload, before a human ever reviews: naming validation (non-compliant files rejected), format validation (only agreed formats accepted), metadata validation (required fields before upload completes), duplicate detection, and status-code transition validation, you cannot, for instance, publish straight from WIP. External tools run at the gates: IFC schema validation, COBie schema validation at each drop, rules-based model checking, clash detection, and classification compliance.

The BIM Model Review Report, the audit at the exchange

Aligned to ISO 19650-2 clauses 5.6–5.7, the Model Review Report is the record of a coordination review: what was checked, what it found, and what must happen next. At a stage exchange it's the evidence a Decision B rests on, the receiver isn't accepting blind, they're accepting against a documented audit.

The same report serves a design-coordination review (architecture, structural, MEP, civil, landscape) and a construction-coordination review (concrete, steel, MEP installation, temporary works, façade). Only the discipline lineup changes; the structure holds.

The status dashboard

A one-glance verdict, each metric shown against its previous value so the trend is visible: overall coordination (On Track / At Risk / Critical), critical and major clashes outstanding, average model health, overdue actions, MIDP delivery compliance, and a readiness assessment for the next exchange.

The clash summary

Clashes counted by discipline pair and classified by severity, Critical (structural or safety), Major (coordination), Minor (tolerance or aesthetic), with resolved and open counts. Every Critical and Major clash is then listed individually, each with an assigned owner and a resolution deadline.

Model health and actions

Per model: file size, warning count, coordinates OK/issue, naming OK/issue, and a health percentage, sourced from the routine L1/L2 checks or the formal L3 pre-exchange audit. Every issue becomes an entry in the actions register, which carries actions forward until they're formally closed. Overdue actions escalate to the BIM Director; actions are binding from issue, with a five-working-day response window, and the report is filed in the CDE.

Formats, the schema register, and COBie

Every exchange has an agreed format, and the formats are locked before production starts, changing them mid-project is how data gets lost. The Information Exchange Plan's format register is the single reference for what's acceptable, and it flags which formats are the archival ones that must survive the life of the asset.

The exchange format register

• Models, Revit native is the authoring format, but proprietary, so an IFC archive is required (IFC 2x3 / IFC4; open, ISO 16739, the archival model format). DWG for 2D exchange (archived as PDF/A); NWD/NWC for the federated coordination model.
• Data, COBie (Excel, or embedded in IFC via an MVD) for asset handover data; BCF (BIM Collaboration Format, open) for moving coordination issues and clashes between platforms; gbXML for energy; CSV/XML for tabular exports.
• Documents, PDF/A (ISO 19005) for long-term archival: searchable, bookmarked, correctly scaled. Working DOCX and XLSX convert to archival formats at publication.

Test before you produce

The single most common Part 4 failure is discovering data loss at handover. The defence is pre-production format testing at mobilisation: the IFC round-trip (export → import to the coordination tool → verify geometry and data survive), with the export settings, MVD, property-set mapping, coordinates, documented and locked; the COBie mapping test (Revit → schema validation → trial import to the CAFM/CMMS); an encoding test for special and non-Latin characters; a PDF/A generation test; and a BCF round-trip. Then the export preset is saved and distributed to every task team. A failed round-trip found here costs a day; found at handover it costs weeks.

Deep diveCOBie, the handover data schema

LOIN specifies; COBie delivers

Part 1 drew the line and deferred the detail to here. LOIN is the framework for specifying what an element needs across geometry, data and documentation. COBie, Construction Operations Building Information Exchange, governed by ISO 19650-4, is the structured schema for delivering asset data into FM systems (CAFM / CMMS) at handover. COBie fields correspond to the alphanumerical and documentation LOIN defined for the handover stage. They are complementary, not interchangeable: one says what's needed, the other carries it.

COBie is delivered in drops, not all at once

COBie isn't a single handover dump, it's populated progressively across the project in data drops that align to stages, with completeness scaling up the rigour schedule:

Stage	COBie expectation
Developed design	COBie Drop 1–2, early system and component records
Technical design	COBie Drop 3, components, types, attributes deepen
Construction	Full COBie + supporting documentation
Handover	100% COBie + all O&M documents

Each drop is schema-validated, and a continuity rule applies across them: COBie Component and Type records must keep persistent identifiers from one drop to the next. If a component's ID changes between drops, the FM system can't trace it through, a continuity failure caught at Decision B.

Two delivery routes

COBie travels either as an Excel spreadsheet (the familiar tabbed workbook, COBie 2.4 / COBie UK 2012 / ISO 15686-4, agreed per project) or embedded in an IFC export via the appropriate Model View Definition. The route is fixed in the format register and proven in the pre-production COBie mapping test, never improvised at handover.

Further reading

• ISO 19650 series, BSI, Part 4 covers information exchange in full.
• buildingSMART, the IFC and COBie schemas behind a clean exchange.