Clash Detection

What is clash detection?

Clash detection is the process of testing discipline models against each other to find physical interferences (a duct through a beam, a pipe through a wall) before they reach the site. Catching these in the model is a fraction of the cost of fixing them in concrete.

We audit the input models first, run detection across every discipline, and deliver an NWD model with viewpoints plus a structured report so nothing is lost between detection and resolution.

Who it is for

• General contractors and subcontractors coordinating trades
• Project teams that want fewer RFIs and less on-site rework
• Owners who need an independent check before construction

Types of clashes we catch

Not every clash looks the same, and each type needs a different fix:

• Hard clashes: two elements physically occupy the same space, such as a duct running through a beam
• Soft/clearance clashes: elements that technically fit but leave no room for insulation, access or maintenance
• Workflow clashes: sequencing conflicts, such as a wall scheduled before the ductwork that needs to pass through it

Setting the clash matrix and tolerances

Before running any test we agree a clash matrix with you: which discipline pairs get checked against each other (structure vs. MEP, architecture vs. structure, MEP vs. MEP) and what tolerance counts as a real clash for each pair. A structural connection might get zero tolerance, while a duct running near a beam gets a clearance allowance for insulation and access.

Getting the matrix right before the first run is what keeps a report a short, prioritised list instead of hundreds of false positives nobody has time to review. It's the main technical difference between a clash test that actually gets used and one that gets ignored after the first pass.

The pairs below are the starting point we bring to that conversation. Projects move them, and the numbers behind a word like clearance belong to your standards, not to ours.

What the clash report actually contains

A clash report is only worth producing if someone can act on it. Ours is two artefacts that travel together: an NWD model with a saved viewpoint for every issue, and a tracked sheet where each clash has an owner and a status. The model shows what the problem looks like. The sheet is where it gets closed.

Every clash moves through the same states. It opens when detection finds it and we confirm it is real rather than tolerance noise. It goes to the discipline that owns the element. A proposed fix comes back, lands in the next model issue, and we re-run the test on that area to check the clash is gone rather than moved somewhere else. Only then does it close.

The count matters less than the triage. A raw test across a federated model returns far more hits than there are real problems, most of them one duct crossing one beam at twenty points, or noise the matrix should have excluded in the first place. Grouping those into a single issue with a single owner is the difference between a list a coordinator works through and a list they close and never open again.

We keep the sheet in Google Sheets rather than a proprietary tracker, because everyone on a project can open it without a licence or an account. If your project already routes issues through a CDE, we work in yours instead.

• Clash ID and the viewpoint that shows it, so anyone can jump straight to the geometry
• The two elements involved, named by discipline and element type
• Location: level, grid reference and room or zone
• Clash type: hard, clearance or sequencing
• Priority, so a structural conflict gets looked at before a cable tray
• The discipline that owns the fix
• Status, from open through proposed to verified and closed
• A comment thread, so the reasoning behind a decision stays attached to the clash

What we need from you to start

Most delays at the start of a clash job are not technical. They come from models that were never meant to be federated: three disciplines on three different origins, or a file exported without the elements the test depends on. The model audit exists to catch exactly that, and the less there is to catch, the sooner detection runs.

You do not need a complete set to begin. Running detection on two disciplines while a third is still in design is normal, and it catches the expensive conflicts while they are still cheap. What we do need is to know which is which, so a missing element reads as missing rather than as a clearance.

• Discipline models in native format or IFC. Revit, Navisworks and IFC all work.
• A shared coordinate system, or the information we need to establish one
• Which disciplines are in scope, and which are still in design
• Your clash matrix, if you have one. If you do not, we propose one and you approve it.
• The level of development the models are at, so we test against what is modelled rather than what is planned
• A named contact per discipline, because a clash with no owner does not close

What you get

• Clash detection across all disciplines, with input models audited first
• An NWD model including viewpoints for every issue
• A structured report (Google Sheet format) tracking each clash
• Communication via chat and coordination meetings
• Direct communication with contractors and subcontractors
• CDE maintenance and administration
• Integration into your internal project meetings

Why catch clashes before the site does

A clash caught in the model costs a few minutes to flag and reassign. The same clash caught on site costs a stop-work order, a rework crew and a delay, often at a multiple of the price. That gap is the entire business case for running detection before construction starts.

Beyond avoiding rework, a tracked clash report gives every trade a single, shared list of what's outstanding, so nothing gets lost between the coordination meeting and the person actually fixing it in the model. Estimators and schedulers work from the same report to price and sequence the job. A set of drawings that clash on paper isn't a schedule anyone can actually commit to.