As Singapore’s built environment transitions towards structured digital submissions through CORENET X, project teams are becoming increasingly familiar with IFC+SG.
But producing an IFC+SG file is not the same as producing good IFC+SG information.
A model can export successfully and still contain information that is incomplete, incorrectly classified or unsuitable for automated validation. For organisations preparing their BIM workflows for CORENET X, this distinction is important.
The challenge is no longer simply: Can our software export IFC?
It is increasingly: Does the information inside our IFC model mean what the receiving system expects it to mean?
IFC+SG is an information requirement, not just an export format
IFC provides a standardised way of representing built assets and their information. IFC+SG applies this framework to Singapore’s regulatory submission requirements.
For project teams, this means that preparing for IFC+SG involves more than configuring an exporter.
Teams need to understand:
how model elements should be classified
which properties are required for particular elements
when requirements apply only to specific types of elements
how information created in authoring software is mapped into IFC
and how the resulting IFC information will be interpreted by downstream validation systems
These decisions affect modelling standards, templates, BIM execution processes and quality assurance.
Example: what does “N.A.” in the Industry Mapping Table mean?
The IFC-SG Industry Mapping contains information about IFC classes, subtypes and the parameters associated with them.
Consider a simplified example where a requirement is mapped to an IFC class and the IFC Sub Type is stated as N.A.
It would be easy to interpret this as meaning that the element should have no defined subtype, or that “N.A.” is itself a classification to be assigned.
That is not the intended interpretation.
Where the IFC Sub Type is stated as N.A., the parameters on that row apply across the relevant subtypes (including those specified in the IFC+SG Industry Mapping Table, NOTDEFINED, USERDEFINED and other IFC4.3 subtypes).
In practical terms, N.A. means that subtype is not being used to restrict the applicability of that particular information requirement.
Compare that with a requirement associated specifically with a particular subtype. In that situation, the subtype becomes part of determining whether the requirement applies.
It looks like a small distinction in a spreadsheet. For automated validation, however, it can materially change the result.
Why interpretation matters
Imagine that a validation rule incorrectly treats N.A. as meaning “only elements without a defined subtype”.
An element with a valid subtype could then be excluded from a check even though the information requirement was intended to apply to it.
The opposite problem is also possible. A requirement intended only for a particular subtype could incorrectly be applied to every element in the IFC class.
Both situations create unreliable validation.
This illustrates a broader challenge with digital regulatory submissions: information requirements have to be understood semantically before they can be automated correctly.
A spreadsheet cannot simply be converted cell-by-cell into checking rules without understanding what each field means and how applicability is determined.
What this means for project teams
For organisations implementing CORENET X workflows, IFC+SG readiness therefore needs to extend across the information lifecycle.
Modelling standards need to define how project information should be created and classified.
Authoring templates need to support the required information structures.
Export configurations need to map authoring data correctly into IFC-SG.
Quality assurance processes need to check the resulting IFC information before submission.
Automated validation needs to apply each information requirement to the correct population of model elements.
If these pieces are treated separately, problems often appear only at the end of the workflow.
A better approach is to work backwards from the information requirement: understand what needs to exist in the submitted IFC, determine how that information should be represented, and then configure the modelling and validation workflow accordingly.
From BIM compliance to information governance
This becomes even more important as the built environment moves beyond digital submissions towards greater automation and AI.
Automated systems can only act reliably on information when its meaning is sufficiently structured and consistent.
An IFC model containing poorly classified or inconsistently structured information does not become machine-ready simply because it is digital.
This is why CORENET X readiness should be viewed as part of a broader information-management capability.
The immediate objective may be regulatory submission. But the same disciplines (structured information, consistent classification, clear information requirements and validation) also create better foundations for coordination, automation, analytics and AI.
At AcePLP, we help project teams translate digital delivery requirements into practical BIM workflows, including IFC+SG and CORENET X readiness, modelling standards, information management and model validation.
The goal is not simply to produce an IFC file.
It is to produce information that people and machines can interpret consistently.
Frequently Asked Questions
What is the difference between exporting to IFC and validating IFC+SG?
Exporting to IFC creates an IFC file from the authoring model. IFC+SG validation goes further by checking whether the information inside that file has been classified, structured and populated in the way required for Singapore’s digital submission workflows.
A file can therefore export successfully while still containing missing properties, incorrect classifications or information that downstream systems cannot interpret correctly.
Is successfully exporting an IFC file enough for CORENET X?
No. Successful export only confirms that an IFC file has been generated.
For CORENET X workflows, project teams also need to consider whether model elements are correctly classified, whether the required IFC+SG properties are present, whether authoring information has been mapped correctly into IFC, and whether validation systems will apply those requirements to the correct elements.
Why can an IFC model look correct but still have validation problems?
Humans can often recognise an element from its geometry and context even when its underlying information is incomplete or inconsistent.
Automated systems rely much more heavily on explicit information such as IFC classes, subtypes, properties and values. A model can therefore appear visually correct while still containing information that cannot be reliably checked by software.
What does “N.A.” mean in the IFC+SG Industry Mapping Table?
Where an IFC Sub Type is stated as N.A., it does not mean that the element must have no subtype or that “N.A.” should be assigned as a subtype.
It means that subtype is not being used to restrict the applicability of that particular information requirement. The associated parameters can therefore apply across the relevant subtypes.
This distinction matters because interpreting N.A. incorrectly can cause automated validation rules either to exclude elements that should be checked or to apply requirements too broadly.
When should IFC+SG validation be carried out?
Validation should not be left until the final submission stage.
A stronger workflow works backwards from the information requirement: understand what the submitted IFC needs to contain, determine how that information should be represented, configure the modelling and export processes accordingly, and validate the resulting information before submission.
How should organisations prepare their BIM workflows for IFC+SG?
IFC+SG readiness should extend across the information lifecycle.
This includes defining appropriate modelling standards, configuring authoring templates, mapping information correctly during IFC export, checking the resulting IFC information and ensuring automated validation applies requirements to the correct model elements.
The objective is not simply to produce an IFC file, but to produce information that both people and machines can interpret consistently.
