Back to the BIM & IFC blog
Validation · 2026-06-28 · 20 min
IFC Model Checker: The Complete Guide to IFC Validation, Model Quality, and IDS
IFC model checker guide: schema, model quality (44 rules + Health Score), and IDS are three independent layers. Confusing them causes delivery failures. Complete breakdown for BIM coordinators.
IFC Model Checker: The Complete Guide to IFC Validation, Model Quality, and IDS — IFC Viewer Online article cover
- 3 — independent validation layers
- 44 — model quality rules
- 6 — IDS facets (buildingSMART 1.0)
- 0 — bytes uploaded — browser only
Every IFC delivery conversation eventually hits the same wall. The structural engineer says the file passed the validator. The BIM coordinator sees half the property sets missing and asks which validator. The client's EIR specifies IDS requirements nobody has checked. The CDE rejects the upload. Three weeks later, everyone is confused about what 'valid' even means.
The confusion is understandable — the word 'validation' covers three completely different operations that share a name. Getting them untangled is one of the most consequential things a BIM coordinator can do for a project.
Three Completely Different Validation Problems
Think of a building permit application. The building control officer independently verifies three things: whether the drawings are legible and complete (file integrity), whether the design meets building regulations (quality and compliance), and whether it meets the client's specific brief (project requirements). A legible drawing can completely ignore fire regulations. A fire-compliant scheme can miss the client's acoustic specification entirely. These are separate questions with separate answers.
Level 1 — IFC Integrity
Is the file a valid IFC according to ISO 10303-21 and ISO 16739-1? Are GlobalIds unique and format-compliant? Is the spatial hierarchy coherent? Schema-level binary checking.
Level 2 — Model Quality
Is the data actually useful for coordination? Are property sets populated? Do elements follow naming conventions? Are classifications present? This governs real deliveries — not schema compliance.
Level 3 — IDS Validation
Does the model satisfy this project's contractual information requirements? EIR and AIR requirements encoded as machine-readable IDS specifications, checked facet by facet against every element.
These three layers are completely independent. A file can be Level 1 schema-valid while being useless for coordination because no property sets were exported. An IDS check can pass for all declared requirements while the model has 400 duplicate GUIDs. A Health Score of 91 says nothing about whether the client's fire-rating requirements are encoded and met. Each layer answers a different question — all three are needed before a formal delivery.
Level 1: IFC File Integrity — Is This a Valid IFC?
Level 1 is schema checking. It answers a binary question: does this file conform to the IFC schema (ISO 16739-1) and the physical file format (ISO 10303-21 STEP)? Most IFC parsers silently accept files that fail Level 1 checks — they are permissive by design, because strict rejection would break too many workflows. That permissiveness hides the damage until it surfaces downstream.
What Level 1 Integrity Checking Covers
- GlobalId uniqueness: every IfcRoot entity must have a unique 22-character GlobalId using IFC's base-64 alphabet. Duplicate GlobalIds are a schema violation that parsers accept but that silently corrupt BCF workflows, CDE versioning, and FM asset registers.
- GlobalId format compliance: the first character of a valid IFC GlobalId encodes values 0–3 only (two significant bits from a 128-bit UUID). Scripts that naively truncate UUIDs produce out-of-range leading characters — invalid by spec, tolerated by most parsers, rejected by strict validators.
- Spatial hierarchy completeness: the IFC schema mandates IfcProject → IfcSite → IfcBuilding → IfcBuildingStorey. Missing nodes (a Building directly under Project, physical elements sitting in IfcSite) are schema violations with real downstream consequences.
- IfcRelAggregates chain integrity: the relationship entities that build the spatial tree must reference existing entities. Dangling references — where a relationship points to a deleted or missing entity — break tree navigation in every downstream tool.
- IfcRelContainedInSpatialStructure: physical elements must be contained in a spatial element (typically IfcBuildingStorey). Elements with no containment relationship are orphans — invisible in most tools' spatial navigation.
- Exactly one IfcProject: every valid IFC file must contain exactly one IfcProject as the hierarchy root. Sub-models that omit it parse without error but have no spatial anchor.
- FILE_NAME and FILE_DESCRIPTION header fields: the STEP file header carries traceability metadata. ISO 19650-2 requires these to be populated — most tools leave them as empty strings.
- Geometry validity: non-manifold meshes, faces with zero area, bodies with reversed normal winding, self-intersecting boundary representations that fail to produce valid solids in receiving tools.
What Level 1 Does NOT Check
- Whether property sets are populated or correct — a schema-valid model with zero Psets passes Level 1.
- Whether element names follow any project naming convention.
- Whether classification codes are present, correct, or consistent.
- Whether LOD quantity requirements (IfcElementQuantity at LOD 300+) are satisfied.
- Whether the model meets any project-specific or contractual information requirement.
The buildingSMART Validation Service for Level 1
The buildingSMART IFC Validation Service (validate.buildingsmart.org) is the authoritative reference for Level 1 schema compliance — it uses the same engine deployed for IFC software certification. Run it when: you need to certify IFC output from a custom exporter, you're troubleshooting a file that parsers handle inconsistently, or a contract clause explicitly requires a buildingSMART schema certificate.
What it does not do: check data quality, validate naming conventions, inspect property set completeness, check ISO 19650 metadata fields, or assess whether the model meets any project requirement. It is a schema tool, not a project delivery gate.
Inspect a complex real-world IFC — all three validation layers
A multi-storey office building exported from Revit. Open the Validation tab to see the full 44-rule quality report and Health Score. Then try loading an IDS specification to see Level 3 checking on the same model.
IFC4 · 14 MB
Open the interactive IFC viewer
Level 2: Model Quality Checking — The Layer That Actually Governs Deliveries
Model quality checking is the layer most BIM coordinators mean when they say 'IFC validation', even though they rarely call it by that name. It answers practical questions: Is the data here? Is it correct? Is it consistent? Can someone downstream actually use this model for coordination, cost planning, or FM?
Unlike Level 1, quality checking is not binary. A model doesn't simply pass or fail — it has a quality profile across dozens of dimensions. The Health Score (0–100) aggregates these dimensions into a single number that can be written into a BEP, tracked across revisions, and attached to transmittals as evidence of delivery quality.
What the 44-Rule Quality Check Covers
Core structural rules (18)
Duplicate GUIDs, orphan elements, wrong containment, broken aggregates, missing IfcProject, empty element names, invalid storey placement. The rules that cause the most CDE rejections in practice.
Spatial + file header (11)
ISO 19650 metadata fields on IfcProject, FILE_NAME author and organisation population, site placement vs. shared coordinates, element-to-storey association, building storey completeness.
LOD, classification, MEP (9)
IfcElementQuantity presence at LOD 300+, IfcRelAssociatesClassification on structural and architectural elements, MEP system connectivity, proxy overuse (IfcBuildingElementProxy as a % of the model).
Geometry + storey integrity (6)
Element bounding box validity, storey elevation ordering, elements below the ground plane, floor slab absence from storey, coordinate origin offset from WCS, clash detection (optional rule, off by default).
The Health Score: Model Quality as a Single Number
The Health Score uses logarithmic penalty weighting. Schema errors carry 3× the weight of warnings; warnings carry 3× the weight of info checks. The 1,000th instance of the same issue subtracts far fewer points than the 10th — this prevents large, dense models from appearing arbitrarily worse than small sparse models for the same underlying problem density. A model with 800 naming warnings can score 83; a model with 12 broken spatial references scores 41. Severity is what drives the score, not volume.
- 31/100 — Critical — structural failures, do not deliver
- 58/100 — Poor — significant remediation required
- 74/100 — Fair — acceptable for internal review only
- 87/100 — Good — CDE delivery ready
- 96/100 — Excellent — ISO 19650 milestone quality
What Model Quality Checking Does NOT Do
- Verify project-specific information requirements — that is Level 3 (IDS). Quality rules are generic best-practice checks, not your EIR.
- Fix the model — quality checking produces a report. Remediation happens in the authoring tool or, for property and GUID fixes, in an IFC property editor.
- Provide the schema compliance certificate required by buildingSMART certification programs — that is Level 1 via the buildingSMART Validation Service.
- Tell you whether the model is geometrically correct — some geometry integrity checks are included, but a quality checker is not a clash detection or BIM authoring tool.
Level 3: IDS Validation — Exchange Requirements as Machine-Readable Code
IDS (Information Delivery Specification) is a buildingSMART standard for encoding project-specific information requirements in a machine-readable XML format. It is the missing link between an EIR — which is a Word document — and a validation engine that can systematically check a model against it. IDS 1.0 became an official buildingSMART standard in 2023.
What buildingSMART IDS Actually Is
An IDS file is an XML document containing one or more specifications. Each specification has an applicability section (which elements does this apply to?) and a requirements section (what must those elements have?). The engine checks every element in the model that matches the applicability, verifies it satisfies all requirements, and reports pass or fail per element, per specification. The result is a machine-generated audit trail of contractual compliance.
The buildingSMART reference test suite contains 100 official testcases that define the expected behaviour of any conforming IDS engine — they are the specification in runnable form. An IDS engine that passes all 100 testcases has demonstrated it will interpret .ids specifications consistently with the standard.
The Six IDS Facets
- Entity: restricts applicability or requirements by IFC entity type (IFCWALL, IFCDOOR, IFCBEAM) and optionally predefined type. This is the filter most specifications start with.
- Attribute: checks IFC attribute values that sit directly on the entity — Name, Description, ObjectType, Tag, PredefinedType. Attributes are distinct from property sets and are checked differently.
- Property: checks a named property within a named property set (Pset_WallCommon.FireRating, Pset_DoorCommon.IsExternal). The most commonly used facet. Supports data type constraints and pattern matching on values.
- Classification: checks that elements carry a classification reference via IfcRelAssociatesClassification — Uniclass 2015, OmniClass, NBS, or a custom scheme. Can constrain the classification system name and code pattern.
- Material: checks that elements have an assigned material via IfcMaterial, IfcMaterialLayerSet, or IfcMaterialConstituentSet. Optionally constrains the material name — useful for fire-rating or sustainability requirements.
- PartOf: checks that elements participate in a required spatial or logical relationship — contained in a storey, aggregated into a building system, hosted in a specific building. The facet that enforces spatial hierarchy compliance for specific element types.
<?xml version="1.0" encoding="UTF-8"?>
<ids:ids xmlns:ids="http://standards.buildingsmart.org/IDS"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://standards.buildingsmart.org/IDS ids_09.xsd">
<ids:info>
<ids:title>Stage 3 Architecture — EIR Data Requirements</ids:title>
<ids:description>Fire safety and classification requirements.</ids:description>
<ids:ifcVersion>IFC4</ids:ifcVersion>
</ids:info>
<ids:specifications>
<!-- All walls must carry a fire rating property -->
<ids:specification name="Wall FireRating required" minOccurs="1">
<ids:applicability>
<ids:entity>
<ids:name><ids:simpleValue>IFCWALL</ids:simpleValue></ids:name>
</ids:entity>
</ids:applicability>
<ids:requirements>
<ids:property dataType="IFCLABEL">
<ids:propertySet><ids:simpleValue>Pset_WallCommon</ids:simpleValue></ids:propertySet>
<ids:baseName><ids:simpleValue>FireRating</ids:simpleValue></ids:baseName>
</ids:property>
</ids:requirements>
</ids:specification>
<!-- Structural walls must carry a Uniclass 2015 classification -->
<ids:specification name="Structural wall classification" minOccurs="0">
<ids:applicability>
<ids:entity>
<ids:name><ids:simpleValue>IFCWALL</ids:simpleValue></ids:name>
<ids:predefinedType><ids:simpleValue>SOLIDWALL</ids:simpleValue></ids:predefinedType>
</ids:entity>
</ids:applicability>
<ids:requirements>
<ids:classification>
<ids:system><ids:simpleValue>Uniclass 2015</ids:simpleValue></ids:system>
</ids:classification>
</ids:requirements>
</ids:specification>
</ids:specifications>
</ids:ids>
EIR → IDS: The Translation Step Most Teams Skip
An EIR specifies what information the client needs. An IDS encodes those requirements so a machine can check them. The translation between the two is the step almost nobody does — because it requires someone who understands both the information requirements and the IDS XML schema well enough to write a specification that tests exactly what the EIR asks for, no more and no less.
The consequence: teams either skip IDS entirely and rely on informal manual review at delivery, or use a generic IDS file that does not reflect their actual EIR. Both produce false confidence. An IDS check that passes against a generic specification tells you nothing about whether your specific client requirements are met.
Profile-Based IDS: A Practical Starting Point
Not every team writes IDS from scratch. A practical approach is to maintain a library of reusable IDS profiles: one for Stage 3 architecture, one for MEP Stage 4, one for structural handover. Each profile covers the most common requirements for that phase and discipline, and is extended per-project with client-specific additions. IDS profiles can be loaded directly into the validation engine and composed — you can run multiple .ids files against the same model and aggregate the results.
How the Three Levels Work Together — The Validation Pipeline
The three layers form a quality gate that a model passes through in sequence. Each level has a different cadence: Level 1 runs on every export (a sanity check), Level 2 runs before any CDE upload (the quality gate), Level 3 runs before formal delivery milestones (the contract check). Running them out of order wastes time — there is no value in running IDS against a file with a broken spatial hierarchy.
┌──────────────────────────────────────────────────────┐
│ EXPORT IFC from authoring tool │
│ (Revit, ArchiCAD, Tekla, Allplan, Vectorworks…) │
└───────────────────────┬──────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────┐
│ LEVEL 1 — IFC Integrity │
│ • GlobalId uniqueness & format (leading char 0–3) │
│ • Spatial hierarchy: Project→Site→Building→Storey │
│ • IfcRelAggregates chain integrity │
│ • IfcRelContainedInSpatialStructure (no orphans) │
│ • Exactly one IfcProject │
│ • FILE_NAME header traceability fields │
└─────────┬────────────────────────────────────────────┘
Fail ◄────┤ Fix in authoring tool (or IFC property editor)
│ Pass
▼
┌──────────────────────────────────────────────────────┐
│ LEVEL 2 — Model Quality (44 rules) │
│ • Naming conventions / empty element names │
│ • Property set completeness (Pset_WallCommon etc.) │
│ • ISO 19650 metadata (IfcProject.LongName etc.) │
│ • Classification presence and consistency │
│ • LOD quantity sets, proxy audit, MEP connectivity │
│ → Health Score 0–100 │
└─────────┬────────────────────────────────────────────┘
Score<80 ◄┤ Fix properties / names in IFC editor or authoring tool
│ Score ≥ 80
▼
┌──────────────────────────────────────────────────────┐
│ LEVEL 3 — IDS Validation │
│ • Project-specific EIR / AIR requirements │
│ • .ids specification(s) for this milestone │
│ • Six facets: entity, attribute, property, │
│ classification, material, partOf │
└─────────┬────────────────────────────────────────────┘
Fail ◄────┤ Fix per IDS issue report → export BCF → remediate
│ All requirements met
▼
┌──────────────────────────────────────────────────────┐
│ DELIVER TO CDE │
│ Attach: Health Score report + IDS pass certificate │
└──────────────────────────────────────────────────────┘
The Comparison Table: Level 1 vs Level 2 vs Level 3
| Dimension | L1: IFC Integrity | L2: Model Quality | L3: IDS Validation |
|---|
| Question answered | Is the file a valid IFC schema? | Is the data useful for coordination? | Does it meet project information requirements? |
| Standard | ISO 10303-21 (STEP), ISO 16739-1 (IFC) | BIM best practice, ISO 19650 norms | buildingSMART IDS 1.0 (XML schema) |
| Defined by | buildingSMART (fixed schema) | BIM team / EIR (project-agreed rules) | Client / employer (per-project) |
| Output | Pass / Fail + schema error list | Health Score 0–100 + prioritised issue list | Pass / Fail per specification |
| Can replace others? | No | No | No — all three needed |
| Cadence | Every IFC export | Before CDE upload | Before delivery milestone |
| Passes but fails another? | Zero Psets, no names → L1 pass, L2 fail | Fire rating missing (IDS spec) → L3 fail | Duplicate GUIDs, broken hierarchy |
| Example tools | bSmart Validator, IFC Viewer Online | IFC Viewer Online, Solibri, IfcOpenShell | IFC Viewer Online (IDS engine), Solibri |
When to Use the buildingSMART Validation Service — An Honest Assessment
The buildingSMART IFC Validation Service checks files against the official schema using a multi-part engine: STEP physical file syntax, IFC schema EXPRESS rules, informal proposition rules derived from the spec, and normative IFC constraint rules. It is the reference tool for Level 1 schema compliance.
Use it when
- Certifying IFC export from a custom exporter: the buildingSMART checker produces the reference result used for software certification. No other tool's output substitutes for it in certification contexts.
- Diagnosing parser inconsistency: when a file opens cleanly in one tool and errors in another, the buildingSMART checker establishes which behaviour is schema-correct. This is diagnostically valuable even if the file is otherwise usable.
- A contract clause requires it: some procurement specifications reference buildingSMART schema compliance as a delivery requirement. In that case, the certificate from the official service is what satisfies the clause.
- Validating an IDS file itself: the buildingSMART IDS schema validator checks whether your .ids file is a valid IDS document — distinct from running it against a model.
Do not use it as a substitute for
- Model quality checking — the service does not check property set completeness, naming conventions, classification, or any data quality rule.
- Project-specific validation — schema compliance says nothing about whether the model meets the client's EIR.
- Pre-CDE delivery confirmation — a schema-valid model with empty Psets and blank names will pass the buildingSMART checker and fail any meaningful quality gate.
Cloud IFC Validator vs Browser-Based IFC Validator
The distinction between cloud validation (file uploaded to a remote server) and browser-based validation (file processed locally via WebAssembly) matters more than most teams realise — especially for government, defence, and sensitive commercial projects.
Browser-Based Validation
- IFC file never leaves the device
- GDPR compliant by design — no data transfer
- Works offline: site visits, restricted networks
- No upload quota or file size restriction
- Instant feedback — no network round-trip latency
- Consistent performance independent of server load
- No account, API key, or subscription required
- Works on government-restricted network environments
Cloud Validation
- File uploaded to remote server for processing
- Data processing agreement (DPA) required for GDPR
- Suited for automated CI/CD validation pipelines
- Central audit log across projects and teams
- API and webhook integration for delivery automation
- Scales horizontally for batch model processing
- Can run headless without a browser session
- Results queryable across historical runs
When Cloud Validation Makes Sense
- Automated CI/CD pipelines: when validation should trigger automatically every time a model is committed or uploaded — similar to how software teams run automated tests on every code push. Cloud APIs with webhooks are the right architecture here.
- Organisation-wide audit: when a BIM manager needs a central record of validation runs across multiple projects and teams. Cloud services can aggregate and trend data across runs in ways per-machine tools cannot.
- Batch processing: auditing a library of existing models — all IFC files delivered to a CDE over the past two years — is practical in cloud batch mode and impractical to do manually in a browser.
- Non-sensitive models: for projects where data handling requirements do not prohibit cloud upload, cloud validators offer CI/CD integration that browser tools do not match.
When Browser-Based Is the Better Choice
- Government and defence projects: models for public infrastructure, defence facilities, and secure assets routinely carry data handling restrictions that prohibit upload to third-party services. Browser-based validation is the only compliant option.
- Sensitive residential and commercial schemes: BIM models often contain occupant information, owner addresses, and asset metadata that qualifies as personal data under GDPR Article 4. Processing these on a third-party server without a valid DPA and legal basis is non-compliant.
- Site and field use: a 200 MB IFC file over a 4G connection uploads slowly and unreliably. Browser validation processes it locally in seconds with no dependency on uplink bandwidth.
- Pre-validation before cloud upload: even when a team uses a cloud validator as the formal gate, running a browser-based check first catches obvious issues without the upload — reducing cloud usage costs and upload frequency.
Six Validation Mistakes BIM Teams Make — and What They Actually Mean
Mistake 1: "IDS passed — the model is good"
IDS validates only what the .ids specification declares. If your file requires FireRating on walls but your EIR also requires IsExternal on doors, Uniclass codes on structural elements, and quantity sets on slabs — and those were not written into the specification — the engine reports all requirements met while half your EIR is unchecked. An IDS pass is a contractual confirmation against a specific specification. It is not a general quality certificate.
Mistake 2: "The buildingSMART checker said it's valid"
Schema validity is the floor, not the ceiling. A file where every element has Name='' and zero property sets is perfectly schema-valid. A model with no IfcElementQuantity, no classification, and every physical element placed directly in IfcSite rather than a storey is perfectly schema-valid. Passing the buildingSMART checker means the STEP file is correctly formatted — it says nothing about whether the data is useful.
Mistake 3: "I can open it in a viewer, so it's fine"
IFC viewers are permissive by design — they are built to display geometry regardless of data quality. A viewer that refused to open schema-invalid or data-poor files would be unusable. Geometry rendering correctly tells you nothing about property set completeness, naming conventions, GUID stability, classification, or any of the 44 quality dimensions. Viewing a file is categorically different from validating it.
Mistake 4: Checking geometry only, ignoring property data
A common reflex is to open the IFC, inspect the 3D model, and if the building looks right, declare the file done. Geometry accounts for roughly 30% of what makes an IFC file useful. Property sets, classifications, element names, type assignments, and quantity sets are what FM systems, cost managers, and CDE asset registers actually consume. A geometrically correct file with blank property sets fails handover.
Mistake 5: Validating once, at the delivery deadline
Treating validation as the final step before a CDE submission means remediating issues under pressure with no buffer. A model with 800 validation issues discovered the day before the deadline will either be delivered with known problems or miss the deadline. The correct cadence: Level 1 after every export, Level 2 before every internal review (weekly minimum), Level 3 two weeks before each formal milestone.
Mistake 6: Ignoring GUID stability across re-exports
Duplicate GUIDs within a file are a Level 1 issue and are detectable by any validator. But GUID instability across re-exports — where the same element gets a different GlobalId each time the model is exported — is invisible to single-file validation. When GlobalIds drift between revisions, every BCF comment, CDE element reference, and FM asset tag silently becomes a dangling reference. This requires a two-revision comparison and a check of export settings, not just single-file validation.
A Practical Validation Workflow for BIM Coordinators
- After every IFC export: run a Level 1 check. Takes under 30 seconds in any browser-based validator. Fix GlobalId duplicates, orphan elements, and spatial hierarchy breaks before they compound across revisions.
- Before every internal review (weekly or per-sprint): run a full Level 2 quality check. Review the Health Score trend. A score declining across revisions means new issues are being introduced — find the source before it becomes a pattern.
- On receipt of any discipline model from a third party: run Level 1 and Level 2 before federating. A model you receive may carry issues you inherit into the coordination model — detect them immediately, not three weeks into coordination on a broken federation.
- Two weeks before any formal milestone delivery: run all three levels. Health Score ≥ 80 target before IDS. Two weeks gives time to remediate without pressure. Flag early — do not absorb the buffer.
- Before uploading to the CDE: run Level 2 and Level 3. Attach the Health Score certificate and IDS pass report to the transmittal. This creates a documented audit trail and gives the information manager everything needed to accept the delivery.
- After any authoring tool version upgrade or change to export settings: re-establish the GUID stability baseline by comparing two consecutive exports. A Revit upgrade or a changed export configuration can silently change GlobalId generation behaviour.
Expert Tips
Triage by penalty, not count
Don't fix issues in order of volume — fix them in order of Health Score impact. Three missing IfcProject metadata fields can cost 15 points. Eight hundred naming warnings might cost 8 points total. Use the severity breakdown to triage by impact.
Lock export settings in a template
Every time export settings are manually reconfigured, there is risk of drifting to a different configuration. Create a named IFC export setup in your authoring tool, commit it to the project template, and document the required settings in the BEP. Configuration drift is the root cause of most 'it worked last time' export problems.
Translate EIR to IDS at project start
Translate the most critical EIR clauses into an IDS specification in the first two weeks of the project. Even a partial .ids file — five or six specifications — is better than full manual EIR review at delivery time, and catches systematic data gaps early when they are cheap to fix.
Validate each discipline model before federating
Issues from one discipline model can mask or interact with issues from another in a federation. Validate clean inputs, federate clean. Running validation only on the coordination model after federation makes it harder to assign issues to the correct originator.
Frequently Asked Questions
Does passing Level 1 mean I can skip Level 2?
No. Level 1 and Level 2 measure completely different properties of a file. A schema-valid file (Level 1) can have zero property sets, empty element names, no classification, and no ISO 19650 metadata — and score 20 on a quality check (Level 2). You always need both. Think of Level 1 as 'the file is correctly packaged' and Level 2 as 'the contents of the package are what was requested'.
Is IDS a replacement for the buildingSMART Validation Service?
No. IDS checks project-specific information requirements (Level 3). The buildingSMART Validation Service checks schema compliance (Level 1). They operate at completely different levels and address different questions. An IDS-passing model that fails schema validation would be a logical contradiction — Level 1 integrity is a prerequisite for meaningful Level 3 checking.
Which IDS facets should I prioritise for a standard BIM delivery?
The Property facet covers 70–80% of real-world EIR requirements — most clients want specific property set values populated on specific element types. Classification covers most of the remainder for Uniclass- or OmniClass-governed projects. The Entity facet appears in almost every specification as an applicability filter. Material and PartOf address specific contractual requirements. Start with Entity + Property, add Classification if your EIR requires it, and expand from there.
Can I validate an IFC without uploading it anywhere?
Yes. Browser-based validators process the file entirely in your browser using WebAssembly. The IFC bytes never leave your device — all 44 quality rules, the Health Score calculation, and the full IDS engine run client-side. For models with data handling restrictions — government assets, sensitive residential data, defence infrastructure — this is often the only compliant option.
What Health Score threshold should I specify in the BEP?
≥ 80 is the standard threshold for CDE delivery and design coordination. ≥ 90 for LOD 300+ design development deliveries and ISO 19650 formal milestone submissions. ≥ 70 is acceptable for concept-stage internal reviews. Below 60, the model has structural quality problems and should not be delivered to any external party under any circumstance.
Can a single tool cover all three validation levels?
Some tools do. IFC Viewer Online covers Level 1 (integrity rules including GUID, hierarchy, and file header checks), Level 2 (44-rule quality check with Health Score), and Level 3 (IDS 1.0 engine validated against all 100 official bSI testcases). Solibri covers Level 2 and Level 3 with a more sophisticated rule engine but no browser-based processing. The buildingSMART Validation Service covers Level 1 only. IfcOpenShell can be scripted for Level 1 and Level 2.
Summary
Schema-valid is not project-valid. Project-valid is not EIR-compliant. All three validation layers are needed — and conflating them is the root cause of most formal delivery failures.
IFC Viewer Blog
Level 1: Run on every export
Schema integrity, GlobalId uniqueness and format, spatial hierarchy. Takes 30 seconds. Catches the structural failures that silently corrupt BCF, CDE versioning, and FM asset registers downstream.
Level 2: Gate every CDE delivery
44 quality rules, Health Score, naming conventions, property set completeness, ISO 19650 metadata. Require ≥ 80 in your BEP and EIR. This is the layer that makes a model useful — not just parseable.
Level 3: Verify before every milestone
IDS specifications that encode your EIR and AIR in machine-readable form. Translate the critical clauses at project start, not the week before delivery. An IDS pass is a documented contractual audit trail.
Run a full quality check on your current model — under 30 seconds in any browser, nothing uploaded. Then read the IFC Health Score guide to understand how the score is calculated and what threshold to set in your BEP. If property values or GUIDs need fixing on a received file, the free online IFC editor guide covers non-destructive property editing without a round-trip through the authoring tool. And for the most common structural failures that cause Level 1 rejections, see the 7 most common IFC validation errors.
IFC Model Checker: The Complete Guide to IFC Validation, Model Quality, and IDS