Advancing Semantic Enrichment Compliance in BIM: An Ontology-Based Framework and IDS Evaluation

Abstract

As BIM projects grow in volume and complexity, automated Information Compliance Checking (ICC) is becoming essential to meet demanding regulatory and contractual requirements. This study presents novel controlled vocabularies and processes for the management of information requirements, along with a structured evaluation of the Information Delivery Specification (IDS) and its associated tools. The controlled vocabularies are important as they provide support to standardization, information retrieval, data-driven workflows, and AI integration. Information requirements are classified by input type and project interaction context (phase, origin, project role, and communication), as well as by applicability (data management function, model granularity, BIM usage, and checkability). The ontology comprises seven categories: identity, geometry, design/performance, fabrication/construction, operation/maintenance, cost, and regulatory category, each linked to verification principles such as uniqueness and consistency. This enables systematic implementation of validation checks aligned with company and project needs. We introduce three ICC workflows in relation to the BIM authoring tools (inside, outside, and hybrid) and suggest key criteria for the functional and non-functional evaluation of IDS tools. Empirical results from a real project using five IDS tools reveal implementation issues with the classification facet, regular expressions, and issue reporting. The proposed ontology and framework lay the foundation for a scalable, transparent ICC within openBIM. The results also provide ICC process guidance for practitioners, a SWOT analysis that can inform enhancements to the existing IDS schema, identify possible inputs for certification of IDS tools, and generate innovative ideas for research and development.

1. Introduction

The prevailing understanding of project information delivery is defined as a cyclical interaction between information providers and specifiers, excluding information consumers. As this exchange becomes increasingly central to project execution through the adoption of Building Information Modeling (BIM), it underscores the growing need for more robust and automated compliance checking to ensure data quality, consistency, and trust.

The Architecture, Engineering, Construction, and Operations (AECOs) industry has witnessed a surge in model checking. This rise was fueled by the wide adoption of BIM-based design tools and cross-disciplinary design BIM coordination. Initially, model checking focused mainly on geometry; however, as BIM projects and their applications have expanded, alphanumeric information has begun to receive the much-needed attention it deserves. The ISO 19650 framework was a response to the need for better information management, where the specifier (the appointing party) defines what information is required, and the information provider (the appointed party) is responsible for ensuring the model meets those requirements. Crucially, both parties guarantee compliance.

Model checking in BIM involves verifying that a digital model complies with specific requirements, standards, and regulations, which can be carried out manually, semi-automatically, or fully automatically. Manual and visual checking is straightforward but time-consuming, error-prone, and inefficient on large, complex projects with frequent changes, which can lead to additional project costs and delays. Automating model checking, conversely, leverages software and predefined rules to systematically and quickly analyze the BIM model. This requires translating human-readable requirements into a machine-interpretable format. Automation of ICC can reduce interactions between the appointing and appointed parties.

This study focuses on the capabilities of Information Delivery Specification (IDS), a recent buildingSMART standard designed to overcome the inflexibility of existing tools and enable the desired “white-box” workflow. IDS offers significant advancements in defining and unifying information requirements. As a machine-interpretable XML definition of alphanumeric Exchange Information Requirements (EIRs), IDS enables the specification of semantic information attached to specific BIM objects at particular project phases. IDS ensures the validation of Industry Foundation Classes (IFCs) for clients, modelers, and other stakeholders, providing a solution for reliable and predictable workflows in project information exchange. We can anticipate that the IDS will become a core reference document, forming the basis for contractual agreements in BIM project delivery. In a previous study [1], we primarily focused on checkability and model mapping to IFC. Figure 1 illustrates the overall process of implementing and validating alphanumeric information requirements with the use of IDS.

The process begins with specifying information requirements (A1), which involves identifying project needs and aligning them with relevant standards, resulting in Exchange Information Requirements (EIRs). The alphanumeric subset of EIR is then translated to IDS (A2), producing a machine-readable IDS XML file using an IDS authoring tool. Finally, information delivery (BIM) is checked (A3) against these specifications using an IDS Checker Tool. The activities and arrows shown in red represent the focus of this study: translating information requirements into IDS-compliant specifications, identifying the limitations of automation (including schema and tool implementation), and executing compliance checking. These elements are critically examined through selected views, requirements classifications, ontology structuring, workflow design, tool evaluation, and practical case validation.

Controlled vocabularies (taxonomies, classifications, thesauri, and ontologies) reduce ambiguity in construction project information by unifying definitions and clarifying domain-specific terminology, improving data integration and interoperability between BIM, digital twin systems, and asset management frameworks, and enhancing retrieval accuracy. Standardized definitions support data-driven workflows, cross-platform communication [2], and help automate routine tasks, as well as facilitate AI integration with significant reductions in manual effort.

While IFC-based model validation has been explored in several studies using rule-based approaches (e.g., MVD (Model View Definition) or custom checking frameworks) [3], these typically focus on geometric or spatial compliance rather than structured alphanumeric information. The use of controlled vocabularies and processes for automated Information Compliance Checking (ICC) with IDS evaluation remains underexplored. Our study addresses this gap by combining ontology-driven structuring with empirical IDS validation, offering a novel and practical contribution to the current literature.

This study presents several novel contributions, grouped into two key areas, that target gaps in the formalization and empirical validation of the IDS:

• Conceptual development: This study outlines the conceptual development of controlled vocabularies, ICC workflows, and process models, all designed to standardize IDS-based implementation. Specifically, we introduce a novel Ontology for Requirements Checking (ORC) to provide a new layer of semantic precision for requirement definitions—an element currently missing in the ecosystem. Furthermore, we developed novel ICC workflows and associated process models, which represent a significant advance by establishing a formal, repeatable structure to replace current ad hoc approaches.
• Empirical development: We present, to our knowledge, the first independent and comparative evaluation of how IDS is implemented across different commercial software. This evaluation is driven by a fundamental question of reliability: when provided with identical input—the same specification and the same model—do different tools converge on the same compliance results? Our study investigates the extent to which IDS checkers consistently identify elements to check, how they execute the checks, and whether their interpretations diverge. This inquiry addresses the significant gap created by the current situation of self-declared vendor compatibility, which has thus far lacked external validation. The goal is to provide novel evidence and objective insights needed to support the reliable deployment of IDS.

The complexities of model checking—specifically, information exchange and compliance verification—require a precise vocabulary; therefore, the next section defines key terms and reviews the relevant literature.

2. Terminology and Literature Review

Terms such as clash detection, model checking, model validation, validation checking, smart object checking, and quality checking are often used interchangeably, despite nuanced differences. “BIM-based Model Checking” (BMC) was introduced as a broader unifying term [4], and “Compliance Code Checking” (CCC) [5] serves as a more specific term focusing on the verification of building codes. Software platforms frequently use different terminologies to differentiate their solutions. We use “ICC” (Information Compliance Checking) to denote the compliance of alphanumeric information, a process that requires two inputs: the requirements and the model to be checked. Compared to other methods for specifying and validating information requirements—such as Information Delivery Manuals (IDMs), Model View Definitions (MVDs), Product Data Templates (PDTs), and SHACL-based rule systems—our proposed approach addresses a distinct gap by focusing specifically on alphanumeric ICC supported by structured ontologies and IDS-based workflows. A comparative analysis of IDSs, IDMs, MVDs, PDTs, and SHACL [6] highlights that no single approach fully addresses all technical, semantic, and process integration needs. IDS is distinguished by its clarity and compatibility with openBIM workflows; however, it still has deficiencies in expressiveness and validation coverage.

In the follow-up subsections, we will dissect the imperative (cost, time, and quality) and overall mechanics for alphanumeric information compliance, then examine identified implementation obstacles, and stress the importance of the “white-box” approach. The three essential drivers for the development and advancement of the “white-box” model of information requirements compliance checking may be summarized by the following:

• Transparency: Clear checking logic builds trust, repeatability, and troubleshooting.
• Customizability: Users can adapt checks to specific needs and ensure reusability.
• Extensibility: New rules can be added to accommodate new project demands and evolving standards.

2.1. The Imperative of Compliance: Time, Cost, and Quality

Eastman [7] foresaw that model checking would become a ubiquitous tool across the building lifecycle, standardizing evaluation and promoting consistency [8]. The integration of ICC into design is not merely good practice; it is an economic imperative that saves time, reduces costs, and ensures higher-quality deliverables.

Reusable, ontology-based rule libraries provide a path to efficiency and scalability, significantly reducing the time required for compliance verification. Automated compliance checking workflows in BIM environments enable a reduction in model review time from hours to seconds [9] and from a weekly workload to only a couple of hours [10,11]. Object-oriented and rule-based automation yields large time savings but also requires investment in model creation and substantial time to rule encoding. Although these implementations typically involve increased upfront costs, as noted in most construction IT applications, the financial repercussions of errors are considerable; for instance, an expenditure of GBP 800,000 for ramp adjustments [12] on a London housing project was attributable to a design oversight, with as much as 40% of problems originating from design-phase errors [4]. Unresolved design issues can inflate project costs by 14.21% [4,13], highlighting the importance of ICC. It was reported that accuracy exceeds 96% when using knowledge graph-based checking [9]. Automated quality control in BIM models has resulted in a 30% reduction in failing elements, thereby enhancing model accuracy and project quality [14]. Rule-based automated code checking detects more nonconformities and avoids false positives compared to manual checklists [15]. Implementing LLM models can ensure accurate reporting of visual observations [16]. IDS can enhance design efficiency and model quality with early integration and automation.

2.2. The Mechanics of Checking: Concepts and Capabilities

Automated compliance checking of alphanumeric information is a complex process. Project requirements evolve, and information varies across stages and disciplines. The model breakdown structure adds additional variability. Utilizing automated approaches with domain-specific tools enhances efficiency and minimizes errors. These tools align better with specialized workflows.

IDS was not designed for complex rule logic, but we can learn from rule-based systems. The core of compliance checking, whether traditional or BIM-based, involves evaluating models against specific clauses or object behaviors [12]. This relies on a consistent information structure, defined requirements, clear rule structure, logical rules, and predictable outcomes. Effective implementation of rule-based systems depends on four key capabilities [7]:

• Rule Interpretation: Translating human-readable rules into machine-processable.
• Model Preparation: Ensuring that the model contains all necessary and syntactically correct data.
• Rule Execution: Applying the model to defined rules, enabling the identification of issues.
• Reporting and Checking: Generating clear and auditable compliance reports.

A “traditional” manual approach was contrasted with a modern, automated sequence [17] that distilled rule content, transcribed it to a rule language, transformed model data into knowledge representation, and executed computable rules within an engine [18]. The RASE (Requirement, Applicability, Selection, and Exception) stands as an applicable ICC approach, structuring rule document content into these four categories to organize and map logic for processing [19,20,21].

Checking systems can be implemented as BIM Authoring Environment plugins or within IFC-based model viewers and checkers [22], allowing them to be used both outside and inside BIM Authoring Environments. While both offer validation, data interoperability across BIM platforms remains a significant hurdle, which can produce results that do not accurately reflect the information quality in the native environment. IFC-based code-checking workflows were developed using ontological constructs, later evolving into a rule-based semantic approach, regulation ontologies, and SWRL (Semantic Web Rule Language) rules. A BIM Rule Language was developed for information extraction and logic checks, utilizing SQL-like syntax and a lightweight geometry engine, thereby enhancing semantic enrichment [23]. Semantic technologies and RDF data models streamline rule-checking and reduce architectural/structural iterations, fostering integration, compliance, and lower management costs [24].

2.3. Compliance Checking Implementation and Obstacles

Compliance checking can occur inside a BIM Authoring Environment or in external software. A critical challenge lies in the verifiability and correctness of rules [25,26]. Most existing tools operate as “black boxes”—inflexible, hard-coded rule templates that can only be modified by software developers [27]. The Singaporean system, with e-PlanCheck, which relies on a proprietary FORNAX Library, exemplifies this opaqueness [27]. This underscores the need for “white-box” workflows. Reliance on raw IFC data for external checking can yield poor performance [21], whereas semantic web technology, such as RDF graphs and ontologies [28], can overcome IFC’s limitations and enhance BIM functionality. Ultimately, data format diversity across systems presents a key barrier to effective information sharing and automated compliance checking [29] with robust semantic frameworks. Different sectors tailor the automation of checking in BIM project delivery to meet their unique information management needs. Civil infrastructure projects apply automation, for example, generating requirements based on the BIM Execution Plans, to accelerate model verification and enhance workflow efficiency. In ports and waterways, implementations combine process mapping with BPMN diagrams and extended Industry Foundation Classes to address proprietary data challenges. The facilities and construction management sectors employ ontology-based knowledge management and federated data governance to support precise querying and secure data exchange. Across these domains, success hinges on modularization, expert validation, and adherence to open standards, despite ongoing challenges in standardization and interoperability.

Existing “black box” tools, IFC limitations, and data diversity hinder BIM information compliance, especially for alphanumeric data. Although dynamic ontologies offer a path to digitize rules and streamline verification by fostering a common understanding and adaptability [30], significant hurdles remain. To overcome these, we analyze research gaps and introduce a multi-faceted research methodology.

3. Research Gaps and Methods

Ontologies offer strong potential for improving alphanumeric compliance checks in BIM, but current methods still face key limitations. To address inefficiencies, this research directly addresses these issues by proposing and implementing a comprehensive methodology designed to bridge the existing gaps and advance the ICC.

3.1. Addressed Research Gaps

While existing studies, e.g., [6,31,32,33,34], have recognized the need for structured data delivery and explored emerging standard IDS, they highlight limitations in semantic coverage, automation, and consistency across tools for authoring IDS, BIM tools, and project phases. To better support semantic enrichment, seamless interoperability, and information requirements, this study complements existing studies and addresses the gaps by proposing an ontology-based approach to information requirements and by evaluating IDS implementations across workflows with the following focuses:

• Imperative for Ontology Standardization: The lack of standardized ontologies hinders the consistent and automated checking of alphanumeric information across platforms and workflows. Our research defines effective and standardized methods for classifying and representing alphanumeric information requirements. Crucially, it also seeks an ontology that addresses the multi-faceted aspects of checking, going beyond mere automation to enhance the quality of information across the entire project lifecycle.
• Consistent IDS-driven Automation for Alphanumeric ICC: We are exploring the boundaries of automated ICC for alphanumeric data in BIM, specifically investigating how effectively IDS can drive consistent automation. This includes addressing potential discrepancies between native checks internal to BIM Authoring Environments and external checks of openBIM models, ensuring accuracy and minimizing effort through the implementation of IDS.
• Overcoming Workflow and Interoperability Issues: Current alphanumeric information management workflows (e.g., element classification, material specifications) are fragmented and manual, resulting in significant interoperability gaps. We aim to identify bottlenecks that hinder the transformation of these systems into cohesive, automated ICC systems, particularly in addressing data fragmentation and loss when exchanging alphanumeric data outside native BIM tools.

3.2. Research Method

The research methodology is systematically divided into two main, iteratively refined phases: conceptual development and empirical development (see Figure 2). Conceptual development focused on foundational research. This included reviewing the literature, analyzing IDS and IFC schemata, and studying project information needs via EIRs and BEPs. The goal was to identify key data categories and define core checking principles, which led to the development of an ontology for alphanumeric information requirements. Empirical development is built on these foundations through practical case studies. It involved translating real project requirements into IDS, selecting tools, designing ICC workflows, and performing automated checks. Insights from the empirical part also helped refine the conceptual framework.

In previous research [1], we examined the checkability of information requirements in BIM using IDS and categorized them as explicit, implicit, or unsupported. Explicit checks can be directly mapped to elements like entity types, properties, or classifications, making them suitable for automation. Implicit checks involve derived values, relationships, or conditional logic, requiring interpretation and logical inference, which are more challenging to express within the IDS schema. Unsupported checks refer to requirements that cannot be validated due to technical or structural limitations of IDS. We also highlighted issues arising from discrepancies between the content of native BIM authoring tools and the exported IFC models, which can affect the validity of checks depending on how information is translated and mapped. In addition to functional checkability, we identified key non-functional criteria—such as usability, performance, scalability, maintainability, and reliability—that are essential for evaluating IDS tools. These factors are crucial for practical implementation and should be taken into consideration in future development.

Testing protocols for IFC-related interoperability in architecture and construction have been evaluated through multiple empirical studies that compare scenario-based, automated, manual, and utility-based methods [35]. An automated six-step procedure for verifying material completeness in structural models demonstrated high accuracy under testing conditions; however, its applicability is limited to structural analysis and does not encompass thorough verification [36], unlike numerous other studies that utilize comparative, experimental, and repository-based methodologies [37,38,39].

In contrast, our approach leverages IDS as a practical, tool-supported standard and enhances its applicability by embedding it within an ontology-driven framework. Unlike studies that focus on broad-scale benchmarking with a set of standard test files, our evaluation was grounded in a real-world project with concrete information requirements, a fixed delivery program, and actual project delivery. The BIM model used had to be delivered to an actual client under tight time constraints, necessitating the use of live data and project conditions. Our intention was not to develop a formal certification process or create a controlled test file suite but rather to assess how IDS-based ICC performs under realistic, project-driven demands.

This approach offers valuable practical insights into the implementation challenges and workflow integration of IDS, bridging the gap between conceptual information modeling and operational validation. This study thus adopts a process-oriented methodology to address ICC gaps and real-world variability in information delivery.

• Information Requirement Ontology: Proposition for the underlying ontology of alphanumeric information requirements for BIM.
• Process Automation and Remediation: This involved developing process maps for automated compliance checking and, critically, for feedback mechanisms to enable correction or guided remediation of identified inconsistencies and errors in models.
• ICC Workflow Examination and Tool Assessment: This final phase involved the comprehensive definition and empirical examination of distinct ICC workflows (internal, external, and hybrid). Concurrently, the software and tools employed within each workflow were assessed for their inherent constraints and capabilities.

3.3. Ontology of Requirements with Seven Categories for Semantic Enrichment

Systematic classification of project information requirements is crucial for effective information management and semantic enrichment within BIM, thereby fostering collaboration and interoperability. Beyond merely defining properties, robust data management is essential to govern evolving information landscape and clarify what is being exchanged. This requires understanding the origin of requirements, professional roles, and communication channels for continuous validation, where checkability (influenced by technology) dictates automation. In addition, taxonomic views on data management, the intended use (BIM uses), and the scale of its applicability are vital for the successful automation of compliance checking; this is illustrated in Figure 3. This holistic perspective ensures that compliance is not merely a static checklist but a dynamic process that delivers truly fit-for-purpose data, enabling efficient workflows and informed decision-making across the entire building lifecycle.

The ontology spans seven key categories: Identity, Geometric, Performance, Construction and Fabrication, Operational and Maintenance (O&M), Cost, and Regulatory Compliance (see

Table 1. Ontology for requirement checking with related validation principles.

Data Category	Definition	Examples of Properties	Some Validation Principles Used in Checking
Identity	Unique identifiers and basic descriptive information	ElementID, ElementName, GlobalID, GUID, Category, Type	Uniqueness Consistency Completeness
Geometry	Information describing the physical characteristics and location	Dimensions, Location, Rotation, Material, Weight, Volume, Projected Area	Accuracy Unit Consistency Relevance
Performance	Related to the functional capabilities and expected behavior of an element	ThermalResistance, U-value, FireRating, PowerConsumption	Validity Standard usage
Fabrication and Construction	Relevant to the manufacturing, assembly, and installation of elements	Manufacturer, ModelNumber, InstallationMethod, LeadTime, DeliveryWeight, PreFabricationStatus	Traceability Actionability Up-to-dateness
Operation and Maintenance	Data important for the ongoing use, maintenance, and end-of-life of an element.	MaintenanceSchedule, WarrantyInfo, ExpectedLifespan, ReplacementPartNumber, CommissioningDate, DecommissioningInstructions	Clarity Accessibility Sustainability Considerations
Cost	Financial information associated with an element.	UnitCost, InstallationCost, LifecycleCost	Accuracy Granularity Comperability
Regulatory Compliance	Information indicating adherence to relevant laws, codes, and standards.	BuildingCodeCompliance, CertificationBody, RegulatoryApprovalDate, PermitRequirements	Verifiability Jurisdictional Relevance Completeness

).

For each category in Table 1, verification principles such as accuracy, completeness, traceability, and standard compliance are proposed. This ontology not only provides a conceptual foundation for structured semantic enrichment management in BIM but also guides automation through the application of IDS tools, ensuring robust, lifecycle-spanning data governance.

3.4. Automating ICC Inside and Outside Authoring Tools and Types of Checks

In studied ICC scenarios with IDS we addressed three distinct check types:

• Simple Checks: Basic pass/fail validation for fundamental data presence.
• Detailed Semantic Checks: ensuring correctness and consistency across delivery milestones. This includes validating properties, data types, values, and actual data.
• Duplicate Semantic Enrichment Checks: Identifies redundant or conflicting semantic information, ensuring data uniqueness and preventing ambiguity (e.g., the same name value pairs in different property sets, where only one pair is allowed).

Figure 4 illustrates the two primary checking workflows for validating BIM models using IDS, with a specific focus on alphanumeric information compliance. ICC workflows can be executed outside or inside BIM Authoring Environments, as well as in both, i.e., hybrid approaches.

Figure 4 builds on the assumption that the IDS has been created and approved during earlier stages, as illustrated in Figure 1. The process model reflects the evolving practice of IDS-based ICC, where external validation remains widespread due to the maturity of model viewers and checking tools.

A growing trend in BIM practice is the integration of IDS capabilities directly within authoring tools, where information is continuously created, read, updated, and deleted (CRUD). This enables near real-time validation, selective export of only the data defined in the IDS, and better control over compliance throughout the design process. IDS can also function as a filter, limiting export to only required information. While semantic enrichment—such as classifications or metadata—can be applied externally to IFC files, some tools now offer round-trip workflows that allow enriched or corrected data to be reintegrated into the native model, helping maintain it as the single source of truth.

A key outcome of this process is the compliance report, documenting whether the model satisfies the IDS requirements. Even when checks are conducted internally, clients often validate models externally using exported IFC data. This creates a need for consistency between internal and external results. If data is enriched only outside the authoring environment, discrepancies may arise between native models. Ensuring alignment across workflows is crucial for reliable and auditable digital delivery. The three workflows—internal, external, and hybrid—differ in scope, integration, and feedback mechanisms, as summarized in

Table 2. Types of workflows for Information Compliance Checking (ICC) using IDS.

Aspect	W1: Outside BIM Authoring Tools	W2: Inside BIM Authoring Tools	W3: Hybrid Approach
Definition	Separate standalone software.	Embedded functionalities or plugins within BIM software.	Combines both internal and external tools.
Scope	May include broad, cross-model/inter-disciplinary checks for complex rules.	Limited to tool functionality, usually simple discipline-specific rule checks.	Comprehensive, leveraging internal (frequent) and external (specialized) checks.
Input	Exported BIM data (e.g., IFC). External rules can use IDS.	Native BIM data. Internal rules: limited external use of IDS.	Mix of native/exported data. Internal and external (IDS).
Interoperability	Relies on data export formats (e.g., IFC); potential issues may arise.	Direct native BIM data; limited by software capabilities.	Uses robust data exchange, native and open (IFC).
Design Integration	Loosely integrated; checks after iterations, risking late rework.	Tightly integrated; immediate feedback, less rework.	Immediate internal feedback, specialized external checks.
Feedback Loop	Delayed; issues found post-iteration; use BCF; may cause rework.	Immediate/near real-time; alerts for quick corrections and sharing.	Blended: Immediate internal alerts and reports from external tools.
Required Expertise	Export, rules definition, report interpretation.	BIM authoring software features and plugins.	Internal/external tools and diverse data flow.
Required Tools	Standalone software (e.g., Solibri Model Checker and BIMcollab), rule engines, etc.	Core BIM software (e.g., Revit, ArchiCAD); native tools or plugins (Dynamo Interoperability).	BIM software/plugins, external compliance software, integration platforms, and scripts.

.

Workflow W1, the most common in practice, involves exporting the BIM model (typically to IFC) and validating it in an external checker or viewer against the IDS. The effectiveness of this workflow relies heavily on proper translator settings and mapping; misconfigurations can cause incomplete or inaccurate validation.

Workflow W2 occurs within the BIM Authoring Environment, using visual scripts, built-in tools, or plugins to check alphanumeric parameters with internal IDS support. Some tools also enable the automated creation of properties and parameters based on the IDS, streamlining the setup of required information and ensuring alignment with delivery specifications. This integrated approach is increasingly supported by BIM software.

Workflow 3 is a hybrid workflow that combines both methods, enabling issues detected externally or internally to be corrected and revalidated directly within the modeling environment. In practice, BIM models are checked against various types of criteria, not only by IDS.

3.5. Practical Implementation of ICC

Figure 5 presents a structured process model for implementing IDS as part of an ICC strategy on a company and project level, which are also aligned with ISO 19650 stages:

• A1—Develop ICC Strategy: This initial phase defines the organization’s overarching ICC approach, aligning common requirements with company goals, digital strategy, and regulatory expectations. While not tool-specific, it sets the foundation for IDS.
• A2—Implement Company ICC: Here, internal standards (e.g., naming conventions, parameters, libraries, etc.) are formalized into reusable IDS templates and vocabularies. This phase uses classification of requirements, ontology for requirement checking, checkability principles, workflow types, and types of checks developed in this study. These become reusable across multiple projects.
• A3—Implement Project ICC: In this phase, the company-level IDS strategy is adapted to project-specific requirements, including client-provided IDS and contractual information needs. The integration of multiple IDS sources (company, discipline, client) is addressed, including conflict resolution and phase-specific filtering, which must be aligned with project BEP and overall company strategy.
• A4—Deploy (Mobilize Project): With validated IDS templates and workflows, the team sets up the environment (CDE, roles, and validation tools) and prepares for execution. This step connects the translated requirements to modeling environments.
• A5—Deliver BIM Project: The project team executes delivery and performs model validation using IDS-checking tools (internal, external, or hybrid). Feedback loops and compliance reports feed back into earlier stages for continual improvement.

The activities and connections shown in red represent the core contribution of this study: the implementation and testing of IDS-based workflows, the use of developed controlled vocabularies for classifying requirements and ontology for requirement checking, and integration strategies across company and project levels. These components ensure the delivery of structured, scalable, and semantically compliant information delivery.

4. Empirical Results

A real-world case study involving a 15,000 m² administrative building (Figure 6) was developed as part of the initial analysis presented in [1,40] to evaluate automated ICC workflows. The study served as a testbed for IDS-based validation, providing a comprehensive Information Requirement (IR) map aligned with the project’s EIR and BEP. These IRs were implemented across workflows both inside the BIM Authoring Environment and using external openBIM tools. This enabled a comparative assessment of IDS support and the consistency of validation results.

While this study focuses on tool evaluation, ontology structuring, and real-world IDS workflows, complementary insights into checkability mapping, non-functional tool requirements, and IDS auditing workflows are discussed in a complementary process-oriented study [1].

In this section, we focus on the functional aspects of IDS implementations, particularly how they support or limit automated ICC workflows. Given the range of available tools and integration strategies, our analysis is structured in two parts. First, we examine IDS usage outside authoring tools, where validation typically occurs in openBIM environments or dedicated model checking platforms. These settings offer flexibility but introduce challenges related to interoperability and data export. Next, we investigate IDS implementations within authoring tools, where tighter integration allows for real-time checking and potentially more streamlined workflows. This dual perspective highlights the current capabilities, limitations, and opportunities for improving IDS-supported ICC across the BIM ecosystem.

4.1. IDS Implementation Outside Authoring Tools

Without favoring any particular solution, this study evaluates five market-available IDS validation tools: BIMcollab, Solibri, ACCA usBIM.IDS Validator, BlenderBIM Add-on, and Open IFC Viewer (see Table 4 for exact versions). The assessment included applying identical IDSs to a consistent IFC model for validation, as detailed in

Table 3. Selected Specifications used in this study.

Code	Check	Used IDS Facts
C01	The model MUST contain entities that have IFC class IFCPROJECT that MEET the following requirements MUST HAVE attribute Name matching the pattern ^[A-Z]{2}-[A-Za-z0-9]{3}-[A-Za-z0-9]{4}-[A-Z]{3}-[A-Z]{3}-\d{3}-[A-Z]\d{3}$	Applicability: Entity
		Requirement: Attribute
C02	The model MUST contain entities that have IFC class IFCBUILDINGSTOREY that MEET the following requirements MUST HAVE attribute Name	Applicability: Entity
		Requirement: Attribute
C03	The model MUST contain entities that have IFC class IFCCOVERING (or: IFCDOOR; IFCFURNISHINGELEMENT; IFCMEMBER; IFCPROJECTIONELEMENT; IFCPLATE; IFCREINFORCINGMESH; IFCROOF; IFCSLAB; IFCSTAIR; IFCSTAIRFLIGHT; IFCWALL; IFCWALLELEMENTEDCASE; IFCWINDOW; IFCBEAM; IFCBUILDINGELEMENTPART; IFCCHIMNEY; IFCCOLUMN; IFCPILE; IFCFLOWTERMINAL; IFCBUILDINGELEMENTPROXY; IFCTRIMMEDCURVE) that MEET the following requirements MUST HAVE material matching the pattern RP-. *	Applicability: Entity
		Requirement: Material
C04	The model MUST contain entities that have IFC class IFCCOLUMN that MEET the following requirements MUST HAVE property ClassName of PSet ProtimPset (IFCTEXT) matching the pattern RP-ST-STCL-(Rectangular|Round|IPE|HEA)(-(Forks|Drop_Panel))??(-M3-R2[0-5])??	Applicability: Entity
		Requirement: Property
C05	The model MUST contain entities that have attribute GlobalId that MEET the following requirements MUST HAVE classification Uniclass2015	Applicability: Attribute
		Requirement: Classification
C06	The model MUST contain entities that have IFC class IFCCOLUMN (or: IFCBEAM; IFCSLAB; IFCFOOTING; IFCSTAIR) that MEET the following requirements MUST HAVE Uniclass 2015 classification	Applicability: Entity
		Requirement: Classification
C07	All structural walls and structural columns should be separated by ST levels	Applicability: Entity
		Requirement: part of

C05 and C06 are two different ways to define the specification: All structural elements within the structural model are classified according to Uniclass 2015.

and

Table 4. Results of study IDS validation (red: results that are inconsistent with other tools).

Specification	Software/Tool	Checkability	Passed	Failed	Total Elements
C01—IFC File Name	BIMcollab	Supported	0	1	1
	Solibri	Unsupported	-	-	-
	ACCA	Supported	0	1	1
	Blender BIM Add-on	Supported	0	1	1
	Open IFC Viewer	Supported	0	1	1
C02—Level Naming	BIMcollab	Supported	11	0	11
	Solibri	Supported	N/A	0	N/A
	ACCA	Supported	11	0	11
	Blender BIM Add-on	Supported	11	0	11
	Open IFC Viewer	Supported	11	0	11
C03—Material List	BIMcollab	Supported	N/A	N/A	0
	Solibri	Supported	N/A	36	N/A
	ACCA	Supported	299	36	335
	Blender BIM Add-on	Supported	299	36	335
	Open IFC Viewer	Supported	299	36	335
C04—Structural Column ClassName Correct/Wrong Value	BIMcollab	Supported	0	54	54
	Solibri	Supported	N/A	6	N/A
	ACCA	Supported	48	6	54
	Blender BIM Add-on	Supported	48	6	54
	Open IFC Viewer	Supported	48	6	54
C05—All Elements Have a Uniclass 2015 Classification	BIMcollab	Supported	85	352	437
	Solibri	Supported	N/A	352	N/A
	ACCA	Supported	133	6394	6527
	Blender BIM Add-on	Supported	133	4036	4169
	Open IFC Viewer	Supported	414	3755	4169
C06— All Elements Have a Uniclass 2015 Classification	BIMcollab	Supported	48	6	54
	Solibri	Supported	N/A	101	N/A
	ACCA	Supported	61	101	162
	Blender BIM Add-on	Supported	61	101	162
	Open IFC Viewer	Supported	162	0	162
C07—All structural walls and structural columns should be separated by ST levels	BIMcollab	Supported	144	0	144
	Solibri	Supported	N/A	0	N/A
	ACCA	Supported	198	0	198
	Blender BIM Add-on	Supported	198	0	198
	Open IFC Viewer	Supported	198	0	198

Legend: • N/A—not applicable; note: • red: results that are inconsistent with other tools; used software: • BIMcollab Zoom Version 8.2 (build 8.2.2), Solibri Version 14.9.0.38, ACCA usBIM.IDS CloudV, Blender Version 4.1, and Blender BIM Add-on V 0.0.240402.

.

The results, summarized in Table 4, highlight three critical aspects: the software’s ability to validate the specified check, the total number of elements recognized, and the count of elements that either passed or failed the validation process. These tools, known as IDS Checkers, parse both IFC and IDS files to perform checks based on the IDSs. This systematic evaluation helps in identifying advancements and gaps in automated Information Compliance Checking.

Our findings reveal significant gaps in the implementation, interoperability, and consistency of current IDS validation tools. These limitations directly impede robust and comprehensive automated compliance checking:

• Inconsistent Reporting: Validation results lack standardization across tools. While some display only passed elements, others focus solely on failed ones, and several omit the total count of elements checked. This inconsistency hinders complete validation assessment and cross-platform result comparison.
• Limited Entity Recognition: Tools like BIMcollab do not support multiple IFC entity classes within a single IDS. For instance, if a specification includes both IfcColumn and IfcWall, only the first class is recognized. This limitation leads to incomplete validations and potential misinterpretation of results.
• Incomplete Classification Facet Implementation: Some tools, such as Open IFC Viewer, exhibit deficiencies in handling the classification facet of IDS. They fail to correctly identify and report elements that do not comply with classification requirements, thereby affecting the accuracy of validation.
• Project Information Validation Failure: Solibri was unable to validate project-level information defined in the IDS, specifically checks related to the IFCProject entity. This limits its ability to support comprehensive model validation encompassing general project details.
• Regex Expression Incompatibility: BIMcollab incorrectly interprets regular expressions (regexs) defined in IDSs. As regexs are essential for pattern-based validation (e.g., naming conventions or property formats), this shortcoming restricts the tool’s usefulness in advanced validation scenarios.
• Insufficient BCF Support: Not all evaluated tools support exporting results in BIM Collaboration Format (BCF). The absence of this feature hinders seamless communication and issue tracking between platforms, making it more difficult to resolve identified issues efficiently in collaborative workflows.

4.2. Integrating IDS: A Look Inside BIM Authoring Tools

While IDS is not yet universally embedded in BIM authoring tools, several software vendors have begun integrating IDS to streamline ICC. These integrations help resolve common mapping issues and enable faster, in-context validation. For example, the DiRoots IDS Plugin for Revit enables users to read IDS files, validate Revit models, and directly map Revit parameters to IFC properties within the authoring environment.

We tested the DiRoots plugin (IDS4Revit 0.9.1) using the same IDSs and native Revit model (RVT) as used in our external validation comparisons (see Table 4 and

Table 5. General principles for checking all information and IDS capacity.

Principle	Description	IDS Capacity
Relevance	Is the information genuinely useful for the intended purpose of the BIM model (e.g., design, construction, operation)? Avoid collecting “data for data’s sake.”	Not directly supported. IDS does not assess the contextual usefulness or purpose-specific value of information. Indirectly, yes, by specification.
Consistency	Ensures consistent naming conventions, units, and data formats across the entire model and related datasets. Uses predefined data schemas where possible.	Partially supported. IDS can enforce formats, units, and some naming conventions, but not full cross-model consistency, e.g., through vocabularies.
Accuracy and Reliability	Information should be factually correct and derived from authoritative sources.	Not supported. IDS does not verify the correctness of data or factual accuracy.
Completeness	While not all information types are required for every project, this ensures that critical data fields relevant to the project’s purpose are populated.	Supported. IDS can require that specific information fields be present in the model.
Granularity	Data should be provided at an appropriate level of detail. Too much detail can be overwhelming; too little can be unhelpful.	Not directly supported. IDS cannot assess whether the level of detail is appropriate for a specific use case.
Interoperability	Data should be structured in a way that facilitates exchange and use across different software platforms and by various project stakeholders.	Supported. IDS is based on open standards (e.g., IFC) and supports interoperability and data exchange.
Maintainability and Updatability	Considers how information will be updated as the project progresses and as elements change.	Not supported. IDS defines requirements for a specific delivery but does not handle ongoing updates or maintenance.
Security and Privacy	For sensitive information (e.g., PII in O&M data), this ensures that appropriate access controls are in place and compliance with data protection regulations, such as GDPR, is maintained.	Not supported. IDS does not address access control or data privacy compliance.
Accountability	Defines clear roles and responsibilities for who is responsible for creating, validating, and maintaining each type of information.	Not supported. IDS does not define roles, responsibilities, or accountability mechanisms. It could be implemented through the provenance of data.

). Although the plugin is specific to RVT, it serves as a valuable proof of concept for implementing native IDS. Our observations highlight the following:

• Interoperability Challenges: The DiRoots plugin exhibited version-specific incompatibility, failing to recognize a valid IDS file in some instances. A negative test using a DiRoots template-based IDS confirmed this behavior, indicating potential limitations in schema support or validation logic.
• IFC Mapping: The plugin supports direct mapping of IDS-defined properties to Revit parameters. This ensures consistent data export to IFC and addresses a critical pain point in aligning alphanumeric information.
• Integrated Reporting and Interaction: Operating entirely within Revit, the plugin offers immediate validation feedback. Users can select, isolate, and correct semantic issues directly, eliminating the need for external BCF exchanges or separate coordination processes (see Figure 7).

At the time of writing, approximately 50 IDS tool integrations are available, supporting either the authoring of IDS, the verification of IDS-based requirements, or both. However, many of these are self-declared implementations—meaning they have not yet undergone formal certification by buildingSMART. This lack of certification introduces variability in how tools interpret and apply IDS rules. The functionality of these tools also varies widely: some offer basic query or graphic filtering for visual checking, while others—such as Solibri, BIMcollab, or specialized Revit plugins—provide more advanced validation workflows and tighter integration with BIM environments. This wide range of capabilities underscores the importance of establishing standardized certification processes and implementation guidelines to ensure consistent and trustworthy use of IDS across diverse software ecosystems.

4.3. Analysis of IDS Capacity

While IDS was originally designed to support discrete data exchanges, IDS can also be applied more broadly to help ensure that information requirements, as outlined under the Level of Information Need (LOIN), are met throughout a project lifecycle. IDS contributes to more predictable and verifiable information deliveries aligned with contractual and regulatory obligations.

IDS supports several key aspects of data quality. It enables robust completeness, allowing users to define mandatory attributes, properties, or classifications to ensure critical data is present in the model. Interoperability is also a core strength, built on open standards like IFC, which IDS facilitates through consistent data exchange across diverse tools and stakeholders. Consistency is partially addressed, with support for enforcing naming conventions, formats, and units; however, full semantic consistency requires integration with external vocabularies or ontologies.

Importantly, IDS schema, authoring tools (IDS builders), and checking engines (IDS checkers) should be analyzed separately. While the output of one component—such as a schema-compliant XML file from an authoring tool—is used as input for another (e.g., a checker), each part has its own technical constraints, implementation status, and limitations. Schema design governs expressiveness and syntax; authoring tools affect ease of use and rule definition; and checkers influence compliance validation and reporting. Understanding these layers independently is critical for successful IDS deployment and integration. Despite its strengths, IDS does not directly evaluate the relevance of information in relation to the project phase, user role, or specific BIM use. It also lacks capabilities for verifying the accuracy, reliability, or granularity of the information. Additionally, it does not support maintainability (versioning and updates), security (access control), or accountability (data ownership and responsibility).

Thus, while IDS offers a powerful mechanism for specifying structured information, effective implementation must be complemented by broader data management strategies (Table 5).

5. Discussion and Conclusions

This section discusses our research findings on automated BIM IC with IDS. We assessed the capabilities of IDS tools and workflow limitations, efficacy, data interoperability, and future directions for advancing automated compliance.

5.1. Discussion

This study builds upon prior research [1] that identified functional and non-functional limitations of IDS through a process-oriented lens. Expanding on that foundation, the present study combines a detailed analysis of IDS tool implementations with a critical examination of the IDS schema itself. Through empirical validation and ontology-based structuring, several limitations have been identified, ranging from inconsistent tool behavior and incomplete feature support to schema constraints that affect the expressiveness and precision of information compliance requirements. These findings are further contextualized in the SWOT analysis presented in

Table 6. IDS SWOT matrix.

S—Strengths	W—Weaknesses	O—Opportunities	T—Threats
Automates ICC and enhances collaboration with “White-box” openBIM. Builds trust as a Machine-readable and Human-readable. Checks field names, data types, values. Extensive support for IFC attribute/property. Supports regex.	No support for cross-referencing and item counting. Limited alphanumeric uniqueness checks. Limited integration and possible control over implementation in BIM authoring tools. Inconsistent BCF use. Weak exception handling possibilities.	Wider support in Authoring Environments. Make authoring of IDS easier via aliases and project-specific constants simplify IDS. Implements SQL-like unique/distinct checks. Historical data for context-specific IDS. Templates for projects/organizations, specific unified BIM uses, etc.	Low awareness levels and no readiness among key appointing parties Poor IFC export may lead to data loss and not relevant or even wrong checks. Overspecification may cause information overflow. Additional IRs may compensate for IDS deficiencies.

, which captures both the strengths and current challenges in achieving robust, scalable IDS-based ICC.

Our analysis of IDS validation tools directly addresses these research gaps, revealing significant inconsistencies that impede comprehensive automated ICC. External tools exhibit clear limitations, including inconsistent reporting, limited entity recognition, incomplete classification handling, and a lack of project-level validation.

These issues, compounded by poor regular expression compatibility and inconsistent BCF support, directly demonstrate the workflow limitations and interoperability challenges identified as research gaps. They hinder the seamless exchange and processing of alphanumeric data, making compliance difficult to manage and verify across platforms.

Conversely, integrated plugins within BIM Authoring Environments, like the DiRoots IDS Plugin for Revit, offer a more effective approach to bridging these gaps. Despite exhibiting version-specific interoperability issues, their seamless IFC mapping and direct reporting capabilities streamline issue resolution, highlighting the benefits of native integration over fragmented, external coordination methods. This contrast underscores the critical need for enhanced, integrated solutions to truly realize automated BIM compliance, moving beyond the current fragmented and non-standardized landscape.

Our approach aligns with the Ontological Research Standard by structuring the conceptual development phase around a formal classification of information requirements based on purpose, context, and applicability. The ontology was not developed as a general-purpose data model but rather as a pragmatic, task-oriented structure grounded in the semantics of information compliance. It incorporates key ontological principles—such as categorization, relationships, and constraints—to support reasoning and validation.

The modeling of the execution architecture builds upon this ontological foundation by embedding the identified requirement categories (e.g., identity, geometry, and regulatory) into three implementation workflows: external, internal, and hybrid. These workflows serve as executable structures that operationalize the ontology in real project contexts, guiding how requirements are mapped, validated, and resolved across tools and project phases. Rather than developing an ontological architecture in isolation, we embed ontological clarity into decision points, tool interactions, and validation checkpoints within the practical ICC process.

The proposed method is universally applicable. It builds on the open IDS and IFC standards, a domain-neutral ontology, and a platform-independent process model. This standardized modeling approach supports the reengineering and continuous improvement of requirements management in architecture and engineering. The method is adaptable to different facility types and project contexts. Its seven-category ontology and three ICC workflows provide a modular structure that supports phased adoption based on an organization’s digital maturity. The ontology is bridging information requirements and delivery workflows. It ensures that requirements are consistently classified by context—such as phase, role, and origin—and aligned with checkability criteria. This enables more specification, validation, and traceability of project information across delivery stages. The method was tested using both standalone model checkers and one BIM authoring tool (Revit). However, it remains tool-independent. Its principles are applicable across diverse BIM platforms and IFC-compliant workflows, supporting design, construction, operational, and demolition phases.

5.2. Limitations of This Study

While this study offers significant contributions to the automation of ICC for alphanumeric data in BIM, several limitations define the scope and generalizability of our findings. First, the development and testing of our methodology were constrained by the availability and complexity of selected real-world BIM project models rather than a controlled set of standardized test models. Although efforts were made to ensure data diversity, the proprietary nature of some project information and the time-sensitive delivery context limited the breadth of empirical validation. As such, the performance and efficiency gains observed may vary in highly customized or exceptionally large-scale projects, which are not represented in our sample.

Additionally, this study does not comprehensively cover all project phases or building systems, particularly complementary systems involved in building operation, such as Building Management Systems (BMSs), which introduce distinct information requirements and validation needs. Moreover, while our assessment of IDS tools and workflows reflects the technological state at the time of the study, the landscape is evolving rapidly, and future developments may render some tool-specific observations less relevant.

Importantly, the shortcomings identified in our evaluation—such as inconsistencies in the number of entities being checked, in classification handling, regular expressions, limited entity recognition, and varying support for IDS features—can serve as a basis for repeatable validation. These issues can be further tested across different models, tools, and project contexts, making our findings not only informative for current practice but also a reference for future benchmarking and improvement in IDS-based compliance workflows. A formal evaluation procedure, such as one expected from buildingSMART, will be instrumental in supporting “certified IDS tools”.

5.3. Conclusions

The benefits of automated Information Compliance Checking (ICC) are clear. It saves time and money by reducing the need for manual checks, helps avoid costly design errors and delays, and improves project quality by ensuring consistent and standardized model evaluation. When tied to contracts, IDS can play a key role—but this requires thoughtful setup.

To reach its full potential as a contractual tool, project teams must carefully maintain and audit IDS. Its use will likely need to expand beyond its current scope and support practical authoring tool integration and automation, particularly for public clients and small firms, as demonstrated in recent workflow-oriented evaluations [31]. However, applying IDS across different project phases can be difficult. For example, in public projects, naming a building product supplier before tender may breach rules—yet that same information is required to be on hand at handover.

Despite its promise, IDS still faces practical challenges. Tool support is inconsistent, with gaps in features and compatibility across software. Many tools lack robust handling of classifications and semantics, which limits the effectiveness of IDS in supporting advanced compliance checks. This study shows the importance of integrated workflows and standard data structures. Tools like the DiRoots plugin for Revit show how in-authoring validation can streamline the process, allowing faster issue detection and correction.

Accurate mapping from native models to IFC is crucial. For automated checks to function effectively, alphanumeric data must be well-structured and adhere to clear standards, such as ontologies. This study demonstrates that automating semantic checks and correcting issues early makes compliance faster and more reliable.

However, IDS could be complemented. It does not verify whether the data is relevant to the project phase, factually accurate, detailed enough, or handled securely. It also does not state who is responsible for the data. These issues limit its effectiveness. Recent research has shown that IDS can also be extended to support emerging sustainability goals, such as circularity and disassembly planning; however, capturing such data reliably in BIM still presents challenges [32].

5.4. Future Work

To make IDS a strong tool for information compliance, we need to develop new features and complementary systems. Future research should focus on combining IDS with the following:

• Contextual Reasoning Engines: To infer information relevance based on project phase, stakeholder roles, and intended model use.
• Data Provenance and Verification Systems: To track information origin and enable automated checks for accuracy and reliability against authoritative sources.
• Dynamic Granularity Metrics: To allow for specification and validation of appropriate levels of detail aligned with specific use cases, moving beyond simple checks.
• Lifecycle Management Protocols: To ensure information remains maintainable and updatable throughout a project’s evolution.
• Integrated Security and Privacy Frameworks: To embed access controls and data protection compliance directly within information delivery specifications.
• Accountability Linkages: To connect information elements to defined roles and responsibilities, potentially through hash (blockchain) to a relevant group of elements.

The findings highlight a broader challenge in digital project delivery. To unlock the full potential of BIM for verifiable, high-quality outcomes, IDS capabilities must evolve beyond static specification files. Without enhancements, projects will continue to rely heavily on manual oversight, which limits the scalability and trustworthiness of compliance automation. One critical shortcoming is the lack of built-in mechanisms for accountability and factual accuracy. IDS does not inherently link information to responsible roles or verify the truthfulness of model data, leaving a gap that hampers automated checks.

While this study focused primarily on IDS use for design-phase validation and information delivery, the role of IDS in supporting Building Management Systems (BMSs) and operation-phase use cases is a promising area for future development. For BMS integration, the structured delivery of alphanumeric data—such as sensor, control zones, commissioning values, and system classifications—is critical and has already been addressed in other studies [41,42]. In support of implementation, IDS could serve as a lightweight, standardized mechanism to define and verify the delivery of such data from design to operation. Although current IDS applications are mostly limited to early and handover phases, extending IDS to include BMS-related requirements (e.g., HVAC setpoints, asset IDs, and energy monitoring systems) could bridge the gap between BIM and facility operation workflows. Future research should explore how IDS can complement COBie or IFC 4.3 Asset and MEP extensions for this purpose, and how validation workflows could ensure that delivered data is directly usable by BMS platforms.

Artificial Intelligence (AI) offers a promising path to bridge this gap. By analyzing historical data from past compliance checks, BCF exchanges, and project outcomes, AI could learn to generate intelligent, context-aware IDS templates tailored to specific phases, disciplines, or asset types. These AI-generated specifications could also adapt dynamically to changes in project scope, enabling more resilient and automated compliance tracking across the lifecycle.

While some researchers have already explored the automatic generation of IDS from BEP [33], the potential for AI in managing information requirements is far broader. AI techniques could be used to extract structured IDS content by analyzing a range of unstructured and semi-structured sources, including guidance documents, written client or regulatory commands, industry standards, and archived data from past projects. Additionally, historical BCF (BIM Collaboration Format) comment threads offer a rich source of contextual insights, capturing recurring issues, compliance gaps, and clarifications that could inform requirement formulation. By leveraging such diverse inputs, AI can support the dynamic structuring, clustering, and refinement of IDS requirements, enabling a more responsive, intelligent, and learning-driven approach to information compliance across the project lifecycle.

Looking beyond specification generation, the convergence of AI and reality capture technologies opens new opportunities for as-built validation. Reality capture (e.g., 3D scanning, photogrammetry) combined with AI recognition could automatically identify building elements and properties. These observations could then be translated into structured data, generating a live IDS that reflects on-site conditions. The system could compare as-built data with design intent, instantly flagging deviations, missing classifications, or inaccuracies. This would reduce the effort needed to verify construction quality and compliance during handover and operation.

Moreover, generating IDS—as seen in tools like Plannerly—introduces a new layer of requirements definition and enforceability. When IDS requirements are derived directly from the BIM Execution Plan (BEP), a better scope of work is achieved, and they are linked to contractual milestones. Verified compliance can then automatically trigger payment releases, issue resolution workflows, or design freeze confirmations, which may potentially support the implementation of smart contracts. Combined with AI and reality capture, such a system could shift compliance from a reactive, manual process to a real-time, self-auditing mechanism. These advancements mark a shift from static rule interpretation to adaptive, data-driven compliance ecosystems.

Together, these developments signal a shift in how compliance will be managed. In summary, while IDS and ontology-based frameworks are foundational for alphanumeric compliance checking, the next generation of digital delivery demands intelligent, integrated, and verifiable systems. By embedding AI, accountability structures, and real-world validation into IDS-driven workflows, we can unlock scalable, transparent, and trustworthy automation, bringing BIM closer to its vision of seamless, data-rich lifecycle management.