Quality depends on use
A tidy model can still be unusable. Structural analysis needs connected analytical elements, appropriate materials, and declared support assumptions. Quantity review needs stable element identity, correct classification, and a defined measurement basis. Coordination needs the right revision, location, and agreed geometry. Start each quality review by stating the next decision and recipient. Ask what evidence lets that person use the model without inventing assumptions. This keeps effort proportional: a check should establish the properties and relationships needed for a named purpose rather than chase a universal score.
Turn the need into a check
For each use, define object scope, required property or relationship, responsible author, verification method, and acceptance threshold. For example: every primary concrete column in Zone C has a structural type, material, unique identifier, and level association. Or: analytical beams at the transfer level connect at intended nodes. Keep rules measurable and local. For IFC exchange, buildingSMART’s IDS standard can express requirements for object types, classifications, properties, and values in a computer-interpretable form. IDS checks conformance to a stated specification; it does not decide whether the specification is engineering-correct. A human must define and approve the actual requirement.
Review in layers
Start with identity and provenance: file name, revision, author, coordinate authority, and linked model versions. Check structure next: required categories and objects exist, expected levels and grids are present, and relationships such as analytical connectivity are plausible. Then inspect information: required parameters are populated with allowed values. Finally inspect geometry and exchange behavior in the receiving tool. This order catches setup failures before reviewers spend time on individual elements. Keep a saved view or report for each check so another reviewer can reproduce it. State the model scope explicitly, especially when a linked discipline is absent or out of date.
Read diagram notes
- File and federation
- Revision, units and placement
- Required information
- Fields, types and allowed values
- Intended use
- Evidence for the receiving task
Prevent variation with review views
A check is easier to repeat when the team opens a predictable view with known visibility and graphic settings. The BIM Pure template guide recommends establishing view templates and describes applying required settings while keeping them independent where appropriate. For structural review, create named views for framing by level, openings, transfer zones, and analytical elements. Use filters to make required categories or status values visible, then record which template and model revision the reviewer used. This supports consistent inspection, but a colored element is not proof that its data or engineering is correct; pair visual review with schedules, analytical checks, and written acceptance rules.
Investigate warnings by cause
Warnings are evidence of conditions, not a score to reduce blindly. Review type, count, location, and effect on intended use. Overlapping structural members may signal a geometry error; an intentional join may be acceptable if documented. Autodesk’s file-health guidance recommends auditing, reviewing warnings, and checking unused content as part of inspection. Assign each warning class an owner and a disposition: correct, accept with rationale, or investigate. Track repeat warnings across revisions to find workflow causes rather than repeatedly clearing symptoms. A warning trend can expose authoring guidance gaps even when no individual item blocks this issue.
Separate maintenance from acceptance
Audit and Purge Unused can support maintenance, but neither proves design correctness or fitness for delivery. Autodesk describes Purge Unused as removing unused views, families, and other objects and recommends a backup beforehand. Review candidates because templates, future phases, and office standards affect what should remain. A smaller file can still have wrong levels, missing attributes, stale links, or a bad analytical assumption. Preserve an issued snapshot and record any cleanup afterward so the team can distinguish maintenance from design change. Never use file size or warning count as a stand-alone acceptance metric.
Create an acceptance card
For the next issue, record use, model and revision, checks performed, exceptions, and reviewer/date. Include measurable results, such as all 42 primary columns have the required identifier, or three exceptions remain and each points to an approved issue. For IFC, record schema and version, export configuration, recipient application, and a sample review of geometry and required properties. A file opening successfully is only a first check. The recipient must confirm that information supports the agreed task. When exceptions remain, state their impact and who accepted them; do not bury them in an overall pass label.
Improve the rule set after failure
When a check fails, decide whether the model is wrong, the requirement is unclear, or the check does not measure the intended condition. Correct the underlying cause, rerun against the revised model, and update the acceptance record. If the same omission appears each issue, improve the template, authoring guide, or automated rule. Keep limitations explicit: a rule may cover only selected categories, values, or model versions. This transparency lets recipients understand what the review establishes and what still needs professional judgement. Review the rules when the project use changes, because an appropriate check for design coordination may not prove fabrication readiness.