Clash Detection: Finding Design Conflicts Before Construction Starts

Clash detection is the process of checking a federated multi-discipline model for components that collide or breach required clearances. The purpose is to move conflict resolution off the site and into design, while changes are still cheap and nothing has to stop for anyone.

What types of clash are there?

There are three, and separating them decides which rules the check runs on. A team treating all three the same produces a report nobody can act on.

Teams new to coordination chase hard clashes only, because they are the easiest to spot and the most convincing as evidence of work. Yet soft clashes are the ones that generate complaints once the building is in operation.

It usually takes this shape: an air handling unit sits exactly where the drawings put it, colliding with nothing, but the clearance to the wall is too tight to open the service panel. Geometrically nothing is wrong. Operationally, every maintenance visit to that unit requires dismantling ceiling. The cost never appears in a project report, because it only surfaces years after handover.

What is the clash detection workflow?

The cycle repeats every round, and what separates experienced teams is not finding clashes but the discipline of closing them. The six steps below run in order, and skipping the fourth is the most common mistake.

1. Collect the latest model from each discipline on an agreed date, not when each feels ready.
2. Federate them into a single combined model on a shared origin point.
3. Run checks against a defined rule set, not every possible discipline combination.
4. Filter the results: merge duplicates, discard the irrelevant, group those sharing one root cause.
5. Assign an owner to every remaining issue, with a name and a deadline.
6. Re-check on the next cycle and close what has been resolved.

The fourth step is skipped most often because it feels administrative. The result is a report of thousands of rows, most of them the same issue seen from different angles, and the design team stops reading it after the second week.

How do you build a clash matrix?

Running every discipline pair at once produces thousands of results nobody can act on. A matrix restricts checking to the pairs that genuinely carry risk, and the four below cover most of the valuable findings on a building project.

• Structure against mechanical, particularly where large ducting runs.
• Structure against plumbing on vertical risers and slab penetrations.
• Mechanical against electrical in ceiling voids, where installation density is highest.
• Architecture against all disciplines where ceiling heights are tight.

The matrix also sets tolerances per pair. A sensible clearance between ducting and structure differs from the clearance between cable tray and pipework, and using one figure for everything is the most common source of the false positives that flood a report.

Why is clash count not a success measure?

A report listing thousands of clashes can look like hard work. In practice a large number usually signals rules that are too loose or models not yet ready to be checked — not a problematic design.

Two measures are more useful. First, how many issues were closed before the agreed date. Second, how many recur in the next cycle. Recurring issues point to a coordination problem, not a modelling one: someone fixed one side without telling the discipline on the other.

What must be ready before checking?

Checking a model that is not ready produces a report that wastes everyone’s time. Four conditions must hold before the first cycle runs.

• Every discipline shares the same origin point and coordinate system. If they differ, models appear offset and every finding is meaningless.
• Component naming is consistent, so issues can be referenced clearly without opening the model.
• Model detail suits the stage. Checking a coarse model produces false positives; checking an over-detailed model too early wastes effort on what will still change.
• Models arrive on the same date rather than trickling in across the week. A late model desynchronises the whole check.

The first condition causes most first-cycle failures and is the easiest to prevent. Agreeing a shared origin costs one meeting at project start, while fixing it after every discipline has modelled costs weeks.

Frequently Asked Questions

When should clash detection start?

As soon as each discipline model reaches a level of detail appropriate to the current design stage — not once design is nearly complete. Waiting until the end removes most of the benefit, because by then a change costs almost as much as a change on site.

How often should it run?

Typically weekly as design completion approaches, less often in early stages. More decisive than the frequency is the regularity: every discipline must know when its model is due, and that date cannot slip.

Must every clash be resolved?

No. Some are irrelevant or resolve themselves at the next stage. What matters is that each one is decided deliberately and the decision is recorded against a name — not ignored without a trace.

Hard clash vs soft clash?

A hard clash is two components physically occupying the same space, such as a pipe through a beam. A soft clash is a component that collides with nothing but breaches a required clearance, such as equipment with no service access. Hard clashes are easier to find; soft clashes cost more when missed.

Sources

• ISO 19650-2:2018 — Delivery phase of the assets — https://www.iso.org/standard/68080.html
• ISO 19650-4:2022 — Information exchange — https://www.iso.org/standard/78246.html

Get an Initial Consultation with BIMAGE Indonesia

BIMAGE Indonesia runs model coordination and clash detection with a matrix built per project, including issue management through to closure and reporting management can actually read. If your coordination cycle is producing thousands of unactioned issues, bring one recent report to an initial consultation — the problem is usually in the rules, not the design.