Two tools, one model, two numbers
You federate the same NWD and the same IFC, run a clash test in Navisworks Clash Detective and a rule set in Solibri, and get two different counts. The instinct is to ask which tool is right. That is the wrong question. A clash count is not a property of the model. It is the output of a configuration: what geometry was tested, which elements were in scope, and which results were suppressed before they reached the report. Change any of those three layers and the number moves, in either tool, without a single element moving in the model.
This is a diagnostic for reconciling the two counts. It treats the difference as a configuration audit finding first, and a coordination signal second. The residual set that survives matched configuration is the part worth putting in front of the design team.
Layer 1: geometric tolerance
Both tools expose a tolerance, and the semantics are not interchangeable. Autodesk’s Clash Detective help documents an Insulation Thickness rule template intended for use with a Clearance test: the clearance tolerance is set to the required insulation thickness, and items whose clearance value exceeds that thickness are not reported. That is a distance-based clearance concept applied through a rule, not a single global clash tolerance.
Solibri’s published clash detection rule example defines an Allowed Tolerance parameter as a volume in cubic meters, with a default value of 0.01 in that example rule. Intersections whose volume falls below the allowed tolerance are skipped rather than reported. That is a volumetric threshold, and it is a developer example rule, not a statement of the product’s shipped defaults.
The practical consequence: a tolerance expressed as a distance and a tolerance expressed as a volume cannot be compared by reading the two numbers side by side. Do not assume equivalence and do not attempt a conversion. Record the value, the unit, and the parameter it belongs to, then test sensitivity by moving the tolerance in one tool and watching the count. If the count is volatile across a small tolerance change, the two tools were never measuring the same thing.
Layer 2: element selection scope
Before any geometry is tested, each tool decides which pairs of elements are candidates. Navisworks relies on selection and search sets plus the ignore rules described below. Solibri relies on rule-based component filters: the clash detection rule example uses a source filter and a target filter, and the documentation describes rule-based checking that lets teams define which elements are included.
Different scoping produces different candidate pairs before a single intersection is computed. If one tool tests structure against all MEP services and the other tests structure against a filtered mechanical set, the counts will diverge for reasons that have nothing to do with the model. The reconciliation step is to write down the element scope per discipline for each test, in both tools, and confirm the candidate pairs match.
Layer 3: ignore and rule logic
This is where most of the gap lives. Navisworks Clash Detective ships built-in ignore rules that reduce reported results by ignoring certain combinations of clashing items. The documented defaults include:
- Items in Same Layer — clashes between items on the same layer are not reported.
- Items in Same Group/Block/Cell — clashes within a block or cell definition are not reported.
- Items in Same File — clashes within the same appended or externally referenced file are not reported, which lets a test search only for clashes between different files.
- Items with Coincident Snap Points — clashes between items whose snap points coincide are not reported, which matters because Navisworks draws cylinders as faceted triangles and adjacent pipe and fitting geometry can register false intersections.
Beyond the defaults, Navisworks offers rule templates including Insulation Thickness, Same Property Value, Same Selection Sets, Specified Selection Sets, and Specified Properties with the Same Value. Each template removes results from the report. A test with the Same Selection Sets rule active will report fewer clashes than the same test without it, on identical geometry.
Solibri’s rule-based approach lets teams define clearance zones and tolerance-based clash checking, exclude acceptable intersections, and group clashes by system, location, or responsibility. The exclusion of acceptable intersections is the direct analogue of a Navisworks ignore rule, and it is just as capable of removing results from one tool’s count while the other tool still reports them.
There is also a counting-convention difference that is easy to miss. Navisworks documents combining the Items in Same Composite Object rule with the Items in Previously Found Pair of Composite Objects rule so that a multi-layer cavity wall counts as a single clash rather than four. Consider a hypothetical, clearly labeled as such: if one tool counts per intersecting pair and the other groups a multi-layer wall as one composite object, the same physical conflict can appear as four results in one report and one in the other. That is a counting convention, not a modeling difference, and it will dominate the raw count comparison if left unexamined.
The reconciliation workflow
Before comparing counts, document four things for each test in each tool:
- Tolerance value and unit — the number, the unit, and the parameter it belongs to. Do not convert between distance and volume semantics.
- Element scope per discipline — the source and target sets, written out, not assumed.
- Active ignore rules and rule sets — every default and template that is switched on, in both tools.
- Grouping and counting convention — per intersecting pair or per composite object, and whether results are grouped into issues.
Re-run both tools with matched settings. Then diff the residual sets. The residual — the clashes that survive matched tolerance, matched scope, and matched ignore logic — is the real coordination signal. Everything removed by the normalization step was a configuration difference, and it belongs in the audit trail, not the coordination meeting.
Publish a clash test definition sheet
The recommendation is to attach a one-page definition sheet to every reported clash count. It carries the four items above, plus the tool and version, the model version, and the date. The cost is minutes per test. The return is a number that is reproducible across coordination cycles and reviewable by anyone who was not in the room when the test was configured. Without it, a count is an anecdote with a decimal point.
Treat cross-tool count parity as a configuration audit, not a quality KPI. Parity is evidence that two tools were told to count the same thing. It is not evidence that the model is good, and a large gap is not evidence that the model is bad. The category error is expensive: teams spend coordination meetings arguing about a number that was never comparable, while the residual set — the actual conflicts — goes unread.
Checklist for the next coordination cycle
- Record tolerance value, unit, and parameter name for every test in both tools.
- Write out source and target element scope per discipline; confirm candidate pairs match.
- List every active ignore rule and rule template in Navisworks and every exclusion in the Solibri rule set.
- State the counting convention: per pair or per composite object.
- Re-run with matched settings and diff the residual sets.
- Attach the definition sheet to the count before it leaves the coordination folder.
FAQ
Can I convert a Navisworks clearance tolerance to a Solibri volume tolerance?
No. The documented semantics differ: Navisworks clearance and insulation thickness rules operate on distance, while Solibri’s example rule defines allowed tolerance as a volume in cubic meters. Treat them as separate parameters and test sensitivity in each tool rather than converting.
Is the 0.01 figure a Solibri default?
No. It is the default value in Solibri’s published developer example rule, not a statement of the shipped defaults in production rule sets. Do not cite it as a product default.
Which tool produces the correct count?
Neither count is correct or incorrect in isolation. Each is the output of a configuration. The meaningful comparison is the residual set after tolerance, scope, and ignore logic are matched.
Why does a multi-layer wall show four clashes in one tool and one in the other?
Likely a counting convention difference. Navisworks documents combining the Items in Same Composite Object and Items in Previously Found Pair of Composite Objects rules to report a single clash for a multi-layer wall rather than four. Check whether the other tool groups composite objects the same way.