Clash Detection in BIM Projects: Types of Interference, Process, and Limitations

Understand what Clash Detection is, the types of interference, how to configure tests, manage issues, and why collision detection does not replace design coordination.

Check it out!

Clash Detection is the automated or semi-automated process of comparing elements from three-dimensional models to identify collisions, overlaps, clearance violations, and other predefined interferences. In BIM projects, it makes it possible to locate conflicts among architecture, structure, building systems, infrastructure, and other systems before these problems reach construction.

Detection alone, however, does not resolve design coordination. The software flags occurrences according to the models, selections, rules, and tolerances configured; the technical team needs to interpret each result, eliminate false positives, group repeated occurrences, assign responsibility, assess impacts, and verify the correction in subsequent revisions.

For this reason, the value of Clash Detection lies not in the number of collisions generated, but in the ability to transform geometric results into traceable technical decisions. A poorly configured process can produce thousands of irrelevant records. A well-governed process focuses analysis on critical interfaces and reduces rework, improvisation, delays, and implementation risks.

In this article, the term is addressed in the context of engineering and BIM projects. The focus is not on a specific tool, but on the method used to prepare models, configure tests, classify interferences, manage occurrences, and integrate detection into the broader coordination process.

What is Clash Detection in BIM projects

Clash Detection, or interference detection, is the computational analysis of the spatial relationship between sets of elements from one or more models. The tool checks whether objects intersect or violate configured geometric conditions such as minimum distances, maintenance envelopes, and safety zones.

The analysis can be performed in a federated model, which brings disciplinary models together without removing each designer’s authorship. Architecture, structural, electrical, plumbing, HVAC, fire protection, automation, electronic security, telecommunications, and other disciplines remain separate but are viewed and compared together.

The typical result is a list of occurrences associated with elements, location, visualization, source test, and status. Depending on the platform, each occurrence may receive comments, priority, assignee, due date, image, viewpoint, classification, and treatment history.

Hard clash: physical collision

A hard clash occurs when two geometries occupy the same space. Examples include:

HVAC duct passing through a beam;
cable tray crossing piping;
luminaire overlapping a sprinkler;
conduit passing through equipment;
camera embedded in a structural element;
electrical panel occupying an area intended for a door;
piping penetrating a shaft outside the planned opening.

It is the most obvious type, but not every intersection is an error. Elements that are intended to connect, penetrate, or overlap may generate legitimate collisions. The test therefore needs to correctly define which sets will be compared and which exceptions should be considered.

Soft clash: insufficient clearance or spacing

A soft clash occurs when elements do not intersect but violate a minimum distance. The rule may represent:

maintenance space;
door and panel opening zones;
electrical safety distance;
separation between power and telecommunications;
distance from heat sources;
space for removing filters, modules, or batteries;
equipment rotation or movement area;
access envelope for personnel and tools.

This type requires a technically defined tolerance. An arbitrary distance produces meaningless results. The value should come from a requirement, standard, manufacturer, maintenance procedure, owner criterion, or risk analysis.

Duplicate or internal-overlap clash

Models may also contain duplicated objects, overlapping elements, or repeated geometries. These errors can distort quantities, exports, analyses, and coordination.

The occurrence may arise within the same discipline, not only between disciplines. For this reason, auditing should include internal tests where there is a duplication risk, especially after copies, links, imports, or model consolidation.

Temporal or 4D clash

When models are linked to the schedule, analysis can check interferences over time. Examples include:

two work fronts occupying the same area simultaneously;
lifting equipment crossing a work zone;
installation planned before access is released;
temporary structure incompatible with permanent installation;
transport route blocked by a concurrent activity;
maintenance planned during unavailability of a redundant system.

Temporal clash is not limited to final geometry. It analyzes intermediate states, methods, temporary equipment, and implementation sequence.

Rule-based checking is not always Clash Detection

Not every automated check is a collision. Tools may verify parameters, properties, classification, dimensions, slope, accessibility, data completeness, or compliance with requirements. These analyses are complementary but should be correctly identified.

It is important to distinguish:

Check	Main question	Example
Hard clash	do two elements occupy the same space?	cable tray passes through a beam
Soft clash	has the minimum clearance been respected?	panel without maintenance area
Duplication	are there repeated objects?	two pieces of equipment at the same point
Information rule	are properties and data correct?	equipment without code or power rating
Functional check	does the system meet the requirement?	does the camera provide adequate coverage?
Coordination	are disciplines and decisions coordinated?	are power, network, support, and access integrated?

Clash Detection is not design coordination

BIM Design Coordination uses interference detection as one of its tools, but its scope is broader. It addresses physical, functional, documentary, regulatory, constructability, and operational interfaces.

Clash Detection can indicate that a cable tray passes through a duct. It does not automatically decide:

which discipline should change the route;
which system has technical priority;
whether capacity exists on another route;
whether the change affects load, voltage drop, or length;
whether the new route respects maintenance and separation requirements;
whether the change modifies quantities, budget, or schedule;
which documents need revision;
who approves the final solution.

These decisions belong to coordination and design integration. Likewise, Design Review in Engineering Projects analyzes requirements, calculations, documents, risks, and maturity beyond geometry.

Detecting collisions does not mean the design is coordinated. Software locates geometric occurrences; the engineering team must decide priorities, responsibilities, impacts, and affected documents to transform each result into a coordinated solution.

Learn about the Design Coordination and Integration service

Why the raw number of clashes can be misleading

A federated model can return hundreds or thousands of collisions. That number alone does not represent design quality or the actual number of problems.

A single cause can generate dozens of records. A duct passing through a sequence of elements may appear as several collisions. Composite objects may produce one occurrence for each component. Simplified geometries, inappropriate tolerances, and reference elements can also artificially increase the list.

False positives

False positives are results that mathematically satisfy the rule but do not represent a technical problem. Examples include:

intended connection between pipe and equipment;
conduit embedded in a wall;
support associated with the supported element;
insulation modeled over its own piping;
structural opening created for a penetration;
intentional overlap in a finish element;
reserve geometry or auxiliary construction geometry.

The team should establish filters and exclusion criteria without hiding real problems.

Repeated results

Nearby occurrences may represent the same cause. Grouping by room, system, primary element, discipline, zone, or decision reduces noise and makes assignment easier.

Grouping should not erase traceability. The consolidated occurrence must preserve which elements, locations, and results were included.

Inappropriate tolerance

Zero tolerance can generate conflicts caused by numerical precision, coincident surfaces, or small deviations with no construction relevance. Excessive tolerance can hide important interferences.

The configuration should consider:

model units and precision;
design phase;
discipline;
construction method;
element size;
required clearances;
installation allowance;
available level of information.

Immature or unsuitable model

Clash Detection does not fix an incomplete, outdated, or poorly coordinated model. If critical elements have not been modeled, there will be no collision to detect. If the geometry is merely symbolic, the result may be misleading.

Common omissions include supports, accessories, access zones, openings, insulation, slope, temporary equipment, maintenance envelopes, and existing elements.

The correct indicator is not only “remaining clashes”

More useful indicators include:

open critical occurrences;
closure rate per cycle;
recurrence after correction;
average response time;
occurrences by discipline and interface;
percentage of false positives;
accepted conflicts with justification;
field problems that should have been detected;
model stability between cycles.

How to prepare models for Clash Detection

Running tests before auditing the models usually produces unreliable results. Preparation needs to ensure that files can be federated, compared, and traced.

Define the coordination scope

The plan should indicate:

participating disciplines;
areas, floors, and zones;
versions and cut-off dates;
exchange formats;
included and excluded elements;
required level of information;
tolerances;
system priorities;
responsible parties;
analysis cycles;
closure criteria.

Not every element needs to be compared with every other element. The test matrix should reflect real interfaces.

Check coordinates and references

Models need to share origin, orientation, levels, floors, units, and coordinate system. Small misalignments can generate widespread collisions or hide conflicts.

The audit should verify:

base point and origin;
north and rotation;
elevations and levels;
units;
georeferencing, where applicable;
link positioning;
transformation of imported files;
consistency among model, survey, and reality.

Control versions

A federation containing different revisions produces decisions about configurations that do not exist. Each file should have a code, discipline, revision, date, status, and responsible party.

Models released for coordination should be separated from working files. The process needs to prevent a test from combining updated architecture with an old structural model or building systems that have not yet been issued.

Check integrity and quality

Before testing, it is advisable to analyze:

duplicated elements;
corrupted geometries;
objects outside the project area;
incorrect categories;
missing properties;
overly detailed elements;
broken links;
unclassified objects;
inconsistent names and codes;
unidentified temporary elements.

Define the required level of information

Modeling everything at maximum detail is not a requirement for good coordination. The model needs to contain enough information for the decision required at that phase.

In Conceptual Design, volumes, spaces, and main routes may be sufficient. In Basic Design, equipment, shafts, routes, and critical interfaces should appear. In Detailed Design, geometry and information are expected to be compatible with procurement, fabrication, installation, and maintenance.

Insufficient detail hides conflicts. Excessive detail increases processing, noise, and cost without proportional benefit.

Prepare selection sets

Robust tests should use sets based on properties, classifications, and systems, avoiding fragile manual selections.

Examples:

all structural beams;
ducts above a specified cross-section;
power cable trays;
fire-protection piping;
equipment requiring front access;
panel doors;
telecommunications cables or trays;
elements by floor or zone.

Reusable sets make it easier to repeat tests in new revisions.

Result quality begins before the test is run. Coordinates, revisions, classification, level of information, and selection sets need to be consistent; otherwise, the software merely automates problems already present in the received models.

Explore the BIM Design Coordination process in more depth

How to build a Clash Detection matrix

The matrix defines which sets will be compared, why the test exists, which tolerance should be used, and who is responsible for the interface.

Test	Set A	Set B	Type	Objective
CD-01	structure	HVAC ducts	hard	avoid unplanned penetrations
CD-02	structure	cable trays	hard	check routes and openings
CD-03	plumbing	electrical	hard	eliminate incompatible crossings
CD-04	electrical panels	front clearance envelope	soft	ensure operation and maintenance
CD-05	luminaires	sprinklers	soft	preserve installation and performance
CD-06	doors	equipment and furniture	soft	check opening and circulation
CD-07	telecom trays	power	soft	check defined separation
CD-08	equipment	removal routes	soft	ensure future replacement
CD-09	disciplinary models	duplicated elements	duplicate	control overlaps
CD-10	work fronts	temporary areas and equipment	temporal	avoid sequence conflicts

Prioritize critical interfaces

The matrix should not begin with every possible combination. Prioritize interfaces that may affect:

safety;
structure;
operational continuity;
critical systems;
spaces that are difficult to modify;
long-lead equipment;
main routes;
maintenance;
procurement milestones;
release of work fronts.

Define tolerances by purpose

The same tolerance does not work for every test. The value should consider size, risk, and field-adjustment capability.

There may be:

geometric detection tolerance;
minimum installation clearance;
maintenance envelope;
safety zone;
separation distance;
expansion allowance;
fabrication and installation margin.

The matrix should record the source of the criterion.

Avoid tests without an owner

Each test needs a technical owner. Responsibility may belong to coordination, a lead discipline, or the person responsible for the interface. Without an owner, the occurrence remains only software data.

Clash Detection process step by step

1. Define the objective and decision criterion

The cycle should begin with a concrete question. Examples:

release shafts and technical rooms;
validate main routes;
freeze structural openings;
release the model for estimating;
prepare Detailed Design;
review vendor documentation;
confirm readiness to begin installation.

The purpose determines the models, tests, tolerances, and severity.

2. Receive and audit the models

The team checks versions, coordinates, integrity, classification, completeness, and compliance with exchange requirements. Inadequate files should be returned or recorded with a limitation.

3. Federate the models

Federation brings the disciplines together for joint analysis. The process needs to preserve authorship, codes, revisions, and file structure.

The federated model does not replace authoring models. It is a coordination environment.

4. Configure and run the tests

Tests should use defined sets, documented rules, and justified tolerances. It is advisable to record the matrix version, date, tool, analyzed models, and person responsible for execution.

5. Perform technical triage

Triage removes or classifies:

false positives;
accepted occurrences;
duplicates;
records from the same root cause;
problems outside scope;
critical conflicts;
conflicts requiring a decision.

This step should not be delegated only to the tool operator. It requires knowledge of the disciplines and the project.

6. Group occurrences

Grouping may be performed by:

room;
floor;
shaft;
system;
primary element;
responsible discipline;
common cause;
expected solution;
construction work front.

A group should represent a manageable technical decision.

7. Create and assign issues

Each issue needs enough information to be understood without depending on an informal meeting.

Recommended fields:

Field	Content
Identifier	unique code
Source test	rule that generated the occurrence
Location	floor, room, grid, or coordinate
Elements	IDs and disciplines involved
Viewpoint	reproducible view
Description	problem and expected effect
Severity	critical, high, medium, or low
Priority	treatment order
Assignee	author of the correction or decision
Due date	response and closure date
Status	new, active, responded, approved, resolved, or closed
Evidence	revision or document proving the solution

BIM Collaboration Format can transfer issues among tools without transferring the entire model again.

8. Analyze the cause and decide the solution

The response should not simply be “move the element.” Requirements, system hierarchy, capacity, space, access, cost, schedule, and documentation impact need to be evaluated.

Possible treatments include:

change the route;
change elevation;
resize the shaft;
create an opening;
revise equipment;
change the support;
coordinate sequence;
accept the conflict with justification;
modify a requirement;
request additional information.

9. Update the authoring models

The correction should occur in the responsible model. Changing only the federated model or marking the occurrence as resolved without revising the source breaks traceability.

Associated documents may also need revision: drawings, technical memoranda, lists, quantities, specifications, calculations, and schedules.

10. Rerun the tests

In the new revision, tests are repeated. The team checks whether:

the conflict disappeared;
the solution did not create a new problem;
the documents are consistent;
the interface was effectively closed;
the analyzed configuration corresponds to the issued revision.

11. Close with evidence

An occurrence should be closed when the solution has been incorporated and verified. A text response without the corresponding revision is not sufficient evidence.

Accepted clashes need to record justification, authority, and condition. A conflict may be technically acceptable, but it should not simply disappear from the list.

A responded issue is not a closed issue. Closure requires the revision to be incorporated, the test rerun, and the evidence verified. When the solution changes requirements, contracts, equipment, or the baseline, the change also needs to be formally controlled.

See how Design Review controls comments, evidence, and gate decisions

How to classify severity, priority, and status

Severity represents technical impact. Priority represents treatment order. The concepts are not identical.

Severity	Characterization	Typical effect
Critical	safety risk, infeasibility, structural conflict, or blockage of an essential system	prevents progress
High	significant change to route, space, equipment, or interface	requires a decision before the next milestone
Medium	localized adjustment with manageable impact	correct in the current cycle
Low	minor inconsistency without systemic effect	may be handled in a later revision
Observation	improvement or question without a confirmed conflict	evaluate and document

Priority may increase when there is a long-lead item, a work front about to be released, a difficult-access area, or a decision affecting several disciplines.

Recommended status flow

A workflow may use:

new: identified in the current cycle;
active: confirmed and awaiting treatment;
under analysis: depends on a decision or information;
responded: responsible party submitted a disposition;
approved: solution accepted for implementation;
resolved: the test no longer finds the interference;
closed: evidence and documents have been verified;
accepted: conflict remains with formal justification;
reopened: solution was insufficient or created a new inconsistency.

The tool may use different terminology. What matters is defining the meaning and transition criteria.

BCF, CDE, ENGiOS, and traceability

BCF for issue communication

BCF makes it possible to record location, elements, visualization, comments, and data for an occurrence linked to the model. It reduces dependence on disconnected screenshots and spreadsheets.

The format does not replace the governance process. The team still needs to define classification, assignees, deadlines, status, approvals, and closure rules.

Common Data Environment

The CDE organizes publication, sharing, review, approval, and history of information containers. It should distinguish work-in-progress, shared, published, and archived files according to the adopted process.

Federation should use models authorized for coordination. The presence of a file in the repository does not mean it has been released.

ENGiOS as a governance layer

ENGiOS can control documents, revisions, issuances, responsible parties, comments, approvals, deliverables, evidence, and indicators. In an integrated workflow, model occurrences can be associated with documents, decisions, contracts, and project milestones.

This layer is especially useful when the problem does not end in the model. An interference may require revision of a technical memorandum, owner approval, contract change, different procurement, or an As-Built update.

NetBox as infrastructure context

In network and Data Center projects, NetBox can provide data on sites, racks, devices, interfaces, circuits, cables, power, and addressing. It does not perform Clash Detection, but it helps validate whether the coordinated solution is consistent with the existing logical and physical infrastructure.

A geometrically clear route may be associated with a rack that lacks capacity, a nonexistent port, an unavailable circuit, or an incompatible topology. Integrating the model with a source of truth improves decision quality.

The model should not be the only source for decisions. BCF and the CDE organize communication, ENGiOS controls documents and approvals, and NetBox adds context from the installed infrastructure. Integration reduces decisions based on isolated files.

Learn about ENGiOS for technical governance of projects and documents

Examples of Clash Detection in engineering systems

Electrical systems

Tests can compare cable trays, ladder trays, busways, conduits, panels, luminaires, and equipment against structure, architecture, plumbing, and HVAC.

In addition to hard clashes, envelopes should be modeled or checked for door opening, breaker removal, ventilation, front and side access, and circuit segregation.

Structured cabling and telecommunications

Telecommunications routes may conflict with power, HVAC, piping, ceilings, structure, and fire-protection systems. Detection helps verify pathways, crossings, and spatial occupancy.

It does not by itself confirm maximum link length, rack capacity, bend radius, performance, certification, or topology. These aspects require Design Review and specific analysis.

CCTV

Geometry can identify a camera embedded in a structural element, an incompatible support, or a conflicting infrastructure route.

It does not automatically detect coverage, pixel density, lighting, backlight, dynamic occlusion, retention, bandwidth, or cybersecurity. A camera with no clash may still be technically poorly positioned.

Access control

Readers, locks, controllers, boxes, conduits, doors, and opening envelopes can be assessed.

Coordination needs to include hardware, emergency conditions, fire protection, egress routes, power supply, logic, and integration with other systems.

Lightning protection and grounding

Air terminals, conductors, down conductors, electrodes, and connections can be coordinated with architecture, structure, roof systems, electrical systems, and equipment.

The absence of a clash does not prove risk analysis, separation distance, equipotential bonding, continuity, or surge protective device selection.

Data Centers

Clash Detection is relevant for cable trays, busways, ducts, piping, racks, containment systems, equipment, floors, ceilings, and maintenance routes.

In critical environments, redundancy, route separation, concurrent maintainability, expansion, and replacement should be considered. Two routes may not collide and still share the same physical risk.

Retrofit and existing installations

Models can be compared with point clouds or as-built surveys. This helps detect incompatibilities between the design and actual conditions.

Reliability depends on survey quality, records of hidden areas, and updates reflecting changes made in the field.

What Clash Detection cannot guarantee

The tool does not, by itself, guarantee:

compliance with functional requirements;
full standards compliance;
correct calculations;
system capacity;
performance;
electrical selectivity or protection;
CCTV coverage;
automation logic;
cybersecurity;
accessibility;
complete constructability;
implementation sequence;
operation and maintenance;
contractual compatibility;
updating of all documents;
owner acceptance.

These topics need to be integrated with Design Review, Constructability analysis, Value Engineering, and change governance.

Clash Detection across project phases

Conceptual Design

The analysis may use volumes, zones, and main routes to avoid infeasible layouts. The objective is not to find details, but to protect critical spaces and interfaces.

Basic Design and FEED

Layouts, shafts, rooms, main equipment, routes, openings, access, and maintenance requirements should be coordinated. Structural interferences and high-impact decisions need to be resolved before detailed development.

Detailed Design

Tests become more specific. Models should reflect equipment, accessories, connections, supports, clearances, openings, levels, and interfaces required for construction.

A clash-free model should not automatically be considered “released for construction.” Release also depends on documents, calculations, approvals, procurement, and contractual criteria.

Procurement and vendor documents

Vendor models and drawings may change dimensions, weights, access requirements, connection points, and other requirements. Coordination needs to incorporate this data before fabrication or installation.

Construction and commissioning

Field changes should return to the process. Otherwise, the coordinated model no longer represents the actual installation.

The final update needs to feed As-Built documentation, operations, maintenance, and asset management.

A clash-free model does not equal a released design. The decision to advance needs to consider calculations, documents, requirements, procurement, constructability, risks, and constraints in addition to the status of geometric interferences.

Understand how Owner’s Engineering supports review, coordination, and acceptance

Deliverables from a Clash Detection process

The scope may include:

coordination plan;
information requirements;
list of models and revisions;
model audit report;
federated model;
test matrix;
rules and tolerances;
occurrence register;
BCF files;
viewpoints and images;
reports by discipline, area, and severity;
coordination meeting minutes;
responsibility matrix;
open-items dashboard;
cycle closure report;
list of accepted conflicts;
readiness assessment for the next milestone.

The deliverable should not be merely a spreadsheet with thousands of rows. It needs to support decisions and demonstrate what was analyzed, corrected, accepted, and remains open.

Indicators for monitoring coordination

Possible indicators include:

Indicator	Purpose
new occurrences per cycle	measure model stability
open critical occurrences	control advancement risk
closure rate	monitor discipline response
average resolution time	identify bottlenecks
recurrence	assess correction quality
false positives	review test configuration
issues without an owner	verify governance
accepted conflicts	control exceptions
occurrences by interface	identify higher-risk areas
problems discovered in the field	assess process effectiveness

Purely quantitative targets can encourage improper closure. Solution quality should prevail over artificially reducing the number of records.

Common errors

running tests before auditing the models;
using inconsistent coordinates;
comparing different revisions;
testing every discipline against every other discipline;
applying a single tolerance;
treating every result as a real problem;
deleting false positives without recording an exclusion rule;
failing to group repeated occurrences;
assigning issues without explaining the required decision;
treating clashes as the exclusive responsibility of the BIM Manager;
closing an occurrence based only on a text response;
correcting only the federated model;
failing to revise associated drawings and technical memoranda;
ignoring maintenance envelopes;
limiting analysis to hard clashes;
considering a clash-free model to be an approved design;
failing to incorporate vendor data;
failing to update the As-Built.

Checklist for releasing a Clash Detection cycle

[ ] objective and decision milestone are defined;
[ ] models and revisions have been identified;
[ ] coordinates, units, and levels have been audited;
[ ] level of information is appropriate for the phase;
[ ] test matrix has been approved;
[ ] tolerances have justification;
[ ] selection sets are reproducible;
[ ] false positives have been handled by rule;
[ ] repeated occurrences have been grouped;
[ ] issues have an assignee and due date;
[ ] critical conflicts have been resolved or conditionally accepted;
[ ] corrections have been incorporated into authoring models;
[ ] affected documents have been updated;
[ ] tests have been rerun;
[ ] evidence has been verified;
[ ] accepted conflicts have justification;
[ ] cycle closure report has been issued;
[ ] released models correspond to the revisions analyzed.

Clash Detection is a powerful tool for anticipating interferences, but its results depend on model quality, test configuration, and the governance applied to occurrences. When integrated with design coordination, Design Review, constructability, and change control, it stops being a simple collision count and begins supporting reliable technical decisions throughout the project.

Technical references

[1] AUTODESK. Clash Detective tool overview. Autodesk Help.

[2] BUILDINGSMART INTERNATIONAL. BIM Collaboration Format (BCF).

[3] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 19650-1:2018 — Information management using building information modelling — Concepts and principles.

[4] ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. ABNT NBR ISO 19650 — Organization and digitization of information about buildings and civil engineering works, including building information modelling.

[5] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 7817-1:2024 — Building information modelling — Level of information need — Part 1: Concepts and principles.

Frequently asked questions

What is Clash Detection?

It is the automated or semi-automated analysis of three-dimensional models to identify collisions, overlaps, clearance violations, and other interferences defined by rules.

Is Clash Detection the same as design coordination?

No. Clash Detection identifies geometric occurrences according to configured rules. Design coordination interprets the results, coordinates disciplines, resolves interfaces, and updates documents and decisions.

What are the main types of clash?

The main types are hard clash, when geometries intersect; soft clash, when a minimum clearance is violated; duplications; and temporal clashes associated with the implementation sequence.

Is a clash-free model approved for construction?

No. The absence of collisions does not demonstrate requirements, calculations, performance, standards compliance, constructability, documentation, or owner acceptance.

What is a false positive in Clash Detection?

It is an occurrence that mathematically satisfies the rule but does not represent a technical problem, such as an intended connection, an embedded element, or an intentional overlap.

How should a test tolerance be defined?

The tolerance should consider purpose, phase, discipline, construction method, model precision, installation clearances, maintenance, safety, and applicable requirements.

What is BCF used for?

BCF enables exchange of model-linked issues, including elements, location, viewpoints, comments, assignees, and status, without transferring the entire BIM model again.

Who should resolve clashes?

Coordination manages the process, but the solution depends on designers and the people responsible for the disciplines and interfaces. The BIM Manager or tool operator should not make technical changes alone.