Reaching zero clashes is often treated as the final objective of BIM coordination. The number is easy to understand, easy to place in a report and easy to use as evidence that a model has been reviewed.
But a zero-clash result is not automatically proof that a project is coordinated.
The result depends on how the test was configured, which models and elements were included, what tolerance was used, which issues were excluded and whether access, clearance and maintenance space were checked. A report can show zero while important coordination risks remain in the model.
The real objective is therefore not simply to reduce a software-generated count. It is to establish a coordination process that produces reliable, reviewable and buildable information.
Zero Depends on the Rules Behind the Test
Clash-detection software identifies conflicts according to a defined set of rules. If those rules are incomplete or too broad, the result can be misleading.
Every coordination plan should establish:
- the models, zones and systems included in each test;
- the element categories checked against one another;
- the tolerance applied to each clash set;
- the frequency and sequence of coordination reviews;
- the treatment of approved connections and intentional intersections;
- the information required for each recorded issue; and
- the acceptance criteria for closing a package.
The tolerance is particularly important. A very small geometric overlap may result from modelling accuracy or rounding, while a larger intersection may represent a genuine construction conflict. Setting the threshold too loosely can hide real problems. Setting it too tightly can generate excessive noise and distract the team from issues that carry greater project risk.
There is no single tolerance suitable for every system. Structural elements, major service routes, insulation, finishes and specialist equipment may require different checks. Tolerances should follow the agreed modelling requirements, system characteristics, project stage and intended use of the model.
Hard Clashes Are Only the Beginning
A hard clash occurs when two modelled objects physically occupy the same space. Examples include a duct passing through a beam, pipework crossing another service or equipment intersecting a wall.
These conflicts are important, but a model can contain no hard clashes and still be difficult to construct, access or maintain.
Soft clashes occur when elements do not physically overlap but fail to maintain the space required around them. This can include:
- insufficient room to install a component;
- inaccessible valves, dampers or control panels;
- inadequate space to remove or replace equipment;
- missing insulation or fire-stopping allowances;
- unsuitable clearance from access panels or doors;
- service routes that prevent safe movement; or
- components placed too close for practical fixing and assembly.
The required clearance should come from the project specification, selected product, manufacturer guidance, maintenance strategy and applicable requirements. A generic allowance may be useful during early design, but it should be refined as the project and product information develop.
This is why coordination must assess how a space will be built and used, not only whether its modelled geometry intersects.
A Clash Count Does Not Show Priority
A raw clash count gives every issue the same numerical weight. In practice, a primary structural conflict and a small local modelling overlap do not present the same risk.
The project team needs an issue register that classifies each clash according to its impact and required response.
| Priority | Typical issue | Required response |
|---|---|---|
| Critical | Conflict affecting primary structure, major equipment or a principal service route | Resolve before the package progresses |
| Major | Access, clearance or coordination issue that affects installation, operation or maintenance | Resolve and verify through coordination |
| Minor | Localised conflict with limited downstream impact | Assign, correct and verify |
| Accepted | Intentional connection or issue confirmed to be within an agreed tolerance | Record the decision and supporting reason |
The labels can be adapted to the project’s own issue-management system. What matters is that priority, responsibility, due date and status are visible.
An issue should not disappear from the register simply because it is inconvenient to resolve. If it is accepted, the reason should be recorded so the decision can be understood during later reviews.
Run Coordination in a Deliberate Order
Coordination becomes inefficient when every possible clash set is run at once. Secondary issues are reviewed against elements that are still expected to move, creating repeated work and an unstable issue count.
A more controlled sequence generally moves from the least flexible and highest-impact systems towards more adaptable detail. Depending on the project, this may include:
- Confirming grids, levels, zones and model alignment.
- Coordinating architecture with primary structure.
- Checking major equipment and principal service routes against structure and spatial constraints.
- Coordinating main distribution routes between disciplines.
- Resolving branches, terminals, supports and local connections.
- Running access, clearance, maintenance and installation checks.
- Verifying drawings and schedules against the accepted model arrangement.
The sequence must reflect the project’s design responsibilities and construction priorities. The principle is simple: resolve the decisions with the greatest downstream impact before coordinating the detail around them.
From Detection to Resolution
Clash detection identifies a potential issue. It does not decide the correct solution.
Effective coordination needs a repeatable cycle:
- detect the issue using an agreed clash rule;
- review whether it is valid, duplicated, intentional or within tolerance;
- assign it to the party responsible for the relevant design or model;
- agree the resolution with affected disciplines;
- update the authoring model;
- rerun the test; and
- close the issue only after the revised condition is verified.
This cycle should be supported by clear meeting records and an accessible issue register. Screenshots can help explain a clash, but they should not replace location data, element references, responsibility, status and revision information.
Use a Clash Gate, Not Only a Report
A clash report should form part of a controlled information workflow rather than being issued as an isolated document.
Models are developed within their responsible teams before being shared for multidisciplinary coordination. Once shared, the relevant clash sets are run, issues are assigned and the coordinated package is reviewed against its acceptance criteria. Only after the required issues are closed or formally accepted should the package progress to an approved or published state.
The gate should confirm more than a headline count. Depending on the package, it may check that:
- the required models and revisions were included;
- clash tests used the approved rules and tolerances;
- critical and major issues are closed;
- accepted issues include recorded reasons;
- access and clearance checks are complete;
- model and drawing information agree; and
- the approval, revision and responsible parties are recorded.
This creates an auditable relationship between model status and coordination quality. Teams can see what was reviewed, which decisions remain open and which information is approved for its intended use.
Validate the Coordination Setup
Automated detection should not be accepted without checking that the test behaves as expected.
Before relying on a clash set, the coordinator can test it against known conditions. The check should confirm that genuine intersections are detected, intentional connections are handled correctly, clearance zones behave as required and excluded elements do not distort the results.
Model alignment and coordinate systems should also be verified before clash detection begins. A misaligned model can produce hundreds of false conflicts, while missing or incorrectly classified elements can create a misleadingly clean report.
The software accelerates the review, but the reliability of the result still depends on competent setup and technical judgement.
What Zero Should Mean
For a coordinated BIM package, zero should not mean that every line in a software report has been removed. It should mean that the package has passed a defined and repeatable coordination standard appropriate to its stage and intended use.
That standard includes honest tolerances, hard- and soft-clash checks, risk-based priorities, accountable issue resolution and a controlled approval gate.
When these conditions are in place, the zero-clash result becomes useful evidence. Without them, it is only a number.
