Checking the model

Imagine a small IFC file: a building model as Bonsai saves it, written to a published, open standard. It contains a project and one wall, and the wall has no properties at all.

Ask whether it is a valid IFC file and the answer is yes, without qualification - it conforms to the standard, and a validator reports no issues. Ask whether it is an acceptable model and the answer is obviously no, because nobody wants a wall that doesn’t know what it is rated to.

Both answers are correct. They are answers to different questions, produced by different tools, and a model can sail through one while failing the other badly.

“It looks right” answers neither

The instinct is to open a file in a viewer and look at it. That is worth doing and it isn’t checking.

Two viewers can legitimately draw the same file differently: they resolve representations differently, and they may show you one context where another shows a second. A model that looks wrong in somebody’s viewer isn’t thereby defective, and a model that looks right has told you nothing about the greater part of itself, which has no geometry at all. It is the same mistake as judging IFC by the exports you have seen: taking the most visible surface for the thing.

Is it a valid file?

This is a question about the file alone, answerable without knowing anything about the project. Are the entity types real ones, are mandatory attributes present, do the references point at things that exist, are the standard’s own rules satisfied?

The tool for it is the validator built into IfcOpenShell. Bonsai will run it over the project you have open, and the same validator runs from a command line, over a file, without Blender open at all:

python -m ifcopenshell.validate model.ifc --rules

That second form is the one you want for a folder of files somebody sent you, or for checking one before you open it; it is one of several tools that run with Blender and without it. You won’t often need it on your own work, because Bonsai doesn’t tend to write invalid files. It earns its keep on files that arrive from elsewhere, and when something is behaving strangely and you can’t tell whether the problem is the model or the software reading it.

Does it contain what was asked for?

This is a different question entirely, and it can’t be answered by looking at the file, because the answer depends on what somebody wanted.

The mechanism is IDS - Information Delivery Specification - which a reader from Revit is least likely to have met.

An IDS is a document containing specifications, and each specification has two halves. An applicability clause says which objects it is about: all walls, or all doors on the ground floor, or everything with a particular classification. A requirements clause says what must be true of those objects: they must carry this property set, they must have that classification, they must be made of a named material.

Run such a check against the wall imagined at the top of this page and the result reads like this:

[FAIL] (0/1) Wall fire rating
    Applies to:
        All IFCWALL data
    Requirements:
        FireRating data shall be provided in the dataset Pset_WallCommon
            The required property set does not exist - #2=IfcWall(...)

The report names the requirement, the object that failed it, and why.

A requirement needn’t be about a property. A file with a wall that was never assigned to a storey is valid too, and the validator passes it; a specification saying that every wall must be contained in a storey is what catches it. What an IDS can’t do is compare objects with each other: it tests each one on its own, so a rule such as no two doors share a Name is a job for a short script instead.

Bonsai loads an IDS and runs it against the project you have open, and since a failure is an object rather than a line of text, you can select the objects that failed a specification and colour them in the viewport. Looking at which walls have no fire rating is a good deal more useful than reading a list of their ids.

The specification is a file, and somebody else writes it

An IDS is an ordinary exchangeable file, and the person who writes it is normally not the person who makes the model. A client writes one. A BIM manager writes one from the execution plan. A contractor writes one describing what they need in order to price the job.

They send it to you at the start. You check your own model against it before you deliver, fix what fails, and send both the model and a report. They run the same check on receipt and get the same answer, because it is the same specification file and the same test.

What that removes is the argument. “Deliver a model with fire ratings on all walls” is a sentence in an email that two people can read differently. An IDS is a test that either passes or doesn’t, and it was agreed before the work started.

Reports are meant to be sent

IDS results come out as HTML to send to somebody, as a spreadsheet, as JSON for anything automated, and as BCF - the BIM Collaboration Format - which turns each failure into an issue that can travel into somebody else’s software and be answered there.

BCF is where checking meets other people’s models: a requirements check produces issues, and issues are how models get discussed between people.

What this isn’t

Checking is one model measured against a written requirement. It isn’t clash detection, which is several models disagreeing about who is entitled to occupy a particular cubic metre.

The distinction matters, because “the model has been checked” is said about both and means quite different things. One says it contains what was asked for; the other says it doesn’t collide with the ductwork. Clash detection belongs with other people’s models.

Last updated 8 October 2026.