Why it matters
The review question keeps the coordination decision in human hands and gives classification and the clash matrix distinct jobs: first define the boundary, then test the relationships that matter inside it.
Section 1
A federated model contains more than one coordination question
A railway-station federation can contain track, platforms, structural frames, drainage, cable routes, technical equipment, and temporary works in the same spatial context. That does not mean every package belongs in every clash run.
Suppose the current question is whether cable routes pass through the platform structural zone. The relevant evidence sits at the interface between platform structure, cable trays, service routes, and selected equipment. Filling the report with track-to-drainage or temporary-works intersections does not make that review more rigorous. It makes the decision harder to see.
A useful workflow therefore runs in this order: review question, classification and scope, clash matrix, then actionable issues. The question establishes why the check exists before the software decides how to execute it.
Section 2
A preset remembers settings, not intent
A saved clash preset can remember model groups, tolerances, rules, filters, and exclusions. Reusing those settings can be efficient when the original review purpose is still valid.
What the preset cannot know is whether those settings answer today’s design question. A matrix prepared for an earlier exchange may include packages that are now stable, omit a newly critical interface, or use tolerances that belong to a different review stage. The run can be technically correct and still be operationally useless.
Loading a preset should therefore be a confirmation step, not the starting point. The team must first confirm that the saved logic still represents the decision it is expected to support.
Section 3
Start by defining the review question
Before opening the clash command, the coordinator should write the question in terms the design team can answer. “Run the station clash matrix” is an instruction. “Are platform service routes conflicting with structural zones?” is a review question.
That distinction forces the team to state what it is trying to confirm, reject, protect, or coordinate. It also creates a practical test for every object and rule added later: does this inclusion help answer the question?
- What decision are we trying to support?
- Which systems and interfaces create actual project risk?
- Which objects should be outside this review?
- What tolerance or clash logic fits this specific question?
- What result would require assignment or design action?
Section 4
Classification turns the question into scope
Classification is the bridge between a human coordination question and a machine-executable clash scope. It converts project language into groups that can be inspected, isolated, included, or excluded consistently.
For the platform-services question, the eligible scope might contain platform structures, cable trays, service routes, and selected technical equipment. Track, drainage outside the interface zone, and temporary works can remain visible for context without automatically entering the test.
This develops the principle explained in “When classification should sit above the clash matrix in railway coordination”: the team should decide which assets belong to the review before asking the matrix to compare them.
Section 5
The clash matrix should refine the scope, not invent it
Classification determines what belongs in the review. The clash matrix determines what should be checked against what. Treating those as separate decisions is one of the simplest ways to improve a BIM clash detection workflow.
Once the classified scope is credible, the matrix can define the useful relationships inside it. Cable trays may need checking against platform beams and selected equipment clearances, while two service groups may not need a hard-clash test at all. Tolerance and clash logic should follow the interface risk and the current design decision, not a generic template.
Section 6
Fewer clashes can mean a better coordination process
The objective of BIM clash detection is not to maximize the number in the report. It is to identify issues that are relevant, understandable, assignable, and connected to a decision. A smaller targeted set can demand more discipline than a large generic run because every inclusion must be justified.
Reducing noise is not the same as hiding problems. The wider federation can still be reviewed through separate questions and controlled checks. What changes is that unrelated intersections no longer compete for attention inside one meeting, one issue set, or one BIM clash report.
This matters on infrastructure projects where repeated assets and long corridors can multiply technically correct intersections quickly. Signal quality determines whether teams investigate the result or stop trusting the report.
Section 7
Where ExyViewer fits
ExyViewer can support the workflow without replacing the coordination judgment behind it. The useful sequence begins with inspection of the IFC federation and its properties, then uses classification, visibility, and model isolation to make the intended boundary explicit.
Clash relationships are configured only after that boundary is understood. Results can then be inspected in model context so the team communicates or exports issues that have a clear reason to exist.
- Inspect the IFC federation and relevant properties
- State the coordination question
- Classify and isolate the eligible scope
- Configure the required clash relationships and tolerance
- Run the targeted check
- Inspect each result in model context
- Communicate or export only meaningful issues
Section 8
The tradeoff
Defining the review question and checking the classification scope takes more preparation than loading a saved preset. It may also expose disagreements about package ownership, tolerance, or what should count as an actionable issue.
That preparation is useful work. It reduces downstream review effort, repeated issue discussions, false-positive debates, and coordination fatigue. Presets still have value, but only when the team can state the purpose they preserve and confirm that the same purpose remains valid for the current model exchange.
Practical takeaways
- Start with a coordination question, not a clash command.
- Classification defines the review boundary.
- The clash matrix refines relationships inside that boundary.
- Test configuration should reflect project risk and the current design decision.
- A smaller targeted clash set can be more rigorous than a large generic report.
- Reuse a preset only when its original review purpose is still valid.
Reality check
- Targeted clash detection still depends on disciplined classification and agreed coordination logic.
- If coordinators define scope differently without governance, results become difficult to compare between model exchanges even when each individual run appears reasonable.
Related commands and features
Classification, Clash Detection, IFC model review, Property inspection, Visibility and model isolation
Connect clash scope to IFC model review
Use the IFC Viewer guide to connect model navigation, property inspection, classification, visibility control, and targeted checking in one review workflow.
Read the IFC Viewer guide
