Revit + Navisworks: the right frequency for clash reviews

The weekly clash report nobody reads

Picture a coordination folder somewhere on a project network drive — or, if the project is more contemporary, a thread in a shared workspace. It contains forty-seven PDF clash reports. The earliest date to schematic design. The most recent was uploaded three days ago, forty-eight hours before the 100% Construction Documents package was due to the structural engineer of record.

Nobody opened the last six.

The BIM coordinator knows this because the ACC Issues dashboard shows no activity. The same 213 clashes that were marked "New" two weeks ago are still marked "New." The structural lead was at a detailing sprint for the lateral system. The MEP engineer had two submittals due. The project manager sent one follow-up email that disappeared into a thread about RFI responses.

The clash report landed in the coordination folder on schedule, exactly as specified in the BIM Execution Plan. And it accomplished nothing.

This is the most common failure mode in Revit–Navisworks coordination workflows: not a tool failure, not a modeling failure — a cadence failure. The detection ran at the wrong frequency for the phase the project was in, generating reports the team was structurally incapable of processing in the time available.

On the other side of the same spectrum sits a different failure, less discussed but equally damaging. A project team running daily clash detection during Schematic Design, flooding the model coordination channel with hundreds of "New" clashes against geometry that is still placeholders. Every notification dulls the signal a little further. When critical CD-phase clashes finally arrive — the HVAC main that bisects the penthouse structural transfer beam, the electrical gear room that collides with the building envelope — they are greeted with the same learned indifference trained into the team by six months of noise.

Too frequent: the team ignores reports. Too rare: clashes accumulate to crisis. The cadence that actually works is the one calibrated to the information density the team can absorb and act on, at each phase, with the models they have.

This guide is a practitioner's framework for building that cadence. It covers the economics of signal vs. noise in clash management, the specific rules that apply at each AIA project phase (and their RIBA equivalents), the technical implementation using Navisworks Manage with Revit exports and BIM Collaborate Pro, and the anti-patterns that derail coordination on otherwise well-run projects. Code samples and configuration files are included for teams that want to operationalize the recommendations directly.

The goal is not to get you to the lowest possible clash count. It is to get the right clashes in front of the right people at the moment when those people have the authority and the context to resolve them.

Why cadence matters

Model stability and change rate

The foundational principle behind clash review cadence is simple: a clash detected in a model that changes tomorrow is not actionable today. The team member who receives that clash cannot close it without reverting work they haven't finished. If they close it anyway, the "Resolved" status becomes meaningless the moment the next model update drops new geometry into the same space.

Model stability — the degree to which discipline models hold their geometry between review cycles — is the primary driver of a useful review cadence. Stability is not the same as completion. An SD-phase model is deeply incomplete, but if the structural engineer's grid, story heights, and primary framing strategy are stable for a two-week stretch, that window is the right time to run a first-pass clash review. The geometry being reviewed is representative. Decisions made on it will hold.

Instability has two signatures that require different responses:

Design volatility — the normal condition of early-phase work, where schemes are tested and discarded rapidly. During periods of high design volatility, clash reports become archaeological artifacts the moment they print. Running reviews during these windows trains the team to treat clashes as background noise. The correct response is to hold reviews until a deliberate design freeze, even a temporary one, creates a stable window.

Post-resolution drift — the insidious condition of later phases, where a resolved clash reappears because an unrelated design change moved geometry back into conflict. This is best caught not by increasing review frequency across all test suites, but by running automated re-checks specifically on previously resolved issues after each model submission. Navisworks Manage supports this through the "Reviewed" and "Approved" status filters combined with new model loads: clashes previously marked Resolved that reappear as New in the updated model are immediately visible without rerunning the full test battery.

The relationship between model stability and review frequency is roughly inverse during design phases and roughly direct during construction. In SD and early DD, the correct approach is to time reviews to design milestones rather than calendar intervals. In late CD and construction, where model updates are driven by issue resolution cycles, reviews should run at the same frequency as model submission requirements — because stability within each cycle can be assumed.

Signal-to-noise economics

The coordination team's attention is the scarcest resource on any BIM project. Every time a report arrives with two hundred "New" clashes, most of which are false positives, anchor bolts overlapping with their own welds, or placeholder ducts that will not exist in the issued model, the team makes a rational economic decision: scan the report for names they recognize, close the ones that look obvious, and defer the rest.

This is not negligence. It is triage under information overload. The problem is that triage applied to clash reports is probabilistic, and the false-positive rate on a poorly configured test suite can easily exceed seventy percent. The consequence is that real clashes — the load-bearing beam penetration, the equipment room that requires an impossible duct radius — are resolved at the same rate as the fake ones: deferred until someone screams about them in a site meeting.

The economic solution is not to run fewer tests. It is to run tests that produce a higher fraction of actionable results per report. This requires three inputs:

1. Test suite configuration — surgical, targeted search sets rather than "Entire File vs. Entire File" blanket tests. A test that checks HVAC primary distribution ductwork against structural steel generates fifty clashes, most of them real. A test that checks "all mechanical objects" against "all structural objects" generates five thousand clashes, a majority of which are false positives from objects the test should never have included.

2. Phase-appropriate tolerance settings — what constitutes a "clash" depends entirely on what phase the project is in and what decision needs to be made. A clearance tolerance of 50mm on primary ductwork during SD might generate useful coordination flag. That same tolerance on detailed branch piping during CD is a noise generator, because the routing hasn't been designed yet and every hit represents a hypothetical conflict.

3. Clash grouping before distribution — Navisworks Manage's grouping function consolidates related clashes (all instances of a duct series intersecting the same beam, for example) into a single addressable issue rather than fifty individual line items. Reports distributed after intelligent grouping are consistently more actionable than raw exports. BIMHeroes's field guidance puts this well: the transformation from "thousands of clashes" to "twenty core problems" happens through grouping and human filtering, not through software configuration alone.

Signal-to-noise ratio also degrades with frequency mismatches. When a daily report arrives on a team that can process weekly inputs, the daily rate generates five times the line items with no corresponding increase in resolution capacity. Within two weeks, the backlog is large enough that the next report gets skimmed rather than read. The review cadence that matches the team's processing bandwidth — not the software's run speed — is the cadence that actually reduces clashes.

Team attention and meeting design

BIM coordination meetings serve two functions that require different cadences. The first is discovery — learning that a clash exists and understanding its spatial context. The second is decision — determining who is responsible for resolution and what the resolution path looks like.

Most failed coordination meetings try to do both simultaneously, spending the first forty minutes discovering new clashes in a shared Navisworks session while the team sits waiting. This is a structural failure, not a meeting management failure. Discovery should happen offline, before the meeting, by the BIM coordinator. The meeting itself should be a sequence of decisions on pre-vetted issues.

The implication for cadence is that review frequency must be matched to a pre-meeting preparation cycle. If the team meets weekly, the coordinator needs at minimum two working days before the meeting to run detection, group results, filter false positives, assign preliminary ownership, and distribute the report. That means model submissions must be locked by mid-week. A "model by Thursday, meeting on Thursday" cycle leaves no preparation time and collapses the meeting into a discovery session.

Well-run coordination programs typically operate on a Monday-through-Wednesday model submission window, Thursday BIM coordinator review and grouping, Friday report distribution, and Monday or Tuesday coordination meeting. This cadence creates a predictable rhythm the team can schedule around. The globaletraining.ca practitioner guide's "two pizza rule" for meeting attendance size is a useful heuristic alongside this rhythm: the meeting is for decision-makers, not observers. Every additional attendee who cannot authorize resolution adds friction to the decision rate.

Phase characteristics

The reason a single cadence cannot serve the entire project lifecycle is that the four major design phases differ structurally in ways that directly affect clash review utility:

Model completeness — SD models are skeletal; CD models are production-ready. The same test suite run on both phases produces fundamentally different output, requiring different review depth and different stakeholder engagement.

Decision authority and consequences — a clash resolved in SD is resolved with a sketch. A clash resolved in CD requires a coordinated model change, a potential spec edit, and possible scope negotiation. The stakes and the process are different. Weekly reviews during SD can drive fast, cheap decisions. Monthly reviews during CD will push unresolved clashes to the field, where they cost multiples of their design-phase equivalent.

Rate of new clash introduction — during SD and early DD, the primary source of new clashes is design intent changes: a program element moves, a structural system changes, an MEP concept is revised. During late CD and construction, the primary source is coordination errors: one discipline's detailing assumption that did not align with another's independently advancing model. The frequency that catches design-intent changes is too low for coordination errors, and the frequency that catches coordination errors would be noise during SD.

Team composition and availability — SD and DD involve a smaller design team making high-level decisions. The structural engineer who needs to weigh in on a SD beam clash is not the same person who resolves a CD slab penetration conflict. Coordination meetings during construction involve trade leads who have daily schedule pressures that designers during SD do not. Frequency recommendations that work in the design studio fail in the field trailer.

Phase-by-phase cadence

Concept Design / Schematic Design: bi-weekly milestone reviews

What SD models look like

At the start of Schematic Design, the structural model typically contains a grid, story heights, and preliminary framing members at LOD 100–200. The architectural model has massing, primary floor plates, and major program elements. MEP may not exist at all as a coordinated model, or may exist as schematic zone reservations in the architectural model.

This is not a model you run clash detection against for construction-level coordination. That is the wrong expectation to set with the team or the owner. What SD-phase clash detection can usefully identify:

• Structural-architectural primary conflicts: does the proposed structural framing strategy clear the program elements it needs to clear? Does the floor-to-floor height accommodate the plenum depth required by the mechanical engineer's preliminary concept?
• Site and structure conflicts: does the foundation strategy interact with below-grade program? Do service entry points conflict with structural elements?
• Massing-to-envelope conflicts: where program elements push against the envelope in ways that will require structural accommodation.

What SD-phase clash detection cannot usefully identify: trade-level MEP routing conflicts, minor clearance issues in systems that don't yet exist in the model, anything requiring LOD 300 or higher geometry.

Recommended cadence: bi-weekly, tied to design milestones

The right SD cadence is not calendar-driven but milestone-driven, with the bi-weekly interval serving as the maximum gap between reviews, not the mandatory rhythm. The trigger for a review should be either:

1. A deliberate design freeze on a major system (structural grid locked, primary program relationships established), or
2. The bi-weekly interval expiring, whichever comes first.

Running reviews more frequently than bi-weekly during SD is the fastest path to coordination fatigue. The models are changing faster than the review cycle can process, and every report delivered to a team in mid-design produces frustration rather than action. "We know about those clashes — we're redesigning that section" is the response. After hearing it three times, the team stops attending.

Running reviews less frequently than bi-weekly risks entering DD with major spatial incompatibilities undiscovered. The cost of resolving a structural-architectural conflict at the end of SD is an order of magnitude lower than resolving it at the start of DD when structural detailing has begun.

Test suite configuration at SD

The SD test suite should be narrow: three to five tests maximum, each targeting a high-level system-to-system check. Recommended tests:

These tests should be saved as a named SD test set in the project NWF file and documented in the BIM Execution Plan. The 300mm clearance tolerance on massing-to-grid is intentionally generous — at SD, flagging anything within a foot of the column grid is useful. Tightening that tolerance produces false positives from preliminary geometry that will be resolved as the design develops.

Who attends the SD review meeting

• Project architect and/or design principal
• Structural engineer of record (or principal in charge)
• MEP lead (even if MEP model doesn't yet exist — they need to validate zone reservations)
• BIM coordinator (runs the session)
• Project manager (for decision authority on program elements)

Subcontractors are not involved at SD. Trade leads are not involved. Owner's representative attendance is optional and often useful if program changes are on the table.

What to add and what to drop compared to a blank-slate setup

Add: Shared coordinate verification as a pre-check before every SD review. Coordinate misalignment between structural and architectural models is the single most common source of false positives at SD, and it is fast to fix if caught early. Make coordinate verification the first item on every SD coordination meeting agenda.

Drop: Any clearance testing on MEP branch distribution, any penetration checking, any testing against placeholder geometry explicitly flagged as "TBD" in model parameters.

Design Development: weekly reviews with expanding test coverage

What DD models look like

Design Development is where BIM coordination earns its budget. By mid-DD, structural models are at LOD 300 — primary and secondary framing, concrete structure, shear walls, stair structures, major openings. Architectural models have resolved floor-to-floor heights, ceiling grid zones, shaft locations, and primary wall assemblies. MEP models have primary distribution: main duct runs, primary piping headers, major electrical conduit and equipment rough-ins.

This is the phase where the structural steel beam that the HVAC main will eventually need to penetrate first becomes visible in the model. This is where the electrical switchgear room that is two inches too shallow for the specified gear first shows up. This is where the mechanical shaft that the structural engineer sized for gravity loads but not for the duct size the MEP engineer requires becomes a documented problem rather than an assumption.

Recommended cadence: weekly

Weekly reviews during DD are the industry standard for good reason. The design team is advancing detailed geometry at a rate where a two-week gap between reviews allows conflicts to compound. An unresolved beam-duct clash discovered in week one of DD may be the root cause of three downstream coordination decisions that will be wrong — decisions about penetration strategies, routing paths, and equipment placement — if it is not resolved before those decisions are made.

The weekly rhythm should be disciplined:

• Model submissions locked by Wednesday noon (or project-specific equivalent mid-week deadline)
• BIM coordinator runs detection and groups results Wednesday afternoon through Thursday
• Report distributed Thursday end of day with preliminary issue assignments
• Coordination meeting held Tuesday of the following week (allowing designers the long weekend to review assignments before the meeting)

This is not a rigid prescription but a structural principle: the coordinator needs at minimum 48 hours between model lock and meeting to produce a report worth discussing.

DD test suite expansion

The DD test suite builds on the SD baseline and adds system-specific tests as models populate with detail. A mature mid-DD test suite typically contains twelve to eighteen tests:

The key discipline at DD is progressive test activation: don't activate a test until both model elements it references exist at sufficient LOD to generate meaningful results. A "piping vs. electrical conduit" test activated when the piping model contains primary headers and the electrical model contains wire routing (rather than conduit) produces a false-positive-heavy report. Activate the test when both sides are at LOD 300.

Managing the growing issue backlog

By mid-DD, an active coordination program will have accumulated a backlog of open issues from multiple review cycles. Managing this backlog is as important as running new tests. The Navisworks status lifecycle — New → Active → Reviewed → Approved → Resolved — only produces value if status changes are systematically updated after each model submission.

The coordinator's pre-meeting workflow should include:

1. Open the prior week's NWF
2. Load updated discipline models
3. Note which previously "Active" clashes no longer appear (resolution confirmed by geometry change)
4. Note which previously "Resolved" clashes have reappeared (regression, requires re-assignment)
5. Run new tests and identify net-new "New" clashes
6. Group and prioritize before report distribution

The Autodesk BIM Collaborate / ACC platform extends this workflow into cloud-based issue tracking, with the Issues tool aggregating clashes from Navisworks, Model Coordination, and Autodesk Docs into a single dashboard. This becomes increasingly valuable in DD when multiple discipline leads are resolving issues independently and the coordinator needs visibility across the full backlog without being a bottleneck.

Who attends the DD review meeting

• BIM coordinator (facilitation and screen control)
• Structural engineer's BIM lead or structural coordinator
• MEP coordinator (representing mechanical, electrical, plumbing — or separate leads for each on large projects)
• Architectural BIM lead
• Project manager (for schedule/scope decisions)

The "two pizza rule" applies with discipline at DD. Inviting all disciplines to every weekly meeting produces meetings where half the attendees are idle for most of the agenda. A better structure is a full-team meeting every other week, with discipline-specific sub-meetings in the intervening week to handle trade-specific issues that don't require full-team visibility.

LOD and clash validity

A practical consideration that coordination leads often understate: the LOD of model elements determines whether a clash result is a real design decision or a modeling artifact. The BIMForum LOD Specification (maintained by AGC/BIMForum, with the 2025 update published December 2026) defines LOD 350 as the coordination-ready LOD — elements include connections, interfaces, and supports necessary for inter-trade coordination. A clash between a LOD 200 duct placeholder and a LOD 350 structural beam is not a design conflict; it is a modeling status mismatch.

Build LOD expectations into the test suite configuration. Document in the BIM Execution Plan that Navisworks clash tests will be considered valid only against elements at the target LOD for the current phase. Review the LOD matrix at the start of every DD review cycle to confirm which models are still below target LOD before running tests against them.

Construction Documents: weekly reviews plus a mandatory pre-issuance gate

What CD models look like

By the start of Construction Documents, the coordination baseline should be clean: major structural-MEP conflicts resolved, primary routing paths established, equipment clearances confirmed. The CD phase is where that baseline is held while every discipline advances to LOD 350–400 detailing: penetration schedules, hanger attachment points, access panel locations, embedded structural elements, electrical panel schedules tied to physical spaces.

This is also where CD models are most vulnerable to regression. The structural engineer detailing a concrete slab may advance the slab edge condition in a way that re-introduces a clearance conflict with a previously resolved MEP run. The MEP engineer adding drain piping to a restroom group may route a branch that conflicts with a structural beam the mechanical model didn't previously include. New clashes introduced in the CD phase are, on average, more consequential than DD clashes because the design is more constrained: there are fewer remaining resolution paths.

Recommended cadence: weekly reviews

The weekly CD review follows the same model-lock / coordinator-review / report-distribution / meeting cadence as DD but with narrower test scope and tighter status discipline.

Test suites at CD should be fully expanded but increasingly targeted to areas of active detailing. If the structural detailing sprint is focused on the north tower floors 8–14, the coordination tests for that week should include location filters that focus on those floors. Running the full building test suite against partially updated models generates noise: clashes in the south tower where the model hasn't moved since last week appear as "New" because the search sets changed slightly.

A mature CD test suite will include:

The pre-issuance gate: mandatory, not optional

The most important cadence-related practice in the entire project lifecycle is the pre-issuance clash gate for Construction Documents packages. This is a deliberate, full-scope review run specifically before any CD set is issued — 50%, 90%, 100% issue for permit, and issued for construction.

The gate is not a routine weekly review. It is a formal checkpoint with defined acceptance criteria:

• Zero "New" or "Active" critical-priority clashes
• All "Approved" exceptions formally documented with the responsible party's acknowledgment
• All "Resolved" clashes validated by geometry confirmation in the submitted model (not just status change)
• Report archived as a dated NWD snapshot in the CDE alongside the issued document set

Why this matters: documents issued with unresolved coordination clashes become change orders. The Schnackel Engineers field documentation on pre-bid clash resolution is illustrative — teams that resolve clashes before document issuance substantially reduce post-bid change orders because contractors cannot bid unknown coordination risks into their proposals. More importantly, the design team retains control of resolution paths rather than ceding that authority to subcontractors making field coordination decisions under schedule pressure.

The gate also protects against the specific CD failure mode of last-minute scope changes. Engineering coordination reviews often produce changes in the final days before issuance. Those changes frequently introduce new clashes in areas the team was not actively monitoring. A gate that runs fresh detection on the actual issued files — not the working files from the prior weekly review — catches these late-entry clashes before they leave the design team's control.

Pre-issuance gate workflow

Step 1 — Model freeze Declare a model freeze at least five working days before the target issuance date. No new geometry changes after freeze without coordinator approval.

Step 2 — Full test suite run BIM coordinator runs the complete CD test suite against the frozen models. Export results as both HTML (for distribution) and XML (for archive).

Step 3 — Critical clash review Any clash rated critical or major receives same-day review by the responsible discipline lead. No issuance if unresolved critical clashes exist.

Step 4 — Approved exceptions documentation Clashes that cannot be resolved before issuance (typically LOD-dependent items that will be addressed by contractor shop drawings) are documented in an Exceptions Log with owner/PM sign-off.

Step 5 — NWD snapshot archive Publish a dated NWD snapshot from the NWF. Archive in CDE alongside the issued document set. This snapshot is the coordination baseline for Construction Administration.

Step 6 — Issue for construction with coordination confirmation Issuance transmittal notes the pre-issuance gate date, the archived clash report reference, and the number of open approved exceptions.

Who attends the CD review meeting

The CD meeting attendee list narrows compared to DD. Decisions at CD level require technical authority, not broad participation.

• BIM coordinator
• Structural detailing lead
• MEP coordination lead (internal or hired coordinator)
• Architectural BIM lead
• Any specialty discipline actively detailing (fire protection, low-voltage, acoustics if modeled)

The project architect and structural EOR attend the monthly gate meeting and any session involving structural modifications, not every weekly review.

Construction: trigger-based reviews on model update

What changes in the construction phase

The shift from Construction Documents to Construction Administration changes the coordination dynamic fundamentally. The construction model is no longer the source from which documents are produced — it is the record of what is being installed. The primary model users are now trade contractors submitting shop drawings, the general contractor coordinating logistics, and the BIM coordinator validating that submitted shop drawings match the coordinated model.

Clash detection in construction is not a design activity. It is a verification activity. The question is no longer "what should this system look like?" but "does the proposed installation, as represented in the updated model, create conflicts with work already installed or already committed?"

This distinction drives the cadence change: in construction, clash reviews are triggered by model updates, not by calendar intervals. When the mechanical contractor submits an updated model reflecting approved shop drawings, run the detection. When the structural contractor updates embedded conduit locations after field verification, run the detection. The review happens because new information has entered the model, not because the calendar says it is Tuesday.

Recommended cadence: on model update, with a minimum bi-weekly floor

In practice, "run detection on model update" requires a defined update submission schedule to be actionable. A model that is updated continuously or without schedule is not a model the coordinator can run disciplined detection against. The BIM Execution Plan should define:

• A required model submission schedule by trade (typically aligned with look-ahead schedules: two-week lookahead zone submissions, for example)
• Maximum acceptable gap between submissions for active zones: typically bi-weekly
• Notification requirement: trades notify the BIM coordinator when submitting updated models, specifying what changed

With this structure, the coordination workflow becomes:

1. Trade submits updated model for active zone
2. BIM coordinator runs zone-filtered clash tests within 24 hours
3. New clashes go directly to the submitting trade and any affected trades as BCF issues
4. Resolution within one look-ahead cycle or escalation to the general contractor

The BCF (BIM Collaboration Format) workflow is particularly valuable in construction-phase coordination. Rather than distributing PDF clash reports that are disconnected from the model, BCF issues delivered directly to the trade's modeling environment (Revit, Tekla, Trimble Connect) place the issue in spatial context. The trade can navigate to the clash location, review the issue, and push a resolution directly back without leaving their modeling tool.

Platforms like BIMcollab NEXUS and BIM Track implement the full BCF lifecycle — open, in progress, closed — with notifications to all assigned parties when status changes. For construction teams managing hundreds of active issues across multiple zones, this is a practical necessity rather than a convenience.

Construction test suite configuration

The construction test suite is narrower than the CD test suite but more granular in the zones under active installation.

The standard approach is zone-based test activation: run full test suites on zones where installation is active in the current look-ahead window. Zones completed and accepted move to a "closed" test configuration that only checks for regression against the accepted baseline. Zones not yet in the look-ahead window are checked at a monthly frequency for sequence planning, not weekly.

This zone stratification prevents the construction-phase equivalent of the SD noise problem: running tests on ten floors of building when only three floors are active generates seven floors of phantom clashes against work that isn't imminent.

Who attends the construction review meeting

Construction coordination meetings are trade-level, not design-team meetings. Attendees:

• BIM coordinator (or VDC coordinator hired by the GC)
• General contractor's field superintendent for the active zone
• Trade foremen for active systems in the zone
• MEP coordination subcontractor (if one is engaged)

Design team members (architect, structural EOR, MEP engineer of record) attend only when a resolution requires a design change — which should be rare if the CD-phase coordination was done correctly.

Implementing the cadence

Federation architecture and NWF/NWD snapshot discipline

The Revit–Navisworks pipeline begins with discipline model exports. Each discipline publishes a .NWC cache file from their native Revit model. The NWC is a compressed geometry representation that Navisworks reads without requiring the source Revit file.

The master coordination file is an NWF — a Navisworks project file that links NWC files without containing their geometry. When the NWF is opened, it reloads all linked NWCs from their last-saved state. If a discipline has published a new NWC, opening the NWF reflects the updated geometry automatically. This architecture is the basis for the coordination rhythm: disciplines publish NWCs on the model submission deadline, the coordinator opens the NWF the next morning, and detection runs against current geometry.

The NWD format serves a different purpose. An NWD is a self-contained snapshot that packages all referenced geometry into a single file. It cannot be updated; it represents the model as of the moment it was published. NWDs are used for:

• Pre-issuance gate archives (dated snapshots alongside issued documents)
• Distribution to stakeholders who need the Navisworks Freedom free viewer
• Audit records of coordination state at project milestones

A mature federation management practice publishes a dated NWD at the end of each weekly review cycle, named with the project identifier and date: PROJ-001_Federated_2026-06-02.nwd. These NWDs are stored in the CDE in a versioned coordination folder. If a dispute arises about what the model showed on the date a document was issued, the NWD provides the evidentiary record.

Clash test configuration as reusable XML

Navisworks Manage allows clash tests to be exported as XML and re-imported into new project NWF files. This is the mechanism for building organization-level clash test templates that embed institutional knowledge — tested search set definitions, validated tolerances, naming conventions — into a reusable starting point.

The export/import architecture requires that test definitions reference search sets by name, not by file selection. This means the search sets must be defined first, and must use consistent naming conventions across projects for the template to transfer correctly.

A minimum viable clash test configuration for a DD-phase coordination file:

<?xml version="1.0" encoding="UTF-8"?>
{/*
  Navisworks Clash Test Configuration Template
  Phase: Design Development
  Version: 2.1
  Maintained by: BIM Coordination Team
  Last updated: 2026-06-02
 
  Search set naming convention:
    [DISCIPLINE]-[SYSTEM]-[LOD]-[NOTES]
  Clash test naming convention:
    [SETA_DISCIPLINE] vs [SETB_DISCIPLINE] · [ZONE] · [TYPE]
*/}
<ClashTests>
 
  {/* ============================================================
       PRIORITY 1: STRUCTURE vs. PRIMARY MEP DISTRIBUTION
       Critical for DD phase: run every review cycle
       ============================================================ */}
  <ClashTest
    name="STR-primary vs HVAC-mains · ALL · Hard"
    status="new"
    type="hard"
    tolerance="0.0"
    merge="true"
    mergeOnRename="false"
    checkElementsWithCoincidentSnapPoints="true">
    <Left>
      <SelectionSource selection="STR-PrimaryFraming-LOD300" />
    </Left>
    <Right>
      <SelectionSource selection="HVAC-PrimaryDucts-LOD300" />
    </Right>
    <Rules>
      {/* Exclude same-discipline items to prevent self-clash */}
      <ExcludeSameDiscipline value="true" />
      {/* Exclude items sharing a Revit host (embedded elements) */}
      <ExcludeItemsWithSameCompositeParent value="true" />
    </Rules>
  </ClashTest>
 
  <ClashTest
    name="STR-primary vs PIPE-mains · ALL · Hard"
    status="new"
    type="hard"
    tolerance="0.0"
    merge="true"
    mergeOnRename="false"
    checkElementsWithCoincidentSnapPoints="true">
    <Left>
      <SelectionSource selection="STR-PrimaryFraming-LOD300" />
    </Left>
    <Right>
      <SelectionSource selection="PIPE-PrimaryHeaders-LOD300" />
    </Right>
    <Rules>
      <ExcludeSameDiscipline value="true" />
      <ExcludeItemsWithSameCompositeParent value="true" />
    </Rules>
  </ClashTest>
 
  <ClashTest
    name="STR-primary vs ELEC-conduit-mains · ALL · Hard"
    status="new"
    type="hard"
    tolerance="0.0"
    merge="true"
    mergeOnRename="false">
    <Left>
      <SelectionSource selection="STR-PrimaryFraming-LOD300" />
    </Left>
    <Right>
      <SelectionSource selection="ELEC-PrimaryConduit-LOD300" />
    </Right>
    <Rules>
      <ExcludeSameDiscipline value="true" />
    </Rules>
  </ClashTest>
 
  {/* ============================================================
       PRIORITY 2: MEP CROSS-DISCIPLINE
       Activate when both sides are at LOD 300
       ============================================================ */}
  <ClashTest
    name="HVAC-mains vs PIPE-mains · ALL · Hard"
    status="new"
    type="hard"
    tolerance="0.0"
    merge="true">
    <Left>
      <SelectionSource selection="HVAC-PrimaryDucts-LOD300" />
    </Left>
    <Right>
      <SelectionSource selection="PIPE-PrimaryHeaders-LOD300" />
    </Right>
    <Rules>
      <ExcludeSameDiscipline value="true" />
      <ExcludeItemsWithSameCompositeParent value="true" />
    </Rules>
  </ClashTest>
 
  <ClashTest
    name="HVAC-mains vs ELEC-conduit-mains · ALL · Hard"
    status="new"
    type="hard"
    tolerance="0.0"
    merge="true">
    <Left>
      <SelectionSource selection="HVAC-PrimaryDucts-LOD300" />
    </Left>
    <Right>
      <SelectionSource selection="ELEC-PrimaryConduit-LOD300" />
    </Right>
    <Rules>
      <ExcludeSameDiscipline value="true" />
    </Rules>
  </ClashTest>
 
  {/* ============================================================
       PRIORITY 3: CLEARANCE TESTS ON PRIMARY SYSTEMS
       50mm clearance on HVAC mains; 75mm on primary piping
       Adjust per project MEP engineer's requirements
       ============================================================ */}
  <ClashTest
    name="HVAC-mains vs STR-primary · ALL · Clearance-50mm"
    status="new"
    type="clearance"
    tolerance="0.050"
    merge="true">
    <Left>
      <SelectionSource selection="HVAC-PrimaryDucts-LOD300" />
    </Left>
    <Right>
      <SelectionSource selection="STR-PrimaryFraming-LOD300" />
    </Right>
    <Rules>
      <ExcludeSameDiscipline value="true" />
    </Rules>
  </ClashTest>
 
  <ClashTest
    name="PIPE-mains vs STR-primary · ALL · Clearance-75mm"
    status="new"
    type="clearance"
    tolerance="0.075"
    merge="true">
    <Left>
      <SelectionSource selection="PIPE-PrimaryHeaders-LOD300" />
    </Left>
    <Right>
      <SelectionSource selection="STR-PrimaryFraming-LOD300" />
    </Right>
    <Rules>
      <ExcludeSameDiscipline value="true" />
    </Rules>
  </ClashTest>
 
</ClashTests>

BCF issue distribution and lifecycle

BCF (BIM Collaboration Format), maintained as an open standard by buildingSMART International, is the mechanism for distributing clash-derived issues back to discipline authoring tools without PDF round-trips. A BCF file packages:

• A topic/issue identifier and title
• A camera viewpoint in IFC coordinates (allowing any BCF-capable tool to navigate to the exact clash location)
• A PNG snapshot of the clash viewpoint
• Status, assigned party, due date, and comment thread
• References to the specific IFC elements involved (by GUID)

The BCF workflow in Navisworks: after grouping and reviewing clash results in Clash Detective, export selected clashes as BCF files. The receiving party (typically the discipline responsible for resolution) opens the BCF in their authoring tool's BCF manager plugin — available natively in Revit via ACC integration, or via third-party plugins for Tekla, ARCHICAD, and others. The plugin navigates to the clash location in the model, allowing the designer to make the fix in context.

A sample BCF issue markup file illustrates the structure:

<?xml version="1.0" encoding="UTF-8"?>
{/*
  BCF Issue Markup — BIM Collaboration Format 3.0
  Standard: buildingSMART International BCF-XML Schema
  Exported from: Navisworks Manage 2025
  Project: Sample Commercial Project
  Export date: 2026-06-02
*/}
<Markup>
 
  {/* Issue header */}
  <Topic
    Guid="7c4f3a2b-e591-4d8c-a3f1-bc9e2d147f30"
    TopicType="Clash"
    TopicStatus="Active"
    Priority="Critical">
 
    <Title>STR beam (W18x97) intersects HVAC supply main — Level 08 Grid C-D/4-5</Title>
 
    <Description>
      Hard clash: HVAC supply duct (24x20 in, insulated) intersects W18x97 beam
      web at column line C.5, Level 08 — approximately 1,200mm from east face of
      core. Interference depth 180mm. Resolution required before slab pour at
      this level. Options: (1) structural web penetration with sleeve and
      reinforcement per SE approval; (2) reroute duct above beam with revised
      plenum clearance coordination; (3) revise duct size with mechanical engineer
      approval.
    </Description>
 
    <AssignedTo>[email protected]</AssignedTo>
    <CreationDate>2026-06-02T08:30:00Z</CreationDate>
    <CreationAuthor>[email protected]</CreationAuthor>
    <ModifiedDate>2026-06-02T08:30:00Z</ModifiedDate>
    <DueDate>2026-06-09T17:00:00Z</DueDate>
 
    {/* Viewpoint for spatial navigation */}
    <Viewpoints>
      <ViewPoint Guid="a1b2c3d4-e5f6-7890-abcd-ef1234567890">
        <Snapshot>snapshot_clash_01.png</Snapshot>
        <PerspectiveCamera>
          <CameraViewPoint>
            <X>45231.5</X>
            <Y>12840.2</Y>
            <Z>32400.0</Z>
          </CameraViewPoint>
          <CameraDirection>
            <X>-0.707</X>
            <Y>-0.500</Y>
            <Z>-0.500</Z>
          </CameraDirection>
          <CameraUpVector>
            <X>0.0</X>
            <Y>0.0</Y>
            <Z>1.0</Z>
          </CameraUpVector>
          <FieldOfView>60.0</FieldOfView>
        </PerspectiveCamera>
 
        {/* IFC element references for navigation in authoring tool */}
        <Components>
          <Component IfcGuid="2O2Fr$t4X7Zf8NOew3FLOH">
            <OriginatingSystem>Autodesk Revit 2025</OriginatingSystem>
            <AuthoringToolId>Revit_STR_Beam_W18x97_L08_C5</AuthoringToolId>
          </Component>
          <Component IfcGuid="3Zr7iXq2b8CvL4GPwq1KRT">
            <OriginatingSystem>Autodesk Revit 2025</OriginatingSystem>
            <AuthoringToolId>Revit_HVAC_SupplyDuct_24x20_L08_Main</AuthoringToolId>
          </Component>
        </Components>
      </ViewPoint>
    </Viewpoints>
 
    {/* Comment thread — append as resolution progresses */}
    <Comment Guid="d4e5f6a7-b8c9-0123-4567-890abcdef012">
      <Date>2026-06-02T08:30:00Z</Date>
      <Author>[email protected]</Author>
      <Comment>
        Clash detected in weekly coordination review — Week 24.
        Assigned to MEP coordinator for resolution proposal.
        Structural EOR to be consulted for web penetration option.
        Due before Level 08 pour, targeted June 9.
      </Comment>
    </Comment>
 
  </Topic>
 
</Markup>

Issue lifecycle discipline

The issue lifecycle — Open → Assigned → In Progress → Resolved → Verified — only produces audit value if transitions are documented with model evidence, not just status clicks. The practical standard:

• Resolved means the discipline has updated their model to eliminate the clash geometry. It does not mean they intend to update it.
• Verified means the BIM coordinator has confirmed the geometry change in the updated model by re-running the specific clash test and confirming the issue no longer appears as "New" or "Active."

The distinction matters for the pre-issuance gate. A gate that counts "Resolved" clashes without verifying them in updated model geometry is not a gate — it is a status audit. The gate that counts only "Verified" clashes provides actual quality assurance.

Automation and continuous coordination in ACC

Autodesk BIM Collaborate Pro (part of Autodesk Construction Cloud) offers a Model Coordination module that automates several steps of the Navisworks manual workflow:

• Clash tests run automatically against models uploaded to designated coordination spaces
• Issue creation from clashes requires batch processing via the interface, with each issue linked to its spatial location
• Issues from Navisworks and Model Coordination are aggregated in a single Issues dashboard
• Clash test configurations (content, tolerance, grouping rules) can be saved and reused, eliminating repetitive setup

The ACC automation does not replace the BIM coordinator's grouping, prioritization, and triage workflow. It accelerates the detection and distribution steps so the coordinator's time is spent on analysis and facilitation rather than running tests and exporting reports. The cadence recommendations in this guide apply equally to manual Navisworks workflows and ACC-automated workflows: the question of how frequently to run detection and how to distribute results is a coordination design problem, not a platform capability problem.

Cadence calendar: a YAML specification

The following cadence calendar can be used as a starting point for BIM Execution Plan documentation or project management tool configuration:

# BIM Clash Review Cadence Calendar
# Version: 1.0
# Reference: BIM Execution Plan, Section 4.3 — Coordination Schedule
# Phase definitions: AIA B101 Basic Services (SD / DD / CD / CA)
# RIBA equivalences: Stage 2 (SD) / Stage 3 (DD-early) / Stage 4 (CD) / Stage 5 (CA)
 
project:
  name: "Sample Project"
  bep_version: "1.2"
  coordination_lead: "BIM Coordinator"
  cde_platform: "Autodesk Construction Cloud"
 
phases:
 
  schematic_design:
    aia_phase: "Schematic Design"
    riba_equivalent: "Stage 2 — Concept Design"
    typical_duration_weeks: 8
    cadence:
      trigger: "milestone OR max_interval"
      max_interval_days: 14
      model_submission_deadline: "milestone_minus_3_days"
      coordinator_review_period_days: 2
      report_distribution: "coordinator_review_complete"
      meeting_day: "report_plus_2_days"
    test_suite:
      active_tests:
        - "STR-primary vs ARCH-floor-plates · Hard"
        - "STR-foundation vs SITE-below-grade · Hard"
        - "ARCH-massing vs STR-grid · Clearance-300mm"
      deactivated_tests:
        - "all_MEP_branch_tests"
        - "penetration_schedule_tests"
    attendees:
      required:
        - project_architect
        - structural_EOR_or_lead
        - MEP_lead_for_zone_validation
        - bim_coordinator
        - project_manager
      optional:
        - owners_representative
    deliverables:
      - type: "HTML clash report"
        archive: false
      - type: "NWD snapshot"
        archive: true
        naming: "{PROJECT_ID}_SD_{DATE}.nwd"
 
  design_development:
    aia_phase: "Design Development"
    riba_equivalent: "Stage 3 — Spatial Coordination (early DD) through Stage 4 start (late DD)"
    typical_duration_weeks: 10
    cadence:
      trigger: "weekly"
      model_submission_deadline: "Wednesday_1200"
      coordinator_review_period_days: 2  # Wed PM through Thu
      report_distribution: "Thursday_EOD"
      meeting_day: "Tuesday_following_week"
      full_team_meeting_frequency: "bi-weekly"
      sub_meeting_frequency: "bi-weekly_alternating"
    test_suite:
      progressive_activation: true  # activate tests as models reach target LOD
      active_at_dd_start:
        - "STR-primary vs HVAC-mains · Hard"
        - "STR-primary vs PIPE-mains · Hard"
        - "STR-primary vs ELEC-conduit-mains · Hard"
        - "ARCH-ceilings vs STR-primary · Clearance-150mm"
      activate_at_lod300_confirmation:
        - "HVAC-mains vs PIPE-mains · Hard"
        - "HVAC-mains vs ELEC-conduit-mains · Hard"
        - "PIPE-mains vs ELEC-conduit-mains · Hard"
        - "MECH-equipment vs ARCH-walls · Clearance-150mm"
      activate_at_mid_dd:
        - "HVAC-mains vs STR-primary · Clearance-50mm"
        - "PIPE-mains vs STR-primary · Clearance-75mm"
    issue_status_requirements:
      pre_meeting: "All 'New' clashes grouped and assigned; false positives marked 'Approved'"
      post_meeting: "All discussed clashes updated to 'Active' with responsible party assigned"
      end_of_week: "All 'Resolved' clashes verified by geometry check in updated model"
    deliverables:
      - type: "HTML clash report grouped by system"
        distribution: "all_discipline_leads"
        advance_hours: 48
      - type: "NWD snapshot"
        archive: true
        naming: "{PROJECT_ID}_DD_W{WEEK}_{DATE}.nwd"
      - type: "BCF export"
        per_discipline: true
        tool: "Navisworks Manage BCF export"
 
  construction_documents:
    aia_phase: "Construction Documents"
    riba_equivalent: "Stage 4 — Technical Design"
    typical_duration_weeks: 12
    cadence:
      trigger: "weekly"
      model_submission_deadline: "Wednesday_0900"  # earlier than DD for tighter gate prep
      coordinator_review_period_days: 2
      report_distribution: "Thursday_noon"
      meeting_day: "Monday_following_week"
    pre_issuance_gate:
      trigger: "5_working_days_before_issuance"
      required_for_all_issues:
        - "50_percent_CD"
        - "90_percent_CD"
        - "100_percent_permit_set"
        - "issued_for_construction"
      acceptance_criteria:
        zero_new_critical_clashes: true
        zero_active_critical_clashes: true
        all_resolved_verified_by_geometry: true
        exceptions_log_signed_off: true
      deliverables:
        - type: "Formal clash gate report (HTML + XML)"
          archive: true
          naming: "{PROJECT_ID}_CD_GATE_{ISSUANCE_DATE}"
        - type: "NWD snapshot — issued for construction baseline"
          archive: true
          naming: "{PROJECT_ID}_IFC_BASELINE_{DATE}.nwd"
        - type: "Exceptions log"
          format: "PDF"
          signatories: ["project_manager", "owner_representative"]
    test_suite:
      expansion_from_dd: true
      added_tests:
        - "STR-secondary vs HVAC-branch · Hard"
        - "STR-secondary vs PIPE-branch · Hard"
        - "ARCH-ceilings vs HVAC-branch · Clearance-25mm"
        - "FP-sprinklers vs ARCH-ceilings · Hard"
        - "FP-piping vs STR-all · Hard"
        - "ELEC-conduit-branch vs all · Hard"
        - "ARCH-access-panels vs HVAC-all · Clearance-600mm"
      location_filtering: true  # filter by floor/zone for active detailing areas
 
  construction_administration:
    aia_phase: "Construction Administration"
    riba_equivalent: "Stage 5 — Manufacturing and Construction"
    cadence:
      trigger: "on_model_update"
      minimum_interval_days: 14  # floor: no zone goes unreviewed for more than 2 weeks
      model_submission_schedule: "aligned_with_lookahead_schedule"
      coordinator_review_turnaround_hours: 24
      report_distribution: "immediate_BCF_to_affected_trades"
    zone_stratification:
      active_zone:
        detection_frequency: "on_update"
        test_depth: "full_suite_zone_filtered"
      committed_not_installed:
        detection_frequency: "bi_weekly"
        test_depth: "primary_tests_only"
      completed_and_accepted:
        detection_frequency: "monthly"
        test_depth: "regression_only"  # verify no changes to accepted work
    attendees:
      weekly_coordination_meeting:
        - gc_field_superintendent
        - active_trade_foremen
        - vdc_bim_coordinator
      design_team_involvement: "as_needed_for_design_changes_only"
    deliverables:
      - type: "BCF issues per affected trade"
        tool: "BIMcollab / BIM Track / ACC Issues"
        turnaround_hours: 24
      - type: "Weekly coordination status report"
        format: "dashboard_export"
        audience: "PM_and_owner"

Anti-patterns

Anti-pattern 1: daily clash reviews during Schematic Design

The team that runs daily clash detection during SD is usually trying to do the right thing — stay on top of a fast-moving design — but achieves the opposite. SD-phase models change every day because that is what SD is for. Running daily detection against geometry that is still in active design produces a daily report with high false-positive rates (placeholder geometry generating hundreds of hits) and zero actionable clashes because the discipline responsible for resolution is in the middle of the design iteration that will render the clash obsolete.

After two weeks, the team has learned that clash reports are background noise. That learning persists into DD and CD, when the reports contain real problems. The coordinator who cried wolf during SD has no credibility left when the structural-MEP primary conflict appears in week six of DD.

Correct approach: Hold SD reviews to bi-weekly milestone windows. Declare a design freeze before each review. Communicate the freeze to all disciplines 48 hours in advance. A single three-hour review on stable geometry outperforms twenty daily reviews on unstable geometry.

Anti-pattern 2: monthly clash reviews during Construction Documents

The mirror failure. CD models advance daily, with each discipline independently detailing their systems based on assumptions about what adjacent disciplines are doing. In a month without coordination review, a mechanical engineering detailing sprint, a structural drawing set advance, and a plumbing coordination update can each independently introduce five to fifteen new clashes. Discovered together in a month-end review, those clashes are queued behind each other for resolution, and any that involve multiple disciplines require multiple revision cycles that may not clear before the next issuance milestone.

The compound effect: a team running monthly CD reviews typically enters the 90% issue with an unresolved backlog of thirty to fifty clashes that should have been caught and closed in the previous six weeks. Resolving fifty clashes in the two weeks before the 90% issue is not a coordination program. It is a fire drill.

Correct approach: Weekly CD reviews, full stop. If the project schedule or team capacity cannot support weekly reviews, the alternative is to narrow the test suite to only the highest-priority systems and accept that lower-priority clashes will be caught later. Reducing frequency is never the right tradeoff; it compounds the problem it is trying to solve.

Anti-pattern 3: no pre-issuance gate

Document sets issued without a pre-issuance clash gate carry an unquantified coordination liability into the bidding and construction phases. Contractors bidding on uncoordinated sets apply risk contingencies to their bids. After award, unresolved clashes become change orders that redistribute project risk in ways the original contract didn't contemplate.

The objection to the pre-issuance gate is usually time: the design team is already under pressure, and a gate that requires five additional working days before issuance feels like a schedule hit. This objection miscounts the trade. Five days of gate review versus four to six weeks of post-bid RFI resolution and change order negotiation is not a close comparison.

Correct approach: Budget the gate into the CD schedule from the start. Five working days of model freeze and coordinator review time is a standard deliverable, the same as a specification review or a code compliance check. It belongs in the schedule the way those milestones belong in the schedule.

Anti-pattern 4: single-discipline reviews on multi-discipline federations

A BIM coordinator running a clash review between the architectural model and the structural model, and distributing results only to those two disciplines, without including the MEP leads in the distribution or the meeting, misses an entire class of consequential clashes. The architectural ceiling grid change that resolves an architectural-structural clash may simultaneously introduce a new HVAC clearance violation. Without MEP present to catch the cascade, the resolution creates a downstream problem that won't surface until MEP reviews their model in a separate session.

This failure mode is especially common on large projects where coordination is organized by discipline pair rather than by federated model. The discipline-pair approach produces locally consistent coordination decisions that are globally inconsistent.

Correct approach: Run all coordination reviews on the full federated model. Distribute reports to all affected disciplines simultaneously, not sequentially. Use the issue assignment system (in ACC, BIMcollab, or Navisworks) to route specific clashes to the responsible party without preventing others from seeing them.

Anti-pattern 5: treating "Resolved" as the goal metric

The coordination dashboard that shows "total resolved clashes this month" is measuring the wrong thing. Resolved count is a lagging indicator of past problems. It tells you nothing about the current quality of the coordinated model.

The meaningful metric is critical open clashes at each phase milestone. Zero critical open clashes before the 90% CD issue is a meaningful quality indicator. Three hundred resolved clashes in the same period says nothing about the state of the remaining open issues.

Secondary metrics worth tracking alongside critical open clashes: the regression rate (previously Resolved clashes that reappear as New after model updates, a signal of coordination discipline breakdown), and the pre-meeting grouping ratio (what fraction of raw detected clashes were grouped into distinct issues before the meeting, a signal of coordinator quality).

Case studies

Case study 1: Mid-rise commercial office, design-build delivery

Project context: Twelve-story commercial office building, 180,000 sq ft, design-build delivery with early trade involvement. General contractor engaged a VDC coordinator. Structural steel and primary MEP trades were contracted at 35% DD.

The coordination problem: The design team was running weekly DD reviews, but the GC's trade coordination runs were happening in parallel, on a different NWF file, with different search set definitions. By the time the CD phase started, there were two competing coordination records — one from the design team's coordination process and one from the trade VDC coordinator — that disagreed on which clashes were resolved and which were open. The pre-issuance gate for the permit set revealed 94 clashes classified as "Resolved" in the design team's file that were still "Active" in the trade coordination file.

Root cause: Two separate coordination workflows running at different frequencies (design team: weekly; trades: bi-weekly) on different federation files, with no synchronization mechanism.

Resolution pattern: The VDC coordinator established a single NWF file hosted in ACC Model Coordination as the coordination master. Design team and trade NWC updates both fed into the same federation. The two coordination programs merged into a single weekly review with a combined meeting that included the design team BIM leads and the trade VDC coordinators. Review frequency remained weekly through CD. The permit set gate was clean.

Lesson: On design-build projects where trades are engaged during DD, the coordination program must have a single master federation file and a single coordination record from the start. Two coordination programs running at different cadences on different files will always diverge.

Case study 2: Hospital expansion, traditional delivery

Project context: 280,000 sq ft hospital expansion, eight floors above grade, two basement levels. Complex MEP due to infection control and medical gas requirements. Traditional design-bid-build delivery. A&E team ran BIM coordination using Navisworks Manage with Revit-originated models.

The coordination problem: The team correctly ran weekly DD coordination reviews but used an SD-era test suite without updating it for DD-phase LOD. The search sets still referenced "MEP zones" from the SD model rather than the actual LOD 300 duct and pipe geometry that had been modeled in DD. As a result, a critical coordination zone — the mechanical penthouse to main distribution corridor — had no active clash tests targeting the actual MEP geometry being modeled. The test suite was running, reports were being generated, and nobody noticed that the most complex coordination zone in the building was not being tested.

The problem surfaced at the 90% CD gate: 47 critical clashes in the mechanical corridor, all of them between the primary distribution ductwork and the structural transfer beams at the penthouse-to-floor-8 transition. Eight of those clashes required structural modifications.

Root cause: SD-to-DD test suite evolution was not completed. The search sets were not updated when MEP models advanced from zone placeholders to LOD 300 geometry.

Resolution pattern: All 47 clashes were resolved before the IFC set through a six-week accelerated coordination sprint. The structural modifications required engineer of record review and two addenda to the permit documents. Total coordination delay: four weeks to the IFC date.

Lesson: The test suite must evolve with model LOD. Assign the search set update as a deliverable at each phase transition — specifically, at the DD kickoff and at the CD kickoff — and include LOD verification as a pre-meeting check. A test suite that was valid at SD is not valid at DD.

Case study 3: Data center fit-out, fast-track delivery

Project context: 45,000 sq ft data center fit-out with 22-week design-to-substantial-completion schedule. Fast-track delivery meant CD and construction phases overlapped: bidding and early procurement happened while CD was still in progress.

The coordination problem: The condensed schedule made a sequential design-then-coordinate approach impossible. The team needed a coordination program that could run during active construction without a clean CD baseline. There was no pre-issuance gate in the original schedule.

Solution pattern: The coordination program was restructured around zone delivery milestones rather than document issuance milestones. The building was divided into eight coordination zones corresponding to the construction sequence. Each zone had its own mini-CD cycle: design advance to LOD 350 for the zone, pre-zone-release gate (same as a pre-issuance gate but scoped to the zone), then construction release for that zone while design continued on the next zone.

Reviews ran bi-weekly on non-released zones (design-in-progress) and weekly on zones approaching their release gate. The BIM coordinator maintained a zone-keyed test suite in the NWF, activating full-suite testing for zones within two weeks of release and reduced-scope testing for zones still in early design.

Results: Six of eight zones released with zero critical open clashes at their zone gate. Two zones required minor schedule extensions (three days each) to resolve structural-MEP conflicts discovered at the gate. Zero field coordination conflicts after zone release.

Lesson: On fast-track projects, the pre-issuance gate logic can be applied to zone release milestones rather than document package milestones. The gate principle — a deliberate, acceptance-criteria-based check before construction begins in an area — is more important than the specific organizational unit it applies to.

Case study 4: Coordination fatigue recovery on a university science building

Project context: 120,000 sq ft university research building, complex lab MEP. The BIM coordinator ran weekly clash detection from SD through mid-DD, distributing raw Navisworks HTML reports without grouping or triage.

The problem: By week twelve of DD, the report contained 1,847 line-item clashes. The MEP coordinator's summary response to the weekly report was "we'll clean it up before the 90%." The structural team had stopped opening the reports. The weekly coordination meeting was attended by two people — the BIM coordinator and one architectural intern.

This is the textbook coordination fatigue pattern: too-frequent reports on too-early models, without grouping or triage, producing a backlog the team rationally concluded was impossible to process.

Recovery process:

1. The BIM coordinator ran a triage session with the MEP engineer and structural team to classify all 1,847 line items. Result: 340 actual coordination issues; the remaining 1,507 were false positives from unfinished model elements, overlapping design options, and tolerance misconfiguration.
2. The test suite was reconfigured with corrected search sets and adjusted tolerances. The next week's report contained 214 clashes.
3. Those 214 were grouped into 41 distinct coordination issues by system and location.
4. Weekly meetings resumed with a revised format: agenda built from the 41 grouped issues, with preliminary assignments distributed 48 hours before the meeting.
5. Within four weeks, the active issue backlog was below 20.

Lesson: Coordination fatigue is recoverable, but it requires a deliberate reset: a triage session to separate real issues from noise, test suite reconfiguration to reduce future noise, and a structured grouping workflow before every report distribution. The recovery cost (two weeks of intensive coordinator effort) was significant but far less than the alternative of carrying the fatigue into CD.

Limits and caveats

When cadence recommendations break down

The framework presented in this guide assumes a reasonably well-organized BIM execution program: models in a shared CDE, search sets configured before detection runs, LOD tracked against the BEP, and discipline leads who respond to issue assignments. When these preconditions are missing, cadence optimization is a second-order problem.

If models are not consistently published to a known location on a known schedule, no coordination cadence can function reliably. The first fix on a dysfunctional coordination program is nearly always model submission discipline, not review frequency. A team that publishes models on an agreed schedule at agreed LOD, running monthly reviews with thoughtful triage, will outperform a team running daily detection on chaotic model submissions.

Coordination detection is not coordination resolution

Every practitioner knows this, but it bears explicit statement: no Navisworks configuration, no review cadence, no BCF workflow resolves a clash. Humans resolve clashes. Tools make the detection and tracking efficient. A sophisticated coordination program with engaged discipline leads resolving issues between review cycles outperforms any technically sophisticated program with passive leads who only respond in meetings.

The cadence framework is a tool for structuring the human coordination process, not a substitute for it. A BIM Execution Plan that specifies weekly DD reviews without specifying who has resolution authority for cross-discipline clashes, what the escalation path is when a lead is unresponsive, and what "Resolved" means in terms of geometry change is a document that describes a process without actually creating one.

Model-based coordination does not replace constructibility review

Clash detection identifies geometric conflicts. It does not identify:

• Installation sequence conflicts (something that can be built but cannot be built in the specified order)
• Accessibility conflicts (something that can be built but cannot be maintained)
• Tolerance stack-ups (something that is clean in the model but conflict-prone in the field due to cumulative installation tolerances)
• Specification conflicts (systems that do not clash geometrically but are incompatible in operation)

A complete coordination program includes constructibility review alongside clash detection. Field-experienced trade leads reviewing the model for sequencing and installation-method conflicts add a layer that no clash detection tool can replicate.

Platform matters less than process

The recommendations in this guide are documented against the Navisworks Manage + Revit + ACC stack because that is the most common enterprise coordination pipeline in the market. The underlying principles — test suite precision, phase-appropriate cadence, pre-issuance gates, BCF-based issue lifecycle — apply equally to Solibri, Revizto, BIMcollab NEXUS, Trimble Connect, or any other coordination platform with clash detection and issue tracking capability. Changing platforms does not change the cadence problem.

Sources and further reading

The research and recommendations in this guide draw on the following primary sources. All URLs were verified accessible at the time of publication.

Official documentation

Navisworks Clash Detective — Autodesk Help 2024 The official Autodesk documentation covering Clash Detective workflow steps, clash test configuration, status lifecycle (New / Active / Reviewed / Approved / Resolved), and result management. https://help.autodesk.com/view/NAV/2024/ENU/?guid=GUID-69869C23-A4A9-4FB0-A4F8-7E1E4F3A7970

BIMForum LOD Specification 2025 The AGC/BIMForum Level of Development Specification, including LOD 350 definition for coordination-ready model elements. The 2025 edition defines element-level LOD requirements across structural, architectural, and MEP disciplines, including the coordination threshold that determines when models are valid inputs for clash detection. https://bimforum.global/wp-content/uploads/dae-uploads/BIMForum-Global_2025_LOD_ENG_2025-12-26_final.pdf

BCF Standard — buildingSMART International The BIM Collaboration Format standard specification maintained by buildingSMART International, including the BCF-XML schema and BCF REST API for issue management. Version 3.0 is the current release. https://technical.buildingsmart.org/standards/bcf/

Platform and tool documentation

Autodesk BIM Collaborate: Issue Management in Coordination Workflows (IMAGINiT) Practical documentation on how issue management works across Model Coordination, Navisworks, and Autodesk Docs in the ACC platform, including the centralized Issues dashboard behavior. https://resources.imaginit.com/building-solutions-blog/autodesk-bim-collaborate-issue-management-in-coordination-workflows

BIMcollab: Clash Detection vs Issue Management Practitioner guide distinguishing the geometric detection step from the human resolution process, with workflow state definitions and integration guidance. https://www.bimcollab.com/en/resources/blog/clash-detection-vs-issue-management/

Practitioner guides

Beyond the Report: A Guide to Navisworks Clash Detection That Protects Margins (BIMHeroes) Field guide covering test suite configuration, grouping strategy, coordination meeting design, and the signal-to-noise economics of clash management. The risk-filtering philosophy articulated here is among the best practitioner-level framing available. https://bimheroes.com/navisworks-clash-detection/

50 Tips for Better BIM Coordination Meetings (GlobaleTraining) Comprehensive practitioner guide to coordination meeting structure, frequency, attendee management, agenda design, and technology optimization. The two-pizza rule and pre-meeting preparation cycle documented here reflect accumulated field experience. https://www.globaletraining.ca/50-tips-for-better-bim-coordination-meetings-the-definitive-list/

Navisworks Clash Detective: The Complete Field Guide (Atelier 7 Studio) Detailed field guide covering clash type definitions, status lifecycle, test configuration parameters, naming conventions, and export formats. https://www.atelier7arch.com/2026/04/navisworks-clash-detective-complete.html

Five Common Mistakes New BIM Coordinators Make (BIM Corner) Practitioner-oriented review of coordination setup failures including search set configuration, issue prioritization, reporting tool selection, and meeting facilitation. https://bimcorner.com/five-common-mistakes-new-bim-coordinators-make-and-how-to-avoid-them/

The Advantages of Pre-Bid Clash Resolution (Schnackel Engineers) Field documentation on the pre-issuance / pre-bid gate concept, including cost and schedule impact analysis of resolving clashes before versus after document issuance. https://schnackel.com/blogs/the-advantages-of-pre-bid-clash-resolution

Clash Detection and Coordination in Large-Scale MEP Projects (TAAL Tech) Case-based analysis of MEP coordination workflows including hospital project clash resolution documentation and ROI analysis. https://www.taaltech.com/clash-detection-and-coordination-in-large-scale-mep-projects/

Navisworks Clash Deep Dive: Configuration (GlobalCAD) Technical deep dive on Navisworks clash test configuration parameters, naming conventions, tolerance settings, and XML export/import workflow. https://globalcad.co.uk/navisworks-clash-deep-dive-1-configuration/