Your BIM validator might check if parameters exist without checking if they're correct. Understanding this distinction changes how you choose your tools.
If you've been 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 tell you what's actually wrong, not just what's missing.
Your BIM validator falls into one of two categories, whether you know it or not. Either it's checking for parameter existence. Or it's checking for parameter correctness. These sound similar. They solve entirely different problems.
Existence checking answers one question: Is a field populated or is it empty? You upload your model, the tool scans each element, and flags any mandatory IFC-SG parameters that have no value. You see 847 missing fields across the model. You know which elements are incomplete. It's a useful first pass.
But compliance isn't about completeness. It's about accuracy. Parameter correctness answers a different question: Is the value in that field the right value for this element in this building in this regulatory context? That question sits at the boundary between the IFC schema and your building code. Most validators stop at the first question. Very few reach the second one.
An existence-checking validator scans your IFC file and asks one question per element: Does this field have a value, or is it empty?
Your IfcDoor is missing the fire rating property? Flagged. Your IfcSlab lacks the accessibility parameter? You'll see it in the report. On a model with hundreds of elements across disciplines, this saves you from manually hunting for empty fields. You see that 847 fields need values. You know where the work is.
Some validators group these gaps by entity type, floor level, or agency. If 60% of your missing parameters are BCA accessibility fields on Level 3, you work through them systematically. This kind of triage is efficient.
But the check stops at presence. It doesn't evaluate content. It doesn't know whether what you entered is correct.
Correctness checking is harder because compliance itself is harder. 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 than an internal wall in a hospital corridor. Both need a fire rating parameter, but the correct value for each one differs.
An existence checker will tell you both walls need a FireRating field. It stops there. It won't tell you that the hospital corridor wall needs FRP 120 while the residential external wall needs FRP 60. It won't notice if you typed "1 hour" instead of "FRP 60", a value that exists but doesn't match CORENET X format.
This is where schema and code separate. The IFC-SG schema defines what fields must exist. BCA's Code on Accessibility, SCDF's Fire Code, NEA's environmental standards, and URA's planning parameters define what values belong in those fields. A validator checking one without the other gives you half a compliance picture.
A validator that only checks existence will show you 4,200 populated fields out of 5,000. But populated and correct are not the same. You've seen the checkmark. You might assume all 4,200 are right. They're not necessarily. They're just filled.
If your validator only checks existence, you'll need a second tool to check correctness. Some tools openly acknowledge this. They direct you to a separate checker for actual compliance verification against building codes.
Now your workflow is: export IFC from Revit, upload to Tool A for parameter existence, fix empty fields, upload to Tool B for compliance checking, discover some values are wrong, go back to Revit, fix the values, re-export, re-upload to both tools, repeat.
Two tools. Two interfaces. Two error formats. And you're doing it all outside Revit, on an exported snapshot that's already drifting from your live model.
Every handoff between tools adds context switches, file transfers, and delay. But the deeper cost is the reconciliation. When Validator A says the field is populated and Checker B says the value is wrong, you have to make sense of two different systems, neither of which sees the full picture. You do. The reconciliation falls on you.
I covered the export-upload-fix loop in detail in "What BIM Validation Actually Costs Your Team." Adding a second tool to that cycle makes it worse, not better.
Every tool you add to a submission cycle is another place where accuracy breaks down.
If you've been in a BIM team during submission crunch week, you know how this feels. Revit is open. Navisworks is open. BIMCollab or Solibri runs for coordination. Someone has a validator in a browser tab. Someone else is cross-referencing a PDF of the IFC-SG mapping table. Your model lives on your server or in Autodesk Construction Cloud, and five people are worksharing while you fix parameters that a web tool flagged on an export from hours ago, which is now outdated.
Each tool you add is another place where reality branches. Your Revit model is the source of truth. It's what your team is actively working in. It's what you'll export for submission. Every external tool that asks you to upload a snapshot, review in a browser, fix elsewhere, then return to Revit and make the actual change puts distance between you and your source of truth.
You learn this quickly. You spend 45 minutes fixing errors flagged by a validator at 10 AM, only to discover your colleague renumbered half the rooms at 10:30. The export you were triaging was already wrong. The fixes you made were wasted. You re-export, re-upload, start over.
The external validation workflow looks like a consulting engagement because that's often how it was designed. Hand off the file, receive a report, reconcile. When someone else bills for the analysis, that makes sense. When you're the one doing the fixing on a deadline, in a live model with four other people working in it, it doesn't.
The fewer tools between your model and your submission, the less drift accumulates. That's not a design preference. It's something anyone who's been through October submission deadline season already knows.
If your validator understands both the schema and the rules, the entire workflow simplifies.
Instead of checking whether a FireRating field exists, then separately checking whether the value is correct, a rule-aware tool does both in one pass. It reads the wall's properties, looks up the applicable BCA rule, and knows immediately whether the value is right for that element's context.
That's schema validation versus compliance validation. Schema validation asks: is the field there? Compliance validation asks: given this building code, this element's location, this occupancy type, is the value correct?
When I was working on authority submissions for Expo City Dubai at DP Architects, the hard part wasn't finding empty fields. We caught those early. The time went to determining correct values for each element. Fire ratings, accessibility widths, egress calculations, material grades. Every one depends on rules from the building code, not from the IFC schema.
This is why validating inside Revit, before export, changes the equation. No browser tab, no snapshots, no asynchronous drift between your model and the feedback loop. No need to make judgments across two tool interfaces. One tool, inside your authoring environment, checking both presence and correctness in context. I wrote more about this in "How to Validate CORENET X Compliance Before IFC Export."
And why direct access to the Revit API matters. You need to read the full model, not a snapshot. A file parser works on exports. Real-time validation works on the live file.
If you're evaluating compliance tools for October 2026, these distinctions matter.
❓ Does it check existence, correctness, or both?
✅ Some tools check only parameter presence. That's useful as a starting point but it won't tell you if your submission will pass agency review. Know what your tool actually validates.
❓ Where does validation happen?
✅ If it happens in a browser on an exported file, you're working on a snapshot outside your authoring environment. You're in the export-upload-fix loop. If it happens inside Revit, you validate live data, fix in context, and export once when ready.
❓ When does it flag problems?
✅ Post-design validation tells you what's wrong in a model you thought was finished. That's valuable for submissions. But the costliest failures surface after coordination is done, when corridor width fixes mean reopening structural and MEP. The most useful validators will catch problems during design, not after.
A validator that only checks existence is a useful filter for eliminating obviously incomplete models. For production workflows with real submission deadlines, you need something that goes further. You need confirmation that what you entered will actually 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 starting Senibina, he worked at DP Architects across projects ranging from Expo City Dubai to Dubai Square, where complex freeform geometry had to survive the full journey from design through Rhino, into Revit, and out to authority submission.
If your practice is preparing for October 2026 and wants to validate both parameter existence and correctness inside Revit before you export, Gateway is in alpha with founding firms. The program is open to firms preparing their CORENET X submission strategy.