Passing the buildingSMART validation is not the same as good data
Summary
The buildingSMART validation service is the official conformance check for IFC files, provided by buildingSMART International, the organisation that maintains the IFC standard. It tells you whether a file is a correctly written IFC file: readable as a STEP file, matching the IFC schema it declares, and following further rules from the IFC documentation and from agreements between software vendors.
That check is necessary, and forensicBIM shows its result in every report. It does not tell you whether the data is of any use to you. IFC allows a model to consist entirely of generic proxy objects with no classification and no properties, and such a file can be valid against the schema. It looks right in a viewer, but software cannot tell a beam from a pump, count the doors or link anything to an asset register.
The rest of the forensicBIM report measures that gap: whether the objects say what they are, and whether they carry data someone can use. When you accept IFC deliveries, ask for both.
What the validation checks
The service reports its results in eight topics. forensicBIM shows each one with the status the service gave it:
| Topic | What it covers | Shown on |
|---|---|---|
| STEP syntax | The file can be read as a valid STEP physical file (ISO 10303-21), the plain-text format IFC files are usually written in. | Validity |
| IFC schema | Every entity and attribute matches the declared IFC schema, including types and cardinalities (how many values an attribute may hold). | Validity |
| Header syntax | The file header (FILE_DESCRIPTION, FILE_NAME, FILE_SCHEMA) is well-formed. | Validity |
| Header fields | Header fields such as the MVD, authoring tool and timestamp are filled in correctly. | Validity |
| Prerequisites | Basic conditions the other rule checks depend on, such as a valid project and units context. | Validity |
| Informal propositions | Rules written in the IFC documentation that the schema itself cannot enforce. | Validity |
| Implementer agreements | Agreements between software vendors on how to structure IFC, for example spatial structure, placements and representations. | Structure |
| Industry practices | Good-practice recommendations. Deviations are reported as warnings. | Consistency |
An entity is the IFC word for a kind of object, such as IfcWall or IfcPump. All eight topics are about whether the file uses the schema correctly.
Why a valid file can still be poor data
IFC has a generic entity for objects that do not fit, or were not mapped to, a specific class: IfcBuildingElementProxy, usually called a proxy. It is a legitimate part of the schema, so a file in which every element is a proxy is still written correctly. The same holds for the data on the elements. Nothing in the schema obliges an element to carry a classification, a material or a property set. A file with thousands of proxies and no properties can therefore pass the validation.
For the owner, such a file holds shapes and little else, and the cost shows up after handover:
- A quantity take-off cannot separate walls from slabs, or kerbs from safety barriers, because every object has the same class.
- Objects cannot be linked to an asset register or a maintenance system, because nothing in the file says what they are.
- Someone has to recognise each object by eye and add the missing information, paying again for data already paid for once.
Proxies are sometimes the right choice, for objects IFC has no class for. How to tell acceptable proxies from a problem, and how to make them say what they are, is explained in Proxies: when they are acceptable. How elements are given a meaning through a classification system is covered in Classification in IFC.
Where you see it in the report
The buildingSMART validation card
On the Validity page, the card buildingSMART validation shows the eight topics, each with one of these statuses: Valid / compliant, Warning, Invalid / failure, Not applicable or Not processed yet. Implementer agreements and Industry practices count on other pages, and their tiles say shown in Structure and shown in Consistency.
Once the service has processed the file, each topic also appears in the Checks list of its page, marked buildingSMART. Until then the topics are left out of the checks, and the card says that the service has not processed the file yet.
If a file has not been validated, the card offers a Run buildingSMART Validation button, which sends the file to buildingSMART's servers. The service accepts files up to 256 MB. Only files that declare IFC2X3, IFC4 or IFC4X3_ADD2 are sent.
Overview and Capabilities
On the Overview, the schema version in the About this model header carries a small label: verified when the service passed the IFC schema topic, invalid when it found schema errors, and not validated in all other cases.
On the Capabilities page, Valid STEP file depends on four topics: STEP syntax, IFC schema, Header syntax and Prerequisites. It is earned when none of them is invalid, failed when one of them is, and shown as not validated until the service has processed the file. Coordination ready includes the condition Not invalid (buildingSMART) on the same four topics, next to conditions the validation does not cover: a recognised MVD, one site, containment of at least 95%, an effective proxy share of 10% or less and geometry on at least 98% of elements.
How the results are scored
Each topic is a check in the dimension shown in the first table, with its own weight. STEP syntax and IFC schema carry the most weight and are marked key in the list view.
| Topic | Weight | Valid | Warning | Invalid |
|---|---|---|---|---|
| STEP syntax | 2 | 100 | 70 | 0 |
| IFC schema | 2 | 100 | 70 | 0 |
| Header syntax | 0.5 | 100 | 70 | 0 |
| Prerequisites | 1 | 100 | 70 | 0 |
| Informal propositions | 1 | 100 | 70 | 0 |
| Header fields | 0.5 | 100 | not scored | not scored |
| Implementer agreements | 1 | 100 | not scored | not scored |
| Industry practices | 0.5 | 100 | not scored | not scored |
Topics that are Not processed yet or Not applicable are not scored, so a file is never marked down for not having been validated. The last three topics can only raise the score: a warning or failure there is shown on the card but does not lower it. None of the eight is a gate check, so a passed topic keeps its full weight.
What the rest of the report measures
The checks that catch a valid but empty file most directly:
| Question | Checks (page) |
|---|---|
| Are objects modelled as what they are? | Share of proxies, Share of unclassified proxies (Structure) |
| Are elements classified, with a real system? | Classification coverage (Information), Classified with a real system (Consistency) |
| Do elements carry useful properties? | Effective facts per element, Informative property values, Properties with a defined meaning (Information) |
| Are materials and quantities there? | Material coverage, Quantity coverage (Information) |
The Forensic BIM score™ brings these together into one number for the data itself. It also limits the quality score, which can be at most 35 + 0.7 × the Forensic BIM score™. A correctly written file without usable data cannot score high.
Two warning tags can appear on the Overview. non-IFC data means every element is a proxy and none carries a classification reference. useless data means that no property has a defined meaning and the file has no materials, no quantities, no facility such as a building or bridge, and no alignment. For a file tagged useless data every scored check is set to 0, the buildingSMART topics included, whatever the validation said.
On the Capabilities page, Real IFC asks for an effective proxy share of 10% or less, unclassified proxies at no more than 2% of elements, effective data on the elements, and at least 30% standard property sets or URI-linked properties.
What to ask for in IFC deliveries
A pass in the buildingSMART validation is a reasonable minimum for any IFC delivery. A file that fails it may be rejected or misread by other software, and little else in it can be relied on until the export is fixed.
Data requirements belong next to it: which classification system to use, which objects may be delivered as proxies, and which properties and quantities each type of object must carry. The checks above show the gaps before you accept and pay for a delivery.
forensicBIM reads IFC2X3, IFC4 and IFC 4.3 files today and will support IFC 4.4 and IFC 5 as they are released. Why forensicBIM works with IFC at all is explained in Why forensicBIM works with IFC.
Frequently asked questions
My file passed the buildingSMART validation. Why is its score low?
The validation confirms the file is written correctly. The score also reflects whether the objects are classified and carry properties, materials and quantities, and the Information dimension counts double in the quality score. Filter the checks on To improve on the Information and Structure pages to see where the points go.
Does a missing buildingSMART result count against my file?
No. Topics that are Not processed yet are left out of the checks and not scored, and Valid STEP file shows as not validated. You can start the validation from the card on the Validity page.
What happens when a file fails the validation?
An Invalid / failure result on STEP syntax or IFC schema scores 0 on a check with weight 2, Valid STEP file shows as failed and Coordination ready misses a condition. The other checks still run on what forensicBIM could read, but the export should be fixed before the file is accepted.