Every check we run, and why it's there
~50 automated checks across five dimensions, plus official buildingSMART validation, a real 3D viewer, a geo-location view, a geometry heatmap, and the reports you can export from it all. Nothing here is a black box.
1 Validity — can this file even be trusted?
The basics that decide whether anything else in the report can be relied on: does the file parse cleanly, is it complete, and does it say where in the world it actually is.
Author, organisation, authoring tool and export timestamp are genuinely filled in — not left as "Architect", "Unknown" or blank placeholders.
Why it's checkedIf a question comes up years into operation about who delivered this data, with what tool, and when, this is the only record of it. Missing or generic authorship isn't just untidy — it's the difference between being able to trace a problem back to its source and not.
The file states what kind of exchange it's meant for (e.g. Coordination View), so downstream software knows how to interpret it — rather than a translator-internal label or nothing at all.
Why it's checkedThe MVD tells importing software what the export actually promises to contain. Without a recognised one declared, there's no way to tell whether something missing downstream is a real gap or simply outside what this export was ever meant to carry.
A length unit is explicitly declared in the file, so every measurement has a defined, unambiguous meaning.
Why it's checkedEvery length, area and volume in the file depends on this being right. Leave it undeclared and a tool can silently misread millimetres as metres — scaling every quantity in the model by a factor of 1,000. Nothing downstream can be trusted until this is settled, which is why it's a gate.
The model states where in the real world it sits — coordinates, elevation and coordinate reference system — not just "somewhere near the origin".
Why it's checkedWithout real coordinates, the model can't be lined up with a GIS layer, a survey, or the asset register — not once at handover, and not again five years later when someone needs to check it against a new survey or a neighbouring project.
The file opens cleanly. Every parsing error or header warning the file carries chips away at this score.
Why it's checkedA file that doesn't open cleanly puts every other check on shaky ground: broken entity references and export issues here tend to cascade into wrong answers everywhere else. That's why this one is a gate rather than a simple deduction.
Shown for context, never scored — IFC2X3, IFC4 and IFC4.3 are all equally valid choices; newer schemas simply add options like full georeferencing and infrastructure entities.
Why it's checkedNot a risk in itself — the schema version only tells you which capabilities, like full georeferencing, were actually available to the exporter.
STEP syntax, IFC schema conformance, header syntax, header fields, prerequisites and informal propositions are all official buildingSMART validation rules, run against your file in addition to our own checks. See how buildingSMART validation works ↓.
2 Structure — can you find things in it?
Whether elements are organised into a real building, site and storey hierarchy that software can navigate — or scattered as generic, unclassified objects nobody can locate.
How much of the model is generic, unclassified "IfcBuildingElementProxy" placeholders instead of real, typed elements.
Why it's checkedA proxy is a shape with no real identity attached — software can't tell a proxy pump from a proxy wall by its IFC class alone. If every downstream use only needs the geometry, that may genuinely not matter. But if you need to query, schedule or hand the model to an FM system by element type, a high proxy share is exactly the kind of risk this check exists to surface before it becomes a problem.
Even where proxies exist, whether they at least carry a classification code — and ideally a URI — so they aren't completely anonymous.
Why it's checkedA classified proxy at least tells you roughly what it is, even without a proper IFC type. Without that, the object is effectively invisible to anyone filtering or searching by type or system — exactly the lookup an engineer runs during fault-finding.
Whether elements are actually placed inside a building, site or storey — or float outside the spatial hierarchy where most software simply can't find them.
Why it's checkedAn element that isn't actually contained in a building, site or storey can't be found by location — not in the 3D viewer, not in a spatial query, and not by whoever is walking the floor with a tablet trying to match what they see to the model.
Whether the model has real storeys or facility parts under its facilities, rather than a flat, unstructured list of objects.
Why it's checkedA flat list of objects is still navigable while you remember the project. It stops being navigable the moment someone who wasn't there — a facility manager, a new contractor years later — has to find their way around it cold.
A single, clean site is normal. More than one usually means separate models were merged or federated without cleanup.
Why it's checkedThis mainly matters if anything downstream groups quantities or georeferencing by site. If nothing does, it's a lower-stakes tidiness issue — but worth knowing which situation you're in before you rely on site-level numbers.
Structural inconsistencies the parser itself flags — duplicate containment, orphaned elements and similar plumbing issues.
Why it's checkedThese are the kind of plumbing errors that never throw a visible error anywhere in the viewer — they just quietly break queries and take-offs that assume a clean Project → Site → Facility → Part tree.
Whether occurrences are linked back to a shared type object — efficient and consistent — or each modelled as a one-off with its own disconnected data.
Why it's checkedData shared on a type object only needs correcting once. Duplicated on every occurrence instead, a correction made on one object never reaches the others — a real risk if the model gets edited or maintained after handover, less of one for a pure as-built snapshot that will never be touched again.
Whether wall and floor openings are properly linked to the door or window that fills them, so areas and quantities add up correctly.
Why it's checkedAn opening without its door or window properly linked back to it throws off wall area and opening take-offs — numbers that feed straight into cost and material quantities downstream.
Whether IfcSpace objects define the model's rooms and functional zones, on models that otherwise look architectural (walls, slabs and at least one door or window).
Why it's checkedWithout spaces defined, room areas and functional zones can't be calculated — not inaccurately, just not at all. Only scored on models that otherwise look architectural; on a bridge or road, spaces simply aren't expected and this is shown for information only.
For roads, rail and bridges built with IFC4.3 alignments, most tools only check that the geometry is valid — not that it means what it says. We go a step further and check the business logic: whether each linear alignment's declared segments actually correspond 1:1 to its geometry, with continuous joints and no discontinuities.
A file can have perfectly valid geometry and still have alignment segments that don't match where the design intent says they should — this check is what catches that gap. Shown automatically whenever a model contains IfcAlignment entities; every other model simply won't show this card.
3 Geometry — will it actually open and perform?
How heavy the 3D geometry is, whether it was built efficiently, and whether every element has a real shape — not just a placeholder box standing in for one.
Every element that should have a shape actually has one, rather than existing only as a data record with nothing to show for it.
Why it's checkedAn element with data but no shape is invisible in the 3D viewer and absent from any take-off, even though it technically exists in the file. That affects whether the object can be used at all, not just how well — which is why this is a gate.
The 3D geometry can actually be meshed and rendered by standard tools, not just referenced in the file.
Why it's checkedGeometry that can't be meshed by standard tools breaks viewers and clash detection — the two things most people actually open a model to use.
Average triangle count per object. Too high and the file becomes slow to open, heavy to host and painful to view on site.
Why it's checkedThis is the one with a genuine trade-off, not a simple pass/fail. Maybe you really do need advanced B-reps and manufacturer-grade detail for a specific use case — but if you don't, that detail is pure risk: a heavier, slower file to open, host and view on site for the rest of the asset's life, for no benefit anyone will ever use. The check isn't saying complex geometry is wrong, only that it should be there on purpose.
Whether a small handful of over-detailed objects — screws, profiles, manufacturer-grade parts — dominate the entire file's weight.
Why it's checkedWhen a handful of objects carry most of the file's geometric weight, it's usually imported manufacturer detail rather than anything meaningful to the project — worth knowing before paying to host and render it for years of its service life.
Repeated objects — windows, chairs, bolts — reused as one shape definition instead of being duplicated in full for every occurrence.
Why it's checkedRepeated objects that share one geometry definition stay small and fast to load. The same objects duplicated in full for every occurrence bloat the file without adding a single piece of new information.
The inverse check: how much of the model's geometry is literal copy-paste rather than properly reused or instanced.
Why it's checkedLiteral copies instead of shared definitions inflate the file today, and turn every future edit to that object into a manual, error-prone repeat across every copy instead of a single change.
Whether room and space volumes are properly closed shapes, which matters directly for area and volume calculations.
Why it's checkedA room volume that isn't a properly closed shape gives wrong answers for area, volume and energy calculations — quietly, since the space still looks perfectly normal in the viewer.
Evaluates how the 3D shapes were actually constructed — standard sweeps, extrusions and tessellations, versus CSG booleans, faceted B-reps or advanced B-reps with excessive voids.
Why it's checkedThis is the one closest to the complex-geometry example: maybe a piece of geometry genuinely needs advanced B-reps, but if it doesn't, those constructs are a real risk — they're what's most likely to crash or corrupt the import in whatever CAD or BIM tool receives the file next, possibly years after it was authored. Faceted B-reps and arbitrary profile voids are the medium-risk version of the same problem: non-manifold topology errors or slow imports rather than outright failures.
Counts surface textures (images, embedded blobs, pixel data) attached to the model, and flags any that reference a hardcoded local file path.
Why it's checkedTextures are ignored by the Coordination and Reference exchange profiles most BIM workflows use, so they add file weight most recipients can't use. A texture pointing at a local path like C:\Users\... breaks the moment the file leaves the machine it was exported from — a problem that only surfaces when someone else opens it later.
4 Information — how much can you actually reuse?
Materials, quantities, classification and properties — the data that gives a model value beyond a pretty 3D picture, and the dimension most asset owners actually pay for.
Share of elements that actually carry a material assignment, rather than being left blank.
Why it's checkedNo material assignment means no carbon, cost or fire-safety analysis is possible for that element — not inaccurate, just impossible, because there is nothing for the calculation to read from.
Share of elements with real quantities — area, volume, length — attached, not just geometry with nothing behind it.
Why it's checkedWithout exported base quantities, every take-off has to re-measure the raw geometry from scratch instead of reading a number the model already has — slower and more error-prone each time someone needs it, for as long as the asset is in use.
Share of elements classified against a recognised system (Uniclass, Omniclass, national systems, and similar), not left uncategorised.
Why it's checkedClassification is what lets an element be matched automatically to a cost plan line, a specification section or an asset register entry. Without it, that matching has to happen by hand — once at handover, and again every time the asset register is updated.
How many meaningful, non-empty data points sit on the average element — the real, practical density of usable information.
Why it's checkedThis counts only the meaningful, non-empty data points — not raw property count, which is easy to inflate with noise. A low number here means downstream workflows like FM systems and cost plans have little real data to actually work with per object.
Of the property values that exist, how many are genuinely informative rather than disguised filler such as "n/a", "-" or "tbd".
Why it's checkedA property that exists but reads “n/a” or “-” looks like data in a completeness check while giving a facility manager nothing real to act on.
Whether custom properties are tied to a standard property set or a URI — ideally a bSDD entry — so their meaning is machine-readable, not just a text label a person has to interpret by hand.
Why it's checkedA custom property with a plain text label only means something to the person who named it. Tied to a standard Pset or a URI instead, its meaning is machine-readable — so it survives being handed to someone else's software, or into an AI workflow, without a person having to interpret it first.
Share of classification references that resolve to a real entry in an online dictionary like bSDD, rather than being plain, unlinked text.
Why it's checkedA code like "23.15.10.10" only means something if whoever — or whatever software — reads it later also knows the standard behind it. Linked to bSDD, that lookup is automatic and permanent; left as bare text, it depends on a person who happens to know that classification system still being around to interpret it.
Share of common property values that live on the shared type object rather than being repeated on every individual occurrence.
Why it's checkedProperties centralised on the type get corrected once and apply everywhere automatically. Repeated on every occurrence instead, the same correction has to be made object by object — a maintenance cost that compounds every time the data is reviewed or updated after handover.
Checks that standard Pset_ and Qto_ property and quantity sets actually match the official IFC schema — correct property names, data types and enumeration values — not just the right set name.
Why it's checkedA property set named "Pset_WallCommon" that uses the wrong data type or an invalid enum value looks standard at a glance but silently fails validation in anything that reads the schema strictly. This is what catches the gap between looking standard and being standard.
A classification code like "23.15.10.10" only means something if the person or system reading it also knows the standard behind it. We check whether classification codes and property references are linked to real entries in buildingSMART's own Data Dictionary (bSDD) — the official, public, machine-readable registry of what every code and property actually means — rather than being plain, unlinked text.
Every distinct bSDD reference found earns the model a dedicated bSDD trust badge, and classification systems that reference it are flagged directly in the Consistency tab's classification table.
5 Consistency — can you trust the numbers?
The quiet errors that break downstream work without ever throwing a visible error — duplicate IDs, impossible quantities, and fields dressed up to look like real data.
Elements sharing an ID they should never share, negative areas or volumes that shouldn't exist, and property values that are empty or disguised as real data — errors that silently corrupt calculations built on top of the file.
Why it's checkedEach of these looks fine until something is built on top of the file. Duplicate IDs break change tracking and issue management (BCF) between model versions; negative areas or volumes are physically impossible and corrupt any calculation that uses them; disguised-empty values pass a naive completeness check while carrying nothing real.
Openings that were cut into a wall or floor but never got their door or window fill back — a common sign of a rushed or partial export.
Why it's checkedAn opening cut into a wall but never filled back with its door or window throws off wall area and opening take-offs the same way an unlinked opening does — and usually signals a rushed or partial export worth asking about.
Near-duplicate names ("Concrete", "concrete ", "Concrete_1"), placeholder names, and stray spacing that quietly fragment what should be one single material.
Why it's checked“Concrete”, “concrete ” and “Concrete_1” look identical in the model but get treated as three different materials by anything that groups or costs by material name — silently fragmenting quantities that should be one line item.
Elements classified against an actual, recognised classification system, rather than only the authoring tool's own internal default categories.
Why it's checkedAn authoring tool's own default categories only mean something inside that tool. A recognised system — Uniclass, Omniclass, a national classification — is understood by the next piece of software, the next contractor and the asset register; the tool's own defaults generally aren't.
Elements named meaningfully and uniquely, rather than left with the authoring tool's default auto-labels like "Wall 1", "Wall 2".
Why it's checked“Wall 1”, “Wall 2” tells a person nothing and a search function even less. Meaningful names are what let someone — today, or years into operation — find the right element without opening every one to check.
Whether classification is attached directly to each element, only to its type, or missing on both — inconsistent placement makes classification unreliable to query.
Why it's checkedClassification stored only on the type, or only on the element, still answers most queries correctly. Stored on neither, the element is invisible to any classification-based search or report — however complete the rest of its data looks.
Object names that have ballooned with concatenated parameters, type definitions or URL-encoded characters, rather than staying short and readable.
Why it's checkedA name built from concatenated export parameters is hard for a person to read and easy for software to mis-parse. It's a smaller problem than a missing name, but it adds up — every list, schedule or search gets harder to scan the more of these pile up.
Objects that carry quantity values (area, volume, length) but have no 3D shape behind them to check those numbers against.
Why it's checkedA quantity with nothing to visually verify it against is a number you have to trust blindly. It's a narrower version of the geometry-coverage risk: here the data exists, but there's no shape in the viewer to confirm it's measuring the right thing.
Whether classification references have a complete code, name and source, and whether the referenced class actually matches what the IFC schema expects for that kind of element.
Why it's checkedA classification reference with a missing code, or one that points to a schema class mismatch, fails silently — it can still show up as "classified" in a simple coverage count while actually pointing nowhere useful. This is what catches classification that looks complete but isn't.
Elements that carry more than one code from the same classification system.
Why it's checkedShown for information only, because this can be entirely intentional — some systems legitimately need more than one code per element — or it can be an export error. Worth a quick check with whoever modelled or exported the file if the count looks unexpectedly high.
Placeholder material assignments and materials that are declared in the library but never actually assigned to anything.
Why it's checkedA placeholder assignment and an unused declared material both inflate the material library without adding real data — clutter that makes a cost or carbon analysis built on "materials used" unreliable, because the library no longer reflects what's actually in the model.
Checks whether the average room area from space quantity sets (Qto_SpaceBaseQuantities) falls in a plausible architectural range, rather than being off by a unit-scale or export error.
Why it's checkedAn average room area of 0.04 m² or 40,000 m² is obviously wrong, but it won't throw an error anywhere — it will just quietly poison every area-based calculation built on top of it, from room schedules to space-based valuations.
Whether each declared unit actually matches the physical quantity it's assigned to — a length unit used for area, for example.
Why it's checkedA mismatched unit corrupts every property value that depends on it, invisibly, until someone notices the numbers don't add up — usually much later, once those values have already been used for something.
Whether the author, organisation and timestamp recorded in the file header agree with the same details recorded in the model's owner history.
Why it's checkedThe file has two separate places that record who made it and when. When they disagree, it's a sign the export pipeline itself has an inconsistency — worth knowing before this file is treated as the authoritative record of who delivered what.
Whether the same classification system (e.g. Uniclass) is declared more than once in the file instead of being referenced from a single shared definition.
Why it's checkedEvery duplicate declaration adds dead weight to the file for no benefit — the classification-system equivalent of copy-pasted geometry, and just as easy to avoid by referencing one shared definition.
Whether virtual space boundaries (IfcVirtualElement) stay virtual — no materials, no solid 3D geometry, no physical properties — rather than carrying substance they shouldn't have.
Why it's checkedA virtual boundary is meant to be a logical line, not a physical object. One that picks up materials or solid geometry along the way gets treated as a real wall or partition by anything downstream that filters on those properties — energy analysis in particular.
Whether external document and library references (IfcDocumentReference, IfcLibraryReference) actually resolve, rather than pointing at broken URLs or local file paths.
Why it's checkedA broken external link is invisible until someone actually clicks it — usually long after the person who could fix it has moved on. A reference that resolves for the exporter today but points at a local file path will break for everyone else the file is shared with.
Checks the IFC file's own internal structure — whether 3D shape definitions are properly attached to the elements they belong to, and whether geometry references actually resolve.
Why it's checkedThis is the deepest-level check on the page: not whether the data is good, but whether the file itself is structurally sound. A shape disconnected from its element, or a reference that can't be resolved, usually means something broke during export or transfer — and everything built on top of a corrupted file inherits that corruption.
Official buildingSMART validation
On top of our ~45 forensic checks, every file can also be run through buildingSMART's own eight official conformance topics — the same independent standard used across the industry. Included on the Free plan, at no extra cost.
buildingSMART validation runs as a separate, independent pass. Until it's completed for a given file, its topics show as pending rather than scored — we never guess a result, and a pending topic never counts against you.
Badges — for your files, and for you
Every file that clears a bar earns a badge automatically — no self-reporting, no guessing. And every badge you've ever earned, across every file, collects into your own trophy case.
Trust badges
Whether the file itself can be relied on: Valid IFC, Real IFC (not mostly generic proxies), Clean export (no duplicate IDs or spatial warnings), Georeferenced, Valid alignment, and bSDD for models with real Data Dictionary links.
Data completeness badges
How much of the model's data is actually filled in — classification, materials, quantities, typed elements and more — each tiered gold at ~100% coverage and silver at 90%+, so partial credit still shows.
Fit-for-use badges
Whether the model is actually ready for a specific downstream job: quantity take-off, AI analysis, operations & FM handover, energy analysis, digital product passport, and coordination.
A badge is either earned, still out of reach, or almost — one condition away, shown as a grey medal with a progress ring so you can see exactly how close it is. Click an almost-earned badge and it takes you straight to the Potential tab, showing exactly what would push it over the line.
Every badge you've ever earned, across every file you've ever analyzed, collects into one page: your full 19-badge collection, your personal-best overall and forensic scores, and how many models and analyses stand behind them.
Generate a public link and it becomes your trophy case — anonymized (your name and email are shown masked, never in full) and ready to share with a colleague, a client, or put in your own portfolio. See all 19 badges in our directory →
See it, don't just read a number about it
A score tells you something is wrong. Seeing the model tells you exactly what and where. Every report includes three ways to look directly at the data behind the numbers.
The 3D viewer
Every uploaded model opens in a full 3D viewer, right in your browser — orbit, pan and zoom into the actual geometry, colour-coded by element class. No plugins, no desktop CAD tool, no round trip.
See it on its real-world location — in 3D
For georeferenced models, we don't just show you a georeferencing score — we place the actual model onto a live satellite or street map, positioned at its true coordinates, so you can see with your own eyes whether it lines up with the real site.
The geometry heatmap
A density map of the model's own geometry: every triangle rendered as heat, from cool to a bright glow, so the parts carrying the most geometric weight jump out visually — instead of being buried inside a single average-triangles number.
Exports & reports
A report you can only view on our site isn't much use to a contractor, an accountant or a modeller who needs to fix the file. Every analysis can be taken with you, in whatever form the next person needs.
Everything above, plus room to work across a whole project
- Tweak processing parameters to fine-tune results for your specific use case
- Compare and aggregate multiple files into one full project overview
- Advanced reports and analytics exports — for your contractor, modelleur, accountant or LLM
- Priority support and self-service billing
Ready to see it on your own model?
Upload your first IFC file and get the full forensic audit — every check on this page, free, forever, on the Free plan.