A Conceptual AI-Based Framework for Clash Triage in Building Information Modeling (BIM): Towards Automated Prioritization in Complex Construction Projects

Abstract

Effective clash management is critical to the success of complex construction projects, yet BIM coordinators face severe information overload when modern detection tools generate thousands or even millions of collision reports, making interdisciplinary coordination increasingly difficult. This article presents a conceptual framework for using AI for collision triage in a Building Information Modeling (BIM) environment. Previous approaches have focused mainly on collision detection itself and simple, rule-based prioritization, rarely exploiting the potential of Artificial Intelligence (AI) methods for post-processing of results, which constitutes the main innovation of this work. The proposed framework describes a modular system in which collision detection results and data from BIM models, schedules (4D), and cost estimates (5D) are processed by a set of AI components, offering adaptive, data-driven decision support unlike static rule-based methods. These include: a classifier that filters out irrelevant collisions (noise), algorithms that group recurring collisions into single design problems, a model that assesses the significance of collisions by determining a composite ‘AI Triage Score’ indicator, and a module that assigns responsibility to the appropriate trades and process participants. The framework leverages supervised machine learning methods (gradient boosting algorithms, selected for their effectiveness with tabular data) for noise filtering, density-based clustering (HDBSCAN, chosen for its ability to detect clusters of varying densities without predefined cluster count) for clash aggregation, and multi-criteria scoring models for priority assessment. The article also discusses a potential way to integrate the framework into the existing BIM workflow and possible scenarios for its validation based on case studies and expert evaluation. The proposed conceptual framework represents a step towards moving from manual, intuitive collision triage to a data- and AI-based approach, which can contribute to increased coordination efficiency, reduced risk of errors, and better use of design resources. As a conceptual study, the framework provides a foundation for future empirical validation and its limitations include dependency on historical training data availability and the need for calibration to project-specific contexts.

1. Introduction

1.1. Research Background

To achieve the idea of a Smart City, a certain critical mass of Building Information Modeling (BIM) models is necessary. Due to the high cost of annotation, the BIM models currently being developed are unable to feed into smart city models because of their limited number. One of the critical moments in the long and arduous BIM process is interdisciplinary coordination. In the scientific literature and industry practice, the terms “clash,” “collision,” and “conflict” are often used interchangeably. For consistency, this manuscript uses “clash” as the primary term, following common BIM coordination practice. Traditional methods of interdisciplinary coordination are becoming insufficient, especially during the so-called clash detection, which is usually performed manually, typically by a BIM Coordinator. Although BIM has established itself as the dominant digital technology in the AECOO (Architecture, Engineering, Construction, Owner Operators) sector, enabling the creation and management of information-rich 3D models throughout the life cycle of a building, but it still does not meet the expectations of the industry [1]. The BIM model is understood as a common and sole source of truth for stakeholders and a platform for the integration of design, implementation, and operational processes [2]. Smart cities rely on digital twins and integrated urban information systems that require accurate, interoperable building data at scale. BIM models serve as the foundational data source for these systems, providing geometric, semantic, and operational information about individual buildings that can be aggregated into city-wide digital models (City Information Modeling, CIM). However, the quality of BIM models and, particularly, the resolution of interdisciplinary conflicts during the design phase directly affect their usability for smart city applications. Unresolved clashes in building models propagate as data inconsistencies in urban-scale systems, undermining the reliability of smart city infrastructure management.

The challenge of clash management is particularly acute in large and complex projects such as hospitals, transportation hubs, and university campuses. These projects are characterized by high complexity metrics: dozens of discipline-specific models (architectural, structural, mechanical, electrical, plumbing, fire protection), multiple design teams (often 10–20+ stakeholders), large model scale (hundreds of thousands of elements), and tight coordination schedules.

One of the key applications in the BIM process is BIM-based Model Checking (BMC), which involves automatic verification of models for completeness, compliance with requirements, and collisions. Reviews of BMC methods indicate that this area can be divided into three main categories: (i) clash detection, (ii) quality control, and (iii) automatic code checking [3]. In design practice, clash detection has become one of the most recognizable and widely used elements of BIM, closely linked to the process of interdisciplinary coordination. Design clashes, understood as geometric or process conflicts between elements of different disciplines, are among the main sources of risk of delays, cost increases, and the need for rework on site. Research conducted in various contexts shows that a properly organized collision detection process in a BIM environment allows many problems to be identified during the design phase rather than the implementation (construction) phase, thus reducing the number of errors on the construction site [4].

In the literature and standardization documents, collisions are divided into geometric (hard clashes), soft (clearance clashes), and time-process (4D/workflow clashes). Hard clashes describe the physical overlap of solids (e.g., a ventilation duct passing through a beam), soft clashes describe, for example, the violation of safety or service zones, while time clashes refer to scheduling and logistical conflicts (e.g., the impossible parallel installation of elements in the same space) [3,4]. Below is an example of a hard collision between the sewage system and the ventilation system, which must be removed quickly due to its geometric nature, which makes it impossible to implement on-site (Figure 1).

The development of specialized tools such as Autodesk Navisworks and Solibri Model Checker has made automatic collision detection a relatively easy and routine task for professionals such as BIM Coordinators and BIM Managers (in the absence of a BIM Coordinator within the organization). As a result, however, modern projects often generate tens of thousands or even hundreds of thousands of collision reports for a single coordination model, a significant portion of which are repetitive or insignificant from a project risk perspective. In the famous large hospital project described by Khanzode [5], BIM design coordination identified over 3 million collisions and resolved over 2.4 million of them before construction began [6]. From the perspective of BIM Coordinators, the key problem is no longer the detection of collisions itself, but controlling their number, understanding the context, and prioritizing their resolution. Research conducted by Hasannejad et al. [7], Bitaraf et al. [8], and others shows that:

• A large proportion of detected collisions are insignificant, duplicates, or the result of accepted modeling tolerances;
• The lack of consistent rules for assessing significance makes prioritization a highly intuitive process that depends on the experience of the specific BIM Coordinator;
• The way collision reports are presented (lists, screenshots, or BCF–BIM Collaboration Format) encourages working through collisions one by one, rather than a problem-based approach (grouping them into larger design issues).

Hasannejad et al. show that in some projects, the number of detected collisions reaches millions, which forces the use of prioritization and filtering methods to enable effective teamwork at all [7]. Bitaraf et al., on the other hand, point out that despite advanced BIM tools, the process of analyzing and resolving collisions remains largely manual and labor-intensive, and the actual reduction in project delivery time is limited by the so-called bottleneck on the human side of report interpretation [8]. These findings directly motivate the need for automated support in clash management. In this context, the concept of collision triage is increasingly emerging, understood as a sequence of actions:

• Filtering noise, i.e., rejecting irrelevant or erroneous collisions;
• Grouping, i.e., combining related collisions into larger project problems;
• Significance assessment, i.e., prioritization based on multi-criteria indicators;
• Routing, i.e., assigning responsibility to the appropriate teams/industries.

Today, most of these steps are performed manually or with the support of simple rules, which limits the scalability of the process in large BIM projects and digital city models (also known as CIM, City Information Modeling). An example of this is the collision triage table below, created manually by the BIM Manager at Climatic for a hospital project using Autodesk Navisworks and Microsoft Excel tools (

Table 1. Example of a hand-made collision triage table. Source: own elaboration.

Clash Type (Priority)	Critical (1)
Image
Discipline	Structure	Architecture
Object	Structural column	Window
Clash type (priority)	Hard (2)
Image
Discipline	HVAC (Ventilation)	HVAC (Sewage system)
Object	Duct 250 × 500	Pipe DN100
Clash type (priority)	Soft (3)
Image
Discipline	HVAC	Architecture
Object	Pipe DN20	Interior wall

).

In recent years, scientific literature has focused on two complementary issues:

• Classification of collisions (e.g., significant/insignificant, hard/soft/temporary, division by industry).
• Prioritization of conflicts using multi-criteria methods.

In their work, Akhmetzhanova et al. proposed, among other things, dividing collisions into relevant and irrelevant ones, where the criterion for relevance is the impact on productivity, the need for rework, and potential disruptions to the construction process [4]. Hasannejad et al. used the fuzzy AHP (Analytic Hierarchy Process) method to assign weights to individual criteria (e.g., depth of penetration of elements, weight of structural elements, and Mechanical, Electrical, Plumbing (MEP) in terms of cost and time) and then defined a formula for calculating the collision importance index. This allows both for the systematization of the collision list and the identification of insignificant collisions [7]. More recent research by Bitaraf et al. develops this direction by using the Best–Worst Method (BWM) to determine the weights of structural and MEP elements based on expert opinions and then integrating these weights with additional parameters (including floor function, number of adjacent elements, MEP volume share) within a dedicated plugin for Autodesk Navisworks [8]. At the same time, numerous studies point to the possibility of using network analysis, collision context, and environmental features to better group and classify collisions, but these are most often solutions developed for specific cases or types of objects.

In conclusion, previous scientific research on collision prioritization has been based mainly on explicitly defined multi-criteria models calculated by BIM experts. However, there is a lack of systematic approaches to using historical data and AI techniques for learning adaptive collision triage.

1.2. AI in the BIM Environment and Collision Handling

Parallel to the development of classical multi-criteria methods, there has been an intense increase in the number of studies on the integration of AI and/or Machine Learning (ML) with BIM. A review by Kutá and Faltejsek [9] shows that AI in the BIM environment is used, among other things, for:

• Generative design;
• Energy optimization;
• Predictive risk and schedule management;
• Automatic object recognition and model quality control.

In the area directly related to collisions, several research directions can be distinguished, summarized, among others, in the work of Bitaraf et al. [8]:

• Classification of relevant/irrelevant collisions using supervised learning methods—based on both tabular data (numerical features) and images (projections from Autodesk Navisworks), where Convolutional Neural Networks (CNN) were used, among others.
• Modeling the context of collisions using graph neural networks (GCN), enabling prediction of which components will be modified in the coordination process.
• Automation of correction sequences, considering the relationships between collisions, so that resolving one collision does not cause further conflicts.

Ahmadpanah et al. propose integrating BIM with machine learning for project coordination, emphasizing that large datasets from collision reports can provide valuable training material for AI models [10]. Other studies, in turn, use a modified XGBoost algorithm (MXGBoost) to improve the effectiveness of collision detection and classification in complex BIM models [11].

Despite the growing number of examples of AI applications, most work focuses on individual aspects of the process: better classification, more accurate detection, or automation of selected decisions. However, there is a lack of an approach in which AI would be used to manage the entire collision stream (from the initial collision detection report to an organized list of coordination tasks with assigned priorities and responsibilities).

1.3. Research Gap and Purpose of the Study

Based on the results of the literature review, the following three research gaps can be identified:

• Lack of a consistent concept of “collision triage” in BIM literature despite the existence of works on classification and prioritization, these are not usually treated as a separate, formalized stage of the coordination process.
• Fragmented use of AI, as research shows the potential of machine learning in classification and prediction of coordination decisions but does not integrate these methods into a modular framework that includes noise filtering, collision grouping, significance assessment, and responsibility assignment.
• Limited integration with existing BIM workflows, as most solutions are prototypes or dedicated tools that are difficult to integrate with practical applications such as Autodesk Navisworks, Solibri Model Checker, or Common Data Environment (CDE) platforms, and thus with the processes used in large building and infrastructure projects, which form the foundation of smart city systems.

The aim of this article is therefore to propose a conceptual, modular AI framework for collision triage in the BIM environment, which:

• Uses geometric, semantic, contextual (4D/5D), and historical data from coordination processes;
• Integrates several complementary AI models (classification, clustering, scoring, responsibility recommendation),
• Is designed to be integrated into the existing ecosystem of BIM tools and coordination procedures,
• Responds to the specific nature of projects implemented on the scale of smart buildings and smart cities, where the number of collisions and stakeholders is particularly high.

The structure of the article includes: a detailed description of the proposed system architecture, the concept of a new ‘AI Triage Score’ indicator, and assumptions for validating the framework based on case studies and expert evaluation. In summary, the proposed framework addresses the critical problem of information overload in BIM coordination by automating the transformation of raw clash detection reports into prioritized, actionable coordination issues, thereby helping to reduce the risk of overlooking critical clashes, minimize delays caused by inefficient manual review, and improve the overall quality of design coordination.

2. Methodology and Framework Design

Due to the conceptual nature of the work, the designed framework is not the result of the implementation of a single specific programming solution, but a synthesis of conclusions from the literature and observations of BIM coordination practices in large projects, including those carried out at Climatic. This chapter describes the research approach adopted, the functional requirements for a collision triage support system, and then the proposed conceptual framework architecture and its main components. The conceptual framework provided can be tested in practice and then implemented in the work of BIM companies (design studios, contractors).

2.1. Research Approach and General Assumptions

The starting point for the design of the framework was an analysis of: (i) existing interdisciplinary coordination procedures based on collision detection tools and BCF exchange, (ii) research on the classification and prioritization of collisions using multi-criteria methods, (iii) research on the integration of BIM with AI methods, particularly machine learning. A design approach similar to design science research was adopted: instead of verifying a predefined hypothesis, the goal is to construct a modular framework that directly addresses identified research gaps and practical needs. The design process included the following steps:

• Conceptualization of the current collision handling process in a typical BIM environment;
• Identifying areas where information overload occurs and manual data processing is necessary;
• Determining the functional requirements for a collision triage support system,
• Papping these requirements to potential AI components;
• Proposing a modular architecture that can be implemented in stages and integrated with existing tools.

The focus was on highly complex projects typical of smart cities (large hospitals, extensive public facilities, complex transport hubs, university campuses, etc.), selected because they feature dense MEP systems, strict regulatory requirements, and numerous interdisciplinary interfaces, resulting in particularly high numbers of detected collisions and stakeholders.

2.2. Functional Requirements for an AI Framework for Collision Triage

Based on a review of the literature and analysis of design processes, several requirements have been identified that a system supporting collision triage in a BIM environment should meet. The most important of these can be grouped into four categories:

• Noise reduction requirements [12]:
  • Automatic differentiation between significant and insignificant collisions (e.g., those resulting from tolerances, minor insulation overlaps, collisions in working models);
  • The ability to hide or lower the priority of collisions of low significance for design risk.
• Information aggregation requirements [13]:
  • Grouping related collisions into logical design problems (e.g., collisions of an entire branch of a duct with a structural beam);
  • The ability to analyze collisions at the level of zones, floors, systems, and work packages (chosen as they reflect natural spatial and organizational divisions in construction projects), rather than just individual pairs of elements.
• Prioritization requirements [14]:
  • Consideration of multiple criteria when assessing the significance of conflicts (design, cost, schedule, operational);
  • The ability to learn from the historical decisions of coordinators (adaptive weighting of criteria);
  • Translation of numerical assessment into clear priority categories (e.g., high/medium/low).
• Process integration requirements [15]:
  • Assigning responsibility for resolving conflicts to the appropriate teams/industries;
  • Integration with the existing ecosystem of tools (Autodesk Navisworks, Solibri Model Checker, CDE platforms, BCF managers);
  • The ability to iterate and re-triage after updating BIM models, with change history tracking.

From the user’s perspective (BIM Coordinator, BIM Manager), the framework should therefore provide a streamlined, organized list of coordination issues, supplemented with priority and owner information, instead of a standard list of thousands of individual conflicts.

3. Results: AI-Based Clash Triage Framework

3.1. General Architecture of the Proposed Framework

To meet the above requirements, a modular architecture of the AI framework for collision triage has been proposed. The four-layer structure was chosen to reflect the logical data flow from raw inputs to actionable outputs and to allow incremental implementation based on organizational maturity. The layers are:

• Data acquisition layer (input layer);
• Pre-processing and feature extraction layer;
• AI reasoning layer;
• Output/integration layer.

The four layers operate in a sequential pipeline, with well-defined data interfaces between them. The Data Acquisition Layer collects raw inputs from heterogeneous sources (clash detection reports, BIM models in IFC format, 4D schedules, 5D cost databases, and historical BCF/CDE records) and standardizes them using common element identifiers (GUIDs). These standardized inputs are passed to the Pre-processing and Feature Extraction Layer, which transforms them into structured objects (Clash, Element) populated with geometric, semantic, contextual, and process features represented as numerical and categorical feature vectors. The AI Inference Layer receives these feature vectors and processes them sequentially through four modules: first, the Noise Filtering module assigns relevance probabilities and removes or deprioritizes low-relevance clashes; second, the Clash Clustering module groups remaining clashes into logical Issue objects; third, the Severity & Impact Scoring module computes the AI Triage Score for each Issue; and fourth, the Responsibility Assignment module identifies the accountable party. Finally, the Output and Integration Layer receives the enriched Issue objects and transforms them into deliverables compatible with existing BIM tools including prioritized issue lists, BCF files for coordination platforms, and status updates for CDE systems. This sequential data flow ensures traceability from raw clash reports to actionable coordination tasks. Conceptually, this can be represented as a data flow: clash detection results + BIM models + 4D/5D data, followed by feature extraction, then AI modules (filtering, grouping, scoring, assigning responsibility), and a list of sorted issues returned to the coordination environment. The developed conceptual framework shows the relationships between the individual layers (Figure 2).

3.1.1. Data Acquisition Layer

The input layer is responsible for collecting and harmonizing data from various, often disparate sources:

• Collision detection reports from tools such as Autodesk Navisworks, Solibri, BIMcollab Zoom, or cloud platforms;
• Native BIM models (e.g., Revit) and exchange files (Industry Foundation Classes (IFC));
• Schedule data (4D) associated with model elements;
• Cost data (5D) and economic significance indicators for individual elements;
• History of notifications and coordination decisions, usually recorded in BCF or CDE format.

At this stage, it is crucial to standardize element identifiers so that collisions can be linked to specific BIM objects and their semantic and process attributes. In practice, this process can be supported by standards such as Information Delivery Specification (IDS) and buildingSMART Data Dictionary (bSDD), which enable the automation of information exchange and verification in projects implemented using the BIM methodology [16]. Key data prerequisites include API access to clash detection tools and CDE platforms, as well as BCF import/export capabilities.

3.1.2. Pre-Processing and Feature Extraction Layer

The second layer is responsible for transforming the input data into a representation that can be used by AI models. For each collision (pair of colliding elements) and its context, the following are determined, among other things:

• Geometric features: penetration size, minimum distances to surrounding elements, relative orientation and position;
• Semantic features: element types (e.g., beam, column, ventilation duct, pipeline), system affiliation (Heating, Ventilation, Air Conditioning (HVAC)), water and sewage, electrical, structure), fire resistance classes, load-bearing capacity information;
• Contextual features: floor, functional zone (corridor, operating room, technical room), connection to escape routes or communication cores;
• Process features: project stage, element status (designed, ordered, prefabricated, installed), connection to schedule tasks.

The result is a structured data set in which each collision description is a vector of numerical and categorical features, which can be used by subsequent AI modules. The transformation process maps raw input data to the data model structures. Specifically, for each detected clash, the layer creates a Clash object populated with geometric features (penetration size, distances, orientation) and references to the two colliding elements. Simultaneously, Element objects are instantiated or updated with semantic attributes (element type, system affiliation, fire resistance class) and process attributes (project stage, execution status, schedule links) extracted from the BIM models and 4D/5D data sources. Contextual features (floor, functional zone, proximity to critical areas) are computed by spatial analysis and attached to both Clash and Element objects. This structured representation enables the subsequent AI Inference Layer to process clashes as feature vectors while maintaining traceability to the original BIM elements and their rich attribute sets.

3.1.3. AI Inference Layer

The most distinctive element of the proposed framework is the AI-based inference layer, consisting of four specialized modules:

• Noise filtering module

The purpose of the module is to distinguish between collisions that are relevant from a design risk perspective and collisions that constitute noise (false positives, minor tolerated collisions, collisions in temporary zones). The conceptual layer assumes the use of supervised machine learning models (e.g., decision trees, boosting methods) trained on historical data in which collisions have been classified by coordinators as significant or insignificant. The output of the module is a relevance probability, which can be used to pre-filter some collisions or to lower their priority. In particular, gradient boosting algorithms such as XGBoost or LightGBM are recommended due to their proven effectiveness in binary classification tasks with tabular data and their ability to handle mixed feature types (numerical and categorical). The input feature vector includes clash penetration depth, element types and categories, system priorities, spatial zone classification, and project phase indicators. The model outputs a relevance probability p ∈ [0, 1], where clashes with p < 0.3 can be automatically filtered as noise, while those with p > 0.7 are forwarded directly to subsequent modules. Clashes in the intermediate range (0.3 ≤ p ≤ 0.7) may require human verification.

2.

Clash clustering module

The second module is responsible for aggregating individual collisions into broader issues that the user works with. Unsupervised clustering methods (e.g., variants of the DBSCAN/HDBSCAN algorithm) are used here, utilizing geometric similarity, common model elements, and belonging to the same functional zone or system. The goal is to reduce repetition: instead of dozens of clashes between the same branch of the installation and several beams, the user (BIM Coordinator) receives a single coordination issue. The HDBSCAN algorithm is particularly suitable for this task as it does not require pre-specification of the number of clusters and can identify clusters of varying densities.

3.

Severity & impact scoring module

The third module determines the value of the ‘AI Triage Score’ indicator describing the total significance of the collision (at the level of a single collision or an aggregated issue). Conceptually, it is assumed that this indicator is a function of several components:

• Severity—technical significance of the collision (e.g., violation of the load-bearing structure, fire zone, escape route);
• Cost impact—estimated impact on costs (collision with a prefabricated element, high-value element, collision in the late phase of the project);
• Constructability risk—risk of construction complications (e.g., limited assembly space, lack of service clearances);
• Time pressure—sensitivity to schedule (collisions in areas with an approaching completion date).

The relationship between individual components and the ‘AI Triage Score’ can be determined either based on a defined multi-criteria model calibrated by experts, or because of machine learning on historical data describing the actual order of collision resolution. The learning-based approach enables automatic weight calibration through feature importance analysis.

4.

Responsibility assignment module

The last module is designed to assign a responsible party to each issue: industry, project team, contractor, or model owner. Conceptually, it combines rules based on system hierarchy (e.g., structure > MEP divisions > MEP distribution > interior design) with information about the authorship of elements in BIM models. In a more advanced version, the module can use machine learning models that analyze historical decisions about who ultimately made changes in response to a given collision. For the machine learning variant, a multi-class classification approach is recommended, where classes represent responsible parties (e.g., structural engineer, MEP contractor, architect). Candidate algorithms include Random Forest Classifier or neural network-based models trained on historical issue assignments. Input features include element authorship metadata, system hierarchy levels, clash location, and historical resolution patterns for similar clash types.

3.1.4. Output and Integration Layer

The output layer of the framework is responsible for transforming the results into a form that is useful for existing coordination tools and processes, in particular CDE platforms and CDE/BCF-class systems, which in practice constitute the center of information flow in BIM projects. According to Zima’s observations [17], it is the way in which data flow is organized and models are integrated with costing and scheduling processes that determines the real benefits of BIM implementation, rather than the mere fact of having 3D models. Similarly, Drozdowska and Radziejowska emphasize the role of a well-organized data environment (CDE) in investment management [18]. Therefore, key functions include:

• Generating an organized list of issues containing identifier, problem description, location, priority, e.g., high (critical)/medium (significant)/low (cosmetic), ‘AI Triage Score’ value, assigned responsibility;
• Exporting this list in formats that support existing platforms (e.g., BCF, CDE);
• Visualization of collisions and their priorities in the context of 3D models and 2D projections;
• Iteration support: updating issue statuses (open, in progress, resolved) and re-evaluation after model revisions.

From the user’s point of view, the framework should be seen as a service layer in the existing BIM ecosystem, rather than a separate, competing environment. This is especially true given that over the last two decades of strong BIM development, certain tools have become firmly established in practice [19].

3.2. Representation of Collisions and Context in the Data Model

An important element of conceptual framework design is the adoption of a universal data representation that allows both individual collisions and aggregated issues to be described. In abstract terms, the following structures are assumed:

• Clash object, containing, among other things, identifiers of two colliding elements, collision type (hard, soft, temporary), basic geometric features, and detection timestamp.
• Element object, representing a reference to a BIM model (e.g., via a global GUID), along with a set of static (geometric, semantic [20]) and dynamic (links to schedule, execution status, costs) attributes.
• Issue object, representing an aggregated coordination problem, associated with one or more collisions and having its own attributes: priority, AI Triage Score, responsibility, and change history.

Such an abstract representation allows for consistent handling of both input data from various collision detection tools and the results of AI modules. It also facilitates possible implementation in the form of an independent service (e.g., microservice) communicating with several source systems.

3.3. Definition of the AI Triage Score Indicator

A key element of the proposed framework, linking information from different modules, is the ‘AI Triage Score’ indicator (Figure 3). At the conceptual level, it is assumed that:

• The AI Triage Score is scaled in the range [0, 1] (or [0, 100]) and represents the relative importance of a collision/issue in the context of the entire project.
• The value of the indicator is a function of several components (severity, cost impact, constructability risk, time pressure), which can be determined partly by AI models and partly by rules based on expert knowledge.
• Based on the distribution of the ‘AI Triage Score’ values, thresholds are defined to classify ‘issues’ into priority categories (e.g., P1—high, P2—medium, P3—low).

For the purposes of this study, the AI Triage Score ($\mathrm{A}{\mathrm{I}}_{\mathrm{T}\mathrm{S}}$) was defined as the weighted average of four key components (severity, cost impact, constructability risk, time pressure), according to Equation (1):

$$\mathrm{A}{\mathrm{I}}_{\mathrm{T}\mathrm{S}}={\displaystyle \frac{{\mathrm{w}}_{\mathrm{s}\mathrm{e}\mathrm{v}}\ast \mathrm{S}\mathrm{e}\mathrm{v}+{\mathrm{w}}_{\mathrm{c}\mathrm{o}\mathrm{s}\mathrm{t}}\ast \mathrm{C}\mathrm{o}\mathrm{s}\mathrm{t}+{\mathrm{w}}_{\mathrm{c}\mathrm{o}\mathrm{n}\mathrm{s}\mathrm{t}\mathrm{r}}\ast \mathrm{C}\mathrm{o}\mathrm{n}\mathrm{s}\mathrm{t}\mathrm{r}+{\mathrm{w}}_{\mathrm{t}\mathrm{i}\mathrm{m}\mathrm{e}}\ast \mathrm{T}\mathrm{i}\mathrm{m}\mathrm{e}}{{\mathrm{w}}_{\mathrm{s}\mathrm{e}\mathrm{v}}+{\mathrm{w}}_{\mathrm{c}\mathrm{o}\mathrm{s}\mathrm{t}}+{\mathrm{w}}_{\mathrm{c}\mathrm{o}\mathrm{n}\mathrm{s}\mathrm{t}\mathrm{r}}+{\mathrm{w}}_{\mathrm{t}\mathrm{i}\mathrm{m}\mathrm{e}}}}$$

(1)

where

• Sev—severity (0–1);
• Cost—cost impact (0–1),
• Constr—constructability risk (0–1);
• Time—time pressure (0–1);
• w_sev, w_cost, w_constr, w_time—weights of individual components (positive), determined by experts or learned from historical data.

By dividing by the sum of weights, the $A{I}_{TS}$ index always takes values in the range [0, 1].

Each component of the AI Triage Score can be computed using specific methods:

• Severity (Sev): Calculated using a rule-based classifier that evaluates clash characteristics against predefined criteria. For example, clashes involving load-bearing elements receive Sev = 0.9–1.0; clashes affecting fire compartments or escape routes receive Sev = 0.7–0.9; clashes between MEP systems receive Sev = 0.4–0.6; and minor architectural clashes receive Sev = 0.1–0.3. These rules can be refined using decision tree models trained on expert-labeled datasets.
• Cost impact (Cost): Derived from 5D BIM data by calculating the ratio of affected element costs to total project cost, normalized to [0, 1]. For clashes involving prefabricated or already-ordered elements, a penalty factor (e.g., 1.5×) is applied. When 5D data is unavailable, a regression model trained on historical cost impact data can estimate this component based on element types, sizes, and project phase.
• Constructability risk (Constr): Assessed through spatial analysis evaluating assembly space availability, access clearances, and installation sequence constraints. A fuzzy inference system with membership functions for “limited space,” “restricted access,” and “sequence conflict” can aggregate these factors into a single score.
• Time pressure (Time): Computed from 4D schedule data as a function of remaining time until the planned installation date for affected elements. Elements scheduled within 2 weeks receive Time = 0.9–1.0; within 1 month: Time = 0.6–0.8; within 3 months: Time = 0.3–0.5; beyond 3 months: Time = 0.1–0.2.

For weight learning, the framework employs gradient-based optimization or Bayesian inference to adjust w_sev, w_cost, w_constr, and w_time based on historical data. The objective function minimizes the discrepancy between predicted priority rankings and actual resolution sequences observed in past projects. This approach enables project-specific or organization-specific calibration of the AI Triage Score.

Unlike classic multi-criteria methods, in which the weights of the criteria are permanently determined by experts, it is assumed that in the proposed framework these weights can be updated based on historical data (e.g., the observed order of conflict resolution, the occurrence of claims and disruptions on the construction site). This allows the system to be adapted to the specifics of the organization, project type, or local context (norms, implementation standards).

3.4. Scenario for Using the Framework in the Coordination Process

For a complete picture, it is worth presenting a typical scenario for using the designed framework in BIM coordination practice:

• The coordination team performs standard collision detection tests in the selected tool, generating a traditional collision report.
• The report and the relevant BIM models and 4D/5D data are automatically or semi-automatically transferred to the AI framework.
• The pre-processing layer generates feature vectors for all collisions and the design context.
• The AI modules sequentially:

  –

  Filter out some collisions as irrelevant or of low importance;

  –

  Group the remaining collisions into logical issues;

  –

  Assign an ‘AI Triage Score’ and priority category;

  –

  Assign responsibility for each issue.

• The organized list of issues is fed back into coordination tools (e.g., in the form of BCF) and becomes the basis for work at coordination meetings.
• During subsequent iterations of the models, the history of decisions and status updates is added to the training data, enabling further improvement of the AI models.

This scenario emphasizes that the designed framework does not replace existing BIM tools but provides a layer of intelligent decision support on top of them, aimed at reducing information overload and systematically prioritizing collisions in complex smart building and smart city projects.

The key result of the work is the framework’s systemic response to the three research gaps identified in Section 1.3.

3.5. Definition of Collision Triage in BIM

In the literature on the subject, the concept of collision triage rarely appears and is most often equated with simple prioritization of detected collisions (e.g., assigning them high/medium/low priority categories) [21]. In the practice of BIM coordination, such a reductionist view proves insufficient, as the design team does not work on individual collisions, but on interrelated coordination problems, which have cost, time, and execution implications [22]. Therefore, this paper proposes a broader, systemic definition of collision triage.

The new definition is as follows:

Collision triage in a BIM environment is an organized, data-driven, and potentially AI-assisted process of transforming a traditional collision list from detection tools into an organized set of coordination issues with assigned priority, scope of responsibility, and design context, considering the time, cost, and execution constraints of a given project.

Collision triage, understood in this way, is not a single activity, but a separate phase of the coordination process, comprising four interrelated tasks:

• Noise filtering involves filtering out collisions that are irrelevant to the project requirements (e.g., those within tolerances, repetitive, or with negligible consequences) so that only collisions requiring the team’s attention are passed on to further stages.
• Clash clustering involves grouping individual clashes into logical coordination problems according to the model structure, industry scope, implementation phase, or object zone, which allows BIM Coordinators to work at the issue level rather than on hundreds or thousands of scattered clashes.
• Severity & impact scoring involves a quantitative and qualitative assessment of the impact of aggregated issues on costs, schedule, and constructability, and then translating this information into a consistent indicator (e.g., ‘AI Triage Score’) and priority classes (P1–P3).
• Responsibility assignment involves clearly identifying the owner of a given issue (industry, team, process participant) and specifying the expected action (e.g., redesign, correction of the working model, change in the sequence of works).

The proposed definition highlights several key features of collision triage:

• Process-oriented, as triage is not a one-time filter, but a cyclically repeated stage between successive iterations of BIM models;
• Decision-oriented, as the goal is not only to classify, but to generate a list of issues on which specific design and execution decisions can be made;
• The possibility of AI support, as the individual steps of triage (filtering, grouping, scoring, assigning responsibility) are adapted for implementation using machine learning and data mining methods, while maintaining expert control;
• Tool neutrality, as triage is defined as a process concept and data model, rather than a function of a specific program; it can be implemented in various tool configurations (different collision detection engines, different CDEs), if they provide access to the required data.

The inclusion of collision triage, understood in this way, as a separate stage between the generation of the collision report and coordination meetings, organizes the role of AI in the BIM coordination process. Triage then becomes a kind of decision gate because, on the one hand, it protects teams from being flooded with irrelevant information, and on the other hand, it ensures that issues with the greatest potential to disrupt project implementation are identified and properly assigned before entering the construction site, which is particularly important in complex infrastructure and smart city projects.

4. Discussion

4.1. Fragmented Use of AI in Collision Management—Practical Tools and Architectures

An analysis of the literature and existing market solutions indicates that AI is currently used in collision management in a piecemeal and scattered manner. This most often involves individual tasks, such as automatic collision type classification [23], false positive collision identification [24], or prioritization support based on selected geometric features [25]. This approach, while valuable, does not cover the full collision triage process defined in Section 3.1—from noise reduction and aggregation to assigning responsibility and generating an organized list of issues. As a result, organizations end up with a set of inconsistent tools or functions that are difficult to integrate into a uniform, repeatable BIM workflow.

The framework proposed in this paper addresses this gap by integrating multiple classes of AI methods into a single, coherent triage process. Each of the four steps highlighted in the definition in Section 3.1 is associated with a dedicated module:

• The Noise filtering module uses classification methods (e.g., supervised learning) to distinguish between significant and insignificant collisions.
• The Clash clustering module uses clustering and similarity analysis techniques to construct coordination problems from raw pairs of colliding elements.
• The Severity & Impact Scoring module transforms a multidimensional description of a collision into a continuous indicator (‘AI Triage Score’).
• The Responsibility Assignment module can use expert rules, recommendation models, or hybrid AI approaches to identify the responsible participant in the process.

What is new, therefore, is not so much the presence of AI itself, but its organization into a sequence of interdependent steps that reflect the logic of the BIM Coordinator’s work. The output data of one module becomes the input data for the next, creating a complete processing chain: from the base collision report to the finished, sorted list of issues with priorities and responsibilities. In this way, AI ceases to be an addition to the traditional process and becomes the core of the defined collision triage stage.

Another element of the response to the research gap is the modular design of the framework. Each module can be developed, trained, and validated independently, using different AI techniques and data sets. This allows for:

• Gradually implement the solution in the organization (e.g., start with automatic noise filtering only);
• Compare alternative models within the same stage of the process (e.g., different clustering algorithms);
• Adjust the level of automation to the digital maturity of the team and the availability of data.

Finally, the proposed approach considers the need for AI and expert knowledge to coexist. The framework assumes that the results generated by individual modules (e.g., classification of collisions as insignificant, grouping, proposed priority) are transparent and can be verified and corrected by the BIM Coordinator. On the one hand, this enables models to be trained based on expert decisions (in the spirit of continuous learning), and on the other hand, it reduces the risk of uncritical reliance on the so-called black box.

In summary, the response to the identified research gap of fragmented AI use is to design collision triage as a complete, modular process in which AI supports each of the key decision-making steps, rather than just individual technical operations. This perspective paves the way for the systematic validation of the entire collision handling chain in highly complex projects typical of the smart cities environment.

4.2. Limited Integration with Existing BIM Workflow

The third research gap identified concerns the fact that AI solutions in collision management are very rarely fully integrated with the actual BIM workflow. Literature and practice are dominated by prototypes functioning as separate scripts, one-off report analyses, or add-ons related to a single specific collision detection tool. As a result, they are difficult to incorporate into established coordination procedures, remain outside the main communication flow in the CDE, and their use is sometimes perceived as additional work rather than an integral part of the design process [26].

The proposed collision triage framework was designed from the outset as a service layer that will support existing BIM tools rather than attempt to replace them. The key here is to rely on open standards and tool neutrality. Collision data can come from different collision detection engines, while model elements and their properties are represented in IFC format, and coordination issues are represented in the form of issues stored, for example, in BCF and in the CDE system. The framework reads the generated collision report, processes it through successive triage modules (noise filtering, grouping, scoring, assignment of responsibility), and then returns an organized list of issues in exactly the formats that are already used in the project. Thanks to this, AI does not create a parallel information flow but automates a fragment of the existing one.

In practice, integration can take several forms of increasing depth, but all of them have a similar result—a collision report and a list of issues in the CDE. In the simplest scenario, the framework acts as an external service alongside the existing process, as the BIM Coordinator generates a standard report, forwards it to the AI triage system, and then receives a sorted and grouped list of issues in return. This approach allows the coordination team to compare AI results with traditional work without interfering with the main workflow. In a more advanced variant, the triage modules are integrated directly into the collision detection tool as a plugin, so that after generating the report, the user can start the triage with a single click, see the priorities and responsibilities in the same interface, and then export the result to the CDE. The most far-reaching scenario is the “CDE-centric” approach [27], in which the CDE acts as a central repository of issues, and the framework periodically retrieves new conflicts via API, updates their priorities and owners, and supports the generation of coordination meeting agendas [28]. This aligns with literature, where CDE implementation, open standards, and data standardization are indicated as key enablers of integrated information management and lifecycle-oriented use of BIM models [29]. The choice between these scenarios depends on organizational factors such as digital maturity, data security requirements, and implementation cost.

An important element of the proposed response to the integration gap is also the way organizational change is managed. The framework assumes that in the initial phase, it can operate in read-only mode, generating an alternative triage proposal without automatically imposing decisions in the CDE. This allows teams to gradually build trust in the models, compare the results with their own practice, and identify areas where AI saves time or improves the quality of decisions. At the same time, each result of the modules’ operation (assigned priority, indicated owner, method of aggregating conflicts in issues) must be fully visible, manually correctable, and accompanied by an audit trail. Corrections made by experts become training material for subsequent iterations of the models, which strengthens the system’s learning cycle on real project data.

The modular architecture of the framework makes it easy to adjust the level of integration to the digital maturity of the organization [30]. Where readiness for automation is limited, organizations can start with noise filtering alone and treat AI results as recommendations. In more advanced environments, it is possible to implement full triage with automatic scoring and preliminary assignment of responsibility, while maintaining the BIM Coordinator’s control over final decisions. In each of these variants, the common denominator is that AI does not function as an experimental addition to the process, but as a coherent component woven into a well-known cycle: collision detection—triage—issue management—coordination meetings.

In this way, the proposed framework addresses the gap of limited integration with the existing BIM workflow by designing collision triage as a flexible, standards-supported service layer that maximizes the use of existing tools and organizational infrastructure rather than replacing them. As a result, the potential of AI can be exploited in highly complex projects without the need to revolutionize the entire workflow of design teams.

4.3. Implications for BIM Coordination Practices in Smart City Projects

From the perspective of BIM coordination practice, especially in complex projects characteristic of smart buildings and smart cities, the proposed framework has several important implications. First, organizing triage as a separate phase of the process allows for conscious management of the so-called bottleneck between automatic collision detection and coordination meetings. The introduction of a noise reduction and issue aggregation module can significantly reduce the number of collisions that experts must deal with manually, freeing up their time to solve truly critical problems.

Second, defining the AI Triage Score indicator and priority classes enables a transition from intuitive, often implicit prioritization logic to a data-driven approach. In practice, this can mean greater predictability and repeatability of coordination decisions, as well as better justification for resource allocation (designers’ time, rework budget, time reserves in the schedule).

Third, the module responsible for assigning issue ownership streamlines communication between stakeholders. Clearly indicating which team or industry is responsible for solving a given problem reduces the risk of “passing the buck” between project participants and facilitates the preparation of the agenda for coordination meetings. This transparency also helps resolve disputes, as stakeholders can refer to objective, data-driven criteria rather than subjective judgments. In a smart cities environment, where the number of industry models and stakeholders is particularly high, such clarity of responsibility is crucial for maintaining the smooth flow of work.

4.4. Limitations of the Proposed Framework

The presented framework is conceptual in nature, so it needs to be tested in practice. The proposed modules and data flows have not yet been verified in a full-scale programming implementation or in a series of empirical studies, but this material can be used as input for a grant or project proposal. In particular, the following should be investigated:

• The effectiveness of the noise reduction module, which depends on the availability of sufficiently large and representative training datasets in which collisions have been classified by experts;
• The quality of the clash clustering module results, as in practice, this will depend on the similarity metrics and clustering algorithm parameters adopted, which may need to be adjusted to the specifics of a given project type;
• The design and calibration of the AI Triage Score indicator, which requires the joint work of domain experts and data analysis specialists, and if the data quality is insufficient, there is a risk of overconfidence in the value of the indicator;
• The accountability module, which may be sensitive to local contractual and organizational practices that vary between countries, companies, or project types.

In addition, the effectiveness of the framework is closely related to the level of digital maturity of the organization and the quality of the existing BIM ecosystem (models, CDE, modeling standards). In environments with a low degree of process standardization, the implementation of such a service layer may require prior streamlining of basic coordination procedures.

4.5. Future Research and Validation Scenarios

The proposed framework opens several directions for further research and implementation. The first step should be to develop a technical prototype comprising at least two modules (e.g., noise filtering and clash clustering) and to pilot it in a selected highly complex project with numerous clashes. This will allow the assumptions regarding data representation, information flow, and integration with existing tools to be verified.

The next step is to conduct case studies in which the triage results generated by the framework will be compared with the decisions of experienced BIM Coordinators. Such expert validation may include both an assessment of the quality of the classification (e.g., the accuracy of identifying insignificant collisions) and the impact on practical performance indicators, such as the time needed to prepare meeting agendas, the number of missed critical collisions, or the response time to key issues.

It is also worth considering the development of the ‘AI Triage Score’ indicator itself, in particular:

• Automatic learning of the weights of individual components based on historical project data;
• Testing the sensitivity of results to changes in the adopted weights;
• Comparison of different multi-criteria models (e.g., utility function-based approach vs. machine learning models).

A promising direction for research is also to link the collision triage framework to broader concepts, such as CIM, in which data on collisions and their priorities could feed into risk analyses at the level of entire investment programs in cities.

5. Conclusions

The conceptual AI framework for collision triage in the BIM environment proposed in this article addresses three key research gaps identified in the literature: the lack of a consistent definition of collision triage, the fragmented use of AI methods, and the limited integration of existing solutions with practical BIM workflows in complex smart building and/or smart city projects. A broader, process-based approach to triage is proposed as a separate phase between collision detection and design and execution activities, including noise reduction, aggregation of individual collisions into coordination problems, assessment of their significance using the ‘AI Triage Score’ indicator, and assignment of responsibility to the appropriate teams and industries. The modular architecture of the framework organizes the role of different classes of AI methods, from classification and clustering to scoring and recommendation, all in a single coherent data processing chain, allowing for the gradual implementation of automation and adaptation of the level of advancement to the digital maturity of the organization. From the perspective of BIM coordination practice in smart city projects, the adopted approach can contribute to a significant reduction in the information overload of BIM Coordinators, increase the predictability and transparency of prioritization decisions, and organize communication between stakeholders by clearly identifying issue owners. At the same time, the framework remains tool-neutral and is based on open standards, which facilitates its integration with the established ecosystem of tools (collision detection engines, IFC format, CDE/BCF platforms) without the need to revolutionize existing procedures. Due to the conceptual nature of the work, further research is needed, including prototype implementation, case studies, and expert validation, including training and calibration of the AI Triage Score on historical data and assessment of the framework’s impact on real coordination performance indicators (agenda preparation time, number of critical collisions missed, construction disruptions). Despite these limitations, the presented conceptual framework sets the direction for the development of coordination tools and practices, indicating how data from collision reports, BIM models, and CDE systems can be transformed, with the support of AI, into a structured, scalable decision-making process that supports the implementation of complex investments in the smart cities environment.