Use several layers of checking
buildingSMART's IFC Validation Service checks conformity to STEP syntax, the referenced IFC schema and normative specification rules, with additional industry-practice checks. These checks address file conformity. They do not replace a project's review of intended scope, geometry, information or fitness for use.
Agree acceptance criteria before exporting. A file that opens successfully can contain missing objects, unexpected coordinates or incorrect data. Separate automatic results from manual inspection so the recipient can see the evidence behind each conclusion.
Official references
A practical review checklist
| Check | Evidence to keep | Action if it fails |
|---|---|---|
| File and package integrity | File names, sizes, revisions and optional checksums | Repeat or repair the transfer before investigating content. |
| Schema and readability | Exporter and importer versions; validation/import report | Resolve unsupported or malformed content. |
| Scope | Expected disciplines, areas, object groups and exclusions | Compare source selection with exported content. |
| Scale and coordinates | Known measurement and control-point comparisons | Resolve units, reference systems or transforms. |
| Geometry | Representative views of openings, curves and thin elements | Investigate source geometry and output settings. |
| Information | Required fields, rule-set version and object-level failures | Correct source data or mapping; rerun the rules. |
| Appearance | Accepted comparison of colours and transparency | Check material settings and package dependencies. |
| Receiving workflow | Result of the recipient performing the intended task | Revise the exchange configuration and retest. |
Compare counts only when the counting rules are equivalent. A source item can be split into several output objects or multiple items combined. Record the reason for a difference rather than declaring every count mismatch an error.
Choose a sample that can reveal failures
- Include every required discipline and object category.
- Include large and small components, curves, openings and elements near the edge of the export scope.
- Include items with required properties and known source values.
- Include repeated types and individual occurrences so inheritance and identity can be inspected.
- Use automated checks across the whole delivery where available, and record the limits of manual sampling.
Make each failure reproducible
Give each finding an issue identifier, model revision, affected object identifiers, expected result, actual result and reproduction steps. Assign an owner and a due date. Add a view or image when it explains the location, but keep the written condition understandable without the image.
After correction, rerun the failed check and any checks that could be affected by the change. Save the new report separately from the original. Use explicit statuses such as passed, failed, not checked and accepted exception, with a named approver for exceptions.
Close the review with an acceptance record
- Identify the exact reviewed file and source revisions.
- List the tools, settings and checks used.
- Record unresolved issues and approved exceptions.
- State the permitted purpose of the delivery and any limitations.
- Name the reviewer and record the review date and decision.
If using an online validation service, confirm that the model may be uploaded under the project's information-sharing rules. An offline check or an approved minimal sample may be more appropriate for restricted data.