A coordinated model is only useful if the team receiving it can trust it. That's easy to say and often judged too late — after a contractor opens the file, starts coordination, or finds a drawing that doesn't match the model.
We treat QA as more than confirming the model opens without warnings. The real test is whether another project team can pick it up and use it without discovering basic problems for themselves.
Where QA actually happens
Rules before geometry
Templates, naming, units, worksets and LOD requirements are checked before anything gets modelled.
Not just the federated view
Each MEP system is reviewed on its own before it disappears into a combined coordination view.
Independent final review
Whoever didn't model it looks at the package last, because the original modeller already knows why something was done.
Start with the project requirements, not the geometry
Before checking geometry, we check the rules. Project templates, naming conventions, units, worksets, coordinates, LOD requirements, view standards, shared parameters, model exchange requirements and client-specific conventions all decide what "correct" actually means on a given project.
A technically accurate model can still fail a project requirement if it uses the wrong units, coordinate system, naming or deliverable structure — which is why this comes before anything else.
Checking the model before checking the design
- Warnings and obvious model errors
- Unnecessary or duplicated elements
- Broken or suspicious links
- Worksets and element ownership
- File size and performance issues
- Correct coordinates and model origin
- Consistent units and project settings
This is the digital equivalent of making sure the workshop is clean before the final inspection starts.
Reviewing mechanical, electrical, plumbing and fire protection separately
We review each MEP discipline on its own before looking at the federated model, specifically to catch discipline-level issues that can otherwise disappear inside a large coordination view: system continuity, correct equipment and major components, duct/pipe/containment routing, fittings and transitions, access and maintenance zones, elevation consistency, and whether elements match the latest approved information.
A clash-free model is not necessarily a coordinated model — two services can technically avoid each other while leaving no realistic installation space or maintenance access.
Looking past hard clashes
We look beyond hard clashes at clearance, access, constructability, sequencing and routing logic. If the model is being used to produce shop drawings or construction documentation, the drawings become part of QA too — views should show the intended information, dimensions should make sense, tags should be readable, and details should reflect the model. A model that looks correct in 3D can still produce incomplete or misleading documentation.
High-risk areas get more attention than open floor space
Not every part of a project carries the same coordination risk. Plant rooms, risers, ceiling congestion, major equipment connections, service corridors and tight shafts get more scrutiny than open areas with few interfaces — and get reviewed by someone who wasn't responsible for every modelling decision, since fresh eyes catch what the original modeller unconsciously overlooks.
QA as a gate, not a formality
The goal isn't a perfect-looking Revit file — it's a reliable project deliverable. This is the same discipline behind our BIM coordination and clash detection work: check the requirements, check the model, check the coordination, check the drawings, then check it again from the next person's point of view.