Clash detection that closes: a practical standard for architectural models
Hard, soft and workflow clashes only matter if someone owns them. How BIM teams detect, assign and close coordination issues before site.
Most firms can produce a clash report. Fewer can show that the report changed the models before anyone arrived on site. Detection is easy. Resolution is a standard.
This article was inspired by Hitech CADD Services’ Clash Detection and Resolution through Architectural BIM Models. The argument here is our own.
Architectural models sit at the centre of that work. Walls, ceilings, cores, façades and grids set the envelope that structure and MEP must occupy. If the architectural model is messy, every downstream test is noisy. If the resolution process is informal, the same beam-through-wall returns in the next federation.
Three kinds of clash, three kinds of work
A useful test names the type of conflict. Mixing them into one numbered list makes everything look equally urgent.
Hard clashes
A hard clash is a physical intersection: a beam through a wall, a duct through a slab edge, a pipe through a stair soffit. These are the issues site will find with a tape measure. They need a design change, not a note.
Soft clashes
A soft clash is a missing space. The objects do not touch, but maintenance access, door swings, accessibility routes or manufacturer clearances fail. Soft clashes rarely look dramatic in a viewer. They become change orders when a unit cannot be pulled or a corridor fails inspection.
Workflow clashes
A workflow clash is a sequence problem. The model can be geometrically tidy and still unbuildable: conduits scheduled before the wall they sit in, a façade installed before the bracket that holds it, a ceiling closed before the services above it are tested. These are coordination issues, not just geometry.
If the report cannot tell hard from soft from sequence, the team will spend the week arguing about colour, not about ownership.
Architectural models create their own collisions
Generic clash sets — ducts versus beams, pipes versus slabs — miss the conflicts that belong to architecture.
Façade assemblies are a common example. Mullions, brackets, insulation and ventilation zones occupy space that MEP also wants. A duct that “misses” the glass can still hit the backpan or the bracket. Ceiling systems do the same with services, lights and access panels.
Grid and level misalignment is the quiet version. Architecture and structure may share a file name and still sit on different coordinates, different finished-floor assumptions or different levels of development. Walls that look coordinated in plan miss the slab edge in section. That is not an interference test failure. It is a setup failure.
Before the first rule runs, agree:
- A shared coordinate system and true north
- Which architectural elements are in the test (and which furniture or entourage is out)
- The level of development expected at this gate
- Tolerances that match construction, not software defaults
Tools help. They do not close clashes.
Revit can catch many same-file interferences early: a stair against a wall, a floor against a shaft. That is worth doing in design, before a 400-item federated report appears.
A federated tool such as Navisworks is still the usual place to test architecture against structure and MEP. It aggregates models, groups results and produces a view everyone can open. Other CDE coordination tools do the same job. The brand matters less than the rule: one federated model, one issue register, one owner per clash.
Reports should be short enough to act on. Location, elements, discipline, severity and a recommended action are useful. A 2,000-row export with no grouping is not a coordination deliverable.
A close-out process, not a screenshot
1. Build a model worth testing
Start with a clean architectural model: consistent naming, correct categories, no leftover worksets, no unbound links used as the source of truth. Ask structure and MEP for models that match the same gate — same issue date, same coordinates, same agreed scope.
2. Run the test against named rules
Use saved clash tests, not a one-off click. Separate hard, soft and workflow checks. Tag critical, moderate and minor against project risk, not against how red the box looks.
3. Assign, do not circulate
Every open critical clash needs a responsible discipline, a due date and a proposed resolution. Architecture may move a wall. MEP may reroute. Structure may drop a beam. The decision is recorded. Emailing the NWD is not assignment.
4. Change the model, then federate again
Resolution happens in the authoring files. The coordinated architectural model is updated, republished to the CDE, and federated with the other trades. Then the same tests run again. That second run is the proof.
Share the closed set through the project CDE — Autodesk Construction Cloud, or whatever the appointment named — so the record matches the models, not a slide from last Thursday.
What “good” looks like
Good clash detection is quiet. The architectural model is testable. Rules are reused. Issues close in the register. Site does not discover a riser in a beam. Soft clashes are treated as real. Sequence is discussed before the ceiling is closed.
The benefit is not a prettier coordination meeting. It is fewer late changes, fewer dayworks, and a design that can still be built as drawn.
Write the standard once: which tests, which tolerances, who owns which clash type, and what “closed” means. Then run it at every gate. Clash detection only pays for itself when the clash actually disappears from the model.
Source
Inspired by Clash Detection and Resolution through Architectural BIM Models by Hitech CADD Services (29 January 2025).
Frequently asked questions
Is clash detection the same as BIM coordination?
No. Detection finds interferences. Coordination is the agreement on who changes what, by when, and how the result is checked back into the CDE.
Should teams run clashes in Revit or Navisworks?
Use Revit for early, same-discipline checks. Use a federated environment such as Navisworks or a CDE coordination tool when architecture, structure and MEP must be tested together.
What is the difference between a hard clash and a soft clash?
A hard clash is a physical intersection. A soft clash is a failed clearance, access, or code space. Both can stop construction. Soft clashes are easier to ignore and more expensive later.
When is a model actually clash-free?
After the revised models are federated and the agreed tests return no open critical issues — not when the first report is issued.