Hard clashes vs. soft/clearance clashes, the coordination software workflow, clash grouping and prioritization, running an effective coordination meeting, clash report documentation and issue tracking, and when to escalate a clash to an RFI vs. resolve it directly in coordination.
This module closes the loop the last two modules opened: Module 6 covered how discipline models get linked and where coordination conflicts quietly originate before any formal test ever runs, and Module 7 covered the BIM Execution Plan that governs how and when models publish for review. Here, that groundwork becomes an actual coordination process — the difference between a hard clash (unambiguous geometric overlap) and a soft or clearance clash (a code or maintenance-access violation that never physically overlaps at all), how coordination software aggregates published discipline models into a federated view, and why grouping and prioritizing a raw clash report is what turns hundreds of individual hits into a coordination meeting someone can actually get through.
By the end of this module you should be able to explain what makes a coordination meeting actually productive rather than just a status review, how proper clash documentation prevents a resolved item from quietly reverting to unresolved, and the practical test for deciding when a clash belongs in an RFI instead of being closed out directly in coordination.