Test the interfaces that can fail.

We turn coordination requirements into repeatable clash rules. Every test has a purpose, a tolerance and a defined pair of model elements.

Pressing run is not a clash strategy.

Clash detection tests examine specific relationships between model elements. Hard tests identify physical intersections, soft tests protect access and clearance zones, and workflow or 4D tests expose conflicts created by installation sequence, temporary works or construction access.

Without a defined matrix, software can produce an impressive result count with little coordination value. Default tolerances may flag insulation overlaps as major issues while missing the maintenance space needed to remove a valve or install a façade panel.

CNE develops the test structure around design intent, buildability and package responsibility. We document the rulesets, run them against the approved federation baseline and preserve the settings so every later cycle can be compared consistently.

Rules built around real interfaces

01
Clash matrix

Discipline and system pairs are mapped to named tests, priorities, owners and planned coordination stages.

02
Hard clash rules

Physical intersections between structure, architecture, building services and other packages are tested with appropriate tolerances.

03
Clearance tests

Access zones, maintenance envelopes, headroom, code clearances and installation allowances are checked as measurable spaces.

04
Workflow and 4D tests

Construction sequence, temporary access and installation order are reviewed where programme logic affects whether work is buildable.

05
Ruleset register

Search sets, exclusions, tolerances and model revisions are recorded so results can be reproduced and audited.

06
Initial test output

Raw findings are issued with test references and viewpoints, ready for structured review, filtering and prioritisation.

Navisworks ManageSolibriBCFIFC4D BIMLOD 100–500

Every rule has an engineering reason.

Tolerances matched to the interface

We set thresholds according to system behaviour and construction need, not one global distance for the entire project.

Clear ownership boundaries

The matrix shows which packages are being tested and who must participate when an interface fails.

Repeatable cycle data

Stable named rules let the team measure closure and detect regressions without changing the test halfway through.

Build a matrix that finds what matters.

Tell us which disciplines, systems and construction stages need coordination. We will define focused tests that expose genuine design and workflow conflicts.