BIM Issue Closure: Model Revisions, Review Criteria & Acceptance

A status is a record, not a technical conclusion

A building information modelling (BIM) coordination meeting may end with an issue marked closed, only for the same interface between systems to appear in the next review. Ask what closure meant, which revisions were reviewed and who had authority to accept the response. An issue is a recorded question requiring action; its status alone is not evidence that the engineering problem is resolved.

Software records help organise this work. Autodesk’s Navisworks Coordination Issues Add-In exposes issue details, attachments and an activity log, with permissions governing who can close an issue. These are workflow capabilities; they do not, on their own, establish project-specific engineering acceptance. [1]

The workflow below is a suggested review discipline, not a replacement for a project’s BIM execution plan, design approvals or contractual responsibilities.

Find the break in the information chain

Start by distinguishing a genuinely new constraint from a recurrence of an unresolved one. A revised ceiling requirement is not necessarily evidence that the earlier review was careless. A duct adjustment that was never incorporated into the shared model is a different problem.

• Different revisions: the reviewer checks one combined set of discipline models while the author updates another. A screenshot without its source revisions leaves the comparison ambiguous.
• Different completion criteria: one person means ‘geometry moved’; another expects access, installation and maintenance implications to be reviewed.
• Unresolved dependencies: an architectural level, structural opening or adjacent service remains provisional when the issue is closed.
• No acceptance owner: the person implementing a change is also assumed to be the person authorised to accept its consequences.

Do not resolve these differences by adding more status labels alone. First establish the required evidence and responsibility at each transition.

Controlled model exchanges and revision workflows help make the review basis explicit.

Build a closure record that can be checked

For an interface requiring multidisciplinary review, a compact closure record should make the following questions answerable without relying on someone’s memory:

What was the issue? Record its location, affected disciplines and the constraint being tested.

What information was used? Identify the relevant models, drawings and revisions, with enough traceability to reproduce the review.

What changed? State the implemented response and any assumptions or remaining dependencies.

What was checked? Record the applicable spatial, construction, operational or discipline-specific checks. A clear clash test is not a substitute for these checks.

Who accepted it? Identify the agreed reviewer and approval route, including any limits on that acceptance.

A screenshot can help explain a decision, but should accompany the record rather than stand in for the model revision, measurement or authorised review. Sensitive project records belong in the project’s controlled environment, not in a public blog.

Use a review gate, not a one-click finish

Separate implementation from acceptance. The author records the change; the nominated reviewer checks it against the agreed closure criteria. Close the issue only when those criteria are met and the authorised party accepts the evidence. Keep blocking dependencies open. A separate, non-blocking follow-up may remain only under the agreed procedure, with a linked record, owner, due date and explicit limits on use.

SUGGESTED REVIEW SEQUENCE

Define the issue → Assign responsibility → Implement the response → Review the evidence → Accept the resolution

This sequence describes responsibilities, not mandatory software status names.

If a subsequent revision affects the interface, reopen or create a linked issue with the reason recorded. Preserve the earlier evidence instead of silently overwriting it. This distinguishes change-driven rework from incomplete closure and makes the next review more useful.

Make the next coordination meeting about decisions

Before the meeting, separate issues that need engineering input, missing information and approval. During the meeting, capture the decision, responsible party, dependency and next review point. After the meeting, verify that the agreed response exists in the information being shared.

Review recurring issues by cause rather than treating every reopened item as individual failure. Repeated version mismatches call for exchange controls; repeated acceptance disputes call for clearer responsibilities. A dashboard can make these patterns visible, but cannot decide whether an engineering response is acceptable.

The objective is a traceable decision that survives the next model exchange — not a cleaner-looking issue count.

Our BIM coordination service applies agreed review criteria and issue ownership to the project scope.