Back to the BIM & IFC blog
Delivery & ISO 19650 · 2026-08-07 · 9 min
BEP Clauses That Actually Prevent Bad IFC Deliveries
Most BEPs say models must be "of suitable quality" and nothing else — which is why quality arguments never end. Four short clauses, written to be pasted, that turn an opinion into a testable condition.
BEP Clauses That Actually Prevent Bad IFC Deliveries — IFC Viewer Online article cover
Open a random BIM Execution Plan at the information delivery section and you will find a sentence like this: "All models shall be delivered in a suitable format and be of appropriate quality for their intended use." Everybody signs it. Nobody can fail it, and nobody can enforce it.
That sentence is why IFC quality arguments on projects are so bitter: there is nothing to point at. When the coordinator says the model is unusable and the author says it is fine, both are giving opinions, because the contract never converted "quality" into a condition anyone could test.
A quality clause that cannot fail is not a clause. It is a hope with a clause number.
What makes a clause enforceable
Three properties, and they are worth checking against anything already in your BEP:
- It names a test. Not "good quality" but a specific check, run by a specific method, producing a specific output.
- It names a threshold. A number, a count, or a binary condition — something a reviewer can compare against without judgement.
- It names what happens when the threshold is missed. A clause with no consequence is documentation, not a requirement.
The four clauses below have all three. They are deliberately short: a quality clause nobody reads has no effect, and a clause that fits on half a page gets quoted back at people, which is the entire point.
Clause 1 — Automated check before issue
Every IFC container issued to the CDE at status S2 (Shared) or above shall
have been checked with the project's agreed rule set within the 24 hours
preceding issue. The check report shall be issued alongside the container.
Containers issued without a check report may be rejected without review.
The last sentence does the work. Without it, the clause creates an obligation with no cost attached to skipping it, and it will be skipped on the week when the programme is tight — which is exactly the week the check matters.
Note the placement: at S2, not at publication. By the time something is published, three disciplines have coordinated against it, and a structural fault means re-doing their work rather than yours. The whole economics of pre-delivery checking depends on catching things at the Work in progress → Shared boundary.
If you have not settled on a rule set yet, start from the standard checks any validator runs — the most common IFC validation errors cover the great majority of real rejections, and they are the same everywhere because they come from export settings rather than from modelling style.
Clause 2 — A minimum quality threshold
IFC containers shall achieve a Health Score of at least 80/100 under the
project rule set. Containers scoring below the threshold may be issued only
with the prior written agreement of the Information Manager, recording the
findings concerned and the reason.
Two design decisions worth copying. First, the escape hatch is explicit: sometimes a model below the threshold genuinely needs to be shared, and a rule with no legitimate exception gets ignored rather than followed. Second, the exception has to be written down, which converts "we agreed to let it go" into a record with a date and an author.
Pick your threshold deliberately. A score is a compression of a whole report into one number, weighted by category and severity — worth understanding before you contractualise it. The guide to the IFC Health Score explains what moves it and by how much.
Clause 3 — Identifier stability
IFC GlobalIds shall be persistent for the life of the project: the identifier
of an element shall not change between revisions unless the element itself is
deleted and replaced. Task teams shall configure authoring and export tools
accordingly, and shall report any event that invalidates identifiers (model
recreation, round-trip import, template migration) at the time it occurs.
If you add only one clause from this article, add this one. Threshold clauses improve the average delivery; the identifier clause prevents a class of damage that cannot be repaired afterwards.
When GlobalIds change on every export, three things break silently and simultaneously: issues detach from the elements they were raised against, revision comparison becomes fiction because every element looks new, and asset data cannot be reconciled with the model it came from. None of these produce an error message. They produce a project where nobody quite trusts the coordination history and nobody can say why.
The reporting obligation in the last sentence matters more than it looks. GUID turnover is usually caused by a process event somebody knows about — a model rebuilt, a file round-tripped through another tool. Knowing when it happened is the difference between a note in the log and a forensic exercise. See why IFC GUIDs change on every export for the specific causes, and duplicate GUIDs in IFC files for the related failure where two elements share one identifier.
Clause 4 — Shared coordinates and units
All task teams shall use the project shared reference point and rotation
defined in {document}, and shall deliver in metric SI length units. Storey
names and elevations shall follow the agreed level schedule without local
variation.
This is the clause that only pays off in federation. Each discipline model can be internally perfect and the federated set still be unusable, because three failure modes are invisible until models meet: models referenced to different origins, one file in imperial units, and per-discipline level schedules that require a translation table maintained by a human.
The georeferencing half is the one that produces the spectacular failures — a building several hundred kilometres from site, or rotated. The mechanics are covered in IFC coordinates and georeferencing.
Where these clauses go
| Document | What belongs there |
|---|
| EIR (client-side) | What the client requires: the purpose of each delivery, the classification system, the asset data expected at handover. |
| BEP (delivery team) | How it will be met: these four clauses, the named rule set, the export configuration references, the responsibility matrix. |
| BEP appendix | The acceptance criteria table — one row per criterion, with the project position filled in before the first delivery. |
| Transmittal | The per-delivery statement: revision, suitability, score, rule set, and any findings accepted by agreement. |
The clauses are worth little on their own — they need a place where the receiver applies them, which is the acceptance criteria table.That table is the subject of the next article: IFC acceptance criteria — how to accept or reject a model without an argument. And once a container passes, the question becomes what travels with it, which is covered in what to hand over with an IFC model.
The one-paragraph version
If your BEP is already written and reopening it is politically expensive, add this single paragraph to the information delivery section and you will have captured most of the value:
IFC containers issued at S2 or above shall be checked with the project rule
set immediately before issue, shall reach a Health Score of at least 80/100,
and shall carry persistent GlobalIds between revisions. The check report
shall accompany the container; exceptions require the written agreement of
the Information Manager.
To see what those requirements look like in practice before you commit to them, run the checks on a model you have already delivered — the pre-delivery model check workflow takes about a minute per file, and the result will tell you whether 80 is a generous threshold on your project or an ambitious one.
BEP Clauses That Actually Prevent Bad IFC Deliveries