Clash detection that doesn't drown the team

1. Lede — The 50,000-Clash Problem

It always happens on a Thursday afternoon, somewhere around week four of Design Development.

The BIM coordinator federates the models for the first time — architecture, structure, MEP mechanical, MEP electrical, MEP plumbing — opens Navisworks Clash Detective, sets Selection A to "Entire File," Selection B to "Entire File," accepts the default tolerance of zero, and clicks Run All.

Navisworks runs for six minutes. The progress bar crawls. Then the results panel populates: 52,847 clashes. New.

Nobody on the team has seen a number that large in a coordination context before. The project manager asks whether this is normal. The structural engineer asks why his model is even in the federation yet — he thought it was still at LOD 200. The MEP coordinator pastes the number into the group chat with three question-mark emojis. The architect, who has a site visit in twenty minutes, says she'll look at it Monday.

By Friday morning, the backlog is already labeled a crisis. By Monday, someone has suggested that the team review every single clash. A spreadsheet is created. Columns are added: Trade A, Trade B, Description, Owner, Status, Due Date. Someone is assigned to fill it in. That person opens the spreadsheet on Tuesday, looks at row 52,848, and quietly closes it again.

This is the team-paralysis scenario that experienced BIM managers describe as the single most common failure mode in large-project coordination. It is not caused by bad models, bad software, or bad people. It is caused by a workflow that uses detection as if it were the same thing as triage — as if surfacing a conflict and assigning it a resolution path were one step rather than two entirely different disciplines.

The number 50,000 is not an exaggeration. A 400,000-square-foot mixed-use project running five discipline models through an unfiltered all-versus-all hard-clash test at zero tolerance will routinely produce results in that range. The clashes are real in the narrow sense that Navisworks is correctly reporting geometric overlaps — but the overwhelming majority represent noise: modelling artifacts from different authoring platforms, coordinate tolerances between linked files, ceiling grid geometry intersecting HVAC hangers by two millimetres, insulation allowances that were never removed from MEP elements before export, duplicate elements from a copy-monitored structural link that was not cleaned up.

The 200 clashes that do matter — the primary duct running through a wide-flange beam web, the fire suppression main that conflicts with a post-tensioning tendon, the transformer pad that has no maintenance clearance — are buried inside that 52,847 and effectively invisible until someone with deep domain knowledge manually reviews the full set. Which nobody has time to do.

This article is about preventing that scenario before it starts. The solution is not a better clash-detection algorithm — Navisworks already has those. The solution is a tiered severity framework that is designed into the Clash Detective configuration from day one, so that when the first run completes, the output is already organized into a small set of critical issues, a medium set of design questions, and a large set of intentionally suppressed noise. The team sees 200 clashes on day one. They are all real. They can all be assigned, tracked, and closed.

The following sections cover how Navisworks surfaces clashes mechanically, how to build a three-tier severity model on top of that, how to implement it through search sets, XML rules files, and BCF export, and what the most dangerous anti-patterns look like in practice.

2. What Clash Detection Actually Surfaces

2.1 The Three Navisworks Algorithms

Autodesk Navisworks Manage's Clash Detective supports four clash test types, which are best understood as two detection algorithms with two variants each.

Hard is the standard intersection test. Navisworks checks whether any triangle in the mesh defining Object A intersects any triangle in the mesh defining Object B. If any pair of triangles overlaps, a clash is reported. The geometry test is run against the actual mesh triangulation of each element — the precision is therefore a function of how finely meshed the source geometry is when exported from the authoring tool. The tolerance parameter in Hard mode works as a positive offset: a tolerance of 5 mm means that overlaps smaller than 5 mm are filtered out and not reported. The canonical use case is physical intersection — a steel beam penetrating a concrete slab, a conduit passing through a structural column.

Hard (Conservative) runs the same triangular intersection logic but additionally reports all pairs of bounding boxes that might overlap, even when the actual triangulated meshes do not intersect. This catches edge cases that the standard Hard algorithm misses — for example, two elements that share a parallel face and overlap by a sub-triangulation distance — but it also produces substantially more false positives, because many elements whose bounding boxes overlap do not have intersecting meshes. The Autodesk community documentation describes this mode accurately: "Hard (Conservative) reports all pairs of items which might clash, which may give false positives in the results, but it is a more thorough and safer clash detection method." Most mature coordination workflows use standard Hard for primary detection and reserve Hard (Conservative) for specific scenarios — hanger clustering checks, tight MEP racks — where the extra sensitivity is worth the additional review burden.

Clearance does not test for intersection at all. It tests for proximity: whether any part of Object A comes within a user-defined distance (the tolerance parameter) of any part of Object B. A clearance clash means the elements are closer than the defined minimum, not that they overlap. The tolerance in Clearance mode is therefore a minimum acceptable gap, not an overlap filter. Setting 600 mm clearance around a piece of HVAC equipment will report a clash whenever anything comes within 600 mm of that equipment envelope — walls, structure, adjacent services. Clearance detection is the primary tool for maintenance access validation, insulation allowance checking, and regulatory setback enforcement.

Duplicate is a degenerate case of Hard detection: it reports pairs of objects that occupy the same space at the same location to within a very small threshold. The practical use case is finding copy-monitor errors, duplicated MEP fixtures between models from different consultants, or structural elements that appear in both the structural model and the architectural model at identical coordinates. Duplicate checks should always run as a separate test before coordination begins — they are a model quality gate, not a coordination issue.

2.2 Tolerance Handling and Its Implications

Tolerance is the most consequential parameter in any Clash Detective configuration, and it is the one most often left at the default of zero.

Zero tolerance in Hard mode means that any geometric overlap, no matter how small, triggers a clash report. In practice, every multi-discipline federated model contains sub-millimetre overlaps that are not real conflicts: rounding differences between authoring tools, coordinate system precision limits, face-to-face surface contacts at shared boundaries (floor/ceiling interfaces, wall/slab connections), and insulation geometry that was never separated from the MEP element geometry in the authoring model.

The BIMForum LOD Specification (2023 edition, published February 2024) is instructive here. At LOD 300 — the minimum level of development typically required for coordination — elements are modelled to represent actual shape, size, and location, but the specification explicitly notes that modelling precision varies by element type. Structural concrete has different modelling precision than MEP ductwork hangers. Running a zero-tolerance hard clash between elements at different LOD levels produces a result set where the noise floor is undefined because the modelling precision of each element is unknown.

A practical approach:

• 5 mm tolerance for Hard clashes: filters sub-triangulation artefacts and rounding differences between authoring tools.
• 25 mm tolerance for cross-discipline Hard clashes during Design Development: acknowledges that models at that phase are not yet fabrication-accurate.
• 50–150 mm tolerance for MEP-to-structure Clearance (the minimum maintenance access distance depends on service type and jurisdiction).
• 600 mm tolerance for Clearance checks around MEP equipment: covers the minimum NEC/NFPA 70E electrical clearance for equipment rated below 600V; check local codes for variations.

These are starting values. Every project needs a clash matrix table established in the BIM Execution Plan before the first federation run — one that documents, for every discipline pair and every phase, what tolerance applies and why.

2.3 False Positives and Modelling Artefacts

A false positive in clash detection is not a software bug. It is a real geometric condition that the algorithm is reporting correctly — but which the team has determined does not require resolution. The practical categories:

Floor/ceiling boundary intersections. The architectural ceiling element and the structural floor element frequently share the same face, or the ceiling element extends fractionally above the underside of the structural slab. This produces thousands of Hard clashes in any unfiltered run. The correct fix is a search set rule that excludes architectural ceiling categories from structural comparisons.

Insulation geometry on MEP elements. Many MEP families exported from Revit include the insulation as part of the solid geometry. A 300mm duct with 50mm insulation exports as a 400mm bounding solid. Any clearance check run against the duct without accounting for insulation geometry will produce larger clash volumes than a check against the bare duct, and many of those "clearances" are not real installation constraints. The correct fix is either stripping insulation geometry before export or building the clearance tolerance to account for it.

Room separation lines. Revit room separation lines export to NWC as hairline geometry. They clash with almost everything they cross. Every clash test should exclude room separation lines and space boundaries from both Selection A and Selection B.

Rebar in concrete. At LOD 300, rebar is typically modelled as geometric solid cylinders inside concrete elements. The rebar clashes with the concrete it is embedded in — which is correct geometry but not a coordination conflict. Rebar coordination is a separate workflow (typically run within the structural model) and should be excluded from cross-discipline tests.

Façade system complexity. Curtain wall families often contain dozens of sub-components — mullions, panels, gaskets, anchors — each modelled as separate solids. An all-versus-all test with Composite Object Clashing enabled will test every sub-component against every MEP element near the façade, producing hundreds of false positives per bay.

2.4 What Actually Gets Surfaced

When the configuration is correct — targeted search sets, appropriate tolerances, Composite Object Clashing disabled, categories properly excluded — the remaining Hard clashes represent three distinct populations:

1. Genuine geometric conflicts: elements that physically cannot occupy the same space and must be redesigned.
2. Constructibility constraints: elements that are geometrically compatible but cannot both be installed in sequence given the construction methodology, hanger spacing, or access limitations.
3. Design intent ambiguities: clashes that exist because two disciplines made independent routing decisions that happen to conflict, and both decisions are locally correct — the conflict only becomes visible in the federation.

Category 1 and a portion of category 3 are Tier 1 issues. Category 2 and the rest of category 3 are Tier 2. Everything else — after false positives are eliminated through proper configuration — should not reach the team at all.

3. The Three-Tier Severity Model

The fundamental insight behind tiered severity is that different clash types require different response speeds, involve different decision-makers, and have different consequences if left unresolved. Treating all clashes as equal priority is the fastest path to the team-paralysis scenario described in the lede.

The three-tier model presented here aligns with the informal language used by experienced BIM coordinators ("this is a show-stopper," "this is a design question," "this is noise") and formalises it into a system that can be encoded in Navisworks configuration and tracked in BCF.

3.1 Tier 1 — Hard Conflicts (Immediate Resolution Required)

Definition: A physical intersection between a primary structural element and a primary MEP distribution element where no spatial resolution is possible without redesign of at least one element. The conflict, if unresolved, will result in either a structural compromise or an MEP system that cannot be installed.

Characteristics:

• Involves primary load-bearing structure (beams, columns, shear walls, transfer plates) or major building envelope elements.
• Involves primary MEP distribution (main duct runs ≥ 300mm, piping ≥ 150mm, cable trays ≥ 300mm, branch circuit distribution panels).
• Requires a design decision from both disciplines' engineers of record, not a field accommodation.
• Cannot be resolved by offsets of less than 150mm without affecting system performance or structural adequacy.

Typical examples:

• Wide-flange steel beam web penetrated by a 500mm × 300mm return air duct. The beam cannot be notched at mid-span; the duct cannot route around the beam without exceeding the design-permitted duct velocity. Both engineers of record must agree on a resolution — typically either a structural opening with reinforcement or a duct reroute approved by the mechanical engineer.
• Post-tensioning tendon in a concrete slab conflicting with a 200mm fire suppression main. PT tendons cannot be rerouted. The sprinkler layout must change.
• Structural column inside a transformer pad footprint. The transformer cannot be relocated; the structural bay must be re-evaluated.

Response protocol: Tier 1 clashes should be reviewed within 24 hours of detection, assigned to named engineers of record (not BIM coordinators), and tracked as formal RFI-equivalent issues in the issue management system. They should never be deferred to a subsequent coordination cycle.

Navisworks configuration marker: Hard clash test, tolerance 0–5 mm, Selection A limited to primary structural categories, Selection B limited to primary MEP distribution categories. In BCF, these clashes receive priority: "Critical" and topic_type: "Clash".

Typical volume in a well-configured run: 5–30 per model update on a complex project. If you are seeing 500 Tier 1 clashes, the search set definitions need tightening — you are catching elements that are not primary structure or primary MEP mains.

3.2 Tier 2 — Soft Conflicts (Design Resolution Required Before CD)

Definition: A proximity conflict, clearance violation, or geometric conflict that does not involve primary structural elements or primary MEP mains, but which represents a real coordination issue that must be resolved before construction documents are issued.

Characteristics:

• Clearance violations (elements within minimum maintenance or installation envelope but not intersecting).
• Conflicts between secondary structure and secondary MEP distribution.
• MEP coordination conflicts between disciplines (HVAC vs. plumbing, electrical vs. mechanical) that require routing adjustments.
• Interface conflicts at penetrations, sleeves, and block-outs.
• Equipment access envelope violations.

Typical examples:

• 250mm chilled water pipe running 120mm below an I-beam bottom flange in a ceiling plenum where 200mm maintenance clearance is required. The pipe does not intersect the beam, but it cannot be insulated without violating the required maintenance envelope. This is a Clearance clash, not a Hard clash.
• Two MEP disciplines routing in the same plenum space with inadequate lateral separation for hanger installation. Neither system clashes with structure, but they clash with each other.
• Ceiling grid element clipping the bottom of an FCU hose connection. The ceiling grid and the FCU hose are not structural or primary distribution — this is a Tier 2 coordination issue between architecture and MEP.
• Fire damper position conflicting with concrete block-out location. The sleeve can be relocated, but it requires a structural penetration revision — a coordination task that needs to happen before CD.

Response protocol: Tier 2 clashes should be assigned to BIM coordinators and discipline leads (not engineers of record), reviewed in the weekly coordination meeting, and resolved within one or two coordination cycles. They should not be escalated to engineers of record unless the resolution requires a structural or systems design change.

Navisworks configuration marker: Clearance clash tests, and Hard clash tests between secondary categories. Tolerance 25–100 mm depending on the specific system pair. In BCF, these clashes receive priority: "Normal" and topic_type: "Clash".

Typical volume: 100–500 per model update on a complex project. If after triage you have more than 500 Tier 2 clashes that are genuine coordination issues (not false positives), the coordination workflow has slipped — models are being federated before discipline-level coordination within each model has occurred.

3.3 Tier 3 — Noise (Suppressed, Not Reviewed)

Definition: Geometric conditions that trigger a clash report but do not represent real coordination issues — modelling artefacts, face-to-face contacts at boundaries, sub-millimetre overlaps, or conditions that are explicitly acceptable under the project coordination protocol.

Characteristics:

• Systematic repeating pattern (every floor, every bay).
• Involves element categories that are explicitly excluded from coordination scope (room boundaries, annotation, 2D elements that were not hidden before export).
• Sub-threshold overlaps that fall below the established modelling tolerance.
• Known acceptable conditions (concrete cover over embedded reinforcement, slab/ceiling face contacts).

Response protocol: Tier 3 clashes should not be reviewed at all. They should be suppressed at the Navisworks configuration level — either by excluding the relevant categories from the search sets or by marking them as Approved with a bulk action immediately after the run, before the report is distributed. If you find yourself reviewing Tier 3 clashes in a coordination meeting, your configuration has failed.

The discipline here is hard to maintain under project pressure. The temptation when the clash count is high is to review "just a few more" to make sure nothing important is buried. This is the failure mode. A properly configured search set means that Tier 3 never reaches the team. Trust the configuration.

3.4 Discipline-Specific Tier Rules

The tier assignment of a specific clash type is not universal — it depends on the disciplines involved and the project phase. The following tables provide practical starting points.

4. Implementing Tiering in Navisworks

The three-tier model is only useful if it is systematically implemented in Navisworks configuration — not applied post-hoc by a coordinator manually reviewing results. This section covers the complete implementation stack: search sets, clash test XML, automation scripts, BCF export per tier, and issue tracker integration.

4.1 Search Set Architecture

The foundation of tiered clash detection is a disciplined search set hierarchy. Search sets (not selection sets) are the correct instrument: they are property-based, exportable as XML, importable into any project, and they update automatically when the model is re-appended.

A robust search set structure for a typical commercial project:

STR-Primary-Steel        → Category: Structural Framing, Type: W-Shape, HSS
STR-Primary-Concrete     → Category: Structural Column, Structural Floor
STR-PT-Elements          → Custom parameter: ContainsPT = Yes (or manual set)
STR-Secondary            → Category: Structural Framing, excluding primary
 
MEP-HVAC-Mains           → Category: Ducts, Width >= 300mm (via Find Items)
MEP-HVAC-Branches        → Category: Ducts, Width < 300mm
MEP-HVAC-Equipment       → Category: Mechanical Equipment
MEP-Pipe-Mains           → Category: Pipe, Diameter >= 150mm
MEP-Pipe-Branches        → Category: Pipe, Diameter < 150mm
MEP-Electrical-Trays     → Category: Cable Tray, Width >= 300mm
MEP-Electrical-Conduit   → Category: Conduits
 
ARCH-Ceilings            → Category: Ceilings
ARCH-Floors              → Category: Floors
ARCH-Walls               → Category: Walls, Structural = No
 
EXCLUDE-RoomBoundaries   → Category: Room Separation Lines, Spaces
EXCLUDE-Annotation       → Category: Detail Items, Generic Annotations

4.2 Clash Test XML Configuration

Navisworks stores clash test configurations in XML format. The file can be exported from an existing project (Home → Clash Detective → Export) and imported into new projects. This is the mechanism for standardising a tiered configuration across the office.

The following is a representative clash test XML for a three-tier configuration. Note that Navisworks XML uses its own proprietary schema (located at C:\Program Files\Autodesk\Navisworks Manage [year]\schemas); the structure below reflects the actual element hierarchy.

<?xml version="1.0" encoding="utf-8"?>
<batchtest version="3" units="m">
 
  {/* ============================================================
    TIER 1 TESTS — Hard conflicts, primary structure vs. MEP mains
    Tolerance: 0.005m (5mm)
    Review SLA: 24 hours
  ============================================================ */}
 
  <clashtests>
 
    <clashtest name="T1_STR-Steel_vs_MEP-HVAC-Mains"
               status="new"
               test_type="hard"
               merge="false"
               tolerance="0.005"
               check_new="true">
      <left>
        <searchset name="STR-Primary-Steel" />
      </left>
      <right>
        <searchset name="MEP-HVAC-Mains" />
      </right>
      <rules>
        <rule name="Items with same layer" enabled="false" />
        <rule name="Items in same group/component" enabled="true" />
        <rule name="Items with coincident snap points" enabled="true" />
      </rules>
    </clashtest>
 
    <clashtest name="T1_STR-Steel_vs_MEP-Pipe-Mains"
               status="new"
               test_type="hard"
               merge="false"
               tolerance="0.005"
               check_new="true">
      <left>
        <searchset name="STR-Primary-Steel" />
      </left>
      <right>
        <searchset name="MEP-Pipe-Mains" />
      </right>
      <rules>
        <rule name="Items in same group/component" enabled="true" />
        <rule name="Items with coincident snap points" enabled="true" />
      </rules>
    </clashtest>
 
    <clashtest name="T1_STR-Concrete_vs_MEP-Mains"
               status="new"
               test_type="hard"
               merge="false"
               tolerance="0.005"
               check_new="true">
      <left>
        <searchset name="STR-Primary-Concrete" />
      </left>
      <right>
        <searchset name="MEP-HVAC-Mains" />
        <searchset name="MEP-Pipe-Mains" />
        <searchset name="MEP-Electrical-Trays" />
      </right>
      <rules>
        <rule name="Items in same group/component" enabled="true" />
      </rules>
    </clashtest>
 
  {/* ============================================================
    TIER 2 TESTS — Secondary conflicts, clearance checks
    Tolerance: 0.010–0.100m depending on test
    Review SLA: Weekly coordination meeting
  ============================================================ */}
 
    <clashtest name="T2_HVAC_vs_Pipe-CrossDiscipline"
               status="new"
               test_type="hard"
               merge="false"
               tolerance="0.010"
               check_new="true">
      <left>
        <searchset name="MEP-HVAC-Mains" />
        <searchset name="MEP-HVAC-Branches" />
      </left>
      <right>
        <searchset name="MEP-Pipe-Mains" />
        <searchset name="MEP-Pipe-Branches" />
      </right>
      <rules>
        <rule name="Items in same group/component" enabled="true" />
      </rules>
    </clashtest>
 
    <clashtest name="T2_MEP-All_vs_ARCH-Ceilings_Clearance"
               status="new"
               test_type="clearance"
               merge="false"
               tolerance="0.050"
               check_new="true">
      <left>
        <searchset name="MEP-HVAC-Mains" />
        <searchset name="MEP-Pipe-Mains" />
        <searchset name="MEP-Electrical-Trays" />
      </left>
      <right>
        <searchset name="ARCH-Ceilings" />
      </right>
      <rules>
        <rule name="Items in same group/component" enabled="true" />
      </rules>
    </clashtest>
 
    <clashtest name="T2_MEP-Equipment_MaintenanceClearance"
               status="new"
               test_type="clearance"
               merge="false"
               tolerance="0.600"
               check_new="true">
      <left>
        <searchset name="MEP-HVAC-Equipment" />
      </left>
      <right>
        <searchset name="STR-Primary-Steel" />
        <searchset name="STR-Primary-Concrete" />
        <searchset name="ARCH-Walls" />
      </right>
      <rules>
        <rule name="Items in same group/component" enabled="true" />
      </rules>
    </clashtest>
 
    <clashtest name="T2_STR-Secondary_vs_MEP-Branches"
               status="new"
               test_type="hard"
               merge="false"
               tolerance="0.010"
               check_new="true">
      <left>
        <searchset name="STR-Secondary" />
      </left>
      <right>
        <searchset name="MEP-HVAC-Branches" />
        <searchset name="MEP-Pipe-Branches" />
        <searchset name="MEP-Electrical-Conduit" />
      </right>
      <rules>
        <rule name="Items in same group/component" enabled="true" />
      </rules>
    </clashtest>
 
    {/* DUPLICATE CHECK — Model quality gate, run before coordination */}
    <clashtest name="QA_Duplicate-MEP-Check"
               status="new"
               test_type="duplicates"
               merge="false"
               tolerance="0.001"
               check_new="true">
      <left>
        <searchset name="MEP-HVAC-Mains" />
        <searchset name="MEP-Pipe-Mains" />
      </left>
      <right>
        <searchset name="MEP-HVAC-Mains" />
        <searchset name="MEP-Pipe-Mains" />
      </right>
    </clashtest>
 
  </clashtests>
 
</batchtest>

4.3 The Clash Rules Tab

The Rules tab in Clash Detective provides ignore rules that suppress specific clash conditions without modifying the search sets. These operate as post-detection filters. Key built-in rules:

• Items with same layer: suppresses clashes between objects on the same CAD layer. Useful for DWG-based models where discipline separation is by layer rather than category.
• Items in same group/component: suppresses clashes between sub-components of the same composite family. This is the Revit family internal-clash suppressor — should be enabled in all tests to prevent Revit families from clashing with their own nested content.
• Items with coincident snap points: suppresses clashes at shared endpoints — useful for structural frame joints where two members meet.
• Specified selection sets: suppresses clashes involving any element from a nominated search set. Use this to suppress known acceptable conditions (rebar in concrete, slab/ceiling contacts) without modifying the primary search sets.

A "Specified Selection Sets" rule pointing to your EXCLUDE-RoomBoundaries and EXCLUDE-Annotation sets will eliminate those false positives entirely at the rules level rather than requiring search set maintenance.

4.4 Automation: Generating the XML from a Matrix

In practice, coordination configurations change as the project progresses — new discipline pairs are added, tolerances are refined, phases advance from SD to DD to CD. Maintaining the XML by hand becomes error-prone on large projects. The following Python script generates the clash test XML from a project matrix defined in a simple dictionary, which can be driven from a spreadsheet.

"""
generate_clash_xml.py
Generates a Navisworks clash test XML from a project coordination matrix.
Requires: lxml (pip install lxml)
 
Usage: python generate_clash_xml.py > output_clash_tests.xml
Then import into Navisworks: Clash Detective → Import Tests
"""
 
from lxml import etree
from dataclasses import dataclass, field
from typing import List, Literal
 
 
@dataclass
class ClashTest:
    name: str
    tier: Literal[1, 2, 3]
    test_type: Literal["hard", "hard_conservative", "clearance", "duplicates"]
    tolerance_m: float
    selection_a: List[str]
    selection_b: List[str]
    rules_same_group: bool = True
    rules_coincident_snap: bool = True
    description: str = ""
 
 
# Project coordination matrix — edit per project
CLASH_MATRIX: List[ClashTest] = [
    ClashTest(
        name="T1_STR-Steel_vs_HVAC-Mains",
        tier=1,
        test_type="hard",
        tolerance_m=0.005,
        selection_a=["STR-Primary-Steel"],
        selection_b=["MEP-HVAC-Mains"],
        description="Tier 1: Primary steel vs. main HVAC distribution >= 300mm",
    ),
    ClashTest(
        name="T1_STR-Steel_vs_Pipe-Mains",
        tier=1,
        test_type="hard",
        tolerance_m=0.005,
        selection_a=["STR-Primary-Steel"],
        selection_b=["MEP-Pipe-Mains"],
        description="Tier 1: Primary steel vs. primary piping >= 150mm",
    ),
    ClashTest(
        name="T1_STR-Concrete_vs_MEP-Mains",
        tier=1,
        test_type="hard",
        tolerance_m=0.005,
        selection_a=["STR-Primary-Concrete"],
        selection_b=["MEP-HVAC-Mains", "MEP-Pipe-Mains", "MEP-Electrical-Trays"],
        description="Tier 1: Concrete structure vs. all primary MEP distribution",
    ),
    ClashTest(
        name="T2_HVAC-vs-Pipe-CrossDiscipline",
        tier=2,
        test_type="hard",
        tolerance_m=0.010,
        selection_a=["MEP-HVAC-Mains", "MEP-HVAC-Branches"],
        selection_b=["MEP-Pipe-Mains", "MEP-Pipe-Branches"],
        description="Tier 2: HVAC vs. piping cross-discipline coordination",
    ),
    ClashTest(
        name="T2_MEP-Clearance-Ceilings",
        tier=2,
        test_type="clearance",
        tolerance_m=0.050,
        selection_a=["MEP-HVAC-Mains", "MEP-Pipe-Mains", "MEP-Electrical-Trays"],
        selection_b=["ARCH-Ceilings"],
        description="Tier 2: MEP mains vs. architectural ceilings - 50mm clearance",
    ),
    ClashTest(
        name="T2_Equipment-Maintenance-Clearance",
        tier=2,
        test_type="clearance",
        tolerance_m=0.600,
        selection_a=["MEP-HVAC-Equipment"],
        selection_b=["STR-Primary-Steel", "STR-Primary-Concrete", "ARCH-Walls"],
        description="Tier 2: MEP equipment - 600mm maintenance envelope",
    ),
    ClashTest(
        name="QA_Duplicate-MEP",
        tier=3,
        test_type="duplicates",
        tolerance_m=0.001,
        selection_a=["MEP-HVAC-Mains", "MEP-Pipe-Mains"],
        selection_b=["MEP-HVAC-Mains", "MEP-Pipe-Mains"],
        description="Quality gate: duplicate element detection in MEP",
    ),
]
 
 
def build_xml(tests: List[ClashTest]) -> bytes:
    root = etree.Element("batchtest", version="3", units="m")
    clashtests_el = etree.SubElement(root, "clashtests")
 
    for t in tests:
        ct = etree.SubElement(
            clashtests_el,
            "clashtest",
            name=t.name,
            status="new",
            test_type=t.test_type,
            merge="false",
            tolerance=str(t.tolerance_m),
            check_new="true",
        )
 
        if t.description:
            desc = etree.SubElement(ct, "description")
            desc.text = t.description
 
        # Selection A
        left = etree.SubElement(ct, "left")
        for ss in t.selection_a:
            etree.SubElement(left, "searchset", name=ss)
 
        # Selection B
        right = etree.SubElement(ct, "right")
        for ss in t.selection_b:
            etree.SubElement(right, "searchset", name=ss)
 
        # Rules
        rules = etree.SubElement(ct, "rules")
        etree.SubElement(
            rules,
            "rule",
            name="Items in same group/component",
            enabled="true" if t.rules_same_group else "false",
        )
        etree.SubElement(
            rules,
            "rule",
            name="Items with coincident snap points",
            enabled="true" if t.rules_coincident_snap else "false",
        )
 
    return etree.tostring(root, pretty_print=True, xml_declaration=True, encoding="utf-8")
 
 
if __name__ == "__main__":
    xml_bytes = build_xml(CLASH_MATRIX)
    print(xml_bytes.decode("utf-8"))

Run this script and import the output XML into Navisworks. Every team member working on the project federation gets the same test configuration. When the matrix changes, regenerate the XML and distribute it.

4.5 BCF Export per Tier

Once clash tests have run and results have been filtered, the next step is exporting Tier 1 and Tier 2 clashes to BCF for issue tracking. Tier 3 clashes should never be exported — they stay inside Navisworks, marked Approved in bulk.

BCF (BIM Collaboration Format) is an open standard maintained by buildingSMART International. The current version is BCF 3.0, released in 2021. BCF 3.0 introduced a JSON-based RESTful API alongside the existing XML file format, enabling cloud-hosted issue management through platforms like BIMcollab NEXUS, Trimble Connect, and BIM Track.

A BCF topic JSON payload for a Tier 1 clash:

{
  "guid": "a59a8a2c-1b4f-4c3e-8d7f-2e1a5b6c9d0f",
  "topic_type": "Clash",
  "topic_status": "Open",
  "priority": "Critical",
  "title": "T1 — W24×76 web penetrated by 500mm×300mm supply duct at grid B/4, Level 5",
  "description": "Primary W24×76 beam web at B/4 level 5 (elevation +18.450) is penetrated by 500mm×300mm supply air duct. Overlap: 140mm vertical. Requires structural opening with reinforcement per SE review, or duct reroute approved by ME. Tier 1 — resolution required within 24 hours.",
  "labels": ["Tier1", "Structure", "HVAC", "Level-5"],
  "creation_date": "2026-06-03T08:00:00Z",
  "creation_author": "[email protected]",
  "assigned_to": "[email protected]",
  "due_date": "2026-06-04T17:00:00Z",
  "stage": "Design-Development",
  "reference_links": [],
  "viewpoints": [
    {
      "guid": "7f4a3b2c-9d1e-4a5f-8c6b-1e2d3f4a5b6c",
      "snapshot": {
        "snapshot_type": "png",
        "snapshot_data": "<base64-encoded-PNG>"
      },
      "perspective_camera": {
        "camera_view_point": { "x": 12.450, "y": 8.200, "z": 20.100 },
        "camera_direction": { "x": 0.707, "y": 0.000, "z": -0.707 },
        "camera_up_vector": { "x": 0.000, "y": 1.000, "z": 0.000 },
        "field_of_view": 60.0
      },
      "components": {
        "selection": [
          { "ifc_guid": "2LcWkl5H98HuGSD9l5ydzX", "originating_system": "Revit" },
          { "ifc_guid": "0nwBFX_Q5F4QxL7uSCGVEb", "originating_system": "Revit" }
        ],
        "visibility": {
          "default_visibility": false,
          "exceptions": [
            { "ifc_guid": "2LcWkl5H98HuGSD9l5ydzX" },
            { "ifc_guid": "0nwBFX_Q5F4QxL7uSCGVEb" }
          ]
        }
      }
    }
  ],
  "comments": [
    {
      "guid": "3d4e5f6a-7b8c-9d0e-1f2a-3b4c5d6e7f8a",
      "date": "2026-06-03T08:00:00Z",
      "author": "[email protected]",
      "comment": "Tier 1 clash detected in T1_STR-Steel_vs_HVAC-Mains run. Depth of penetration: 140mm. Beam span: 9.1m, location at 0.45L from east support (critical zone for shear). Duct is supply air main — rerouting will require ME approval and duct velocity recalculation. Assigned to SE for structural review first.",
      "topic_guid": "a59a8a2c-1b4f-4c3e-8d7f-2e1a5b6c9d0f"
    }
  ]
}

The labels array is the critical field for tier tracking. Consistent label values ("Tier1", "Tier2", plus discipline labels and floor/zone labels) allow the issue tracker to filter, group, and report by tier without requiring custom fields on the platform.

4.6 Automating BCF Export from Navisworks

The following Python script reads a Navisworks XML clash report export and generates BCF-compatible JSON payloads, one per clash, with tier assignment based on the clash test name prefix convention (T1_, T2_).

"""
navis_to_bcf.py
Converts a Navisworks XML clash report to BCF 3.0-compatible JSON topics.
Applies tier assignment based on clash test name prefix (T1_, T2_, QA_).
 
Requires: lxml (pip install lxml)
 
Usage:
  python navis_to_bcf.py --input clash_report.xml --output bcf_topics.json
  --assignee-t1 [email protected]
  --assignee-t2 [email protected]
"""
 
import argparse
import json
import uuid
from datetime import datetime, timezone
from lxml import etree
 
 
TIER_CONFIG = {
    "T1": {
        "priority": "Critical",
        "labels": ["Tier1"],
        "due_days": 1,
        "assigned_to": None,  # Override via CLI arg
    },
    "T2": {
        "priority": "Normal",
        "labels": ["Tier2"],
        "due_days": 7,
        "assigned_to": None,
    },
    "QA": {
        "priority": "Low",
        "labels": ["Tier3", "ModelQA"],
        "due_days": 3,
        "assigned_to": None,
    },
}
 
 
def determine_tier(test_name: str) -> str:
    """Map clash test name to tier key using prefix convention."""
    for prefix in ("T1", "T2", "QA"):
        if test_name.startswith(prefix + "_") or test_name.startswith(prefix + "-"):
            return prefix
    return "T2"  # Default: Tier 2 if no prefix matched
 
 
def parse_clash_xml(xml_path: str) -> list[dict]:
    """Parse Navisworks XML clash report and extract clash records."""
    tree = etree.parse(xml_path)
    root = tree.getroot()
    clashes = []
 
    for test in root.findall(".//clashtest"):
        test_name = test.get("name", "UnknownTest")
        for result in test.findall(".//clashresult"):
            clash = {
                "test_name": test_name,
                "clash_id": result.get("name", str(uuid.uuid4())),
                "status": result.get("status", "new"),
                "distance": float(result.get("distance", 0.0)),
                "item1_id": "",
                "item2_id": "",
                "item1_path": "",
                "item2_path": "",
                "clash_point": {"x": 0.0, "y": 0.0, "z": 0.0},
            }
 
            # Extract item GUIDs and paths
            items = result.findall("clashobject")
            if len(items) >= 1:
                clash["item1_path"] = items[0].findtext(".//pathlink", default="")
                smart1 = items[0].find(".//smarttag[@field='Element ID']")
                clash["item1_id"] = smart1.text if smart1 is not None else ""
            if len(items) >= 2:
                clash["item2_path"] = items[1].findtext(".//pathlink", default="")
                smart2 = items[1].find(".//smarttag[@field='Element ID']")
                clash["item2_id"] = smart2.text if smart2 is not None else ""
 
            # Extract clash point
            cp = result.find("clashpoint/pos3f")
            if cp is not None:
                clash["clash_point"] = {
                    "x": float(cp.get("x", 0.0)),
                    "y": float(cp.get("y", 0.0)),
                    "z": float(cp.get("z", 0.0)),
                }
 
            clashes.append(clash)
 
    return clashes
 
 
def clash_to_bcf_topic(
    clash: dict,
    assignees: dict,
    author: str = "[email protected]",
) -> dict:
    """Convert a single clash record to a BCF 3.0 topic JSON object."""
    tier_key = determine_tier(clash["test_name"])
    tier_cfg = TIER_CONFIG[tier_key]
 
    now = datetime.now(timezone.utc)
    due = datetime(
        now.year, now.month, now.day + tier_cfg["due_days"],
        17, 0, 0, tzinfo=timezone.utc
    )
 
    assigned_to = assignees.get(tier_key, "")
 
    title = (
        f"{tier_key} — {clash['test_name']} | "
        f"ID {clash['clash_id']} | "
        f"Overlap {abs(clash['distance']):.3f}m"
    )
 
    labels = list(tier_cfg["labels"])
    # Add discipline labels from test name
    test_parts = clash["test_name"].split("_")
    if len(test_parts) > 1:
        labels.append(test_parts[1])
 
    viewpoint_guid = str(uuid.uuid4())
    cp = clash["clash_point"]
 
    topic = {
        "guid": str(uuid.uuid4()),
        "topic_type": "Clash",
        "topic_status": "Open",
        "priority": tier_cfg["priority"],
        "title": title,
        "description": (
            f"Clash detected in test '{clash['test_name']}'. "
            f"Overlap distance: {abs(clash['distance']):.3f}m. "
            f"Element 1: {clash['item1_path']} (ID: {clash['item1_id']}). "
            f"Element 2: {clash['item2_path']} (ID: {clash['item2_id']}). "
            f"Clash point: X={cp['x']:.3f} Y={cp['y']:.3f} Z={cp['z']:.3f}."
        ),
        "labels": labels,
        "creation_date": now.isoformat(),
        "creation_author": author,
        "assigned_to": assigned_to,
        "due_date": due.isoformat(),
        "viewpoints": [
            {
                "guid": viewpoint_guid,
                "perspective_camera": {
                    "camera_view_point": {
                        "x": cp["x"] + 3.0,
                        "y": cp["y"] + 3.0,
                        "z": cp["z"] + 2.0,
                    },
                    "camera_direction": {
                        "x": -0.577, "y": -0.577, "z": -0.577
                    },
                    "camera_up_vector": {
                        "x": 0.0, "y": 0.0, "z": 1.0
                    },
                    "field_of_view": 60.0,
                },
            }
        ],
    }
 
    return topic
 
 
def main():
    parser = argparse.ArgumentParser()
    parser.add_argument("--input", required=True, help="Navisworks XML clash report path")
    parser.add_argument("--output", required=True, help="Output BCF JSON file path")
    parser.add_argument("--author", default="[email protected]")
    parser.add_argument("--assignee-t1", default="[email protected]")
    parser.add_argument("--assignee-t2", default="[email protected]")
    parser.add_argument(
        "--exclude-tier3",
        action="store_true",
        help="Omit QA/Tier3 clashes from BCF output",
    )
    args = parser.parse_args()
 
    assignees = {
        "T1": args.assignee_t1,
        "T2": args.assignee_t2,
        "QA": args.assignee_t2,
    }
 
    clashes = parse_clash_xml(args.input)
    topics = []
 
    for clash in clashes:
        tier_key = determine_tier(clash["test_name"])
        if args.exclude_tier3 and tier_key == "QA":
            continue
        topics.append(clash_to_bcf_topic(clash, assignees, args.author))
 
    output = {
        "bcf_version": "3.0",
        "project": {"project_id": str(uuid.uuid4()), "name": "BIM Coordination"},
        "topics": topics,
        "generated_at": datetime.now(timezone.utc).isoformat(),
        "total_topics": len(topics),
        "tier_summary": {
            "T1_Critical": sum(1 for t in topics if t["priority"] == "Critical"),
            "T2_Normal": sum(1 for t in topics if t["priority"] == "Normal"),
            "QA_Low": sum(1 for t in topics if t["priority"] == "Low"),
        },
    }
 
    with open(args.output, "w", encoding="utf-8") as f:
        json.dump(output, f, indent=2, ensure_ascii=False)
 
    print(f"Exported {len(topics)} BCF topics → {args.output}")
    print(f"Tier summary: {output['tier_summary']}")
 
 
if __name__ == "__main__":
    main()

4.7 Integration with Issue Trackers

Once BCF topics are generated, they integrate with the three major coordination platforms as follows.

BIMcollab NEXUS accepts BCF files via its web interface or via the BIMcollab BCF Manager plugin installed directly in Navisworks. The plugin allows import of Clash Detective results directly into BIMcollab without exporting an intermediate XML file — Navisworks clashes map to BIMcollab issues with status, priority, and viewpoint preserved. The recommended workflow is to use the plugin's filter to import only Tier 1 and Tier 2 tests (by test name pattern) and to bulk-mark the Tier 3 QA tests as "Resolved — Acceptable" before any distribution.

Trimble Connect supports BCF import via the Connect for Web interface and the Trimble Connect desktop application. Topics imported from BCF become Tasks in Connect, with viewpoints linked to the project model. Connect supports BCF 2.1 and 3.0 formats. When using the tiered label convention ("Tier1", "Tier2"), the Connect task list can be filtered by label to show only critical issues.

BIM Track (now Newforma Konekt) supports BCF API connections, allowing direct synchronization from Navisworks via its native plugin. Like BIMcollab, BIM Track supports BCF 3.0 priority values (Critical, High, Normal, Low), making the label-based tier system directly compatible with the platform's native filtering.

Step 1: Configure search sets

Import the shared SearchSets_ProjectName_v1.xml into the Navisworks Sets window. Verify that every discipline model's categories are correctly captured by running a quick manual selection check on each set.

Step 2: Import clash test XML

Import the project's ClashTests_ProjectName_v2.xml into Clash Detective. Verify that Selection A and Selection B for each test are populated with the correct search sets.

Step 3: Run all tests

Click Run All. Watch for any tests that produce zero results (possible empty search set) or suspiciously high results (possible search set overlap).

Step 4: Bulk-approve Tier 3

Select all results in the QA_Duplicate-MEP and any known noise tests. Use the Approve All action to remove them from the active review queue.

Step 5: Group and annotate Tier 1 results

For each T1 test, group related clashes by zone or grid, add a comment describing the conflict and the required resolution path, and flag for export.

Step 6: Export BCF per tier

Run the navis_to_bcf.py script with --exclude-tier3 to generate the BCF JSON. Or use the BIMcollab BCF Manager plugin to push directly to the issue tracker.

Step 7: Distribute to issue tracker

Import BCF into BIMcollab, Trimble Connect, or BIM Track. Verify that Tier 1 clashes are assigned and have a due date of T+1 day.

Step 8: Hold coordination meeting — decisions only

The coordination meeting reviews only pre-assigned issues. No clash discovery happens in the meeting. Decisions are made, owners are confirmed, and the next model update schedule is established.

5. Anti-Patterns

These are the coordination failure modes that experienced BIM managers encounter repeatedly. Each one is a specific, observable behaviour — not a general principle — and each has a concrete fix.

5.1 Reviewing Every Clash

The pattern: The team opens the Clash Detective results panel and starts reviewing clashes from number 1. A coordinator marks each one New, Active, or Approved manually. The session lasts four hours and covers 600 clashes. Nobody knows whether clash 601 is more important than clash 52.

Why it happens: There is no tiering configuration. Without pre-defined severity tiers, every clash looks equally important and equally unimportant. The team's response is to attempt completeness — to ensure nothing is missed by reviewing everything.

Why it fails: The cognitive load of reviewing 600 unfiltered clashes produces diminishing accuracy after the first 50–100. Important clashes (the structural beam penetration at grid B/4) receive the same 30 seconds of attention as unimportant ones (the ceiling grid intersecting a 25mm conduit by 2mm). The team becomes numb to severity signals.

The fix: Implement the three-tier search set configuration before the first run. Accept that Tier 3 clashes will never be reviewed. The time saved reviewing noise is redirected to deep analysis of Tier 1 issues.

5.2 Suppressing Without Classification

The pattern: A coordinator bulk-approves 40,000 clashes to "clean up the dashboard" before a client review. No record exists of what was approved or why. In the next coordination cycle, similar clashes reappear because the underlying cause was not addressed, and the same bulk-approve action is repeated.

Why it happens: The dashboard is used as a status signal ("zero active clashes = coordination complete") rather than a tracking tool. Reducing the number is treated as the goal.

Why it fails: Suppressed clashes that are not genuinely resolved reappear in every model update. The bulk-approve cycle becomes a ritual rather than a coordination output. Audit trails are destroyed — if a clash that was bulk-approved later materialises as a field conflict, there is no record of the decision.

The fix: The Approve action in Navisworks should be used only for clashes that have been explicitly reviewed and determined to be acceptable — with a comment explaining why. Tier 3 clashes are suppressed not through individual Approve actions but through correct search set configuration, so they never appear in the results at all. The search set XML is the audit trail.

5.3 Running Daily Clashes During Design Development

The pattern: The BIM coordinator runs clash tests daily and distributes the full results to the project team. The team receives a daily email with "Today's clash report: 8,247 New." Coordination meetings are called to review the changes since yesterday.

Why it happens: There is an intuition that more frequent detection means faster resolution. If clashes are checked daily, issues are found sooner.

Why it fails: During Design Development, models change daily — not because issues are being resolved, but because design is actively progressing. A duct that clashes today will be rerouted tomorrow not because of the clash report but because the mechanical engineer was going to reroute it anyway. Daily reports during DD create the illusion of a coordination workflow on top of a design process that is not yet stable enough to coordinate. The clash delta between Monday's run and Tuesday's run is dominated by design changes, not resolved issues. Teams burn coordination bandwidth chasing a moving target.

The fix: Establish a coordination lock date for each discipline by phase. During Design Development, run clash tests at the milestone boundaries (end of SD, mid-DD, end of DD) on frozen model snapshots — not on live working models. Daily coordination testing is appropriate only in the shop drawing and fabrication phases, when models are stable and clash delta genuinely reflects resolved versus outstanding issues.

5.4 Ignoring Soft Clashes

The pattern: The team uses only Hard clash tests at zero tolerance. Clearance tests are never configured. The coordination workflow is considered complete when zero Hard clashes remain. Models go to construction documents with no clearance validation.

Why it happens: Hard clashes are visible, countable, and unambiguous — element A is inside element B, and that is clearly wrong. Clearance violations require judgment (what is the minimum acceptable clearance for this system in this context?) and cannot be resolved by either discipline alone. They are uncomfortable to raise.

Why it fails: A pipe that passes 50mm below a beam flange with zero hard clash may be physically buildable — but it cannot be insulated, it cannot be accessed for maintenance, and it may violate NEC clearance requirements for electrical equipment nearby. Clearance failures that reach the field become expensive RFIs, often requiring demolition and reinstallation of finished ceiling work.

The fix: Add Clearance tests to the clash matrix during Design Development. Define clearances per system type and enforce them. The BIM Execution Plan should include a clearance requirement table — minimum clearances for each MEP system type, referenced to the applicable codes or owner's maintenance standards.

5.5 Mixing LOD Levels in Federation

The pattern: A 400,000 sqft project federates models where the structural model is at LOD 200 (massing), the MEP models are at LOD 350 (coordination), and the architectural model is at LOD 300. Clash tests run against the full federation.

Why it happens: The federation milestone is driven by the project schedule rather than by model readiness. The BIM coordinator is under pressure to produce coordination results.

Why it fails: LOD 200 structural geometry is representative, not accurate. Beam positions are approximate. Running a Tier 1 clash test between an LOD 200 structural model and LOD 350 MEP produces clashes that are artefacts of the structural geometry approximation, not real conflicts. The team spends coordination time resolving clashes that will disappear when the structural model advances to LOD 300 — and new, real clashes may be hidden behind the LOD 200 geometry.

The fix: The BIM Execution Plan should specify minimum LOD requirements for federation participation at each phase. Structural models enter the federation at LOD 300 or higher. If a discipline model is below the federation LOD, it participates as a reference model only, not as a clash detection participant.

6. Case Studies

6.1 Data Centre, 85,000 m² — Tier 1 Count as a Phase Gate

A data centre project in Southeast Asia used a tiered severity framework as a formal phase gate. The project team — four MEP consultants, a structural engineer, and an owner's BIM manager — established in the BIM Execution Plan that no discipline model could advance from Design Development to Construction Documents until Tier 1 clash count reached zero on two consecutive weekly model updates.

The first federation run, at mid-DD, produced 62 Tier 1 clashes and approximately 840 Tier 2 clashes. By the end of DD (six weeks), the Tier 1 count was at zero. The team then focused on Tier 2 resolution through the CD phase. When the models went to CD issue, the remaining open Tier 2 count was 34 — all maintenance clearance issues that had been accepted by the owner's facilities manager with documented rationale.

The outcome: zero structural-MEP conflicts were discovered during construction. The project team estimated that the tiered phase gate prevented between 15 and 20 RFIs related to structural penetrations that would otherwise have been discovered during steel erection.

The key practice that made this work was the explicit Tier 1 zero-count requirement in the BEP, with weekly reporting of the Tier 1 active count. Because the count was a contractual milestone indicator, discipline leads had a clear incentive to resolve Tier 1 issues rather than deferring them.

6.2 Mixed-Use High-Rise, 55 Floors — BCF Triage Workflow

A 55-floor mixed-use tower project used BIMcollab NEXUS as the issue management platform, with the tiered BCF export workflow described in section 4.6. The project's first full-federation clash run (week 6 of Design Development) produced:

• Tier 1 (Hard, primary structure vs. MEP mains): 41 clashes
• Tier 2 (Hard, secondary; Clearance): 312 clashes
• Tier 3 (suppressed in configuration): estimated 28,000+ geometric artefacts, never exported

The 353 real clashes were exported to BIMcollab as BCF topics, with Tier 1 issues assigned to engineers of record and Tier 2 issues assigned to discipline BIM leads. The coordination meeting that week lasted 90 minutes — substantially less than the four-hour meetings the team had been holding in the previous project, where unfiltered clash reports were distributed.

By week 14 (end of DD), the Tier 1 count was at 3 (all related to a transfer slab penetration that required structural engineering analysis). The Tier 2 count was at 67, all maintenance clearance issues under active review.

The project's BIM manager noted that the most significant productivity gain was in meeting efficiency: "The first 20 minutes of every previous coordination meeting was spent sorting the clash report. Now we walk in knowing exactly which 5 issues we're deciding on today."

6.3 Hospital Project, $380M — Clearance Failures Caught Pre-Construction

A large hospital project ran standard hard-clash-only coordination through Design Development — a common practice at the time. When the project transitioned to Construction Documents, the owner's commissioning consultant introduced clearance testing for the first time, focusing on electrical equipment maintenance envelopes.

The clearance test (600mm around all electrical panels, switchgear, and MCCs) identified 28 locations where structural elements, plumbing mains, or wall construction placed obstructions within the maintenance envelope. None of these were Hard clashes — all elements were geometrically separate. But 14 of the 28 locations violated NEC 110.26 working space requirements for equipment operating at 150V to 600V to ground.

Resolving 14 code violations at CD stage required coordination changes in both the structural and MEP models, revisions to electrical panel schedules, and three RFIs to the structural engineer of record. The project team estimated that the same violations discovered during construction would have cost between USD 180,000 and USD 240,000 to remediate — compared to approximately USD 22,000 in coordination time at the CD stage.

The case established the firm's internal standard: clearance tests for electrical equipment are mandatory from the start of Design Development, not deferred to CD.

6.4 Stadium Project, Complex Geometry — Duplicate Detection as Quality Gate

A major stadium project operated with five MEP subcontractor models federated into a common environment. During a model update in week 3, the Duplicate test (run as a pre-coordination quality gate) detected 1,847 duplicate elements across the HVAC main model and a copy of the same model that had been accidentally appended twice by the BIM coordinator.

Had the duplicate test not been run, the 1,847 duplicate elements would have generated approximately 4,200 false Hard clashes in the Tier 1 and Tier 2 tests — because the duplicated MEP elements would clash with themselves. The coordination team would have spent days reviewing phantom clashes.

The quality gate workflow was subsequently formalised: all models are processed through the Duplicate test before any coordination test runs, and any model producing more than 5 duplicate results is returned to the discipline BIM lead for correction before federation.

6.5 Corporate Campus, Phase-Gate Tiering Across Design Stages

A five-building corporate campus project provides a useful illustration of how tier definitions evolve as the project advances through design phases. The project team deliberately redefined what constituted a Tier 1 clash at each phase milestone, reflecting the progressively tighter model accuracy requirements.

Schematic Design (SD): No formal clash detection. Models were at LOD 200 — representative geometry only. Clash testing was explicitly excluded from the BEP for this phase. Teams confirmed massing envelopes and plenum volumes by visual review in the federated viewer only.

Design Development (DD): Tier 1 limited to structural-MEP conflicts involving elements with overall dimension ≥ 300mm. Tolerance 25mm for all tests. Rationale: DD models are not yet fabrication-accurate; a 25mm tolerance filters rounding differences between authoring tools while still catching real penetrations of large elements. The team ran bi-weekly clash tests on frozen model snapshots, not live working models.

Construction Documents (CD), 50% submittal: Tier 1 tolerance reduced to 10mm. Tier 2 expanded to include clearance tests for all MEP systems, not just primary distribution. New Tier 2 test category added: MEP-vs-ARCH interface coordination (ceiling heights, architectural feature walls, canopy elements).

Construction Documents (CD), 100% submittal: Tier 1 tolerance reduced to 5mm (near-final). Tier 1 count required to be zero as a formal CD issue prerequisite — enforced as a checklist item in the project management platform. Tier 2 count target: ≤ 50 open, with all open items having documented acceptance rationale signed by discipline leads.

Fabrication (FAB): Tier 1 tolerance 2mm. New test tier introduced: Tier 1F ("Fabrication Hard") covering hanger conflicts, support bracket clashes, and MEP-to-MEP sleeve penetrations. Clearance tests for access panels and maintenance platforms.

The phased approach prevented the common problem of teams trying to achieve CD-level coordination accuracy during DD, which produces a combination of false precision (clashes that disappear when the model advances) and false negatives (real clashes obscured by the loose tolerance). Each phase's tier definition matched what the models could actually support.

7. Limits and Caveats

Tiered severity in Navisworks is a powerful coordination tool, but it has specific limitations that practitioners should understand before treating it as a complete coordination solution.

7.1 Federation Quality Is a Precondition

Every limitation in this section flows from the same root: tiered clash detection is only as good as the federated model it operates on. Coordinate system misalignment between discipline models is the single most common source of mass false-positive Tier 1 clashes. A 50mm offset between the architectural and structural model origins will cause every primary structural element to appear to clash with nearby MEP elements that actually clear by 50mm. This cannot be fixed in the clash test configuration — it must be fixed in the federation before any clash tests run.

The pre-federation checklist should include: shared coordinate system verification (Revit Survey Point or Project Base Point), NWC export settings audit (object properties, split by level, merge construction type), and a visual spot-check at three distinct locations in the model to confirm that structural and architectural elements are correctly aligned before running any clash tests.

7.2 Sub-Model Granularity

Large projects often split discipline models into sub-models by zone, floor, or building section. Clash tests must be configured for each sub-model combination, not just for full-model tests. A Tier 1 clash test between STR-Primary-Steel and MEP-HVAC-Mains on the full federation will correctly detect clashes — but if the MEP model is split into podium and tower sub-models, the search sets must be verified to correctly capture elements from both sub-models.

The search set architecture described in section 4.1 handles this correctly if search sets are category-based and model-independent. If search sets are defined by layer (for DWG-source models), sub-model splits will require separate search sets per sub-model.

7.3 Joint Venture and Multi-Firm Environments

On joint venture projects where two or more firms are each responsible for part of the building, BIM coordination protocol must be agreed at project outset. Two firms may use different search set definitions, different tolerance standards, and different issue status conventions. BCF topic labels and priority values are not constrained by the standard — each platform implements them differently. Before adopting the tiered label convention ("Tier1", "Tier2"), confirm that all participating issue management platforms support user-defined labels.

The safest cross-firm approach is to establish the coordination protocol — search set definitions, tolerance matrix, tier definitions, BCF label vocabulary, status workflow — as an appendix to the BIM Execution Plan, with sign-off from all firms before the first federation milestone.

7.4 Navisworks vs. Model-Native Coordination

Navisworks is a model-viewer and clash engine — it does not modify source models. Clash resolution happens in Revit, Tekla, AutoCAD MEP, or whatever authoring tool each discipline uses. The BCF workflow is the bridge between Navisworks clash detection and authoring tool resolution, but it is not a bidirectional synchronisation. A clash marked "Resolved" in the issue tracker is not automatically verified in Navisworks — that requires a model update and a re-run of the relevant clash test.

Automated platforms (Autodesk Construction Cloud Model Coordination, Solibri) offer tighter integration between detection and resolution tracking, including automated re-test on model update. These platforms use similar tiering concepts but with different configuration interfaces. The principles in this article apply regardless of platform; the specific XML configuration and Python scripts target Navisworks Manage.

7.5 The 200-Clash Target Is a Function of Tier Definition

The claim in the introduction — that a well-configured tiered system reduces the team's attention to approximately 200 clashes — assumes a specific tier definition: Tier 1 and Tier 2 combined, excluding false positives, on a 400,000+ sqft mixed-use project at the end of Design Development. On a smaller project, the number may be 50. On a more complex project (hospital, data centre, transportation hub), it may be 400–600. The tier configuration in section 4.2, applied correctly, consistently reduces the actionable clash count by 95–99% relative to an unfiltered all-versus-all run. The absolute number will vary.

7.6 Automation Is a Starting Point, Not a Replacement for Judgment

The Python scripts in section 4.4 and 4.6 automate the mechanical steps: parsing the Navisworks XML, assigning tier prefixes, generating BCF JSON, routing to assignees. They do not apply engineering judgment. A script cannot determine that a specific duct-beam clash involves a post-tensioned beam where web penetrations are structurally prohibited, versus a conventional wide-flange beam where a standard opening can be accommodated. The script assigns both as Tier 1 Critical and assigns them to the structural engineer of record — that is correct. The structural engineer's review determines which resolution path applies.

The automation value is in scale and consistency: generating 200 correctly structured BCF topics in two minutes rather than two hours of manual copy-paste from the Navisworks results panel. The judgment value — which tier a specific clash belongs to, whether a clearance violation is acceptable given the maintenance protocol, whether two seemingly separate clashes are symptoms of the same routing decision — is irreducibly human.

BIM managers who have deployed tiered clash workflows at scale consistently report that the framework's productivity benefit comes from two sources in roughly equal measure: (1) eliminating the time spent reviewing noise (configuration benefit), and (2) enabling better conversations about real issues because the team arrives at coordination meetings having already read the pre-distributed clash list and having thought about resolutions before the meeting starts (process benefit). The second benefit is harder to quantify but is frequently described as more impactful.

7.7 Platform Differences: Navisworks vs. Cloud-Native Coordination Tools

Autodesk Construction Cloud (ACC) Model Coordination and Solibri offer built-in clash detection with tighter integration between detection, issue management, and model version control than Navisworks + BCF + external issue tracker. The trade-off is configurability: Navisworks Manage's search set system and rules configuration are more granular than the current ACC Model Coordination interface, and the XML-driven automation approach is not available in cloud-native tools without API integration.

For teams already working in the Autodesk ecosystem (Revit + ACC + Navisworks Manage), a hybrid approach works well: use Navisworks for the initial tiered configuration and the first two or three clash runs (where search set and tolerance tuning is most intensive), then migrate to ACC Model Coordination for ongoing automated clash detection once the configuration is stable. The BCF export from Navisworks maps cleanly to ACC Issues.

Solibri's Clash Detection Matrix rule provides a configuration interface conceptually similar to the matrix-driven approach described in section 4.2, but with a spreadsheet-style matrix input rather than XML. Solibri's tolerance-per-combination setting (where different tolerances can be applied to specific element type pairs within a single rule) is more granular than Navisworks' per-test tolerance. For teams with Solibri licenses, the Clash Detection Matrix rule is worth evaluating as a complement to Navisworks for the Tier 2 clearance test configuration.

8. Sources and Further Reading

The following sources were directly consulted in the preparation of this article. URLs verified as accessible at time of writing.

Autodesk Navisworks Official Documentation

• Autodesk Help — Navisworks 2024 — Select Clash Test Options: help.autodesk.com/view/NAV/2024/ENU/?guid=GUID-B13377D4-8AFA-4E95-8435-C6DC4DF26AF4
• Autodesk Help — Navisworks 2024 — Set Clash Rules: help.autodesk.com/view/NAV/2024/ENU/?guid=GUID-5A4502DF-75DF-4BA2-A649-35A921E3BBCD
• Autodesk Community Forum — "Hard vs. Hard (Conservative)" and "Difference between Hard and Clearance Clash": forums.autodesk.com/t5/navisworks-forum/

BIMForum LOD Specification

• BIMForum — Level of Development (LOD) Specification 2023, Part I (published 2024-02-27): bimforum.org/wp-content/uploads/2023/10/LOD-Spec-2023-Part-I-2024-02-27.pdf
• BIMForum — LOD Specification 2024 (English and Spanish): bimforum.org/bimforum-level-of-development-lod-specification-2024-in-english-and-spanish-language-version/

BCF Specification

• buildingSMART International — BIM Collaboration Format (BCF) 3.0: buildingsmart.org/bim-collaboration-format-bcf-3-0/
• buildingSMART Technical — BCF Standards page: technical.buildingsmart.org/standards/bcf/
• buildingSMART GitHub — BCF-API repository (release_3_0 branch): github.com/buildingSMART/BCF-API
• buildingSMART GitHub — BCF-XML repository: github.com/buildingSMART/BCF-XML
• OSArch Wiki — BCF – BIM Collaboration Format (structural overview): wiki.osarch.org/index.php?title=BCF_-_BIM_Collaboration_Format

Solibri Documentation

• Solibri Desktop Help Centre — 245 Clash Detection Matrix: help.solibri.com/hc/en-us/articles/23765423193111-245-Clash-Detection-Matrix
• Solibri Desktop Help Centre — Clash Detection Matrix (UK) Extension: help.solibri.com/hc/en-us/articles/19082258215447-Clash-Detection-Matrix-UK-Extension
• BIM Corner — Mastering Quality Assurance in BIM with Solibri: bimcorner.com/mastering-quality-assurance-in-bim-with-solibri/

Coordination Workflow References

• BIM Heroes — Beyond the Report: A Guide to Navisworks Clash Detection That Protects Margins: bimheroes.com/navisworks-clash-detection/
• BIM Heroes — Why Your Coordination Meetings Are Ineffective (And How to Fix Them Fast): bimheroes.com/bim-coordination-meetings/
• Revizto — Clash Detection in BIM: revizto.com/resources/blog/clash-detection-in-bim
• BIMcollab — Clash Detection vs Issue Management in BIM: bimcollab.com/en/resources/blog/clash-detection-vs-issue-management/
• Modelical — Navisworks Clash Detection: modelical.com/en/gdocs/clash-detection/
• GlobalCAD / Darren Bond — Navisworks Clash Deep Dive 1: Configuration: globalcad.co.uk/navisworks-clash-deep-dive-1-configuration/
• Taal Tech — Clash Detection and Coordination in Large-Scale MEP Projects: taaltech.com/clash-detection-and-coordination-in-large-scale-mep-projects/

Automation and Scripting

• Paul Kawuma / The Startup — How to Create a Navisworks Clash Test XML From Excel Using Python: medium.com/swlh/how-to-create-a-navisworks-clash-test-xml-from-excel-using-python-9fc458c20f85
• GitHub — Clash Detection Matrix Automation (Kennystruct): github.com/Kennystruct/Clash-Detection-Matrix-Automation

Code Standards Referenced

• NFPA 70 (National Electrical Code) — Article 110.26: Working Space requirements for electrical equipment (consult current edition; requirements are jurisdiction-specific)
• ISO 19650 series — Organisation and digitisation of information about buildings and civil engineering works, including building information modelling

Further Reading For practitioners implementing this workflow for the first time, the recommended reading sequence is: (1) Autodesk Navisworks 2024 Help documentation on Clash Detective configuration, (2) BIMForum LOD Specification Part I to understand model accuracy context, (3) buildingSMART BCF-XML GitHub repository for the topic schema, (4) your issue tracker's BCF import documentation (BIMcollab, Trimble Connect, or BIM Track). The Python scripts in this article are starting points — adapt them to your project's naming conventions and your team's issue management vocabulary.