A coordination brief is most useful when it describes the decisions the review should support. “Run clash detection” alone leaves important questions open: which models are current, what counts as an issue, who decides the response, and how will the result be tracked?
1. Identify the model set
List the disciplines and files included in the review. Record each file's revision or issue date, authoring source where relevant, and any known exclusions. Confirm that the team's reference coordinates and model origins are understood before comparing geometry.
2. Define the review boundary
Describe the buildings, zones, levels, systems, and interfaces under review. Agree what is outside the boundary. Where the team uses clearance checks or tolerance rules, specify them and identify who is responsible for setting or approving them.
3. Agree the issue workflow
Choose the agreed issue recording format and define fields such as location, viewpoint, related elements, description, responsible party, status, and due or review point if applicable. Avoid duplicate issue creation by agreeing how existing items are found and updated.
4. Name decision owners
A model review can reveal a potential conflict, but it cannot determine design intent by itself. Identify who can assess each discipline's response, who approves a proposed change, and how the decision is communicated to other affected parties.
5. Make exchanges repeatable
Set the file exchange location, naming and revision conventions, model update cadence, review date, and method for recording changes. After each round, state which issues are resolved, remain open, or need a project decision.
A concise brief checklist
- Models, revisions, coordinate reference, and included areas
- Review scope, exclusions, test rules, and agreed clearances
- Issue format, naming, locations, statuses, and update method
- Review participants, decision owners, and approval boundaries
- Exchange dates, handoff contents, and open item communication
Project specific caveat
Requirements differ by contract, jurisdiction, project stage, software, and team standards. Confirm technical criteria and design responsibilities with the appointed project professionals. This guide is general preparation guidance, not project specific engineering advice.