IFC entity type and classification are different
Every IFC object has an entity type defined by the IFC schema, such as IfcWall, IfcDoor or IfcFlowTerminal. A classification reference is additional information that places the object in a project or national system, such as Uniclass, OmniClass, CoClass or NL-SfB, using that system's code and title.
The two answer different questions. The entity type says what kind of object the schema considers it to be; the classification code says how the project groups it for cost, specification, maintenance or handover. A model can be structurally valid IFC and still fail a classification requirement because required codes are missing, belong to the wrong system or edition, or do not exist in the agreed table.
How IFC stores a classification reference
| IFC element | Role | What to check |
|---|---|---|
| IfcClassification | Describes the system itself: its name, source, edition and edition date | The system name and edition match the project requirement |
| IfcClassificationReference | One code from that system, with its identification and name, pointing to the system it comes from | The code exists in the agreed table and its name matches |
| IfcRelAssociatesClassification | Links a classification reference to the objects or types it applies to | Every object that needs a code is linked, directly or through its type |
Official references
Write the requirement before checking
- Name the system and the edition or table, and say how a newer edition will be handled during the project.
- Define which objects need a code: by IFC entity, by predefined type, by discipline or by a property such as an asset flag.
- State whether the code belongs on the occurrence, on its type or on both, and which applies when they differ.
- Specify the expected format: separators, letter case, leading zeros and whether a title must accompany the code.
- Say whether more than one system may be used on the same object and how each is identified.
- Record who assigns codes in each discipline model.
Where the project uses buildingSMART IDS, a classification requirement can be written as a classification facet that names the system and, optionally, the allowed values, applied to the objects the specification selects. Keep the written requirement and the IDS file under the same revision control.
Official references
Run a repeatable check
Confirm the system
List every classification system in the file and compare its name and edition with the requirement. An unexpected second system often reveals an authoring template that was not updated.
Find missing codes
Select the objects the requirement applies to and report each one without a reference from the agreed system, taking codes inherited from its type into account as the requirement specifies.
Validate the values
Compare every code with the agreed table. Report codes that do not exist, are formatted differently or use a heading that is too general for the object.
Check consistency
Report objects whose occurrence and type carry different codes, and objects of the same type with different codes where the requirement expects one.
Record the result
Record the file, revision, rule set and the counts of passed, failed and not-checked objects, and list every accepted exception with its owner.
The check can run in an IDS-capable checker, in the authoring application or as a script. Whichever you use, run the same rule set on every revision so results can be compared.
Common failures and their causes
| Finding | Likely cause | Typical correction |
|---|---|---|
| Codes exist in the authoring model but not in the IFC file | The export mapping does not include the classification parameters | Map them to IFC classification references in the export settings and export again |
| Correct codes, wrong system name or edition | An outdated template or object library | Update the system definition at the source and export again |
| Codes stored as plain properties | A property-based workaround in the export | Agree whether a property is acceptable; if not, change the mapping |
| One object type with different codes | Codes assigned per occurrence without coordination | Assign the code on the type, or apply a rule in the authoring tool |
| Code too general | A default heading used as a placeholder | Replace it with the most specific code the requirement asks for |
Correct classification at the source and export again. Editing a delivered IFC file directly breaks the link with the authoring data, and the edit has to be repeated on every revision.