Start with a decision
Model coordination is often reduced to running a clash test. That is a narrow view of the work. A coordination cycle should answer a decision question: can the current design be built, accessed, maintained, and documented within agreed constraints? Geometry checks are one instrument in that cycle.
Information checks, design reviews, and field feedback may matter just as much. Before opening a federated model, state what decision the review is intended to support and which disciplines own the inputs.
Set the review boundary
Suppose a hypothetical hospital project has a transfer level where beams, ducts, cable trays, and fire protection compete for limited depth. The review boundary might include only that level, the adjacent risers, and the plantroom connections. This deliberately bounded area allows teams to agree on tolerances and the consequence of a finding.
A whole-building clash report can obscure a high-risk local issue under hundreds of harmless intersections. Record the model revisions, coordinate reference, view range, and excluded zones so another reviewer can reproduce the same scope.
Check the federation first
A clash result has no meaning until the federation is trusted. Confirm each discipline model's origin, rotation, units, revision, and status against the agreed reference. Compare known grid intersections or survey control points, and inspect a small number of elements whose locations are independently known.
A model placed incorrectly can create both false conflicts and false clearance. Check category mappings and visibility too: a missing object can look like a clean result. Treat a federation preflight as a prerequisite, not an administrative formality.
Read diagram notes
- Observe
- Location + objects + revision
- Decide
- Owner + reason + action
- Verify
- New revision + closure evidence
Turn rules into questions
Rules should represent project constraints, not merely what the software can test. A hard intersection between a beam and duct may deserve review; an expected sleeve, firestop zone, or temporary construction condition may need a different rule. Separate physical overlap, required clearance, access envelope, and information completeness into different checks.
A rule should state the selected element groups, threshold or condition, exclusions, and intended reviewer. Where a requirement is uncertain, mark the result for engineering interpretation instead of presenting it as an automatic defect.
Assign a finding with context
A useful issue communicates a location, the observed condition, the affected objects, and the requested action.
For example: 'At grid C-4 on Level 02, the 450 mm duct crosses the 600 mm deep transfer beam; confirm a coordinated route or a designed opening before the next package.' A camera view alone is not enough if it hides level, orientation, or element identity.
Assign one accountable owner, include a due date tied to the coordination cycle, and state whether the issue is a design decision, model correction, or information request.
Resolve by engineering intent
The first suggested fix is not automatically acceptable. Moving a service may affect gradients, access, fire strategy, or equipment performance; changing a structural member may alter analysis assumptions, reinforcement congestion, or connection details. The coordinator routes the decision to competent discipline leads and records the accepted rationale.
BIM can show alternatives and preserve traceability, but it does not establish structural adequacy. A model adjustment should follow the responsible engineer's review and the project's normal approval process.
Close only after recheck
Issue status is not proof that the design is resolved. After a team marks an item complete, confirm that the new model revision contains the intended change and that the original condition has disappeared without creating a new one nearby. Keep the issue linked to the relevant model revision and any design note.
If the condition is accepted, document the acceptance basis and who had authority. A closed issue means the coordination question reached an approved disposition, not that every aspect of design has been certified.
Learn from the pattern
At the end of a cycle, look for repeated locations, element pairs, late changes, and ownership delays. Several clashes around one riser may point to a missing design interface; a cluster of unresolved issues from one package may signal a timing or requirement problem. Use counts as prompts for investigation rather than performance rankings.
A practical improvement is to change one rule, responsibility, or delivery milestone, then compare the next cycle's results. This makes coordination a feedback process that improves the model and the way teams produce it.