AI Adoption GuideConstructionPlan
BIM Design Clash Detection
ML vision model detects spatial clashes between MEP, structure, and architecture in the BIM model. (e.g., Autodesk Clash Detective AI)
Construction processBidAwardPlanMobilizeBuildInspectHandoverClose
By Don, DoneThat’s AI coach · updated
Keep the clash as a cite, not a clearance
A spatial clash is usable only when it names the colliding elements, a location a coordinator can isolate in the model, and the disciplines that own the change. The detector does not close the issue. Autodesk-class clash tools, including Clash Detective-style AI in that product family, can surface overlaps among MEP, structure, and architecture. They do not own the quality outcome. A coordinator still accepts, rejects, or leaves the record empty when the model is unsure.
Do not treat a high score as a clearance. Do not auto-accept a gap that looks like it meets a specification. If the vision or geometry model cannot cite elements with enough confidence to act, the clash list stays empty for that region. Empty is a valid quality state.
The run path is federate, detect, cite, then stop for a human decision.
Assemble one federated model before you run detection
Clash detection on a single consultant file misses the collisions that matter, because architecture, structure, and MEP live in different models. The run a BIM or design-coordination lead actually uses starts with a federated set: linked files or a published coordination model that shares a common coordinate system, shared levels, and agreed worksets or discipline layers.
Confirm four things before you run. The federation must be the same snapshot the coordination meeting will use; a clash against last week's steel is noise. Units, true north, and survey point must match; a shifted origin looks like a forest of clashes. Scope the views or selection sets you mean to review; running the whole site when you mean Level 2 mechanical rooms wastes the hour. Agree LOD per discipline; a schematic pipe drawn as a centerline will not collide with a beam already modeled as a solid.
Then run clash on that federated set. Autodesk-class detectors typically compare solid geometry for hard clashes and sometimes clearance envelopes for soft clashes. Treat those products as a class, not a ranked list: every row must be a cite a person can open.
Illustrative only, not a recorded clash. A Level 3 corridor at grid D-4 shows a storm drain (plumbing file, element ID) occupying the same volume as a steel beam (structural file, element ID) at a documented elevation. Architecture owns the ceiling zone both are trying to occupy. That sentence is the cite. The detector may highlight the overlap. It does not decide whether the pipe moves, the beam web is allowed a penetration, or the ceiling type changes. If those IDs or the elevation cannot be recovered, do not invent the clash. Leave the region empty.
Cite elements, location, and discipline, then stop
A flag without a cite cannot be owned. The quality outcome is a clash record with element identities from each contributing model (unique IDs, not only type names); a location the coordinator can isolate (level, grid, room or zone, and elevation or offset when the model has it); discipline owners who must answer (plumbing versus steel versus architectural interiors, not a generic "MEP"); clash type (hard overlap versus clearance, if the tool distinguishes them); and the model snapshot (which federation and date the run used).
Write the cite so someone who did not run the job can open the same elements. Then stop. The coordinator accepts (the clash is real and assigned), rejects (false positive, duplicate, or already resolved in a later commit), or leaves it empty if the detector returned a blob without IDs.
Do not auto-close on score. A low-confidence overlap is not "probably fine." A high-confidence overlap is not "already coordinated." Acceptance is a human act because the next step may be a design change, a lookahead constraint scan on the affected activity, or an RFI. Auto-closing a clash the model scored low is how a pipe through a beam reaches the drawings while the clash log looks clean.
When the cite is solid and the coordinator accepts, the record can feed later work: a constraint on install sequence, language for RFI auto-response drafting if a consultant must justify a penetration, or a line on project risk register generation if the clash sits on a long-lead system. None of those downstream uses replace the accept or reject step.
Intended penetrations, coarse LOD, and low-score auto-close
Three failure modes belong in the review, not in an appendix.
Intended penetrations flagged as clashes. Sleeves, reserved openings, and specified beam penetrations are not defects. A clash model that only sees overlapping solids will flag a pipe in a designed sleeve as a hard clash. Auto-accept every red cell and the meeting is spent on work already in the drawings. Auto-reject every overlap that looks like a sleeve and you miss the opening that was never detailed. Include the architectural or structural opening element in the cite when it exists. Reject only when the coordinator can point at that opening in the federated model. If the sleeve is specified but not modeled, keep the clash open as a modeling gap, not as a closed coordination item.
Missing a pipe through a beam because of LOD. A centerline or low-detail MEP run does not occupy the beam's volume even when the constructed pipe would. The detector reports no clash. Empty in that case is not clear; it is that the model did not have enough geometry to collide. Raise LOD for that zone before relying on the run, or keep a manual check for that routing. Do not record a clearance. Do not invent a clash to stand in for the missing solids. If the pipe is a line, leave that location empty and note the LOD limit in the review.
Auto-closing a clash the model scored low. Score is not acceptance. A grazing clearance, a mesh artifact, or a linked file with a stale origin can produce a weak score on a real overlap. Closing those rows because they look like noise is how a pipe-through-beam survives into fabrication. Keep low-score rows visible. Reject them only with a reason: duplicate, already moved in the current federation, or known sleeve with a cited opening. If the cite is incomplete, leave the row empty rather than closing it.
The same rule applies to clearance envelopes. A soft-clash tool in the Autodesk class can flag insulation or access space. Do not auto-accept a clearance dimension because the number looks familiar from a spec. Spec confirmation for a submitted product is a different check, covered under submittal spec compliance check. Clash detection answers whether modeled elements occupy the same space. It does not answer whether a product meets the specification.
What the coordinator does with each outcome
After the run and the cites, work three buckets only.
Accept: the clash is real, the elements are named, location and disciplines are clear, and someone is assigned. The quality record is the cite plus the decision. Design change stays with the authoring teams. The detector does not move the pipe.
Reject: the flag is a false positive, a duplicate of an accepted item, or geometry that no longer exists in the current federation. Rejection needs a one-line reason tied to the cite (for example, opening element present at grid D-4, Level 3). A reject without a reason is how intended penetrations get re-flagged every week and how reviewers stop trusting the list.
Empty: the model did not produce a reliable cite (missing IDs, mixed coordinates, LOD too coarse to collide, or a region the detector skipped). Empty stays empty. Do not backfill with a guessed clash. Do not mark the zone clear.
Keep clash detection in its lane: surface overlaps among MEP, structure, and architecture in the federated BIM, write a cite a coordinator can own, and refuse to treat score as clearance.
Is this worth automating for you?
Whether this pays back depends on how much time it takes your team today. Most teams estimate that from memory, and the estimate is usually wrong in one direction or the other.
DoneThat reconstructs where the time actually went, with no timers to forget, so you can measure the baseline before committing to a project and check the gain afterward.
Measure the baseline first