How to Define Clash Detection Tolerance Rules Before a Coordination Model Flags Thousands of False Positives
Without written tolerance thresholds, clash detection runs produce voluminous reports where genuine interference hides inside noise that no coordination team can clear efficiently.
Clash detection is one of the most broadly adopted BIM workflows in construction, and it is also one of the most frequently misused. Teams run a detection pass, receive a report with hundreds or thousands of flagged items, and then spend coordination meetings debating whether a pipe hanger that sits two millimeters from a duct flange is a real problem or a measurement artifact. That debate repeats every cycle because no one wrote down what a clash is supposed to mean before the model was built.
The gap is a governance problem, not a software problem. Most detection platforms can apply tolerance rules, clearance buffers, and discipline-specific filters. The issue is that those settings default to values chosen by the software vendor for a generic use case. When a project team accepts those defaults without review, the resulting report treats a structural bolt near a conduit the same way it treats a duct running directly through a beam. Reviewers learn quickly that most flags are noise, so they start skimming the list, and that is exactly when a genuine clash goes unresolved into fabrication.
What tolerance settings actually control
A clash tolerance threshold defines the minimum spatial distance two objects must occupy before the system records a conflict. Setting that value to zero means surfaces that touch at a single point generate a flag. Setting it to fifty millimeters means objects must actually interpenetrate by that distance before the system reacts. Neither extreme serves coordination well without context.
Most platforms distinguish between hard clashes, where geometry physically intersects, and soft clashes, where objects are within a defined clearance zone but do not yet touch. Soft clash rules are especially useful for maintenance access corridors, insulation thickness, and seismic bracing swing zones. Those rules require domain knowledge to set correctly, and they should be documented before coordination begins, not adjusted mid-cycle because a report looks inconvenient.
Discipline pairs also behave differently. Structural steel and mechanical ductwork warrant tighter clearance rules than architectural ceilings and electrical conduit runs in some building types. A single global tolerance applied to all discipline pairs collapses those distinctions and forces human reviewers to supply the judgment the model could have encoded from the start.
Writing tolerance rules before coordination begins
The project BIM execution plan is the natural home for clash tolerance documentation, but many BEPs include a clash detection section that names the platform and the meeting cadence without specifying a single numeric threshold. That omission should be caught during BEP review, not discovered during the first coordination cycle.
A useful tolerance rule entry for a discipline pair might read as follows in a hypothetical project BEP: mechanical ductwork and structural steel, hard clash threshold zero millimeters, soft clash clearance 75 millimeters to account for insulation and access; architectural partitions and electrical conduit, hard clash threshold zero millimeters, soft clash clearance 25 millimeters; plumbing and mechanical ductwork, hard clash threshold zero millimeters, soft clash clearance 50 millimeters. Each entry should also note whether that discipline pair requires coordination sign-off before shop drawing release.
Those numbers are illustrative. The right values depend on building type, system density, insulation specifications, and maintenance access requirements specific to the project. The point is that the numbers must exist in writing before the first detection run, agreed upon by the BIM leads from each discipline.
Managing exclusion zones and accepted clashes
Tolerance thresholds address how the software measures geometry. Exclusion zones address areas of the model where detection should not run at all. Penetration sleeves, flexible connections, and construction sequencing gaps are common candidates for exclusion. Without a written list of excluded zones, reviewers encounter the same flagged items in every coordination report and spend time re-explaining why a known gap exists.
Accepted clash status is a related concept. When two systems genuinely cannot be rerouted and the team has accepted a known interference with a mitigation plan, that clash should be formally accepted in the platform with a note describing the resolution. If the platform does not enforce a reason code for acceptance, that requirement should be established in the coordination protocol so the record survives personnel changes on a long project.
Projects that skip both exclusion zones and accepted clash documentation tend to see coordination fatigue set in around the third or fourth cycle. Reviewers stop trusting the report because it still contains items they addressed two weeks ago, and genuine new conflicts start slipping through on the assumption that everything flags repeatedly.
Connecting tolerance rules to downstream workflows
Clash detection outputs do not stay inside the BIM coordination workflow. Unresolved clashes at model handoff affect fabrication drawings, prefabrication sequencing, and in some cases RFI volume in the field. When a fabricator receives a model that was coordinated against vague or undocumented tolerance rules, the fabricator may apply different assumptions and produce shop drawings that reintroduce conflicts the coordination team thought were resolved.
One practical safeguard is to include the project's tolerance rule document as an attachment to the fabrication coordination protocol, so the fabricator knows the clearance standards that governed the model. This is a simple step that is frequently skipped because the tolerance rules, if they were written down at all, live in a BEP version that the fabricator never received.
Project controls teams also benefit from clash status data. Open high-severity clashes by discipline pair can serve as a leading indicator of coordination risk on a schedule. That integration requires that the clash platform export data in a format the schedule or risk tool can read, and it requires that severity classifications in the clash platform are consistent enough to be meaningful. Both of those conditions depend on written rules established before coordination begins.
A practical starting checklist
Before the first detection run on any project, consider confirming the following items are documented and agreed upon by all discipline BIM leads: hard clash thresholds by discipline pair, soft clash clearance values by discipline pair with the assumption each clearance is based on, a list of model zones excluded from detection with reasons, the status codes available in the platform for open, accepted, and resolved clashes, the reason code requirements for any accepted clash, the export format for clash reports shared with fabricators or project controls, and the person responsible for managing tolerance rule changes if scope or systems change mid-project.
None of these items require new software. They require a short meeting before coordination begins and a document that project leadership treats as a binding protocol rather than a suggestion.
Clash detection is reliable when the rules governing it are explicit. When those rules exist only in a reviewer's judgment, the coordination model becomes a list of opinions rather than a record of resolved conflicts. Writing the tolerance rules first does not slow coordination down. It is the step that makes coordination results worth acting on.