One fix, many clashes: root-cause grouping of a clash report

A thousand lines, a few hundred problems

Run Structure against MEP and Architecture against MEP on a single floor of a hospital and the report easily runs past a thousand lines. Anyone who has worked through one knows the pattern: the same pipe appears in both tests, a hundred clashes sit within tolerance, a dozen are copies of your own duct in someone else's model, and one badly placed main accounts for forty lines on its own.

Working that list top to bottom is how coordinators lose a week. Working it by cause is how they get it done in a day. ClashFree does the sorting first, so the list you work on is a list of decisions.

Step 1: match every clash to its elements

ClashFree imports Navisworks XML clash reports and BCF files, several at once, into one list. Each clash is matched to its two elements in your host model or its loaded links. When a report names a fitting or an accessory, ClashFree resolves it to the nearest straight of its run, because a fix moves runs, not elbows. Clashes whose elements cannot be found, or whose link is not loaded, stay visible with that reason under their title.

Step 2: merge duplicates, set aside what needs no action

The same pair of elements reported by two tests becomes one clash. Then a pre-pass sets aside the clashes that need no fix, each with its reason, into the Ignored tab:

• approved or resolved in the report itself;
• within tolerance;
• a probable duplicate: B is your trade's kind of element in another trade's model, and a twin of it exists in your host model (same category, system, size, parallel and overlapping). Without a twin, B is a real obstacle and the clash stays.

Nothing is deleted. Every Ignored clash can be moved back, and your moves are kept with the report set, so they survive a reload and the next import.

Step 3: find the culprit by cost per clash cleared

What is left is grouped by root cause: the run that, if it moved, would clear the most clashes for the least disruption. ClashFree picks culprits with a weighted set cover. For every run that may move, it divides the run's disruption (its system class's change cost times its size factor, see why the pipe moves, not the duct) by the number of still-uncovered clashes it would clear. The lowest cost per clash goes first; its clashes are covered; repeat.

Both answers match what a coordinator would do, and neither falls out of a give-way list. An earlier version of ClashFree used the plain cost of each run and always picked the small pipes, so in case A it asked for three fixes where one would do. Dividing by the clashes cleared fixed that. Runs that may not move (gravity drainage, hands-off classes, linked and other trades' runs) are never selected as culprits; ties are broken by size and a stable key, never by the order of the report.

Step 4: rank the groups, sort them by who decides

Groups get a priority and a G-id, and the first group is the one to fix first. Then the list is split the way coordination actually works:

• To fix: the culprit is a run your trade may move. These go to the AI.
• Coordination: nothing ClashFree may move; another trade or a person decides.
• Ignored: the clashes set aside in step 2, with their reasons.
• Cleared: clashes that no longer clash in the model.

An optional AI grouping review can read the rule-based groups and propose edits to them before you start; you accept or reject each edit.

Fix the run, not the segment

A group is a run with several clashes on it, so the fix is judged against the whole run. The context the AI receives covers both runs through their fittings, every other clash on them, and where B runs beside A. After a fix is verified, those other clashes come back as cleared or unchanged. An unchanged one is a warning, not a failure, and the proposal says why in one sentence, for example "the other element is the culprit there".

When one move is not enough: area fixes

Sometimes the culprit cannot clear its neighbours alone: moving a pipe down clears the beam but lands it on a tray two metres along. For that case an area fix lists the other clashes, each with its own move, or none where this move must clear it too. All of them are applied and verified together, and kept or rolled back together. You review one proposal, not four that only work as a set.

Re-imports: what is new and what is gone

Coordination is a weekly cycle: models are updated, the clash tests are run again, a new report arrives. ClashFree treats a re-import as the next version of the same report set, not as a fresh start. Report details shows what is new since the last import and what is gone, clashes are matched to their elements again, and the moves you made travel with them: a clash you moved to Ignored or Coordination stays there.

Because groups are rebuilt from the current model, a re-import can regroup clashes when the model changed underneath them: a run that another trade moved may no longer be the cheapest culprit, and its group id may change. That is deliberate. The list should describe the model you have now, not the one you had last week.

Cleared, without asking

Fixes have side effects, mostly good ones. A drag on one pipe often clears clashes in another group, and another trade's work clears yours. After every import, when the pane opens and after each Keep or Reject, ClashFree re-tests the To fix clashes in Revit in the background: geometry only, no AI, and clashes whose elements have not changed since the last check are skipped. Whatever no longer clashes moves to Cleared, and is left out of every other count.

Opening a clash re-tests it first, too. If a fix kept elsewhere already cleared it, the page says so and offers Next; nothing is sent to the AI. Every Cleared row has Move back, for the rare case where you disagree.

Next: what happens after the groups are sent, in AI-native clash coordination, or import your own report in the free beta.