Five clash detection mistakes we see on every second project
Key takeaways
- Set a clash tolerance per discipline pair — running everything at zero tolerance flags every brick-to-mortar interface and produces a report nobody reads.
- Run a soft-clash pass as well as hard clashes, or you will coordinate a building that cannot be maintained.
- Federate for the first time at the end of stage 3, while coordination changes are still cheap.
- Run cross-level clash sweeps; filtering by level hides services penetrating a slab into the floor below.
- The deliverable is a coordinated design, not the clash report. Move issues through review, assignment and resolution so coordination can be evidenced.
Clash detection is meant to catch problems before they reach site. Done badly, it generates a 9,000-line report no-one will ever read and a coordination team that ends up resenting the BIM process. After running over 200 federation workflows since 2021, here are the five mistakes we see most often.
First: not setting a clash tolerance. Hard clashes at 0mm tolerance flag every brick to mortar interface as a critical issue. Set a sensible tolerance per discipline pair (we usually run structure-vs-MEP at 25mm).
Second: skipping the soft-clash pass. Hard clashes catch geometry that overlaps. Soft clashes catch the maintenance access zone around a valve that nobody can reach. Without the soft clash pass, you're building a building that can't be operated.
Third: federating too late. If you wait until stage 4, the design teams have already committed to decisions that are expensive to undo. Run the first federation at the end of stage 3 — even with incomplete models — to surface coordination issues while changes are still cheap.
Fourth: ignoring level differences. A clash filtered by 'same level' will miss the chilled water pipe penetrating the slab into the floor below. Always run cross-level clash sweeps as a final check.
Fifth: treating the report as the deliverable. The deliverable is a coordinated design. The clash report is the diagnostic that gets you there. Move resolved clashes through 'reviewed → assigned → resolved → approved' in BIM Track or Solibri so the team can prove the model is genuinely coordinated, not just analysed.
Building a clash matrix people will use
A clash matrix defines which discipline is tested against which, and at what tolerance. Getting it right is mostly an exercise in restraint: test the pairs where a conflict has real consequences, and leave out the pairs that generate noise. Structure against mechanical services matters. Ceiling finishes against ceiling-mounted fittings usually does not.
Publish the matrix with the federation schedule so every design team knows what will be tested and when. Clashes that arrive unannounced get treated as someone else's problem; clashes that arrive on a known rhythm get treated as work.
Closing the loop on resolved issues
An issue that has been fixed in the model but never marked resolved is indistinguishable from one that was ignored. That is how a coordination process loses the confidence of the team running it.
Move every issue through a defined status sequence, assign each to a named person rather than a discipline, and re-run the test after the next model upload to confirm the fix landed. The record of that sequence is what lets you demonstrate the design is coordinated rather than merely analysed.
Frequently asked questions
- What clash tolerance should we use?
- It varies by discipline pair. Structure against MEP is commonly run at around 25mm, which filters out interface noise while still catching genuine conflicts. The right figure depends on construction tolerances and should be agreed with the design team rather than taken from a default.
- What is the difference between a hard clash and a soft clash?
- A hard clash is geometry occupying the same space. A soft clash is an infringement of a required clearance — the access zone around a valve, or the space needed to withdraw a component for maintenance. Both need testing; only the first is caught by default settings.
- How often should models be federated?
- Weekly suits most live projects, because it gives design teams a predictable deadline and keeps the issue count per cycle manageable. Monthly federation tends to produce batches too large to resolve before the next one arrives.
- Can clash detection be automated entirely?
- Only partly. Running the tests is automated; deciding which results matter, who owns them and how they are resolved is judgement. A rule-based check in Solibri narrows a report substantially, but it does not replace a coordination meeting.