2.1. Definition

BIGs represent design information in a graph-based data format. The definition of a BIG $ G $ is as follows:

(2.1) $$ G=\left(\underset{i=1}{\overset{n}{\cup }}\;{G}_i\right)\cup {G}_{meta} $$

where:

- $ G $ is the linked graph representation of building models.

- $ {G}_i $ represents the subgraph of a building discipline $ i $ , such as architecture, structural engineering, or mechanical engineering.

- $ {G}_{meta} $ represents the meta graph that contains interdisciplinary relationships to link subgraphs.

(2.2) $$ {G}_i=\left({V}_i,{E}_i\right) $$

- $ {V}_i $ is the set of vertices corresponding to objects within a building discipline $ i $ .

- $ {E}_i $ is the set of edges representing relationships between the objects within the discipline $ i $ (intradisciplinary relationships).

(2.3) $$ {G}_{meta}=\left({V}_{meta},{E}_{meta}\right) $$

- $ {V}_{meta} $ is the set of vertices corresponding to objectified interdisciplinary relationships.

- $ {E}_{meta} $ is the set of edges representing interdisciplinary relationships.

In mathematics, graphs consist of a set of vertices and edges (Bondy and Murty, Reference Bondy and Murty2008; Bollobás, Reference Bollobás2013). BIGs are defined as a collection of discipline-specific subgraphs ( $ {G}_i $ ), such as architectural and structural subgraphs, which are linked through a meta-graph ( $ {G}_{meta} $ ) that encapsulates interdisciplinary relationships, as shown in Figure 1. In the subgraphs, vertices (nodes) represent objects, including building elements such as doors, columns, and spaces. Edges (links) define intradisciplinary relationships, representing associations within a single domain (e.g., adjacency between two walls in the architectural subgraph). In the meta-graph, nodes represent functions, such as versions and constraints, and edges define interdisciplinary relationships, linking objects across disciplines (e.g., a hosting relationship between an architectural wall and a structural column). Interdisciplinary relationships in the meta-graph can also be objectified as nodes with additional attributes. For example, a constraint edge between a wall and a column can be represented by a node in the meta-graph with additional attributes that specify the condition, operator, and status.

Figure 1. Illustration of Building Information Graphs ( $ G $ ) in partial models.

There are two key differences between BIGs and BIM models:

1. 1. BIGs model represent and store interdisciplinary relationships. BIM models focus on discipline-specific objects, attributes, geometries, and limited intradisciplinary relationships. In BIGs, both intradisciplinary and interdisciplinary relationships are considered. For example, when an expert observes the models from three different disciplines shown in Figure 1, the expert understands that the radiator (a mechanical/electrical/plumbing [MEP] object) is intentionally attached to the wall (an architectural object) and intentionally placed below the window. However, in BIM models, the attached to information and the relative placing information are implicit—no current method or technology enables machines to understand the interdisciplinary relationships nor to store the semantics.

2. 2. In a BIG, the information describing a building is stored in a graph-based database rather than in files. Existing BIM technologies use files to store and exchange design information. In BIGs, the information from all disciplines is stored using the same graph database technology with subgraphs for each discipline and a meta-graph that implements relationships between the objects from different subgraphs.

The advantages of BIGs are twofold. First, BIGs support graph machine learning. A design model contains rich, complex, and multimodal data—including attributes, relationships, geometries, and more—yet existing BIM tools and exchange formats are not structured to facilitate machine learning. By leveraging a flexible and learning-suitable representation, BIGs integrate these diverse data and process them into vector spaces for learning, aiming to bridge building design and AI.

Second, BIGs enable more automated and intelligent design applications. Representing relationships explicitly introduces additional contextual information, making sophisticated functionalities feasible, such as multidisciplinary change propagation and object-level version control, which are difficult to implement in current BIM systems.

In summary, BIGs adopt graphs to represent and store object relationships both within and across design disciplines, and the design data are stored in a graph-based database rather than traditional files. Additionally, BIGs integrate and embed rich, complex, and multimodal BIM data into a learning-suitable representation for supporting AI. By leveraging the graph structure and graph learning, more automated and intelligent functionalities in design and construction become feasible.

2.2. Functional properties

To represent the richness of information in building models, and to support the full range of possible computations and design applications that are needed, BIGs will need to exhibit the following functional properties:

Attributes on nodes, edges, and graphs: Nodes, edges, and graphs can all carry attributes. Node attributes describe the semantics of building objects, such as class, Globally Unique Identifier (GUID), width, length, and material. Edge attributes describe the properties of relationships between objects (e.g., adjacency or constraint violation). Graph-level attributes capture metadata, such as the discipline of subgraphs (e.g., architecture or structure) or version identifiers.

Directional edges: BIGs require both directed and undirected edges. Directed edges represent dependencies (e.g., a column supporting a slab) and are used for causal or hierarchical relationships. Undirected edges capture mutual relationships (e.g., adjacent walls). Depending on the context, BIGs can be treated as directed, undirected, or mixed graphs.

Dynamic definition: BIGs are developed dynamically over time, with nodes, edges, and subgraphs being added, removed, or modified to reflect design changes. Nodes and edges, and even whole subgraphs that are superseded with new information (new nodes and edges) are not deprecated, but rather their metadata are changed to reflect their status. This feature can support functionalities such as incremental updates, version control, undo steps to revert to earlier versions, and incremental increase of the Level of Development (LOD) of objects, as corresponding objects of different detail can be associated with one another to support storage of a record of the design steps.

Aggregation: Object nodes in BIGs can be related through aggregation. Based on the nature of the subordinate relationships, aggregation can be divided into composition/decomposition and association. For example, a structural frame can be decomposed into beams and columns, and a detailed architectural wall can be decomposed into a structural core and two finishing layers. Association denotes a relationship between objects that are not parts of the parent object, but simply associated with it, such as furniture belonging to a room.

Layering: Data in BIGs can be organized into layers to support structured data management. For example, as an architectural model evolves from conceptual to detailed design, graphs from the two stages can form separate layers, with corresponding objects, such as a general wall and its detailed version, linked to represent the design progression. Layers are not limited to graphs. As noted in Section 5.6, life cycle data management places the graph above the file storage layer, using it to link files across project phases. Layering in BIGs primarily serves data organization and management.

Multimodality: Design models involve diverse information types and data modalities. Graphs compile building objects, semantics, and relationships, but other data (e.g., geometry, sensors, and documents) may need to remain in their native formats. BIG supports linking non-graph data to the graph for seamless integration. For example, the geometry of a wall is stored in a geometry file, and the file address is inserted in the corresponding node as a pointer attribute. Therefore, a BIG acts as a central repository for data integration.

Computability: Information in graphs can conveniently be converted into different formats that facilitate computation, such as embedding multimodal data into vector spaces for statistical learning or IF-THEN statements for rule-based inferencing.

2.3. Three key challenges

Representing relationships among building objects explicitly introduces a new dimension of data that captures topology, design intent, and constraints among building objects. Leveraging object relationships, a range of innovative graph applications that are hard to achieve using current BIM technologies become possible, such as multidisciplinary change propagation, automated consistency maintenance, object-based version control, and more. Graphs also provide a machine-accessible format to facilitate learning. However, this is an emerging domain, and we identify three key challenges:

1. 1. What new classes of object relationships will be needed? How can meta-graph relationships be instantiated automatically, accurately, and efficiently?

2. 2. What graph learning techniques are needed to effectively apply AI methods to building design?

3. 3. What applications could be developed by leveraging graphs if BIGs become available?

It is noteworthy that in the following discussion, our goal is to raise the key challenges and elaborate on the questions, but not to provide complete answers. Instead, we review and summarize existing work in the AEC field and in other domains, including computer science, to explore whether their experience and knowledge can be leveraged to tackle the challenges of information representation for AEC.

4.1. Experience from AI domains

Reflecting on the evolution of AI, particularly in the domains of CV and NLP, we note that each domain has its own purpose-specific representation of information for learning, suitable algorithms and training methods, and publicly available datasets. However, as illustrated in Figure 2, the BIM domain remains unexplored. This section discusses these four aspects (data representation, algorithms, training methods, and datasets) in the development trajectories of CV and NLP.

Figure 2. Data representation in various domains (this figure is modified based on Wang et al. (Reference Wang, Ying and Sacks2024)).

When converting human-understandable raw data into machine-accessible and learning-suitable representations, different AI domains adopt distinct approaches. In a CV, images are stored as pixel arrays representing color information. These arrays are structured as matrices that capture the spatial locality of images and can be efficiently manipulated using matrix operations. In NLP, natural language is processed as tokens and mapped to numerical representations. Tokenization involves splitting text into smaller units, such as words or subwords, and mapping each token to a unique integer based on a vocabulary. For example, Figure 2 illustrates an example of word-based tokenization, where each word stands for a token and each token is converted into a unique integer. During this process, tokens preserve the sequential nature of language, allowing the downstream algorithms to capture semantic and syntactic dependencies efficiently.

Algorithms are often specifically designed to leverage the unique features of the data representation. In CV, Convolutional Neural Networks (CNNs) were developed to extract spatial features, such as edges, textures, and shapes, from image matrices (LeCun et al., Reference LeCun, Bottou, Bengio and Haffner1998). CNNs use convolutional operations, where kernel filters slide across pixel neighborhoods to detect patterns, and pooling layers downsample spatial information for efficient feature extraction. These operations are tailored to the matrix representation.

In NLP, algorithms have also been designed to address the challenges of representing languages in sequenced tokens. Word2Vec, a seminal embedding work, maps tokens to dense, high-dimensional vectors, capturing semantic and syntactic relationships between words (Mikolov, Reference Mikolov2013). These embeddings allow machines to process language in a meaningful and efficient way. More recently, the Transformer architecture has profoundly impacted NLP by introducing the attention mechanism, which allows the model to weigh the importance of different words in a sentence relative to each other (Vaswani, Reference Vaswani2017). Because the token representation lacks inherent sequential structure during parallel processing, transformers incorporate positional encoding to enable the attention mechanism to capture sequential dependencies while processing tokens in parallel (Vaswani, Reference Vaswani2017).

The success of generative pretrained transformers (GPT) underscores the critical importance of training methods tailored to a domain’s scenarios. ChatGPT, released in 2022 based on the GPT-3.5 series models, marked the first time a large language model captured widespread public attention (OpenAI, 2022b). The dataset and algorithm architecture of GPT-3.5 and GPT-3 remained largely unchanged (OpenAI, 2022a). However, GPT-3.5 adopted Reinforcement Learning from Human Feedback (RLHF) as the fine-tuning method (OpenAI, 2022a). RLHF aligns the model’s outputs with human preferences and values by incorporating human feedback into the training loop. Specifically, human labelers prepare desired outputs for the language model in the stage of supervised learning. Following that, human labelers rank the quality of the language model’s responses to train a reward model, which is used to optimize the language model for aligning human preferences in reinforcement learning. Again, with similar algorithm architecture and datasets, this innovative training method enabled GPT-3.5 to generate more relevant and user-aligned responses, setting it apart from prior GPT models.

OpenAI-O1, which uses the strategy of the chain of thought to resolve complex problems step by step, outperforms previous GPT-series models (OpenAI, 2024). Recently, the DeepSeek-R1 model has been shown to perform comparably to OpenAI-O1, while requiring less computation for training (DeepSeek-AI et al., Reference Guo, Yang, Zhang, Song, Zhang, Xu, Zhu, Ma, Wang, Bi, Zhang, Yu, Wu, Wu, Gou, Shao, Li, Gao and Zhang2025). One strategy adopted by DeepSeek is to train a smaller student model distilled from a larger teacher model while retaining similar performance, a process known as distillation (Hinton et al., Reference Hinton, Vinyals and Dean2015). This demonstrates the effectiveness and economic efficiency of distillation on powerful base models and larger-scale reinforcement learning (DeepSeek-AI et al., Reference Guo, Yang, Zhang, Song, Zhang, Xu, Zhu, Ma, Wang, Bi, Zhang, Yu, Wu, Wu, Gou, Shao, Li, Gao and Zhang2025). It further highlights that advancements in training techniques and engineering optimizations can enhance model performance alongside improvements in algorithms and computational resources.

Additionally, a critical factor in advancing AI is the construction of large-scale datasets. In CV, ImageNet was the first large-scale image dataset, initially containing 3.2 million images across 5247 classes in 2009 (Deng et al., Reference Deng, Dong, Socher, Li, Li and Fei-Fei2009). By 2014, ImageNet had expanded to over 14 million images spanning 20,000 classes (Russakovsky et al., Reference Russakovsky, Deng, Su, Krause, Satheesh, Ma, Huang, Karpathy, Khosla, Bernstein and Fei-Fei2015). To maximize its potential, ImageNet was used for the annual ImageNet Large Scale Visual Recognition Challenge (ILSVRC), starting in 2010. In 2015, ResNet, a deep learning model, achieved a top-5 error rate of 3.57% in the ILSVRC, outperforming the estimated human error rate of ~5% for the same task (He et al., Reference He, Zhang, Ren and Sun2016). This marked the first time deep learning surpassed human performance in image object classification, demonstrating that large, high-quality datasets, combined with advanced algorithms and sufficient computational power, enable machines to outperform humans in specific tasks. Similarly, GPT-3.5 was trained on a diverse mix of datasets, including Common Crawl, which contains over 250 billion web pages before filtering and cleaning (Crawl, Reference Crawl2024).

In summary, we have identified four aspects of AI development:

1. 1. A learning-suitable data format that can represent the unique features of the domain information is essential. For instance, natural language is tokenized into sequences that preserve word order, enabling models to capture semantic and syntactic relationships.

2. 2. Algorithms are designed to leverage the specific properties of the data. In CV, operations such as convolution and pooling in CNNs are optimized to extract spatial features from image matrices.

3. 3. Training methods are tailored to domain requirements. For example, RLHF fine-tunes language models to align their outputs with human preferences by incorporating human feedback in a training loop. Distillation is used to retain the comparable performance of LLMs while reducing computation resources.

4. 4. The construction of large-scale datasets is fundamental to unleashing the potential of AI. Datasets like ImageNet in CV and Common Crawl in NLP provide the foundation for training models that excel in their respective tasks.

While it is important to acknowledge the critical role of hardware advancements (such as Graphics Processing Units) to enable the training of complex models, the development of computational hardware is beyond the scope of this study.

4.2. Graph learning for BIGs

Inspired by the experience from successful AI domains, we rethink how AI can be leveraged for BIM design. Here, we propose a conceptual framework of graph learning for building information models, as shown in Figure 3.

Figure 3. Conceptual graph learning for building information models.

First, graphs are adopted to compile and represent design data, as their flexibility enables effective integration of heterogeneous data, and graphs provide a format suitable for learning (Section 4.3). Second, the learning process is divided into two stages: embedding and pattern recognition. Embedding transforms multimodal BIM data—including geometry, attributes, and relationships—into a high-dimensional vector space, enabling efficient computational processing. Subsequently, pattern recognition algorithms leverage the resulting embeddings to detect statistical patterns and accomplish various graph-based tasks (Section 4.4). Training strategies should be specifically tailored to domain characteristics, supported by the construction of comprehensive, large-scale datasets (Section 4.5). The ultimate purpose of these learning processes is to support design-related applications, such as data enrichment and generative design (Section 4.6).

4.3. Graph representation

Design data are heterogeneous and complex. A BIM design model encompasses various types of data, including object geometries that define shapes and locations, attributes and properties for object behaviors, and relationships (Sacks et al., Reference Sacks, Lee, Burdi and Bolpagni2025). Additionally, a project includes user requirements and codes in PDF, 2D drawings, tabular schedules, and so on. Beyond these, BIM authoring software records behavioral data, such as user operation histories during the modeling process.

For collaboration and communication purposes, design models are typically exported from software into IFC files in the STEP format (IFC-SPF), where IFC serves as a neutral and open data schema (Borrmann et al., Reference Borrmann, König, Koch, Beetz, Borrmann, König, Koch and Beetz2018; buildingSMART, 2025b). During the export process, part of the design information is lost due to the unmatched data schemas (Inhan Kim and Seo, Reference Inhan Kim and Seo2012), and translation errors may occur (Venugopal et al., Reference Venugopal, Eastman and Teizer2015). From an interoperability perspective, IFC acts as a bridge for exchanging design models, enabling machines to access and allowing users to view models (Borrmann et al., Reference Borrmann, König, Koch, Beetz, Borrmann, König, Koch and Beetz2018).

Nevertheless, IFC was not originally designed for machine learning purposes. Even for simple projects, IFC-SPF tends to be complex and cumbersome. For example, the spatial location of a wall in an IFC-SPF file is stored using “IfcLocalPlacement,” which iteratively defines the relationship between the wall and other objects until it eventually references a specific point “IfcAxis2Placement3D.” While this pointer-based approach avoids redundant storage of the same data, the long and implicit chains make it challenging for machines to learn patterns.

The buildingSMART community has developed a series of tools to parse IFC-SPF files into other formats for wider usage (buildingSMART, 2025b), such as JavaScript Object Notation formats intended primarily for web-based data exchange (Afsari et al., Reference Afsari, Eastman and Castro-Lacouture2017) and RDF graphs for data integration and query (Pauwels and Terkaj, Reference Pauwels and Terkaj2016; Pauwels, Reference Pauwels2021). Users can read and use the resulting files more easily than they can IFC data files, despite the fact that they still conform to the complex data structures of the IFC schema. For example, building elements are still located by chains of “IfcLocalPlacement” objects that must be followed to derive global placement coordinates.

To simplify the graph representation, the LBD community has developed ontologies to guide the compilation of knowledge graphs in a more efficient manner (LBD, 2024). For example, the BOT ontology offers a direct structure to describe building topology (Rasmussen et al., Reference Rasmussen, Lefrançois, Schneider, Pauwels and Janowicz2020). However, during the conversion process, only partial design information is kept, while many attributes and all geometries are discarded (Bonduel et al., Reference Bonduel, Oraskari, Pauwels, Vergauwen and Klein2018). This limits the potential of machines to understand the design model as a human expert might, as the important 3D geometry information is omitted.

Although IFC models in various digital formats are technically machine-accessible, the inherent complexity of their data schema limits ease of implementation and practical use. Recognizing these issues, buildingSMART aims to revise the existing IFC schema to enhance compatibility with AI in the future (buildingSMART, 2024). We argue that the purpose of machine learning in the BIM domain should be oriented toward developing design applications, such as generative design and collaboration tools, rather than addressing the complexity of data schemas.

Therefore, we combine several existing ontologies and adopt a graph-based format to concisely represent and integrate design data in a way that could support machine learning. In BIGs, design data are organized using a core-extension layer structure: information suitable for graph representation is compiled into a core graph, whereas data not efficiently represented as graphs are retained in their native file formats and linked to the core graph (Pauwels et al., Reference Pauwels, Costin and Rasmussen2022; Ouyang et al., Reference Ouyang, Wang and Sacks2023). Specifically, in the core graph layer, nodes correspond to objects, node features encode object attributes, and edges represent relationships among objects. Other data are stored in their native formats, such as geometries in Polygon File Format (PLY) files. The file addresses are stored as node attributes in the core graph. This can effectively integrate the multimodality of design data and ensure efficient retrieval. A conceptual illustration of this representation is provided in Figure 3 (Representation).

The core-extension structure provides a centralized and graph-based representation to integrate diverse building data. A fixed and uniform schema for this integration is essential for achieving interoperability and consistency across software databases. We leverage existing ontologies to represent data in a customized and concise manner. In the subgraph, the BOT ontology is used to represent the building topology (Rasmussen et al., Reference Rasmussen, Lefrançois, Schneider, Pauwels and Janowicz2020). The terminology of object types and properties follows the buildingSMART Data Dictionary (bSDD), which is a collection of definitions of terms to describe the built environment (buildingSMART, 2025a). To link geometry files in the extension layer, the File Ontology for Geometry Formats (FOG) is adopted (Bonduel et al., Reference Bonduel, Wagner and Pauwels2020). Beyond subgraphs, the initial version of CBIM ontology can be used to represent interdisciplinary relationships, such as correspondence or equivalence (Ouyang, Reference Ouyang2023).

Lastly, we distinguish graph-based data storage from graph representation for machine learning. Depending on the application, the graph may require reorganization to align with specific learning objectives. For instance, in tasks such as space-type classification, a tailored graph might consist of space nodes and spatial relationships. In this study, we explore graph learning techniques that can be applied broadly to BIGs. The input is a multimodal design model, and the output could be high-dimensional vectors that are organized into a graph structure, facilitating generic and diverse domain tasks downstream.

4.4. Embedding and learning

Graphs can represent and integrate building information from software and files. Following that, embedding aims to process multimodal design data, such as geometries, attributes in texts, and relationships in graphs, to a high-dimensional vector space, from human-understandable data to a learning-suitable representation. Then, algorithms can leverage these embeddings to recognize statistical patterns serving for downstream applications. The conceptual learning process, integrating both embedding and pattern recognition, is shown in Figure 3.

4.5. Training and dataset

Training methods in CV and NLP have evolved significantly, providing valuable insights. Three primary approaches are widely adopted: supervised learning, self-supervised learning, and transfer learning. Supervised learning relies on labeled datasets, such as ImageNet for vision tasks, to map input data to desired outputs. Self-supervised learning minimizes the need for labeled data by employing pretext tasks, like masked language modeling for NLP (Taylor, Reference Taylor1953). Transfer learning often involves using pretrained models that have been trained on large datasets and then are fine-tuned for specific tasks with smaller datasets. For example, YOLO models trained on the large COCO dataset have been fine-tuned using domain-specific datasets containing personal protective equipment to improve the accuracy of object classification (Nath et al., Reference Nath, Behzadan and Paal2020; Wang et al., Reference Wang, Wu, Yang, Thirunavukarasu, Evison and Zhao2021). These foundational training methods can be adapted to address diverse challenges in BIGs.

In BIGs, the training methods may initially focus on specific tasks due to the lack of large-scale datasets. For instance, algorithms could be trained for consistency maintenance between architectural and structural models or energy simulations using limited, task-specific data. However, as more comprehensive datasets become available, there could be a two-stage training paradigm similar to NLP and CV. In the first stage, a large and generic graph-based model could be pretrained on diverse BIM data, learning fundamental design knowledge and principles. This stage aims to equip the model with broad, generalizable knowledge, such as design intent and constraints, building codes and regulations, and so on. In the second stage, this pretrained model could be fine-tuned for specific applications, such as proposing suggestions for resolving conflicts, generative design, and so on. This paradigm would enable the efficient reuse of pretrained knowledge across tasks, accelerating the development of domain-specific solutions.

For example, generative design could become possible by fine-tuning the large graph-based models. In a manner similar to the use of RLHF in NLP, the fine-tuning could align outputs with designer preferences and domain requirements. A generative design assistant could help architects by predicting and completing partial designs. Designers might start by modeling a few walls and a floor, and the system could propose the rest of the layout based on learned patterns and feedback from the user. By incorporating human corrections and preferences iteratively, the model would refine its predictions, improving its ability to serve as an intelligent design assistant. This feedback loop would not only enhance generative tasks but also ensure alignment with real-world design practices and objectives.

However, we cannot ignore the difficulties of acquiring and constructing the dataset. Unlike the computer science domain, where sharing open data is common, the construction industry is more conservative due to concerns over intellectual property, competition, and data privacy. Design models often contain sensitive information, such as building layouts or client-specific details, raising security concerns if shared publicly.

Could using an intermediate representation like graphs ease part of the concerns? For example, by compiling design models into graphs, we can filter out all the sensitive information but preserve only essential design information. This abstraction reduces the risk of exposing proprietary or private data while retaining the core elements needed for research and development. If such a method were widely adopted, it might encourage more stakeholders in the construction industry to share anonymized or generalized models, fostering collaboration and enabling the creation of the large-scale datasets critical for advancing AI in building design.

4.6. Goals of learning

Graph learning tasks in building design will be tailored to support domain-specific applications by leveraging graph structures. Common tasks include node classification, link prediction, link classification, property prediction, clustering detection, graph classification, graph regression, and graph generation (Hamilton, Reference Hamilton2020; Wang et al., Reference Wang, Sacks, Ouyang, Ying and Borrmann2024). In the context of BIGs, the focus of graph learning is not limited to algorithmic development but also to addressing the practical needs of the construction industry.

For instance, link prediction is expected to automatically instantiate relationships among objects across design disciplines, forming linked graphs. Given that design models may contain thousands of objects, manually generating object links is impractical. Automating this process through graph learning is essential for achieving object-level multidisciplinary collaboration.

Similarly, object classification can predict the types of BIM objects, supporting interoperability across different software. Graph regression facilitates simulations on graphs, such as predicting energy performance. Graph generation enables the creation of new nodes and edges, contributing to generative design processes. These tasks exemplify how graph learning can address challenges that are difficult to solve with existing technologies. In short, the purpose of graph learning in BIGs is to serve discipline-specific design applications that can consider interdisciplinary dependencies.

4.7. Open questions

Considering the proposed graph learning framework in Figure 3, we identify four key stages: representation, learning (embedding and pattern recognition), training, and task applications. Consequently, we summarize the key research questions related to these stages as follows.

1. Q6 What embedding methods can efficiently process multimodal BIM data (e.g., geometry, attributes, and relationships) and integrate them into a unified vector space while preserving semantic, contextual, and geometric information?

2. Q7 What novel graph learning algorithms can be designed to fully leverage multimodal embeddings for the following analysis and prediction tasks, such as interdisciplinary link prediction, dynamic anomaly detection, and graph generation?

   Q8 How can we construct large BIG datasets?

3. Q9 What training strategies can be devised to handle the computational demands of learning while serving domain-specific application scenarios?

5.1. Change coordination and propagation

Some BIM software supports single-domain collaboration on the same model. For instance, Graphisoft (2024) supports multiple architects to work simultaneously on the same architectural model from different devices. Beyond a single discipline, cloud-based CDE platforms, such as Autodesk Cloud Collaborate (Autodesk, 2024) or Trimble Connect (Trimble, 2024), are among the most advanced solutions for multidisciplinary collaboration. These platforms rely on file-based workflows to manage design models, which cannot track and propagate design changes across disciplines. For instance, even just modifying the dimension of an architectural wall, the architect needs to export the whole project as files and mark the changes with screenshots or other methods. The file-based workflow requires extensive manual intervention and coordination.

To address these limitations, researchers have explored a graph-based approach by representing each discipline’s model as a subgraph and linking these subgraphs through instantiated multidisciplinary relationships (Törmä, Reference Törmä2013; Sacks et al., Reference Sacks, Wang, Ouyang, Utkucu and Chen2022). By leveraging the relationships, objects from different disciplines are no longer isolated. From the data perspective, the generated links allow data to be tracked and propagated from one subgraph to another. In a pilot case study, an architectural model created in Revit and a corresponding structural model designed in Tekla were compiled as separate architectural and structural subgraphs and hosted in the cloud. A geometry computation algorithm (Ouyang et al., Reference Ouyang, Wang and Sacks2023) was used to instantiate corresponding to and host/hostedby relationships, linking objects from the two subgraphs. For instance, hosting relationships were established between an architectural wall and two structural columns in Figure 4(a).

Figure 4. Change propagation from the architecture Revit to the Tekla structure by leveraging the interdisciplinary links (adopted and modified from Wang et al. (Reference Wang, Ying and Nyberg2024)).

When architects modified the design, such as moving an architectural wall westward (Figure 4(b)), the changed objects were computed and uploaded to the cloud server. Leveraging the established relationships, the system identified that the change would affect the structural objects hosted by the architectural wall and propagated the geometry of the wall to the structural software. As a result, engineers received the updated geometry reference directly from the cloud server, which was seamlessly loaded into their software without relying on file exchanges, as shown in Figure 4(c). This pilot study demonstrates the use of interdisciplinary relationships to link objects across design disciplines, enabling the propagation of relevant design changes on graphs.

5.2. Consistency maintenance

Researchers have explored interdisciplinary constraint relationships on linked graphs to maintain design consistency (Wang et al., Reference Wang, Ouyang and Sacks2023). This functionality extends beyond basic change coordination and propagation, as it requires computers to interpret design constraints and use these established relationships to resolve conflicts autonomously. To achieve this, Wang et al. (Reference Wang, Ouyang and Sacks2023) defined a set of constraint classes by abstracting expert knowledge. These were subsequently translated into graph formats. Figure 5 illustrates examples of design constraint classes between architectural slabs and structural slabs. For example, the first rule is that structural slabs must be fully contained within architectural slabs in the thickness dimension. For computational efficiency, bounding boxes are employed to evaluate constraints along the z-dimension for this rule. Each constraint instance has a binary “isFulfilled” property to indicate its status.

Figure 5. Examples of design constraint classes among architectural and structural slabs (adopted from Wang et al. (Reference Wang, Ouyang and Sacks2023)).

In a laboratory case study, the authors instantiated constraints using object geometry features and designed a mechanism to detect inconsistencies and propose solutions. Specifically, architects modified the model by moving walls and extending two architectural slabs. The cloud server identified the inconsistencies between the modified architectural slabs and the existing structural slabs. It then computed and suggested an automatic resolution by enlarging the structural slabs to comply with the predefined constraints, thereby resolving the conflict.

This laboratory study validates the concept of maintaining consistency on linked graphs using constraint relationships. However, it faces several limitations. First, a generic method for encapsulating design intent and defining constraint classes is desired. Second, the constraint instantiation algorithms were tailored to the specific case study, with a limited application scope. Third, the mechanism for resolving conflicts does not consider the consequences—if the solution will cause new inconsistencies.

5.3. Graph-based version control

Managing design changes and versions remains a significant challenge in BIM. Existing file-based systems require participants to package entire design models as files for sharing, even when only minor modifications occur. This approach leads to redundant data storage and inefficient communication, particularly in large and complex projects. Researchers have proposed graph-based approaches to detect and manage design changes at the object level, as shown in Figure 6.

Figure 6. Graph-based version control (adopted from Esser et al. (Reference Esser, Vilgertshofer and Borrmann2022)).

In the graph-based version control, design models are compared with previous versions on the sender side to detect changes. Consequently, only changes are transmitted and applied on the receiving side, enabling object-level synchronization (Esser et al., Reference Esser, Vilgertshofer and Borrmann2022). For example, two architects collaborate on the same architectural model. If one architect adds a window, only the modified object and corresponding relationships are detected and transmitted to the other architect’s model for synchronization, eliminating the need to transfer the entire file. Furthermore, the graph-based version control can support automated merging. Multiple users can work on the same project concurrently, each maintaining a development branch. Once their design work is complete, these branches can be merged into the master model after checking without conflicts (Esser et al., Reference Esser, Vilgertshofer and Borrmann2023). These examples illustrate the feasibility of graph-based version control for three key functionalities: (1) incremental change detection, (2) merging design branches, and (3) design variants and history tracking.

However, several challenges remain unresolved. First, there is a need for a standardized ontology to manage design changes and versions in a uniform and consistent way. It should contain version numbers, design timestamps, status (e.g., active or inactive), and so on. Second, resolving conflicts when merging different branches and variants requires further research. At present, when design conflicts occur, systems can display incremental changes, allowing users to review and decide whether to accept or reject specific design variants at the object level (Esser et al., Reference Esser, Vilgertshofer and Borrmann2023). A more advanced functionality would involve systems identifying conflicts and intelligently proposing solutions. This capability would enhance automation as the discussed consistency maintenance in Section 5.2.

5.4. Concurrent design and engineering

In building design, the prevailing design paradigm is sequential engineering, where design and development are executed step-by-step within single domains (Prasad, Reference Prasad1995). This often results in poor coordination, design inconsistencies, and inefficiencies in multidisciplinary collaboration (Akponeware and Adamu, Reference Akponeware and Adamu2017). Researchers in the AEC domain have advocated for adopting concurrent design and engineering, which shifts the sequential workflow into simultaneous collaboration among multidisciplinary teams (Anumba et al., Reference Anumba, Baron and Duke1997; Anumba et al., Reference Anumba, Baugh and Khalfan2002). However, the inherent fragmentation of the construction industry poses significant challenges to implementing concurrent design.

Graph-based applications for change coordination and version control have demonstrated the feasibility of two essential features for enabling concurrent design: (1) maintaining domain-specific models while receiving synchronized updates of other disciplines from the cloud; (2) coordinating relevant changes across disciplines and software platforms; and (3) managing design changes at the object level. In addition, the concurrent design solution should furthermore be equipped with a communication platform where participants can be involved to communicate and comment on design models with precise locations. Additionally, this technology should support real-time collaboration and coordination, allowing participants to review the latest models and changes from any discipline and platform.

In practice, high transparency and synchronized collaboration may raise concerns among users, as partially developed designs are continuously accessible to others. To address this, a permission mechanism should enable users to control the visibility of specific model statuses, allowing them to manage what others can view. While this may limit the full real-time collaboration, it can still overlap workflows to shorten design cycles and improve overall efficiency compared to sequential design (Chen et al., Reference Chen, Lau, Yeung, Nyberg and Sacks2025).

5.5. Design issue detection

As design models are represented as graphs, another potential application is detecting design issues through anomaly detection. This can be achieved by identifying anomalous patterns, nodes, edges, or subgraphs on graphs. Graph anomaly detection has already shown significant success in other domains. For instance, in finance, subgraph-level anomaly detection is used on transaction graphs to identify patterns associated with fraudulent activities, such as money laundering (Pei et al., Reference Pei, Lyu, van Ipenburg and Pechenizkiy2021). In biology, detecting node-level anomalies in protein–protein interaction networks helps reveal potential causal genes for rare diseases (Kuzmanov and Emili, Reference Kuzmanov and Emili2013). Similarly, in social networks, user interactions are compiled as graphs to detect unusual behaviors, such as spam activity and internet attacks (Lamichhane and Eberle, Reference Lamichhane and Eberle2024).

Applying anomaly detection to BIGs can enable the system to monitor dynamic graphs and identify design issues, such as clashes, code violations, improper object placements, or unusual layouts deviating from established design patterns. Unlike existing studies that classify partial model graphs for code compliance (Bloch et al., Reference Bloch, Borrmann and Pauwels2023), this approach would operate on the entire design graph and dynamically detect anomalies.

In the future, anomaly detection could focus on identifying more abstract anomalies coupled with instantiated constraint relationships to ensure issue-free and code-compliant designs. Constraints provide explicit relationships for the system to validate designs, but not all design intents and constraints can be instantiated by rules. Anomaly detection can supplement this by identifying abstract patterns, such as unconventional spatial layouts, that are difficult to encapsulate as explicit languages. By combining constraints with advanced anomaly detection, BIGs could enable more comprehensive and intelligent design issue detection.

5.6. Graph-based life cycle data management

Information Containers for Linked Document Delivery (ICDD) aims to define an open and stable container format for exchanging heterogeneous files to facilitate the delivery, storage, and archiving of documents that describe an asset throughout its entire life cycle (ISO, 2020). The LBD community leverages semantic web technologies to implement the ICDD concept to manage design files in the life cycle (Senthilvel et al., Reference Senthilvel, Oraskari and Beetz2020).

The ICDD utilizes containers, which are structured collections of documents and graphs that link these documents (Göbels and Beetz, Reference Göbels and Beetz2022; Hagedorn et al., Reference Hagedorn, Senthilvel, Schevers and Verhelst2023). Documents could be arbitrary and heterogeneous, such as 2D CAD drawings, 3D BIM models, construction schedules, and external links, which are organized into folders with a hierarchy (Hagedorn et al., Reference Hagedorn, Senthilvel, Schevers and Verhelst2023).

Instead, the ICDD container can be conceptualized as a graph, where nodes represent files or objects, and edges represent relationships between them. Based on different granularities, links can be placed between files and objects (Hagedorn et al., Reference Hagedorn, Senthilvel, Schevers and Verhelst2023). For instance, linking 3D model files with 2D CAD drawings can enhance coordination. Researchers also proposed methods to link objects within files to objects in another file, such as linking the same wall in 2D and 3D models for an interactive evaluation (Borrmann et al., Reference Borrmann, Abualdenien and Krijnen2021).

The concept of ICDD is straightforward to leverage graphs to integrate and manage data via a project’s life cycle. However, the real challenges come from the methods to instantiate relationships. Existing studies illustrated the way of generating links by using the same identifier (Borrmann et al., Reference Borrmann, Abualdenien and Krijnen2021; Hagedorn et al., Reference Hagedorn, Pauwels and König2023). Beyond that, many links are still generated manually (Fuchs and Scherer, Reference Fuchs and Scherer2017).

5.7. Design completion

Design completion aims to assist architects and engineers in completing their designs. It could be similar to existing AI code assistant tools, such as GitHub Copilot (GitHub, 2025), which can complete code lines or generate code from descriptions. Technically, design completion can be regarded as a task of predicting nodes and edges based on existing graphs. For instance, when an architect begins designing an apartment by placing a floor and two walls (an initial graph), the system can predict the remaining elements of the room, such as walls, windows, and doors, by generating nodes and links. It can extend to varying graph depths. At one-step depth, the system predicts directly connected nodes, such as walls that complete the room boundary or windows that fit into existing walls. At multistep depth, the system predicts more complex objects and relationships, such as objects in adjacent rooms.

5.8. Detailing generation

Detailing generation transforms low-LOD designs into high-LOD representations by leveraging graph learning. This process can be framed as two core tasks: graph matching and graph substitution. Graph matching focuses on identifying and classifying low-LOD nodes or subgraphs within the graph. Graph substitution involves replacing low-LOD components with detailed high-LOD counterparts, which can be achieved in two different approaches. The first one is a similarity-based substitution. Using a preconstructed library of high-LOD subgraphs, substitution becomes a task of similarity computation. Alternatively, high-LOD designs can be generated directly using generative models.

Existing has explored to achieve the detailing design by transplanting high LOD BIM objects to lower ones (Jang and Lee, Reference Jang and Lee2024). It requires users to input both a low LOD model as well as a high LOD project model. The matching algorithm mainly utilizes object properties and class types from low LOD models to predict the potential object classes in high LOD models for substitution (Jang and Lee, Reference Jang and Lee2024). The framework heavily relies on the quality and relevance of the high LOD model. Misaligned input models can lead to mismatched substitutions (Jang and Lee, Reference Jang and Lee2024). Additionally, the matching algorithm focuses on properties without considering the broader relational context of objects (e.g., functional dependencies or connections), resulting in inaccuracies when dealing with complex architectural contexts, such as layered walls requiring waterproofing (Jang and Lee, Reference Jang and Lee2024).

On the other hand, graphs show the potential of addressing these limitations. Graphs naturally encode relationships that can provide the relational context for algorithms to learn. Graphs are scalable to represent and store different LOD objects and subgraphs, even for large and complex BIM models. Additionally, the dynamic property of graphs can iteratively update graphs and refine substitutions over time.

5.9. Paired design

Paired design generation focuses on generating models for one discipline based on another. For example, a structural design could be generated from an architectural model. BIGs, with the ability to encode linked graphs, have the potential to extrapolate the entire structural graph from the architectural graph. The system could recommend multiple structural design options, ensuring that generated models are conflict-free and compliant with codes. Furthermore, this capability could extend to generating MEP designs after completing architectural and structural models.

Paired design generation can be formed as a conditional graph generation task, using a full graph as an input to generate another full graph. It could be a challenging graph learning task, as a similar scenario is even rarer in the computer science domain. In theory, the graphs in BIGs are highly interrelated, providing the basis for algorithms to learn. One possible direction is to develop Variational Graph Auto-encoders that can learn a latent representation of architectural graphs and decode it into structural graphs.

In a recent study, Xia et al. (Reference Xia, Liao, Han, Zhang and Lu2025) illustrated a simple approach to paired design generation by formulating the problem as an edge classification task. In their approach, they generate structural shear wall and beam layouts from architectural designs. The input is an architectural graph generated from the architectural CAD drawings by modeling walls, doors, and windows as edges in the graph (Xia et al., Reference Xia, Liao, Han, Zhang and Lu2025). The basic assumption is that structural elements must be embedded in corresponding architectural elements (e.g., structural columns must be located within architectural walls). Thus, the authors modeled the structural layout design as a link classification task on architectural graphs—predicting whether the architectural elements (edges) should be structural elements. They applied a GraphSAGE model for link classification, followed by a rule-based method for refining the GNN-generated layouts. The approach is too simple for application in practice, because the well-developed architectural graphs used as input are not representative of the starting point for conceptual design that structural engineers must use. In addition, the one-to-one relationship between architectural and structural elements does not hold in the general case. Nevertheless, the work suggests that a paired design may be feasible in the future.

5.10. Generative design from text

Another one is to generate design models from user descriptions directly. The input only requires requirements and description of this project, such as the type of this project, size and scale, usage, site information, client needs, and so on. It should analyze and understand the requirements and generate corresponding design graphs.

Existing studies have achieved the text-to-BIM generative design by leveraging LLMs, where LLMs are used to understand the requirements and generate programming codes that can call the BIM software Application Programming Interfaces (APIs) for constructing 3D models (Du et al., Reference Du, Esser, Nousias and Borrmann2024). This further expands the applications of LLMs in the BIM domain, but it meets the challenges of only generating regular, noncurved building models in the early design stage (Du et al., Reference Du, Esser, Nousias and Borrmann2024). It also requires human validation to ensure compliance with design requirements (Du et al., Reference Du, Esser, Nousias and Borrmann2024). These limitations stem from the fact that LLMs are designed for processing natural language in a tokenized format, with limited capacity to understand the complexities of building design. By contrast, graph-based systems have the potential to learn and represent design more effectively, offering possibilities for advanced generative design applications.

Zhao et al. (Reference Zhao, Fei, Huang, Feng, Liao and Lu2023) explored the use of graphs and textual descriptions to generate structural plans. The authors represented architectural CAD drawings as graphs and considered three design conditions: (1) building height, (2) peak ground acceleration of the design basis earthquake, and (3) characteristic ground period. These conditions were encoded as numerical vectors, concatenated with the original node and edge features, and then input into a GNN model for learning (Zhao et al., Reference Zhao, Fei, Huang, Feng, Liao and Lu2023). This study highlights the potential of integrating building elements with relationships and design descriptions to enhance generative design capabilities. However, this approach relies on a predefined architectural graph as input and is restricted to shear wall layout generation. Furthermore, it processes only three specific parameters, limiting its ability to generalize to complex design scenarios with diverse constraints. Incorporating LLM-based methods could enable the processing and embedding of a wider range of textual design descriptions, thereby improving scalability and adaptability. Nonetheless, the integration of LLMs with other techniques for efficiently embedding multimodal design data (text, relationships, geometries, etc.) remains unexplored, posing a critical and fundamental research challenge in BIGs, as discussed in Section 4.4.

5.11. Open questions

This section explores applications that are challenging for traditional file-based BIM techniques but become feasible after adopting graphs. Some of them have been validated in recent studies, such as change coordination, consistency maintenance, and graph-based version control. However, behind the validation, some engineering and research questions still remain, such as graph efficiency and complexity. Furthermore, we discuss several applications that heavily leverage graph learning, highlighting the development of advanced graph learning techniques as crucial for realizing these intelligent applications. We summarize the open research questions as follows:

• Q10 What is the performance of linked graphs with the latest technologies in real-world scenarios in terms of efficiency and complexity?

• Q11 How can learning algorithms efficiently identify and resolve inconsistencies (e.g., geometric clashes or code violations) while incorporating explainable AI techniques for transparency?

• Q12 What graph learning methods can be developed to support various levels of generative design, from design completion and detailing generation to generation from text?

• Q13 How can graph anomaly detection techniques be tailored to detect unconventional patterns, design inconsistencies, or code violations, and how can they integrate established domain-specific constraint relationships?

• Q14 What other practical applications can be developed by leveraging graphs and graph learning? For example, can BIGs support the automatic generation of bills of quantities and construction schedules? Might they be used to compile data for simulations of building performance or of production progress, both in the context of building digital twins (Sacks et al., Reference Sacks, Brilakis, Pikas, Xie and Girolami2020)?