A Conceptual AI-based Framework for Clash Triage in Building Information Modeling (BIM)

1. Introduction

1.1. Research Background

To achieve the idea of a Smart City, a certain critical mass of BIM (Building Information Model) 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. 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].

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 fairly 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 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]. 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).

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 MEP (Mechanical, Electrical, Plumbing) 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 approaches systematically use historical data and artificial intelligence techniques for learning, adaptive collision triage.

1.2. Artificial Intelligence 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 CDE (Common Data Environment) 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.

2. Conceptual Framework Architecture

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 artificial intelligence methods, in particular 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,
• mapping 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.), where the number of detected collisions is particularly high and the number of stakeholders and industry models is high.

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, 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.

2.3. General Architecture of the Proposed Framework

To meet the above requirements, a modular architecture of the AI framework for collision triage has been proposed, consisting of four main layers:

• data acquisition layer (input layer),
• pre-processing and feature extraction layer,
• AI reasoning layer,
• output/integration layer.

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).

2.3.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 (IFC – Industry Foundation Classes),
• 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].

2.3.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 artificial intelligence 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 (HVAC – Heating, Ventilation, Air Conditioning), 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.

2.3.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.

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.

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.

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.

2.3.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].

2.4. 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, 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, 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.

2.5. 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 (AI_TS) was defined as the weighted average of four key components (severity, cost impact, constructability risk, time pressure), according to equation (1):

$$A{I}_{TS}={\displaystyle \frac{w_{sev}*Sev+w_{cost}*Cost+w_{constr}*Constr+w_{time}*Time}{w_{sev}+w_{cost}+w_{constr}+w_{time}}}$$

(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 AI_TS index always takes values in the range [0,1].

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 on the basis of 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).

2.6. 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 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.

3. Results

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

3.1. 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:

2.

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.

3.

Clash clustering involves grouping individual clashes into logical coordination problems according to the model structure, industry scope, implementation phase, or object zone, which allows you to work at the issue level rather than on hundreds or thousands of scattered clashes.

4.

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).

5.

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 artificial intelligence 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, 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.

3.2. Fragmented Use of AI in Collision Management – Practical Tools and Architectures

An analysis of the literature and existing market solutions indicates that artificial intelligence 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, artificial intelligence 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 artificial intelligence 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.

3.3. 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 you 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].

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, you 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 tool and organizational infrastructure rather than replacing it. As a result, the potential of artificial intelligence can be exploited in highly complex projects without the need to revolutionize the entire workflow of design teams.

4. Discussion

4.1. 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. 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.2. 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.3. 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 artificial intelligence 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.