Data Center Lab · BIM and Navisworks · Drawing Note

Thirteen Hard Clashes Were Real; the Zero-Result Test Is Not Clearance

Thirteen hard clashes were genuine, and the third test's zero result proves only that the current proxy envelopes do not intersect, not that maintenance clearance has been approved.

3D model rendering of a long modular data center building with service doors along one facade
Model-based rendering of the modular building.

The register took thirteen raw results as its only input and issued thirteen identifiers. It did not delete, merge, downgrade or close any of them. All thirteen sit at the same status, open against assumed geometry. The zero that people quote is not in this register at all. It belongs to a third test that returned no issue row, and the coordination note that publishes it prints the warning in the same paragraph.

Hard contact is not a clearance rule

Three hard-clash tests ran against the federated coordination model and returned ten, three and zero results [MODELED]. The ten and the three became the thirteen issue records, each carrying its own identifier, both object identities and a clash centre. The selections were 408 objects against 264, then 170 against 264, then 98 against 264 [MODELED]. The third set is a closed list drawn from the frozen mechanical manifest: 48 maintenance envelopes, 42 pull paths and 8 no-occupy zones.

An earlier attempt at the same test ran on an empty selection. The coordination lead filed that run under a named failure identifier and refused it instead of deleting it. The archive now holds two zeros that can be told apart. Every test ran hard intersection at zero millimetres, and the note records that no unconfirmed clearance tolerance was set. At that setting the engine answers whether two solids occupy the same space. Clearance is a distance requirement nobody asked the engine to evaluate. The third test returned zero because nothing overlapped, not because anything was compared against a clearance rule.

Redraw those 98 envelopes at a confirmed clearance distance instead of at proxy dimensions and the zero is the first figure to move, upwards. That would withdraw the only result in the run that currently looks clean. The three federated models the tests ran on are an electrical revision, a structural coordination proxy and a dimension-driven liquid-cooling revision. The coordination note grades the whole run a partial pass on concept geometry.

Keep the Four Related Issues; Do Not Merge by Member

The issue register carries identifiers one through thirteen. Severity is recorded as high but provisional on every row. The severity basis field says why: each is a hard intersection between a coordination object and a structural proxy that may affect equipment clearance, routing or member location, and the proxies still contain assumed and to-be-confirmed dimensions. High is a coordination priority. It is not a risk grade. The register is explicit that high does not oblige any one discipline to give way. It names the two pairings that must resolve each case: electrical with structural for the first set, mechanical with structural for the second.

Eleven structural relation groups cover the thirteen [MODELED]. Two of those groups hold two issues each. The four rows are not two tests colliding with two tests. Each pair is one electrical result and one liquid-cooling result sharing a structural member, with different opposing objects and different clash centres. The register marks those four as related through that shared member and instructs that all four be kept. Merging them because the member is the same would delete a real collision.

The retest field reads not run on all thirteen. The closure field reads not eligible on all thirteen. No geometry has been translated. Any reading of this register as a before-and-after count is describing work that has not been done.

The Machine May Not Decide Who Moves or What Closes

Each record names an owner role and an acceptor role: electrical discipline lead against structural discipline lead for the electrical set, mechanical against structural for the liquid-cooling set. Both name fields are still recorded open. The field that matters most is the one listing what the machine may not decide: which discipline moves, the final equipment footprint, the routing, the structural member size and position, the code clearance, the cost and schedule preference, and the reviewing engineer's acceptance.

Six separate evidence items stand before any closure [TARGET], beginning with a frozen survey coordinate system and ending with an independent read-back confirming that the original clash has gone or has been accepted. No record in the register can yet name the structural member it collides with. The structural crosswalk field is unresolved on all thirteen. The coordinate freeze that would let the first of the six evidence items exist sits outside the coordination discipline altogether.

The electrical side of several rows carries no element identifier from the host export. The register leaves that field empty and uses the display name as the traceable substitute. It does not invent a member.

Limits and open items

Modelled and unfrozen: ten, three and zero results; selections of 408, 170 and 98 against 264; 48 envelopes, 42 pull paths and 8 no-occupy zones; thirteen open records; eleven relation groups, two of them holding two issues each. [MODELED]

The six evidence items are a closure route written by the coordination lead, not an adopted project procedure [TARGET].

Open: owner and acceptor names on every row; the structural crosswalk on every row; survey and shared coordinates; supplier envelopes and final member geometry; a confirmed clearance tolerance for any later run. Nothing here has been sealed. No issue is eligible to close. [HOLD]

Are the Four Related Rows Still Present as Four?

The useful test on the next issue list is not whether the count has fallen. It is whether the four related rows are still present as four. If they have been merged because they share a member, the register has done the one thing this one refused to do.


© 2026 K&K Data Service Inc. All rights reserved. Reproduction or republication is permitted only with clear attribution to K&K Data Service Inc. and a working hyperlink to the canonical URL of this article. Excerpts must preserve the technical context, maturity labels, assumptions, and limitations. No excerpt may imply project approval, field validation, certification, or endorsement that the original article does not state.

Source: K&K Data Service Inc., “Thirteen Hard Clashes Were Real; the Zero-Result Test Is Not Clearance,” https://www.kkdatasvc.com/lab/bim-and-navisworks/thirteen-hard-clashes-were-real-the-zero-result-test-is-not-clearance/.

Challenge This Diagram. If your project record shows a different result, or the same failure domain under another name, we want to see it. Email inquiry@kkdatasvc.com or use the contact page.