BIM Model Quality Assurance: A Practical Model Checking Workflow

Why model QA is not the same as clash detection

Ask most project teams how they check model quality and they will point at their clash report. That is a problem. Clash detection tells you whether a duct passes through a beam. It tells you nothing about whether the duct is on the right workset, whether it carries the parameters the contractor needs for procurement, or whether the model file has quietly grown to a size that makes every sync a coffee break.

Model quality assurance is the discipline of checking that a model is healthy, compliant with project standards, and carrying trustworthy information before anyone else relies on it. Clash detection is one test inside that discipline, and honestly not even the most important one. A model can be clash-free and still be unusable: wrong coordinates, duplicated elements sitting inside each other, rooms unbounded, half the doors missing fire ratings.

The cost of skipping QA is rarely visible on the day you skip it. It shows up three weeks later when the quantity surveyor’s takeoff is wrong, when the fabricator models everything again from scratch because they do not trust your data, or when a federated model refuses to align because one discipline moved the shared coordinates. Every one of those failures traces back to a check that would have taken minutes.

This guide lays out a QA workflow you can actually run on a live project: what to check, which tools to use for each layer, who owns which check, and how often. It is written from the coordinator’s chair, but it works whether you are the sole BIM person in a small practice or running QA across five disciplines on a hospital job.

The three layers of model quality

Model QA gets much easier once you stop treating it as one giant checklist and split it into three layers. Each layer has different checks, different tools, and often a different owner.

Layer 1: Model health. Is the file itself sound? This covers file size, warnings, corrupt elements, unused content, in-place families, imported CAD junk, and audit status. Health problems slow everyone down and eventually corrupt files. They are checked inside the authoring tool, usually Revit.

Layer 2: Standards compliance. Does the model follow the rules the project agreed on? Naming conventions, workset structure, shared coordinates, view and sheet organization, family standards, and the modeling conventions written into your BIM Execution Plan. Compliance problems make models unpredictable for everyone downstream.

Layer 3: Information quality. Is the data inside the elements complete and correct? Parameter values, classification codes, fire ratings, room data, type naming, and whatever your exchange information requirements say must be present at this stage. Information problems are the most expensive because they surface last, often at handover.

A useful mental model: health checks protect your own team, compliance checks protect the project team, and information checks protect the client and contractor. All three matter, but they fail at different distances from your desk.

Layer 1 in practice: keeping the Revit model healthy

Health checks are the cheapest to run and the most commonly ignored. Build these into a weekly routine per model.

Run Audit on open. Open the central model with the Audit checkbox ticked (File > Open, tick Audit). This repairs minor element corruption before it compounds. Weekly is enough on most projects; daily on models over 500 MB or with more than five concurrent users.

Review and triage warnings. Manage > Warnings gives you the full list. Do not aim for zero, aim for triage. Sort warnings into three buckets: harmless duplicates of design intent (identical instances in the same place is usually a real problem though), geometry conflicts that affect quantities (overlapping walls and rooms absolutely affect takeoff), and constraint failures that will bite during design changes. A practical threshold many teams use: keep warnings under 1 per 10 elements, and never let the count grow week over week without an explanation.

Purge unused, carefully. Manage > Purge Unused removes unloaded families, unused view templates, and orphaned styles. Run it two or three times in a row since purging one item often orphans another. Do not purge blindly on a model where the library team stages families for future phases; agree the rule first.

Hunt imported CAD. Every imported (not linked) DWG is a risk: exploded imports scatter thousands of lines and bring in rogue line styles and hatch patterns. Schedule a RVT Links and Import Symbol review monthly. The fastest audit: Manage > Manage Images and a schedule keyed to category Imports in Families.

Watch the numbers. Track file size, element count, warning count, family count, and sync time for each model, weekly, in a simple spreadsheet or dashboard. Trends matter more than absolutes. A model that jumps from 300 MB to 450 MB in a week has a story to tell, usually an exploded import, an over-detailed family, or a flood of unplaced groups.

Layer 2 in practice: checking standards compliance

Compliance checks verify the model matches what the project agreed in the BEP. The checks are simple; the discipline is doing them every time.

Naming. Check model file names, workset names, view names, sheet numbers, and family and type names against the project convention (for ISO 19650 projects, the information container naming from the project’s information standard). Schedules are your friend here: a view list schedule and a sheet list expose naming drift in seconds. For families, a multi-category schedule with family and type fields sorted alphabetically makes off-standard names jump out.

Worksets. Open a 3D view, color it by workset (Visibility/Graphics or a view filter), and look. Ten seconds of looking finds what an hour of report reading misses: structural columns on the architecture workset, an entire link on Workset1. Check that links sit on their own dedicated worksets and that nothing lives on Shared Levels and Grids except levels and grids.

Coordinates. Verify the shared coordinate system against the project base point and survey point every time a model is issued, and any time a link looks even slightly off. Insert the model into a fresh file by shared coordinates alongside the survey file and confirm alignment. Coordinate drift discovered late is one of the most expensive QA failures on any project.

Views and sheets. Working views should be clearly separated from documentation views (a browser organization by view naming prefix does this). No view template overrides on documentation views, no hidden elements in printed views without a documented reason.

Modeling conventions. Walls modeled level to level rather than one giant 40-meter wall, floors by storey, columns split at levels if the structural engineer requires it, no model-in-place elements where a loadable family was the standard. These conventions exist so quantities, phasing, and 4D sequencing work later. Spot-check a sample rather than every element: pick one level, one discipline, twenty elements.

Layer 3 in practice: checking information quality

This is where QA earns its keep, because information errors are invisible in a 3D view.

Start from your information requirements. If the project has an EIR or exchange information requirements, those define which parameters must be populated at which stage. If the project has nothing written down, write your own minimum: every door has a fire rating, every room has a name and number, every mechanical element has a system classification, every element carries the agreed classification code (Uniclass, OmniClass, or whatever the project uses).

Then make the data visible:

1. Build QA schedules. One schedule per rule. A door schedule filtered to show only doors where fire rating is blank is a live to-do list. The moment it shows zero rows, the check passes. This is the cheapest model checking automation that exists, it ships with Revit, and it survives every software update.
2. Color the data. View filters that color elements by parameter state (red where the classification parameter is empty) turn an information audit into something you can see in a 3D view. Solibri and Navisworks can do this too, but a Revit view filter is available to every modeler on the team, instantly.
3. Export and test the exchange format. If the deliverable is IFC, the QA check is on the IFC, not the Revit file. Export with the agreed MVD and open the result in a neutral viewer. Property sets that look fine in Revit regularly export empty because of a mapping issue. Check the export, every milestone.

Information QA has one golden rule: check the data where the recipient will consume it. If the contractor takes quantities from IFC, validate the IFC. If the client takes asset data through COBie, validate the COBie sheet. Checking only the native model gives false confidence.

The pre-share QA checklist

Before any model is shared to the common data environment, run a gate check. Keep it short enough that people actually run it. This one takes 20 to 30 minutes on a mid-size model:

#	Check	Layer	How
1	Model opens with Audit, no errors	Health	Open with Audit ticked
2	Warning count at or below agreed threshold	Health	Manage > Warnings
3	Purge run, no unintended content removed	Health	Purge Unused x2
4	No imported (exploded) CAD	Health	Imports audit schedule
5	File name matches container naming convention	Compliance	Visual check
6	Worksets correct, links on own worksets	Compliance	3D view colored by workset
7	Shared coordinates verified against survey	Compliance	Link test in fresh file
8	Sheets and views named per standard	Compliance	View list and sheet list schedules
9	Required parameters populated for this stage	Information	QA schedules show zero failures
10	IFC export opens clean, property sets present	Information	Neutral viewer check
11	Model description and revision metadata filled	Information	CDE upload form

Print it, pin it, or better: rebuild it as a starting view in every project template so it is the first thing anyone sees when they open the model. The checklist belongs to the model author, not the coordinator. The coordinator’s job is to verify, spot-check, and reject, which only works if authors check first.

Rule-based checking: Solibri, Navisworks, and Autodesk Model Checker

Manual checks scale badly past a certain model size, and they depend on the person doing them. Rule-based checkers run the same checks the same way every time, which is exactly what QA needs.

Tool	Best at	Input	Cost profile
Solibri Office	Rich rule-based checking, information takeoff, classification validation, out-of-the-box rulesets	IFC	Paid license, the deepest rule engine of the three
Navisworks Manage	Clash-centric checking, appearance-based audits, quantification, works directly with RVT/DWG/IFC	Native + IFC	Included in AEC Collection, most coordinators already have it
Autodesk Model Checker for Revit	Free Revit add-in, checks native Revit content against configurable XML checksets, exports reports	RVT	Free, runs inside Revit, ideal for author-side gate checks

A sensible split that works on most projects:

• Model Checker for Revit runs author-side before every share. Build one checkset per discipline from the project standards: naming rules, required parameters, workset rules, prohibited categories. Authors run it themselves; the report goes in the share folder next to the model.
• Solibri runs coordinator-side on the federated IFC at every milestone: space validation, component clearance rules, classification completeness, deliverable-specific information checks. Solibri’s ruleset parameters take real effort to tune, so start with the built-in rulesets and tighten them one milestone at a time.
• Navisworks carries the clash process and doubles as a quick visual QA environment for appearance profiling (color everything by system or by parameter value and look for gray, since gray means missing data).

Do not try to automate everything on day one. Two or three enforced rules that run every week beat forty rules that ran once. Automation pays off when the ruleset is stable, so stabilize your standards first.

Cadence and ownership: who checks what, and when

A QA process without named owners is a suggestion. Assign checks to roles and put them on a calendar:

• Daily, model author: resolve your own warnings before sync, correct worksets as you model, keep working views out of the sheet set.
• Weekly, model manager or lead modeler per model: audit open, purge, warnings triage, health metrics logged, imports hunt.
• Per share or data drop, model author plus coordinator: full pre-share checklist, Model Checker checkset, coordinator spot-check on the shared file. The coordinator has the authority to reject a share that fails the gate. Use that authority early on the project, once, visibly. Nothing establishes a QA culture faster than one politely rejected model.
• Per milestone, BIM coordinator or manager: Solibri run on the federated model, IFC validation against exchange requirements, metrics review across all models, lessons written back into the checksets.

On ISO 19650 projects this maps cleanly onto the check, review, and approve steps of the shared state transition in your common data environment. The checklist above is essentially the “check” step made concrete.

Metrics that tell you whether QA is working

You cannot improve what you do not track, and QA effort is easy to cut when nobody can see what it prevents. Five numbers, tracked per model per week, are enough:

1. Warning count and trend. The single best proxy for model discipline. Report the trend line, not the raw number.
2. Checkset pass rate. Percentage of automated rules passing per share. This is your headline QA number for management, since it compresses the entire standards conversation into one figure.
3. Rejected shares. How many model shares failed the gate this month. Should trend toward zero over the project; a spike flags a training need or a standards gap.
4. Data completeness. Percentage of required parameters populated, straight from your QA schedules or Solibri information takeoff. Track it per discipline.
5. Time to fix. Days between a QA issue being raised and closed. QA that raises issues nobody closes is theater.

Put these on one page and review them in your regular coordination meeting. Ten minutes. The conversation shifts from arguing about whether models are good to talking about specific numbers moving in specific directions.

Common mistakes that undermine model QA

Treating the clash report as the QA report. Covered above, but it is the most common failure by a wide margin, so it earns a second mention. Clash-free is a subset of quality, never a synonym for it.

Checking only at milestones. If the first quality gate is at stage submission, you find three months of accumulated problems with two days to fix them. Small weekly checks exist precisely to make milestone checks boring.

Zero-warning policies. Chasing every warning wastes hours on harmless notices and teaches the team that QA is bureaucratic noise. Triage by impact instead, and write down which warning types your project actually cares about.

QA by one hero. When the entire process lives in one coordinator’s head, it stops the week they go on holiday. Checklists, checksets, and schedules exist so the process survives people.

Rules nobody agreed to. Rolling out a Solibri ruleset that fails 4,000 elements on standards the modeling team never saw creates resentment, not quality. Publish the standards first, agree them in the BEP, then automate their enforcement.

Checking the native file when the deliverable is IFC. The recipient consumes the export, so the export is what needs validating. A perfect Revit model with a broken IFC mapping is a failed deliverable.

No consequence for failing. If a model that fails QA still gets shared because the deadline is tonight, your QA process is decorative. Build the QA time into the share schedule so the gate never competes with the deadline.

How to start this week

You do not need a mandate, new software, or a committee to start doing model QA properly. A realistic first month looks like this:

1. Week 1: Set up the health routine on your main model. Audit open, purge, warnings triage. Log the five metrics for the first time. Build two QA schedules for your most painful data gaps (blank fire ratings and unnamed rooms are safe bets).
2. Week 2: Write the pre-share checklist for your project, one page, adapted from the table above. Agree it with whoever receives your models.
3. Week 3: Install Autodesk Model Checker for Revit and build a ten-rule checkset from your project standards. Run it, fix what it finds, and share the report with your next model drop.
4. Week 4: Run the checklist as a hard gate on one real share. Review the metrics, adjust the thresholds, and put the weekly routine in the calendar as a recurring slot.

From there it compounds. Every rule you add to a checkset is a check you never do manually again, and every rejected bad share saves a downstream failure you never have to firefight.

Model QA is one of those skills that quietly separates BIM professionals who run projects from people who just model on them. It sits at the center of coordination work, right alongside worksharing discipline, federation, and information management. If you want to build that full coordinator skill set on real project workflows, taught by a working BIM Coordinator, have a look at the Archgyan Academy courses. Start with your warnings list this week, though. It is free, it is sitting in your model right now, and it is telling you exactly where to begin.