BIM clashes: types, priority and who resolves them

Finding clashes is the easy part, and the machine does it. The craft starts afterwards: classifying them, filtering the noise, prioritising, assigning and closing them with evidence. A list of two thousand clashes with no owner is not coordination. It is a spreadsheet that reassures everybody and resolves nothing.

Where this came from

Clash detection was not invented in construction. It came from aerospace: the Boeing 777, in the mid-nineties, was the first commercial aircraft assembled entirely in the computer before it physically existed, with no physical mock-up. That was called digital pre-assembly, and construction imported it about fifteen years later.

The craft of coordinating is far older. Before the model it was done with transparent overlays on a light table: ductwork on one sheet, piping on another, electrical on a third. The clash was always visible. What changed is that the machine finds it now, instead of the tired eye of whoever is checking at eleven at night.

Coordination is not about finding clashes. It is about stopping decisions from being made too late.

The five types of clash

Sending every result to the same list is the most common opening mistake. A 4D clash is not the modeller's to fix, and an internal model clash should never reach the coordination meeting at all.

TypeWhat it isExampleWho resolves it
Hard Two elements occupy the same physical space A beam run through by a main duct The author of whichever element can actually move, per the hierarchy
Soft
or clearance
They do not touch, but a space that must stay clear is invaded Pipe four inches from a panel that requires code working clearance in front of it The author, with input from the affected discipline's specialist
4D
or time
They never coexist in the model, but they do in the same week on site Two crews and a crane in the same work front on the same Tuesday The scheduler, not the model coordinator
Model
or internal
The model clashes with itself: duplicated or badly modelled elements Two identical walls stacked by a copy-paste The modeller. It should never reach the meeting
False positive Noise from tolerance, insulation or representation Insulation «clashing» with the structure that supports it Nobody. You adjust the rule, not the model

Tolerance: separating the problem from the noise

Running detection at zero tolerance produces thousands of results, most of them irrelevant. The consequence is not extra work: it is that the team stops opening the reports by week two, and from then on coordination exists on paper and not on site.

Tolerance is set per system pairing, not globally. A two-millimetre overlap between conduits is not the same thing as two millimetres between a beam and a large duct.

A report nobody opens is worse than no report at all, because it also manufactures the feeling that coordination is happening.

How to prioritise

Working the list in the order it came out is working it in random order. The three criteria that actually rank the work are:

The hierarchy: whatever cannot move decides

Solving a clash by moving whatever is easy to move in the model — instead of what is correct to move on site — is the most common way to fix a drawing and create a problem. The order comes from a single question: which element has the least freedom?

1StructureNot negotiable. Everything else runs where it leaves room.
2Gravity drainageIt needs slope. It cannot rise or route freely. Always first among the services.
3Main ductworkLarge section, little flexibility. It defines the space left for everything else.
4Large-diameter pipeIt can be routed, but bends and supports take up more room than the model suggests.
5Sprinkler mainsCoverage rules of their own limit where they are allowed to run.
6Small pipeFlexible, but cumulative: many small runs take the space of one large one.
7Conduit and cable trayLast. It bends the most and costs the least to move.
Teach the question, not the list. That order is the typical answer for buildings. On an industrial or civil project it may be different — a process pipe rack or a high-voltage run can outrank everything else. What does not change is the criterion: whoever has the least freedom decides first.

What happens when one is found

This is what separates a coordinator from somebody who knows the software. There is a ladder, and skipping it is what produces models that no longer match the design.

01Coordinator Detects, discards false positives, classifies and assigns. Moves nothing. Issues the problem with a viewpoint, identified elements, an owner and a date.
02Element author Tries to solve it inside their own discipline. Most clashes die here, and that is the mark of a healthy project.
03Discipline lead Steps in when the fix requires moving somebody else's element. Negotiates across disciplines in the weekly session.
04Design team If the clash reveals a design conflict rather than a modelling one, it stops being a clash: it becomes a formal request for information.
05Owner Only if the fix changes scope, cost or time. At this point it is no longer a technical problem: it is a money decision.
06Coordinator, again Verifies against the updated model that it was actually fixed, and closes with evidence. A clash closed without verification is not closed.

A BIM coordinator has no authority. They have visibility. Confusing the two is the mistake that ruins a new coordinator.

The life cycle of a clash

A clash is not a finding. It is a task with states. Marking it resolved because somebody promised to fix it — without verifying it against the updated model — is the quietest leak in the whole process.

StateWhat it meansWho moves it
NewDetected and classified, no owner yetCoordinator
AssignedHas an owner and a due dateCoordinator
In reviewThe author has proposed a solutionElement author
ApprovedThe fix has sign-off from whoever decidesLead or designer
ResolvedThe model now carries the changeElement author
ClosedVerified against the updated model, with evidenceCoordinator

How a clash travels between different software

Emailing a screenshot does not work: whoever receives it does not know which element it is or where the camera was. That is what the BCF format has existed for since 2010 — an open buildingSMART exchange that carries the issue with its viewpoint, its identified elements, the comment, the assignee and the date, and opens in any tool along the chain.

It is the piece that turns «there's a clash somewhere over there» into a task somebody can pick up. Without something like it, «a clash has an owner and a date» is a wish.

Frequently asked questions

What is the difference between a hard clash and a soft clash?

A hard clash is geometry against geometry: two elements occupy the same space. A soft clash never touches, but it invades a clearance that has to stay free — the code-required working space in front of an electrical panel, the access needed to service a unit, the swing of a valve. Geometry alone does not find soft clashes: they are found by whoever knows the rule. That is why rule-based model checking and geometric clash detection are two different disciplines, and a good coordinator uses both.

Who resolves a BIM clash?

Never the coordinator. The coordinator detects, classifies, assigns and verifies closure, but does not move somebody else's elements. It is resolved by the author of whichever element can move; if the fix touches another discipline it escalates to the lead, and if it reveals a design conflict it becomes a formal RFI.

What tolerance should clash detection run at?

It depends on the system pairing, which is why you define a clash matrix: which discipline is tested against which, and with what clearance for each pair. A single global zero tolerance produces thousands of false positives and the team stops reading the reports, which is the worst possible outcome.

What is a 4D or time clash?

Two activities that never touch in the model but land in the same space in the same week: two crews in one front, a crane blocking access, material laydown where another trade needs to work. It is invisible in geometry; you see it by crossing the model with the schedule.

How many clashes are «too many»?

The right question is not how many there are, but how many have an owner and a date. Two thousand unassigned clashes are worth less than thirty well-assigned ones. Measuring the work by clash count is measuring the noise.

From the model to the site, without losing the thread

VDClens carries a construction project in one application: model, quantities, budget, schedule and field. Every piece of data stays tied to the floor and the document it came from.