Back to the library

Make model-review meetings produce decisions, not screenshots

A useful model-review meeting turns a focused set of observations into recorded decisions, owners and verification steps. The model is evidence for the discussion, not the minutes themselves.

tagged beam interface, action cards and clean orange timeline

Prepare decisions, not a model tour

Each agenda item should state the location, model versions, issue category, decision requested and the people who can make or escalate it. Screenshots become noise when the expected decision is missing.

Freeze the viewing basis

At the start, state the federated package and any exclusions. If a participant opens a newer local model, mark the difference rather than silently using it to settle an issue.

Use focused views

Open a saved section or 3D view that shows the relevant structure, services and level reference. A viewpoint supports context; it does not replace a drawing, calculation or discipline check where those are needed.

Four-stage workflow for make model-review meetings produce decisions, not screenshots.
A practical coordination workflow: use the stages to make the review repeatable. Open diagram ↗
Read diagram notes
Prepare
Select decision-ready issues.
Review
Use a known model revision.
Decide
Assign owner and due date.
Verify
Close with repeatable evidence.

Phrase the minute precisely

Record what was agreed, what evidence supported it, the owner, deadline and downstream models affected. “Discussed beam clash” is not a decision. “Services engineer to test alternate route and return evidence” is actionable.

Separate acceptance from action

A coordinator can close an information-management action after evidence is supplied. Structural adequacy, permit approval and conservation acceptance remain decisions for the accountable role.

Verify at the next cycle

Reopen the named issue against the later package and confirm the agreed condition, rather than accepting a verbal update. Keep rejected alternatives and accepted exceptions visible for the reviewers who follow.

Worked example: duct route below a transfer beam

A services team reports a conflict below a transfer beam. The meeting opens a saved section showing the beam, duct, floor level and required clearance, using stated structural and MEP revisions. The structural engineer explains that an unapproved web opening is not an option; the services engineer agrees to test a reroute. The minutes record the alternative route, responsible author, return date and need for a later coordination view. At the next meeting, the revised route is checked against the named model set before the issue is closed. Inputs are a stated agenda, model revisions and a saved section through the corridor. The mismatch is that the duct reroute solves geometry but creates an access conflict at a valve. The services team returns with a second route, and the model review checks both clearance and access view. The output is a decision minute with the adopted route, model revisions and verification responsibility.

Decision checklist

Bring one stated decision per issue; cite revisions; show a focused view; write the decision and rationale; assign the author and verifier; reopen against the later package.