Coordinate and resolve model clashes

Bring the latest architecture, structure and services models together into one federated set on the shared project origin, and confirm each discipline is the current revision before you test anything.

Why: Clash results are only as good as the models behind them. Coordinating against a stale or misaligned model wastes a whole round chasing conflicts that are already fixed or that do not really exist.

Run the clash tests between the disciplines that matter, structure against services, services against ceilings, and let the tolerances filter out the touch-and-graze noise so the real conflicts stand out.

Why: A pipe through a beam or a duct through a wall costs far more to fix on site than in the model. Detection is where you catch it while it is still a line on a screen and not a change order.

Group the raw hits into genuine issues, drop the false positives, and assign each real clash to the discipline that owns the fix with a clear view of where it sits in the model.

Why: A raw clash count of thousands helps nobody. The value is in a short, owned list where every item is a real conflict with a name against it, so the coordination meeting is about decisions, not sorting.

Where a clash needs a design decision rather than a simple move, raise it as an RFI to the design lead so the answer is written down, dated and traceable back to the model view.

Why: Some clashes cannot be closed by a coordinator alone, they need a real design call. Raising them formally means the decision is on record and the model change that follows can be traced to the reason for it.

When the next model revision comes in, re-run the tests, check the assigned clashes are actually gone, and report the round with what closed, what is still open and what carried over.

Why: Coordination is not done when a fix is promised, it is done when the next model proves it. Re-running and reporting each round is what shows the trend to zero and keeps everyone honest about progress.