What causes IDS content errors?

IDS checklists are authored by people, usually BIM managers, information managers, or consultants, and like any hand-authored content, they can contain mistakes. Common issues include:

Referencing a property that doesn't exist. The checklist asks for a property by name, but that property isn't defined in the IFC standard for the entity being checked. This can happen when a property name is misspelled, or when the checklist author assumed a property existed based on a different IFC version or a software-specific extension.

Using the wrong entity type. The checklist specifies an IFC entity (like IfcWall or IfcDoor) that doesn't exist in the version of IFC being used, or has been renamed between versions.

Data type mismatches. The checklist expects a property value in a specific format (a number, a string, a boolean) that doesn't match how that property is actually defined in the IFC schema.

Invalid restriction patterns. The checklist uses a pattern or enumeration constraint that doesn't conform to the IDS specification, making it impossible for the checker to evaluate.

How to read the processing errors

When the checker encounters these issues, it logs them in the "Processing errors" section of your results. These messages come directly from the validation engine and can be quite technical. Here are some common ones and what they mean:

"Unexpected entity 'IfcSomething'" means the checklist references an IFC entity type that the checker doesn't recognise. This usually means the entity name is misspelled or doesn't exist in the IFC version being checked.

"Property 'SomeName' not found" means the checklist expects an entity to have a property with this name, but it's not defined in the IFC schema. The property might exist in a different property set, under a different name, or only in a different IFC version.

"Could not validate requirement" means the checker couldn't evaluate a particular rule at all. This is a catch-all for various issues with how the requirement was defined.

Don't worry if these messages are hard to interpret. They're primarily useful for whoever authored the checklist. The key thing is that they indicate the checklist itself has issues that need fixing.

What to do about it

If you authored the checklist, review the processing errors and update the affected specifications. An IDS authoring tool with validation (such as the buildingSMART IDS Editor) can help catch these issues before you publish the checklist. Pay attention to property names, entity types, and which IFC version each specification targets.

If you received the checklist from someone else, share the results with them, including the processing errors section. They'll need to update the checklist to fix the issues. The results you did get for unaffected specifications are still valid. It's only the specifications with errors that need attention.

If a specification shows as "Error", this means the checker couldn't complete that particular check at all. It won't have any pass/fail results for that specification. This is different from a specification that ran but produced unexpected results.

Can I still trust the other results?

Yes. IDS content errors affect individual specifications, not the entire check. If your checklist has ten specifications and two of them have content errors, the results for the other eight are unaffected. Data Octopus processes each specification independently, so a problem with one doesn't contaminate the rest.

Look at which specifications are flagged in the suggested improvements and processing errors. The rest of your results are reliable.