How to Run Automated QA/QC and Code Checks in Revit: A Step-by-Step Workflow

Most code and coordination problems are cheapest to fix the day they’re created and most expensive to fix on-site. The trouble is that catching them has traditionally meant a human reading drawings against a code book, slow, late, and inconsistent. If your team already models in Revit, much of that checking can be automated and moved earlier, so issues surface while the model is still easy to change.

This is a practical workflow you could implement on your next project. It’s written for architects and BIM managers, and it assumes you want a repeatable process, not a one-off audit. (For the bigger picture on how AI-driven compliance checking works and where it helps, see the companion guide to this article.)

QA/QC is the foundation: a compliance verdict on a sloppy model is worthless.

First, three things people keep confusing

Before any tooling, get the vocabulary straight, because teams routinely conflate three different questions:

These stack. A clash report tells you that a duct runs through a beam, but not whether either is code-compliant, nor whether the model is even reliable enough to trust its answer. QA/QC is the foundation: a compliance verdict on a sloppy model is worthless. So the workflow below runs quality checks first, then compliance checks, with clash coordination in parallel.

Step 0: Get the model “checkable” first

An automated checker can only evaluate data that actually exists, is correctly typed, and is correctly classified. A rule that says “every fire door has a 60-minute rating” returns nothing useful if your doors have no fire-rating parameter, or if it’s buried in a free-text note. This is the single biggest reason automated checking disappoints teams: garbage in, garbage out.

Before you check, make the model worth checking:

• Start from the right template with your firm’s shared parameters, classification system (Uniclass or OmniClass), and units already set.
• Audit and clean. Run Revit’s Audit on the central file on a regular cadence, review the Warnings dialog and keep the count trending down, and purge unused content (after archiving a restorable copy).
• Confirm classification and required parameters. If a guardrail is modeled as a generic family rather than classified as a railing, the guardrail-height rule will never even select it.
• Match the check to the stage. Don’t run full code checks on concept-stage massing; you’ll generate noise about elements that don’t exist yet. The detail must reach the level of development the rule assumes.

This discipline is what your BIM Execution Plan exists to enforce, and increasingly it’s formalized through buildingSMART’s IDS (Information Delivery Specification), a machine-readable list of the properties and classifications a model must carry, which is validated automatically.

Step 1: Define your rule set

A rule set is a named, reusable collection of checks. Both Autodesk Model Checker for Revit (free, runs inside Revit, strong for data and standards checks) and Solibri (strong for cross-discipline coordination and code compliance via IFC) ship with libraries you adapt rather than build from scratch.

Decide three things up front:

1. Which standards apply to building and fire code, accessibility (ADA / ICC A117.1 in the US), local zoning, plus your own project requirements.
2. Which edition and jurisdiction this matters more than people expect. The ICC writes the model I-Codes, but cities and states adopt them with local amendments and on different editions. A rule set tuned to the wrong edition gives confident, wrong answers. Version-control your rule sets the way you version the model.
3. What’s automatable the prescriptive, numeric checks (widths, heights, occupancy, required properties) are reliable; performance-based provisions (“adequate,” “where practicable”) need a human and shouldn’t be faked with a rule.

Step 2: Run the check

The mechanics are similar across tools: load the rule set, scope it to the relevant elements, and run.

• In Autodesk Model Checker: build or load a checkset in the Configurator, run the report, and batch-select files if you’re checking multiple models. Click a flagged result to highlight that element directly in Revit.
• In Solibri: import each discipline’s IFC (or pull models automatically via Solibri CheckPoint from your CDE), select the role/ruleset, and run. Results come back grouped by rule and severity.

The engine does the same thing under the hood every time: filter to the relevant elements by classification, read or compute the value the rule cares about, compare it to the threshold, and score each element pass or fail with a reason.

Step 3: Review violations by element, in context

This is where automated checking earns its keep. A good report doesn’t just say “12 failures” it links each one to a specific element so you can click it and jump straight to the offending door, wall, or railing in the model.

That traceability runs on persistent identifiers. A flagged element is referenced by an ID that survives between sessions and across the IFC round-trip, so “Door 2.14 on Level 3 fails egress width” points to exactly one object you can inspect, not a vague note to go hunting. Reviewing in a model context, rather than against a printed report, is what makes the fix fast.

A worked example: egress door clear width

Take one rule end-to-end, because it exposes a trap that catches both humans and naive checkers.

The rule. Under the IBC, a door serving as a means of egress must provide a minimum 32-inch clear opening width (IBC 1010.1.1, 2021/2024 editions). Crucially, that clear width is measured between the face of the door and the stop with the door open 90 degrees not the nominal slab width, and not the rough opening. (ICC; accessibility adds a parallel 32-inch minimum under the ADA Standards §404.)

The trap. A “32-inch clear” door is not a 32-inch door leaf. Because clear width is taken from the open door face to the latch-side stop, the leaf, hinges, stop, and hardware all eat into the opening. In practice, a 36-inch (3′-0″) leaf is the common way to net the required 32 inches; a 32-inch leaf will fail.

What a checker reads. To evaluate this honestly, the engine needs to know that the door is on an egress path, then compute the actual clear opening at 90° from the family geometry, rather than simply trusting the nominal Width parameter. A checker that reads nominal width will wave through a 32-inch leaf that delivers only ~30 inches clear. This is a perfect illustration of why model-aware checking that computes geometry beats a tool that just scrapes a parameter, and why model quality upstream determines whether the check means anything.

The fix. Swap the 32-inch leaf for a 36-inch leaf, re-run, and confirm the pass. Document it. This is also the kind of rule that newer model-aware tools such as VitruAI are built to evaluate directly against Revit elements, flagging the specific door rather than leaving you to find it.

Step 4: Triage real violation, false positive, or judgment call

A raw run is a flood of red until a human sorts it. Every result falls into one of three buckets:

• Real violation, fix it in the model.
• False positive is an artifact of a modeling convention or intentional condition; record why it’s acceptable so it isn’t re-litigated next run.
• Needs judgment: a performance provision or an ambiguous case that requires the architect’s interpretation, or field verification (hardware projections into the clear width, for instance, are often not modeled and should be flagged “verify,” not silently passed).

Then prioritize the real ones by severity. The point of triage is signal: an ungrouped list of thousands of warnings trains a team to ignore the report entirely.

Step 5: Resolve, re-run, and document

Fix the real violations, then re-run the only proof a fix worked is a clean check. For issues that cross disciplines or need to go back to whoever authored the element, use BCF (BIM Collaboration Format), the open buildingSMART standard that carries an issue a snapshot, a camera viewpoint, and the element’s ID separately from the model file. The author opens the BCF issue, the viewpoint zooms Revit straight to the element, they fix it and mark it resolved, and it rounds-trip back for verification. That issue record is also your audit trail.

This is the step most teams skip, and it’s where the real compounding happens.

Step 6: Turn every catch into a reusable check

This is the step most teams skip, and it’s where the real compounding happens. When a reviewer catches something the rule set didn’t a recurring modeling habit, a firm standard, a hard-won lesson from a past project don’t just fix this instance. Capture the check itself so it runs automatically next time.

Borrow the discipline software teams have used for decades: when they fix a bug, they write a permanent automated test for it, so that exact defect can never silently return. A QA review can work the same way. Every issue a senior reviewer catches is a candidate to become a new reusable check added to the rule set so that every engineer runs it at modeling time, before the model ever reaches QA. Each catch added this way is one your team can’t regress on again.

Done consistently, this quietly changes what your rule set is. It starts as the public code and grows into a living record of your firm’s own quality standards, the tacit judgment that used to live only in your most experienced reviewers’ heads, now written down and shared. The better model-aware tools (VitruAI among them) are built to make this capture conversational: a QA manager describes what they caught and how they checked it, and it becomes a check that the whole team inherits. Even without such a tool, maintaining a shared, version-controlled checklist of your firm’s recurring issues is the single highest-leverage habit in this whole workflow.

Building it into a cadence

Checking isn’t a single event before submission, it’s a rhythm:

• Continuously, while authoring: keep the Warnings count down; run light data checks (naming, parameters, classification) as you go.
• Weekly, for model health: audit the central file, run the standards checkset, track the issue burn-down.
• Each coordination cycle: federate the models, run clash, triage as BCF issues, and review in the coordination meeting.
• At every milestone, before you share or publish: run the full standards-plus-compliance check and clear or justify every result before the model moves downstream.
• After every QA review: fold the issues your reviewers caught back into the rule set (Step 6), so the next project starts smarter than the last.

Under ISO 19650, this maps to the discipline of check before you share, authorize before you publish the authoring team checks its own model before anyone else relies on it.

Common pitfalls

• Over-trusting automation. A checker reports deviations from rules, not ground truth. It still needs a professional to separate signal from noise, and the architect of record remains responsible regardless.
• Dirty models. Incomplete geometry, missing parameters, or wrong classification produce false positives and miss real problems. Clean first.
• Stale or wrong rule sets. Last project’s checkset, or the wrong jurisdiction’s code, gives confident, wrong answers.
• Checking at the wrong stage. Too early floods you with phantom issues; too late means problems are baked in.
• Ignoring jurisdiction scope. A generic code rule set gives false assurance. Confirm coverage for your edition and locality.

Frequently asked questions

How do you QA a Revit model?

Start with a model hygiene audit, review warnings, purge, and confirm shared parameters and classification. Then run a standards/data checkset (e.g., Autodesk Model Checker) to verify required parameters and naming, fix what fails, and re-run. QA/QC precedes code-compliance and clash checks because those depend on a trustworthy model.

Can Revit check building code automatically?

Revit on its own is an authoring tool, not a code checker. Paired with a rule engine (Solibri, Autodesk Model Checker, or model-aware tools like VitruAI), it can automatically check the prescriptive, measurable parts of a code clearances, occupancy, required ratings and report failures by element. Performance-based provisions still need professional judgment.

What’s the difference between clash detection and compliance checking?

Clash detection finds physical collisions or clearance violations between elements. Compliance checking evaluates whether elements satisfy code and project rules. A model can be clash-free and still non-compliant, and vice versa they answer different questions.

How do I stop the same mistakes recurring across projects?

Capture them. Treat every issue your QA reviewers catch as a candidate for a new reusable check, added to a shared, version-controlled rule set the same way software teams write a permanent test for every bug they fix. Run that rule set at modeling time and recurring, firm-specific mistakes get caught before they ever reach QA. Some model-aware tools let a reviewer add these checks conversationally; at minimum, maintain the shared checkset by hand.

Conclusion

Automated checking won’t replace your judgment, and it won’t issue your permit. What it does is take the high-volume, repeatable, prescriptive checks off your plate and surface the expensive errors while they’re still cheap, provided you feed it a clean model and an accurate, jurisdiction-correct rule set. Put the cadence in place once, and it pays back on every milestone after.

Automated checking won’t replace your judgment, and it won’t issue your permit.

If you want to see model-aware compliance checking running directly on Revit elements, VitruAI is a practical place to start, and the companion guide explains the why behind the workflow.