A Revit model checker automates QA/QC. It doesn't replace it.

Revit's Model Checker is closer to a spellchecker for the model's bookkeeping than a complete quality-control tool. It reads what Revit has stored: whether parameters are filled in, whether names follow a pattern, whether the right type is loaded. It does not judge the design.

So a good checkset can tell you at once which rooms have no department or which doors have no fire rating. It cannot tell you a wall is structurally wrong if its label is right, and it cannot decide whether a deviation from the standard is a problem or a justified exception. That distinction is how much a clean report is actually worth.

Running a checkset on a model that is already a mess produces a long list of warnings nobody has time to act on. Duplicate types, orphaned parameters and downloaded families nobody reviewed, the same clutter covered in Revit library optimization, fill the report with noise rather than findings.

A basic clean-up first, meaning Purge Unused, an object-styles pass and consistent naming, is the difference between a report someone works through and one nobody opens.

Autodesk's Model Checker Configurator lets you write your own rules, and sample checksets such as the Revit best-practice and COBie sets are a place to start. An imported checkset rarely matches what your office actually needs. It is a starting point, not the answer.

Building one is a skill, not a handful of clicks. Three habits make the biggest difference:

• Start on a small test model with known elements, not the live project. One wrong rule against a real model produces a flood of false flags.
• Know how Revit stores data, not how it displays it. Lengths are stored in decimal feet whatever the project units, so a numeric comparison written in millimetres fails without warning.
• Copy and edit an existing checkset rather than starting from a blank one. Most useful rules have already been written by someone.

A first checkset should be short enough to act on. Five groups of rules cover most of what offices actually argue about:

• Naming: views, sheets, families and types against the office pattern.
• Required parameters: the fields schedules and tags depend on, filled in and in the right format.
• View templates: every working view has one, and nobody has overridden it by hand.
• Model hygiene: in-place families, imported CAD and unused elements kept to what the project actually needs.
• Handover data: the fields a delivery format such as COBie expects, if the project needs one.

Anything beyond these belongs in a second checkset, written once the first one has been run on real projects and earned some trust.

Every flag is one of three things: a real violation, a false positive because the checker has no context, or a judgment call that needs a person. Fixing everything in the order the report lists it, without that sort, spends time on the wrong items and finds the ones that matter last.

A long list of flags can come from very few causes. One family loaded with the wrong parameter type flags every instance of it. Group the flags by family and by rule before fixing anything.

Once something is fixed, rerun the check to confirm it, and keep the rule. Nothing found once should have to be found twice.

Model Checker only reads what Revit has stored. Clash detection between disciplines, geometry-level checks and exporting parameters to a spreadsheet for review all sit outside it. Navisworks and Solibri cover clashes and geometry; Dynamo scripts and add-ins such as Ideate BIMLink cover parameter review.

The usual order is data first, geometry second. Confirm naming and parameters with the native checker, then run clash detection. A clash report on a model whose basic data is still wrong is not worth reading yet.

When an office's rules cannot be expressed in the Configurator at all, a custom checker built on the Revit API is the next step: the same rules, run as a test on every model, with a report written for the people who have to act on it. Model checks are one of the workflows covered in how much Revit plugin development costs.

A one-off check buys a few weeks. Models drift back under deadline pressure, the same way libraries do. A quarterly rerun is a reasonable default for active projects.

Run regularly, the results stop being a list and become a trend: which projects are improving and which keep returning to the same problems. That trend belongs on a dashboard the team actually opens, not in a spreadsheet emailed once and forgotten.

If it is one project, a handful of rules cover it and Autodesk's free tool already does the job, nobody needs to be hired, including us. Spend an afternoon in the Model Checker Configurator instead.

Outside help makes sense when the checks must run across several projects for years, when the standard itself is not written down yet so there is nothing to encode, or when the results need to feed an automated flow. That gap, between a free tool and a standard that checks itself on every model, is where custom Revit plugin development earns its place.