How clash reports become theatre, and how to triage what actually matters
The report lands in the shared folder on Monday morning: 4,127 clashes. The coordination meeting opens with a screenshot of the federated model, lit up in red like a Christmas tree. Someone notes that last week’s number was 4,600, so things are moving in the right direction. Heads nod. The meeting moves on.
Nobody in the room can say which of those 4,127 clashes will stop work on site. That’s the problem.
Clash detection is one of the most valuable things BIM offers a project. It’s also one of the most abused. Somewhere between the software and the site, the clash count stopped being a diagnostic and became a performance. The number goes in the minutes, the number goes in the owner’s report, and a falling number becomes the definition of progress. Meanwhile, the handful of conflicts that genuinely threaten cost and schedule sit buried in the pile.
Why the number is almost always wrong
A raw clash count tells you very little, because most clashes in a typical report aren’t independent problems.
One problem, forty clashes. A duct run crossing a cable tray doesn’t generate one clash. Every duct segment, fitting, hanger and insulation layer touching the tray can register separately. Reroute the duct once and forty “clashes” disappear. Nothing about the building changed except one decision.
Intended conditions flagged as conflicts. A pipe passing through a wall is a penetration, not a clash. If the test doesn’t exclude planned and sleeved penetrations, every one of them shows up in red.
Poor model hygiene. Linked models on mismatched shared coordinates, ceilings modelled as solid slabs, oversized placeholder families, and trades working to different levels of development all generate false positives by the thousand. A clash test run against dirty models measures the quality of the modelling, not the quality of the coordination.
Testing everything against everything. Architectural walls against structural walls, finishes against framing, furniture against sprinkler heads. Some of these tests have value late in the project. Run them all on day one and the report becomes noise.
What the theatre looks like
You can usually spot clash theatre from the meeting minutes. The total count is the headline metric. Issues are assigned to “MEP” rather than to a named person. Meetings are spent scrolling through viewpoints instead of making decisions. And clashes get marked “approved” without a recorded reason, because that’s the fastest way to make the number drop.
The incentives are the real culprit. When the count is the KPI, everyone learns to manage the count. Tolerances get quietly loosened, awkward elements go unmodelled, and the report improves while the model doesn’t.
The cost shows up later. The conflict that mattered, a main sanitary line with no room to lose slope running into a transfer beam, was sitting at clash number 2,318, between two insulation touches. Nobody saw it until the pipefitters did.
A triage approach that works

1. Clean before you test. Run a model audit before the first clash test. Confirm shared coordinates, check element categories, strip out placeholders, and verify that each trade is modelling to the agreed level of development. A surprising share of clash detection’s value comes from this step alone.
2. Test with intent. Build a clash matrix that defines which disciplines are tested against which, in what order, and at what tolerance. Start with the least flexible systems: structure against gravity drainage and large ductwork. Move to pressurized piping and cable tray next, and leave small conduit for last. Use clearance tests where access and maintenance zones matter, and set sensible tolerances for flexible services rather than flagging every touch.
3. Group, don’t count. Group clashes by location (level, zone, gridline) and by system. The unit of coordination is the issue, not the clash. A report of 4,000 clashes often contains 60 to 80 real issues, and those are what the team should be discussing.
4. Rank by the cost of being wrong. Prioritize by what can’t move (structure, sloped drainage, large mains), by what’s closest to fabrication or installation (the floor going to shop drawings next month outranks the floor six months out), and by what affects long-term operation, such as access to valves, VAV boxes and equipment needing service clearance.
5. Assign a decision, not a clash. Every issue gets a named owner, a due date and a clear statement of the decision required. Accepting a clash should require a reason in the issue log, so the next person understands why it was allowed to stand.
6. Report what matters. Replace the total count with metrics that reflect risk: open critical issues by zone, the age of open issues, issues blocking fabrication, and zones formally signed off as coordinated. Keep the raw count as a diagnostic for the coordinator, not a headline for the owner.
   Change the meeting, change the outcome
   A good coordination meeting works through the model zone by zone, focuses on the top issues in each, and ends with decisions made in the room. If the team spends an hour scrolling viewpoints and leaves with the same open items, it was a presentation, not coordination.
   The goal of clash detection was never zero clashes. It’s zero surprises on site. A meeting that resolves twelve issues capable of causing a week of rework is worth more than one that “closes” nine hundred.
   Here’s a simple test for any project team. Ask your BIM coordinator: of these 4,000 clashes, which five will hurt us most? If they can answer quickly and with confidence, your process is working. If they can’t, you don’t have coordination. You have a report.