What to automate in model QA, and what to leave to a reviewer

Deterministic checks

Model QA involves several checks that are important but repetitive. These are usually the strongest candidates for automation because the expected result can be defined through a clear rule.

For example:

• Does every required element contain the specified parameters?
• Do model names, view names and sheet numbers follow the agreed convention?
• Are duplicate elements occupying the same location?
• Are elements assigned to the correct workset, system or classification?
• Are required views, sheets and model settings present?
• Do parameter values use the expected format?

These questions have measurable answers. A rule-based workflow can review a large number of elements consistently and flag exceptions for further investigation.

This does not mean every flagged item is automatically an error. Two elements may appear duplicated but serve different purposes. A missing parameter may be acceptable for a particular category. Automation identifies conditions that fall outside the defined rule; it does not always understand why they occurred.

That is why automated QA should produce a reviewable result-not silently modify the model or approve it for release.

What stays human-reviewed

Some checks cannot be reduced to a simple pass-or-fail rule because they depend on project context, design intent and construction knowledge.

A model may pass every naming and parameter check while still being difficult to build. A pipe route may be geometrically clear but leave insufficient access for installation. Equipment may be correctly placed but impossible to maintain or replace. A coordinated system may still conflict with the contractor’s preferred sequence, fabrication method or field conditions.

• Human review remains essential for:
• Routing and constructability decisions
• Installation, access and maintenance clearances
• Design intent and engineering context
• Coordination between multiple trades
• Fabrication and prefabrication considerations
• The suitability of assumptions made from incomplete information
• Final approval before a model or deliverable is released

The reviewer must also interpret automated findings. A list containing hundreds of warnings is not useful unless someone can classify their importance, remove false positives and determine what requires correction.

Automation can show that a parameter is missing. A reviewer decides whether that parameter matters to the current deliverable.

Automation can detect that two elements intersect. A reviewer determines whether the condition is a genuine coordination issue, an intentional connection or an acceptable exception.

Automation can confirm that a naming standard has been followed. It cannot confirm that the overall model communicates the right information to the construction team.

Takeaways

Automate checks with clearly defined rules.
Duplicate-element detection, parameter validation, naming compliance and repeatable setup checks are appropriate candidates because their expected outcomes can be stated precisely.

Use automation to flag-not to make unsupported decisions.
Automated results should direct the reviewer’s attention toward possible problems. They should not silently change the model or replace technical approval.

Keep professional judgment in the release process.
Constructability, coordination quality, access, design intent and final deliverable readiness must remain under human review.

The purpose of automation is not to remove people from model QA. It is to reduce the time spent searching for predictable errors so reviewers can focus on the decisions that genuinely require experience.

At ADES, rule-based workflows support the delivery process. Their results are technically reviewed before they influence project coordination or release.

Prashant Andani, Founder

Hands-on BIM/VDC delivery across infrastructure and building projects.

LinkedIn