Garbage In, Garbage Out: Model Quality

Model quality is not a vague feeling; it breaks into three concrete, checkable dimensions. Geometric quality: the objects are correctly placed and sized, at shared coordinates, with no duplicates, no orphaned or mis-hosted elements, no wrong classifications — the geometry means what it says. Data quality: the objects carry the required information, complete and correct — the property sets are filled, the values are right, nothing that should be there is blank (Module 3's silent failure). Standards compliance: the model follows the agreed rules — naming, structure, LOD at this milestone, classification — so it is consistent and interoperable (Modules 4 and 5).

Each of these can be *verified*, which is the whole point: quality is not asserted by whoever built the model, it is demonstrated by checking. And each maps to something earlier — geometry to coordination and clash detection, data to analysis and handover, standards to the CDE and interoperability — which is why a failure in model quality shows up as a failure everywhere downstream.

The mechanism that turns 'we hope the model is good' into 'we have verified it' is model checking, done with auditing tools (Solibri and others) and increasingly with IDS (Module 4) for the data requirements. A checking routine tests the model against rules: are there duplicate or clashing elements, orphaned objects, wrong classifications? Are the required property sets present and populated? Does the naming and structure follow the standard? Is the LOD appropriate for this stage? The output is a report of exactly where the model fails to meet its requirements — a to-do list, not a verdict of doom.

The crucial shift is that this is a *routine*, not a one-off, and it belongs to the process defined in Module 5: quality is required (the EIR states what 'good' means), assigned (someone owns the checking), and validated (before information is shared or published in the CDE, it passes its checks). IDS is what makes the data side automatic and unarguable — the requirement expressed as a machine-checkable rule, run against the model, pass or fail. This is how model quality stops being a matter of individual conscientiousness and becomes a governed, repeatable gate — the same gates that make the CDE trustworthy.

Return to the sharp point, because it is the heart of the lesson. Every failure mode in this course shares a shape: a model that *looks* trustworthy but is not. Clash detection on it reports zero clashes and coordinates its errors (6.1). Analysis on it produces a confident number from bad inputs (6.2). A render of it sells a design the model has not actually resolved (6.3). Handover from it gives the operator a tidy file full of wrong data (Module 4). In every case the danger is not obvious garbage — obvious garbage gets caught — it is *plausible* garbage, error dressed as authority.

That is why model quality is the lesson that underwrites the module and much of the course. It is also why honesty — the through-line of this entire BIM course — is not a soft value but a hard engineering discipline: the whole apparatus of checking, validating, and stating LOD and assumptions honestly exists to stop plausible-looking wrongness from being trusted. A team that treats model quality as a governed, checked, non-negotiable gate produces models whose confidence is *earned*. A team that trusts the model because it looks finished is building on sand, beautifully. Of everything in this course, this is the discipline that makes all the rest safe to rely on.