Back to the BIM & IFC blog
Delivery & ISO 19650 · 2026-08-07 · 9 min
What to Hand Over With an IFC Model (Beyond the IFC)
A delivery is a claim: this model is fit for this purpose at this revision. Evidence is what turns the claim into something the receiver can check without repeating your work — and what stops the same argument happening twice.
What to Hand Over With an IFC Model (Beyond the IFC) — IFC Viewer Online article cover
Every IFC delivery is an assertion: this model is fit for this purpose, at this revision. The file itself does not carry that assertion — it carries geometry and data. Everything that makes the assertion checkable travels alongside it, and on most projects almost none of it does.
That is why the same conversation happens twice. The first time, somebody checks the model and finds it acceptable. The second time — a month later, a different person, a different gateway — somebody checks it again, because there was no record of the first check that anybody could rely on.
Five artefacts, four of which you already have
| Artefact | Answers | Audience |
|---|
| Validation report | What was checked and what was found | The receiving coordinator |
| Check record | That the check happened, on this exact file, at this time | The information manager, the client, an auditor |
| Issue file (BCF) | What is not fixed, and where to look | The person who has to act |
| Asset data (COBie) | What the building contains, as data | The client and the FM team |
| Transmittal note | Revision, status, score, rule set, waivers | Everyone, and the record |
Assembling all five takes about ten minutes once, and rather less every time after that. It replaces roughly four emails per delivery, and it is the difference between a delivery that is accepted and a delivery that is discussed.
1. The validation report
Export it, attach it, and do not paraphrase it in the email body. Three properties make a report useful to somebody who was not there when it ran:
- It names the rule set, not just the results. A score without its rule set cannot be interpreted, and cannot be compared to the next revision.
- It states coverage — which checks ran, which did not. A report that cannot distinguish "passed" from "not attempted" is a marketing document.
- It carries element identifiers, so a finding can be located rather than hunted for. A report you have to go looking with is a report nobody uses twice.
If you are not sure which findings in your report are worth reporting on and which are noise, the most common IFC model errors is a reasonable triage list — the structural ones are the ones a receiver cares about.
2. The check record
The weakest link in every quality process is that the check and the claim are separate things. Anyone can say a model scored 92. A check record ties the number to a specific file: the file's own fingerprint, the rule set, the schema, the timestamp, the score.
Two properties make such a record worth more than a screenshot of a panel:
- It is derived from the file's content, so that changing one byte of the model and re-issuing the same record is detectable.
- It is verifiable by the receiver, independently, without your involvement. A record that only your own software can confirm is a promise, not evidence.
3. The issue file
BCF exists so that issues survive leaving your screen. Its whole value is the viewpoint: a camera position, a selection and a comment, which together mean the receiver spends ten seconds finding the problem instead of ten minutes.
Two conventions separate a BCF file that gets acted on from one that gets ignored:
- One topic per cause, not per element. Four thousand elements missing a property set are one topic with a representative viewpoint — not four thousand topics that make the file unopenable.
- Title the topic with the rule identifier and the fix, not the symptom. "Missing property set — add the required Pset to the export template" is actionable; "missing properties" is a complaint.
4. Asset data
COBie, or whatever schedule your client asked for, is the point at which model quality becomes commercially visible — because it is delivered to somebody who never opens a model and has no way to interpret an excuse.
It is also, usefully, a validator of your validator. Spaces without names, types without manufacturers, components not assigned to a space: those gaps arrive as blank columns that a facilities manager can see at a glance. If a COBie export from your model would be embarrassing, the model is not ready, whatever the geometry looks like.
5. The transmittal note
Six lines, and it prevents most delivery disputes:
Container: {filename}
Revision/status: {rev} - {suitability code}
Schema: {IFC2X3 | IFC4 | IFC4X3}
Checked: {date} - rule set {name} - {n} of {n} checks completed
Health Score: {score}/100
Open by agreement: {rule id - reason - agreed with - date}
Not suitable for: {e.g. quantity take-off, fabrication}
The last line is the one people skip, and it is the one that protects you. Stating what a container is not for is not defensive — it is the definition of a level of information need, delivered at the only moment anybody actually reads it.
What this adds up to
Nothing here is new technology, and none of it requires a tool you do not already have. What it requires is treating a delivery as a claim that somebody else has to be able to check — which is a small change in posture with a disproportionate effect on how many deliveries come back.
The criteria the receiver applies to all of this are covered in IFC acceptance criteria, and the clauses that make them binding in BEP clauses that actually prevent bad IFC deliveries. For the ISO 19650 framing around all three, see the ISO 19650 IFC delivery checklist.
What to Hand Over With an IFC Model (Beyond the IFC)