Checking the model

Imagine a small IFC file. 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 does not 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. Keeping the two apart is most of what this page is for.

“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 is not checking.

Two viewers can legitimately draw the same file differently - they resolve representations differently, they handle openings differently, they may show you one context where another shows a second. A model that looks wrong in somebody’s viewer is not thereby defective, and a model that looks right has told you nothing about the greater part of itself, which has no shape at all. It is the same mistake as judging IFC by the exports you have seen, described in The file is the document: 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, and it runs from a command line without Blender open:

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

You will not often need it on your own work, because Bonsai writes the file and does not tend to write invalid ones. It earns its keep on files that arrive from elsewhere. When something is behaving strangely and you cannot tell whether the problem is the model or the software reading it, this separates the two.

Does it contain what was asked for?

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

The mechanism is IDS - Information Delivery Specification - and it is worth slowing down for, because it is the part of this that 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(...)

Which names the requirement, the object that failed it, and why.

The specification is a file, and somebody else writes it

That is the part that changes how the work is organised.

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 does not, and it was agreed before the work started. If you have spent time being told at handover that a model is not what somebody expected, this is the machinery for never having that conversation again.

Reports are meant to be sent

Both tools produce reports rather than just printing to a screen. IDS results come out as HTML to send to somebody, as a spreadsheet for people who live in spreadsheets, as JSON for anything automated - and as BCF, which turns each failure into an issue that can travel into somebody else’s software and be answered there.

That last one is the join to Other people’s models, and it is worth noticing which direction it goes: a requirements check produces issues, and issues are how models get discussed between people.

What this is not

Checking is one model measured against a written requirement. It is not clash detection, which is several models disagreeing about who is entitled to occupy a particular cubic metre. Those are different questions with different tools, and the second belongs to Other people’s models.

The distinction is worth holding on to, 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 does not collide with the ductwork.

Last updated 4 September 2026.