Intent
Viewing an IFC model is not the same as checking it
An IFC viewer answers visual and exploratory questions: can the file be opened, where is an element, and which properties does it carry? An IFC model checker starts with a defined requirement or review question and compares the model against it. Keeping those jobs separate prevents a smooth-looking model from being mistaken for a complete or compliant information delivery.
- Visual navigation provides geometry and coordination context.
- Property inspection helps a reviewer understand the information attached to selected elements.
- Structured validation needs explicit requirements and an interpretable result.
Information quality
Check IFC properties in context before automating
Start by sampling representative elements in ExyViewer. Confirm entity mapping, names, classifications, property sets and quantities that matter to the intended use. This manual inspection exposes export conventions and inconsistent data before a broad automated run creates hundreds of failures that the team cannot interpret. A missing value, a value on the wrong entity and a valid project exception are different findings.
- Choose the model areas and element groups that match the delivery scope.
- Inspect representative property sets before defining a pass or fail rule.
- Record the responsible discipline and expected correction path.
IDS validation
How do you check an IFC model against IDS?
Start with project information requirements expressed in a reviewed Information Delivery Specification (IDS). Load the delivered IFC model and the IDS in ExyViewer, run the check, then inspect which objects satisfy the applicability rules and which required properties are missing or invalid. IDS makes selected Exchange Requirements machine-readable, but the specification must accurately express the project need and every result still requires professional interpretation.
- Define and review the information requirements before running the IDS check.
- Keep the IDS, IFC model version and Exchange Requirement context together.
- Group and inspect failures to distinguish systematic export problems from isolated exceptions.
Issue workflow
What happens when an IDS requirement fails?
A failed IDS requirement is a review result, not a correction by itself. In ExyViewer, reviewers can investigate the affected objects, keep the requirement and model context visible, and organize actionable findings as BCF issues or report items. Each issue should include enough viewpoint, element and requirement context for the responsible authoring team to correct the source model before the IFC is exported and validated again.
- Avoid converting every machine result into an issue automatically.
- Preserve viewpoint, selected elements and a concise statement of the requirement.
- Recheck the corrected model version against the same agreed scope.
Limits
What automated BIM validation cannot prove
IDS validation checks delivered IFC information against project-specific requirements. It is different from IFC schema and conformance validation, and ExyViewer does not claim to provide the official buildingSMART Validation Service. Automated checks cannot prove design quality, engineering adequacy, contractual acceptance or regulatory compliance. Geometry that passes a clash tolerance may still be unbuildable, and a property that satisfies an IDS rule may still be wrong for the project. Use the checker as evidence within governance, not as an automatic approval stamp.
Practical sequence
IDS validation workflow from requirement to revalidation
Define the information requirement, express it in a reviewed IDS, receive the IFC delivery and run the model check. Investigate failed requirements in their 3D and data context, promote actionable findings into BCF or a report, correct the source model and validate the next IFC version against the same scope. This requirement-to-revalidation sequence keeps model validation explainable and reduces false urgency from unscoped result lists.