Clash detection is easy to explain: put models together and find where elements conflict.
Clash avoidance is more proactive — the process of designing and coordinating systems so that avoidable conflicts are prevented before they become formal clashes.
Two different jobs, both necessary
The safety net
Finds conflicts in modelled geometry using defined rules — essential once a project has too many interfaces to review by eye.
The strategy
Agreeing routing principles, zones and priorities before the model gets congested, so fewer conflicts ever need detecting.
Not zero clashes
A coordinated, buildable, documented solution with risk understood and decisions closed.
Detection finds what's already there
Clash detection uses model geometry and defined rules to identify potential conflicts. It's valuable because large multidisciplinary projects contain too many interfaces to review reliably by eye alone.
Avoidance happens earlier, on purpose
Clash avoidance includes agreeing routing principles, service zones, elevations, priorities, access requirements and coordination rules before the model becomes heavily congested — the coordination happens by design, not by discovery.
Every clash detected late creates a decision, review and possible redesign. If the team prevents the conflict through a known routing strategy, that coordination effort never becomes a formal issue.
Ceiling coordination, both ways
Suppose ductwork, cable trays and pipework all need to cross a ceiling zone. Detection may identify dozens of intersections after the fact. Avoidance begins earlier — by agreeing which services occupy the main zone, which cross above or below, and what clearance is required, so most of those intersections never happen in the first place.
Avoidance doesn't replace detection
Complex buildings contain too many variables for every conflict to be predicted manually. Detection is the safety net; avoidance is the strategy — and a mature coordination workflow uses both together rather than picking one:
- Understand design intent
- Establish service zones and priorities
- Model accurately
- Federate disciplines
- Run clash tests
- Review constructability
- Resolve issues
- Update coordination rules
- Repeat until the risk is acceptable
The goal isn't zero clashes
A project can have thousands of low-value automated clashes and still be well coordinated. Conversely, one unresolved equipment-interface conflict can be critical. The goal is a coordinated, buildable and documented solution with risks understood and decisions closed — the difference between using BIM to produce a clash report and using BIM to prevent construction problems, which is how we run clash detection and BIM coordination together on every project.
