Free BIM validators check if IFC-SG parameters exist. They don't check if the values are right. For CORENET X, that's the difference between passing and getting sent back.
If you've been the person inside Revit at 11 PM, five people worksharing into the same model, trying to get a clean export before tomorrow's submission window, you already know what matters in a validator. It needs to work where you work. It needs to tell you more than what's missing.
Most of the free BIM validators available in Singapore right now don't do that. The companies building them come from consulting and IT services backgrounds. They built a tool, but the tool isn't their business. Their business is the service that follows. They can parse IFC schemas and list CORENET X data requirements. But they've never sat in that chair at 11 PM.
Free validators do something useful. Upload your model, get a report, see what's missing. They check whether mandatory IFC-SG parameters exist on your model elements. If you've never exported an IFC file for CORENET X, that gives you a fast picture of how much work is ahead. You see the gaps. It's a starting point.
Parameter existence and parameter correctness are two different problems. Most free validators solve the first one. Almost none of them solve the second. And for CORENET X submissions, the second one is where your submission actually passes or fails.
When a free validator scans your IFC file, it's asking one question per element. Does this property set field have a value, or is it empty?
If your IfcDoor is missing the SCDF-required fire rating property, the validator flags it. If your IfcSlab doesn't have the BCA accessibility parameter populated, you see a red line in the report. This is useful. On a large model with hundreds of elements across multiple disciplines, knowing that 847 fields are empty saves you from finding them manually.
Some validators also group errors by entity type, by floor level, or by the agency that requires the parameter. That helps with triage. If you know 60% of your missing parameters are BCA accessibility fields on Level 3, you can work through them systematically.
But the check stops at the boundary of "is something there." It doesn't ask what's there. It doesn't know if what you entered is right.
A fire-rated wall in BCA's Code on Accessibility requires specific values depending on the wall's function, location, and the building's occupancy type. An external wall in a residential building has different fire resistance requirements from an internal wall in a hospital corridor. Both walls need a fire rating parameter. But the correct value for each is different, and the determination depends on rules that sit inside BCA's Code of Practice, not inside the IFC schema.
A free validator that checks existence will tell you both walls need a FireRating value. It won't tell you what that value should be. It won't tell you that the hospital corridor wall needs FRP 120 while the residential external wall needs FRP 60. It won't tell you that if you typed "1 hour" instead of "FRP 60," the value exists but the format doesn't match what CORENET X expects.
This is the gap. The IFC-SG schema defines what fields must be present. BCA's Code on Accessibility, SCDF's Fire Code, NEA's environmental requirements, and URA's planning parameters define what values those fields need to contain. A validator that checks one without the other gives you a compliance checklist that's half complete.
One of the free validators available in Singapore says this directly on their own features page. The tool checks for the existence of mandatory IFC-SG parameters, but does not validate the correctness of the values or check for design compliance. That's an honest statement. The problem is that most users don't read the fine print. They see a green checkmark on 4,200 out of 5,000 parameters and assume those 4,200 are correct. They're not necessarily correct. They're populated. Those are different things.
If your free validator only checks existence, you need a second tool to check correctness. Some validator providers acknowledge this openly. One points users to a separate company's model checker for actual compliance verification against BCA's Code of Practice on Accessibility.
So now your workflow is export IFC from Revit, upload to Validator A for parameter existence checking, fix the empty fields, then upload to Checker B for compliance verification, find out some of the values you just entered are wrong, go back to Revit, fix the values, re-export, re-upload to both tools, repeat.
Two tools. Potentially two companies. Two different interfaces. Two different error reporting formats. And you're still doing all of it outside Revit, on an exported snapshot that's already drifting from your live model.
I talked about the export-upload-triage loop in "The Hidden Cost of 'Free' BIM Compliance Tools." That loop gets worse when you add a second external tool to the cycle. Every additional handoff between tools is another context switch, another file transfer, another wait.
And there's a subtler problem. When two separate tools are responsible for two halves of compliance, who owns the gap between them? If Validator A says the field is populated and Checker B says the value is wrong, the practitioner has to reconcile between two different systems. Neither tool sees the full picture. You do. That reconciliation work falls on you, in the gap between two browser tabs and a Revit model on your other screen.
Practitioners already know this, even if tool vendors don't. Every application you add to a submission workflow is another place where things break.
If you've sat in a BIM team during a submission crunch, you know what software sprawl feels like. Revit is open. Navisworks is open. BIMCollab or Solibri is running for coordination. Someone has a browser tab with the validator. Someone else is cross-referencing a PDF of the IFC-SG mapping table. The shared model is on your firm's server or on Autodesk Construction Cloud, and five people are worksharing into it while you're trying to fix parameters that a web tool flagged two hours ago on an export that's already out of date.
Every tool you add to that chain is another place where reality forks. The Revit model is the source of truth. It's the file your team is actively working in. It's the file that gets exported for submission. Every external tool that asks you to upload a snapshot, triage in a browser, fix in another interface, and then go back to Revit to make the actual change is adding distance between you and the source of truth.
Practitioners know this instinctively. You learn it the first time you spend 45 minutes fixing errors that a validator flagged on an export from 10 AM, only to discover your colleague renumbered half the rooms at 10:30. The snapshot you were triaging was already wrong. The fix work was wasted. You re-export, re-upload, start over.
Companies that come from a consulting or services background design workflows that look like consulting engagements. You hand them the file, they process it externally, they hand back a report, you reconcile. That workflow makes sense when you're billing by the hour. It doesn't make sense when you're the one doing the fixing, on a deadline, in a model that four other people are still working in.
More tools entering this space is a good thing. The industry needs them before October 2026. But there is a difference between a consulting company that ships a free tool and a software company that ships specialist tools for practitioners. The first builds for lead generation. The second builds because the tool working is the entire business. When there is no consulting arm behind the software, the software has to actually solve the problem.
The fewer tools between your model and your submission, the fewer places things drift. That's not a product opinion. It's something anyone who's been through a deadline-week submission cycle already knows.
If your validation tool understands the rules and the schema, the workflow collapses.
Instead of checking whether a FireRating field exists and then separately checking whether the value is correct, a rule-aware validator does both in one pass. It knows that the wall on Level 5 of a hospital needs FRP 120 because it can read the element's properties and look up the applicable BCA rule.
That's the difference between schema validation and compliance validation. Schema validation asks whether the field is there. Compliance validation asks whether what's in the field is right, given the building code that applies to this element in this building type in this location.
When I was at DP Architects working on Expo City Dubai, the most time-consuming part of authority submissions wasn't populating empty fields. We were organised enough to catch those early. The time went to figuring out if the values were correct for each element's context. Fire ratings, accessibility widths, egress calculations, material grades. Every one of those depends on rules that aren't in the IFC schema. They're in the building code.
This is why Gateway validates IFC-SG schema compliance inside Revit, before you ever export. No browser tab, no uploaded snapshot, no drift from your live model. Schema validation is the foundation. Code compliance comes next.
And it's why being an Autodesk Authorised Developer matters for this kind of tool. Building inside the authoring environment requires direct access to the Revit API, not a file parser reading an export. You need to be reading the full model, not a snapshot of it.
If you're evaluating compliance tools for October 2026, there are a few questions worth asking.
Most free tools check existence only. That's useful for a first pass but it won't tell you if your submission will actually pass agency review.
If it happens in a browser on an exported file, you're working on a snapshot. You're outside your authoring tool. You're in the export-upload-fix loop. If it happens inside Revit, you're validating live data, fixing in context, and exporting once when the model is ready.
Rule-based validation tells you what's wrong in a model you think is done. That's valuable at submission time. But the most expensive compliance failures are the ones you discover after coordination is finished, when fixing a corridor width means reopening structural and MEP layouts. The next generation of compliance tools will need to work during design, not after it.
Free tools are fine for a first look. They show you how much work is ahead. For production workflows with real submission deadlines, you need a tool that goes further than checking whether a field exists. You need one that tells you whether what's in it will pass.
Adib Zailan is the technical founder of & Senibina, an Autodesk Authorised Developer building BIM compliance and interoperability tools for architecture practices in Singapore. Before this, he worked at DP Architects on authority BIM submissions for Expo City Dubai and Dubai Square.
Gateway is in Private Alpha with Founding Firms. If your practice is preparing for October 2026 and wants IFC-SG validation inside Revit before you export, the Founding Firm program is open.