01
Federation strategy
Agree what is federated, how often, on what coordinates, and who is responsible for each model. Most coordination problems are actually federation problems.
BIM coordination and clash detection services
Clash detection produces a number. Coordination produces a decision — what actually conflicts, why, whose model has to move, and evidence that it did.
Coordination
The engineering position
A clash count is not a coordination report
Eleven thousand clashes is not information. Most of it is insulation touching insulation, the same duct counted against forty hangers, and two disciplines that were never going to conflict in reality. A report nobody can act on is worse than no report, because it consumes the time that should have gone into the two hundred findings that matter. We classify by cause and by who has to move before anything is issued.
Most coordination failures are not collisions
The parts do not touch; they just cannot be installed in that order, or maintained afterwards, or reached at all. Clearance, access and installation sequence failures do not appear in a hard clash test, and on a services-dense project they outnumber true clashes. We test them as explicit rule sets, which means we have to write the rules down — and a written rule set is something a client can review and disagree with, which is the point.
The issue history is a deliverable
Why a duct moved in March is usually in someone's inbox. The next stage inherits the geometry without the reasoning and re-litigates it. Our coordination appointments produce an auditable record — finding, cause, decision, who accepted it, and the re-test that proved it closed.
Deliverables
What is actually produced and issued
Any of these can be appointed on their own or combined. Nothing here depends on buying the intelligence layer, which is not for sale in any case.
DeliverableFederated model assembly
All contributing disciplines assembled on shared coordinates, at an agreed federation frequency, with model health checked on receipt.
DeliverableClash and clearance rule sets
Written rule sets covering hard clash, clearance, maintenance access and zoning compliance — reviewable before they are run.
DeliverableClassified issue lists
Findings grouped by cause and by responsible discipline, with an element ID against each, and true clashes separated from access and clearance failures.
DeliverableResolution tracking
Issues tracked to closure with the decision and the accepting party recorded, and a re-test that evidences the close.
DeliverableCoordination reports
Per-cycle reporting on what was found, what closed, what is open and where the same cause keeps recurring.
DeliverableCoordination workshop support
Preparation, viewpoints and the evidence pack for the meeting, so the meeting resolves rather than discovers.
How it runs
The sequence, and why it is in this order
Sequence is not a formality on this kind of work. Most of the expensive rework we are asked to fix was produced by doing step four before step two.
02
Rule set definition
Write the clash, clearance, access and zoning rules down and have the project agree them before the first run.
03
Model health check
Every received model checked for coordinates, units, naming and parameter completeness before it enters the federation. A bad model in produces noise out.
04
Test and classify
Run the rule sets, then classify by cause and responsible discipline rather than presenting a raw count.
05
Resolve and record
Route findings, track decisions, record who accepted what.
06
Re-test and evidence
Close nothing without a re-test that proves it. The re-test is the deliverable, not the assertion.
What we need to start
The inputs that decide whether a start is a real start
Missing any of these is survivable. Not knowing which of them are missing is not, so we establish it at enquiry stage rather than at forty per cent.
- Discipline models from every contributing party, on agreed shared coordinates
- The BEP, or the federation and naming convention the project runs to
- Clearance, access and zoning requirements — or ours, if none are stated
- Compartment lines and ceiling zones as geometry, not as a PDF
- The issue tracking environment the project uses, if one is mandated
Automation
Where automation applies to this work
Every line carries its real status. Three of the four states on this site mean "not yet", and we use them.
AutomationRule-based clash and clearance testingLive
Hard clash, clearance, access and zoning run as defined rule sets across the federated model on every cycle.
AutomationClassification by causeLive
Findings clustered so that one template error producing two hundred findings is reported as one cause, not two hundred tickets.
AutomationModel health checking on receiptLive
Coordinates, units, naming, classification and parameter completeness tested on every incoming model.
AutomationPrioritisation and routingIn development
Severity and responsible-discipline assignment proposed automatically for engineering review. In development, used on our own delivery.
Scope boundary
What this appointment does not include
Published because a scope boundary discovered at month three is a dispute, and the same boundary stated at enquiry stage is just information.
- We do not accept responsibility for another party's design decisions; we identify, classify and track, and the originating designer resolves.
- We do not close an issue without a re-test.
- We do not report a clash count as a performance metric, and we will push back if asked to.
FAQ
Questions we are asked at enquiry stage
What is the difference between clash detection and BIM coordination?
Clash detection is a geometric test that produces findings. Coordination is the process of deciding what those findings mean, who resolves them, and evidencing that they closed. A provider selling clash detection is selling you a file. A coordination appointment is accountable for the resolved model and the issue history.
How do you avoid a report with eleven thousand meaningless clashes?
By writing the rule sets before running them, filtering by tolerance and element class, and clustering findings by cause. A recurring cause — a family with wrong insulation, a template error, a coordinate offset — is reported once with its element list, not once per element.
Do you test maintenance access as well as clashes?
Yes, as a separate rule set with its own findings, because access failures and hard clashes have different causes, different owners and different costs. On services-dense projects the access findings are usually the more valuable half.
Can you coordinate models authored by other consultants?
Yes — that is the normal case. We check each model's health on receipt and will report where an incoming model is not in a state that can be coordinated, which is information the project needs whether or not it is welcome.
Which clash workflow and tools do you use?
Navisworks for federation and clash workflows, with in-house routines for the clearance, access and zoning rule sets that a standard clash engine does not express. Where a project mandates a different environment we work in it.
Related
Where this connects
MEP engineeringThe discipline depth that makes a clearance rule set defensible.
Fire protectionThe clearest case for separating obstruction from collision.
BIM automationWhy re-checking after a change costs a fraction of the first check.
AI and automationClash intelligence, and where the engineer signs.
Data centresTolerance coordination at the highest services density we work at.