Multi-Level IFC Exchange-Readiness Assessment Framework for Whole Life Carbon Inventory Preparation and Circularity Observability: Prototype and First Findings

Abstract

A persistent barrier to BIM-based whole-life carbon assessment (WLCA) and circularity assessment is uncertainty whether and to what extent exchanged Industry Foundation Classes (IFC) models contain relevant information needed to parameterise inventory inputs. Without explicit readiness checks, missing or generic semantics may only become apparent during dataset mapping, leading to reliance on undocumented assumptions. This paper proposes an early-stage framework for assessing the information exchange readiness of IFC building models for WLCA inventory preparation and selected circularity-oriented interpretation. The framework structures checks into progressive levels: L1 element identification and classification, L2 geometry and quantity availability, and L3 material definition and property assignment, producing coverage metrics and categorical issue records. L4a and L4b are defined as conceptual extensions toward broader decision-support information for whole-life carbon reporting and end-of-life management. Prototype implementation reports information gaps affecting element inclusion, including incomplete property definitions, assignments, material specifications, and missing quantity data. To support fairer comparison across heterogeneous element subcategories, based on the Royal Institution of Chartered Surveyors (RICS) Whole Life Carbon Assessment 2.0 standard, the framework applies assessment relative to what is relevant for each of the subcategories. The study indicates that transparent, level-based IFC exchange-readiness assessment can support more traceable WLCA inventory preparation and circularity-oriented interpretation by making unmet information requirements explicit.

1. Introduction

Whole life carbon assessment (WLCA) of buildings is commonly structured around life-cycle modules and explicit system boundaries to support reporting and comparison of design and scenario alternatives [1,2]. Data quality and uncertainty are treated as part of WLCA practice (documenting data representativeness and applying uncertainty factors) [2], indicating that result robustness depends on the quality and transparency of underlying inventory inputs [1]. At the building scale, reviews describe uncertainty as arising from multiple sources, including parameter uncertainty (quantities and datasets), scenario uncertainty (service life and end-of-life assumptions), and model uncertainty (method and modelling choices), so improvements in input reliability address only part of the overall uncertainty space [3,4].

Building information models are increasingly used to support WLCA by providing structured quantity and specification information and are increasingly discussed as a source of structured data for Digital Building Logbooks [5]. However, Building Information Modelling (BIM) information is not typically authored with life cycle assessment (LCA) requirements as a primary target, with recurring challenges such as reliability of quantity take-off, inconsistent or incomplete specification of properties, object labelling conventions, and coordination between discipline models [6,7,8,9]; while this does not imply that a model is geometrically incorrect, exchanged information may be semantically incomplete, inconsistent, or difficult to interpret consistently for an assessment inventory.

IFC (Industry Foundation Classes) is a practical focus for readiness checking because it is an open, international standard for the exchange of BIM data across software applications [10,11]. BuildingSMART, developers of IFC, and ISO position IFC 4.3 as the current international standard, reinforcing its role for an interoperability layer beyond single-vendor workflows [10,11]. Alongside, schema conformance alone does not ensure that the IFC model will contain the minimum (and consistently interpretable) information needed for repeatable quantity extraction, mapping to element groupings, or dataset linking [6,8], which motivates assessing information readiness at the IFC layer: whether required inputs are present, consistent, and extractable for WLCA and circularity-oriented analyses, without attempting to verify design correctness. Circularity-oriented evaluation similarly depends on traceable (and decision-ready) information, with persistent data gaps and fragmented enabling conditions being barriers to integrating circular and low-carbon strategies in construction [12].

Existing BIM-LCA studies identify data-quality problems [4,6,7,13], but fewer approaches operationalise these problems as category-specific, traceable checks directly over exchanged IFC files. This study therefore proposes a diagnostic IFC exchange-readiness framework that reports the extent to which exchanged model information is identifiable, measurable, interpretable, for material inventory preparation, environmentally linkable, and observable for selected circularity-relevant signals at the building-element-category level. The framework is aligned with WLCA reporting structures and is executed per building element category (BEC) using the RICS building element categorisation [1]. Each assessment level targets a research question and is developed as deterministic checks over IFC entities, relationships, quantities and properties:

• L1 (Identification readiness): Can elements be consistently identified and grouped for category-based WLCA reporting?
• L2 (Quantification readiness): Can category-relevant quantities required for WLCA be obtained from the model in a repeatable manner?
• L3 (Material and property readiness): Does the model contain minimum semantic and material evidence needed to parameterise inventory inputs?
• L4a (LCA linkability and traceability): To what extent does the model contain evidence that can support linking to external environmental datasets (product/type identity hooks)?
• L4b (Connectivity and circularity observability): Does the model contain relationship evidence that can support assembly interpretation and reveal circularity-relevant cues (reported as presence/coverage rather than correctness)?

The proposed assessment centres around category-based evaluation, with requirements applied as a minimal evaluable set (per category), ignoring information not meaningful for a specific category context, in the scope of this framework. Final levels, L4a and L4b, are reported primarily for observability and coverage due to the absence of available workflow outputs, reflecting the representation of traceability and assembly information being heterogeneous across modelling and export practices [6,7].

The framework is implemented as a prototype IFC analyser using an open-source parser (ifcopenshell, in Python) and produces spreadsheet outputs designed for inspection at multiple levels of detail. This paper contributes a WLCA-oriented definition of IFC exchange readiness structured into assessment levels, categorical operationalisation with prototype implementation and demonstration of outputs illustrating readiness limitations and implications for WLCA and circularity-oriented analysis. The paper is structured as follows: Section 1 motivates the problem and positions the contribution, Section 2 describes the proposed multi-level assessment approach and defines the indicators at each level, Section 3 presents representative outputs from the prototype implementation, Section 4 discusses implications, limitations, and applicability, and Section 5 concludes with key findings and directions for future work.

2. Methodology

2.1. Research Design and Assessment Boundary

This study adopts a prototype-based diagnostic research design. The developed prototype assesses whether exchanged IFC models contain sufficient structured information to support downstream WLCA inventory preparation and circularity-readiness checks. The method focuses on the availability, extractability, and traceability of IFC evidence for transparent downstream carbon/circularity assessment.

The assessment boundary is the exchanged IFC model, the IFC file treated as the available evidence source; the method does not assume that missing IFC information exists in the originating BIM environment. The resulting indicators should be interpreted as model information-readiness indicators, not building sustainability performance. The implementation of the framework can be found in Figure 1; it is a predefined deterministic checking workflow in which IFC entities are routed to Building Element Categories and evaluated through staged information-readiness levels.

2.1.1. WLCA Input Requirements vs. IFC Readiness Scope

WLCA is a structured method for assessing greenhouse gas emissions across the building life cycle. In the EU landscape, it is standardised in EN15978 [14], organised through life-cycle modules covering the product, construction, use, and end-of-life stages, with benefits and loads beyond the system boundary reported separately where relevant. RICS 2.0 [1] provides a practical reporting structure for whole-life carbon assessment, while EN 15978 defines the building-level life-cycle assessment logic for environmental performance assessment. Further, Level(s) indicator 1.2 frames life-cycle global warming potential (GWP) as a core EU building sustainability indicator [15].

At minimum, WLCA calculation can be based on quantities, units, and material or product names [1]. These inputs allow mapping of inventory items to generic or product-specific environmental datasets. However, inventory items should be identifiable and assignable to an assessment category, associated with a measurable quantity and unit, and described sufficiently to enable matching with an environmental dataset; otherwise, calculation is still possible but depends more on manual interpretation, and assumptions. Depending on the element and dataset, relevant quantities may include count, length, area, volume, or mass. Material composition, layer thickness, density, product identity and service-life information can further support quantity conversion, dataset selection and replacement-scenario definition [1,6].

IFC can represent parts of this information-entity classes, PredefinedType, assigned type objects, and classification associations can support element identification and allocation to Building Element Categories. Next, shape representations and IfcElementQuantity objects can provide geometry and quantities with project unit declarations. Material information may be represented through IfcRelAssociatesMaterial: individual materials, layered material sets, and associated thickness or density properties. Further, common property sets, Pset_ServiceLife, manufacturer and product identifiers, and document associations can provide additional specification and traceability. Environmental information may also be represented through environmental-impact properties or references to external documents and datasets [11,13]. Thus, IFC evidence may support more than the minimum WLCA inventory requirements by providing additional traceability between model objects and product information and documentation.

However, the ability to represent this information in the IFC schema does not mean it is consistently authored or preserved during export. As an example, quantities may be missing or require derivation from geometry, material names-generic, assemblies decomposed differently from environmental datasets [13], and document or product references being absent or not machine readable. Consequently, model-derived inventory preparation can still require manual interpretation and external information even when the IFC model is geometrically complete [6,7,13,16].

The IFC readiness scope of this study is limited to the model-derived inventory, focused on availability and extractability of evidence rather than completion of WLCA itself. L1 checks whether elements can be identified and assigned to assessment categories. L2 checks whether relevant quantities are available or computable. L3 checks whether material or product descriptors are available for dataset matching and if service life and documentation evidence are present for additional traceability; the latter two are treated as an information-readiness gap rather than a condition preventing WLCA calculation. L4a is treated as an additional traceability layer for environmental impact-related information; these are not required for every WLCA calculation, but they improve the auditability/transparency of the link between model objects and environmental data. The framework does not claim that missing traceability evidence prevents WLCA; it is focused on showing where the IFC exchange supports a direct inventory workflow and where the assessor must rely more significantly on assumptions or seek external documentation for clarification.

2.1.2. Circularity Information Requirements vs. IFC Readiness Scope

Circularity assessment in the built environment is less standardised than WLCA and remains characterised by fragmented strategies and indicators [17]. Therefore, this study treats circularity as a set of information requirements that may support interpretation of circularity-related performance.

In the European assessment landscape, Level(s) includes indicators that connect material accounting, adaptability, and end-of-life. Indicator 2.1 addresses bills of quantities, materials, and lifespans; Indicator 2.3 addresses design for adaptability and renovation; and Indicator 2.4 addresses design for deconstruction, reuse, and recyclability [15]. These indicators imply that circularity-oriented assessment requires information also on expected service life, adaptability, separability, reuse potential, and end-of-life recoverability.

These requirements can be grouped into three directions for IFC-based checks. First, material and product accounting requires identifiable elements, material composition, quantities, and service-life evidence, which is, as a baseline, checked in L2 and L3, due to overlap with WLCA. Second, adaptability and life-extension assessment requires evidence about whether spaces, systems, or components can be changed, accessed, maintained, or replaced; this is considered indirectly through information readiness because the exact assessment process is context-specific and requires significant stakeholder involvement [15,17]. Third, end-of-life recoverability requires evidence about product identity, documentation, connections, dependencies, and separability. These requirements have significant overlap with WLCA inputs but extend with additional information necessity about transformation capacity, connection logic, traceability, and future reuse or recovery pathways. The BAMB project [18] distinguished between materials passports and reversible building design as complementary enablers of circular construction. However, explicit checks for material passports are not standardised in IFC yet; thus, evidence could be both placed as an IFC document reference but also in manufacturer occurence fields.

In this early prototype, transformation capacity and future reuse/recovery pathways are tackled indirectly through information availability checks to support future assessment decisions. The tool searches for explicit IFC signals related to product traceability, manufacturer or product identifiers, system membership, direct connection relationships, and reversible connections. However, while IFC can represent several circularity-relevant information types, this does not guarantee that such information is authored, exported, or maintained in a given IFC exchange; thus, while L4b is interpreted as assembly and connection observability and L3-related material and property/document references, it does not prove technical reusability, economic feasibility, regulatory acceptance, or actual recovery outcomes. The prototype aims to be a useful tool for diagnosing this information absence and helping in clarification of assessment capacity boundaries.

2.2. Assessment Levels and IFC Evidence

Each BEC is assessed across five information-readiness levels, as found in

Table 1. Assessment levels used in the IFC information-readiness framework. The same level structure is applied across Building Element Categories, while the applicable checks and expected evidence remain category-specific.

Level	Readiness Question	Typical IFC Evidence Used by the Checks
L1	Can the object be identified and routed to a building element category?	IFC entity class; PredefinedType; assigned type object; explicit classification association; populated classification reference fields. Examples include IfcWall, IfcSlab, IfcBeam, IfcColumn, IfcWindow, IfcDoor, IfcCovering and MEP entities.
L2	Is the object measurable for the quantity relevant to its category?	Shape representation; element quantity sets; positive length, area, volume quantities and unit declared. Geometry-derived quantities are used as reporting fallbacks.
L3	Is material, property, service-life, documentation information present to support WLCA inventory preparation?	Material associations/layers or constituents; layer thickness; common property sets; Pset_ServiceLife; document associations/references.
L4a	Does the element contain evidence that could support environmental dataset linking or impact traceability?	Environmental impact property sets; explicit GWP values; element/product document/external references; usable quantity for EPD or dataset mapping.
L4b	Does the element expose explicit manufacturer traceability or connection cues for circularity-readiness interpretation?	Manufacturer properties; product identifiers; direct element connection relationships; realizing connection elements; mechanical fastener evidence; explicit system or group membership such as IfcSystem or IfcDistributionSystem (relevant mostly for HVAC).

. L1 evaluates whether elements can be identified and classified using IFC entity types, predefined types, type objects, and/or classification references. Of these, the type object might be the most nuanced - assigned IFC type object is connected as a shared source of product or assembly-level evidence for similar/family elements, possibly carrying shared classification, material, document, manufacturer, or environmental-reference metadata; while less explicit than direct assignment to an element, absence is treated as reduced readiness. L2 evaluates geometry and quantity readiness using shape representations and quantity take-off information such as area, volume, and length. L3 evaluates material, property, service-life, and documentation readiness using material associations/layers, common property sets, service-life, and document references.

L4a evaluates environmental linkability, including environmental impact property sets, explicit GWP or carbon-related values, EPD-style references, usable quantities for environmental mapping, and external material references. L4b evaluates circularity-related signals, including manufacturer information, product identifiers, direct connection relationships, realizing connection elements, system membership, and explicit mechanical-fastener evidence. Service life is intentionally assigned to L3 rather than L4b because it overlaps with L4a/supports the WLCA scenario definition but does not by itself demonstrate reversibility or circularity.

2.3. Prototype Implementation and Report Structure

The prototype is implemented in Python (using version 3.12.9) using IfcOpenShell (version 0.8.3) for IFC parsing. The active workflow loads an IFC model, passes it through a shared helper-function layer, applies BEC-specific category functions, and exports the assessment automatically to an Excel report. The user input required is selecting the IFC file and pressing “run” button.

The exported report contains an overview table, indicator scores, check percentages, check counts, check definitions, methodology notes, issue rows, and aggregated element rows. Element rows include category code, IFC class, object type, material name, quantities, and element counts. Issue rows document missing or ambiguous evidence, such as missing predefined types, uncertain external/internal classification or unsupported category routing.

Building Element Category Structure and IFC Routing

Elements are routed into Building Element Categories (BECs) using category-specific rules implemented in the prototype. The active reporting pipeline is organised around category functions, where each function collects relevant IFC entities, applies routing logic, aggregates element rows, records issues and generates category-level indicators.

The routing uses explicit IFC evidence as shown in

Table 2. Example Building Element Category routing rules used for categorization of elements in the prototype.

BEC Category	Routing	Ambiguity
1.2 Lowest floor/basement slab	IfcSlab.PredefinedType = BASESLAB.	Basement wall has no determistic flag in IFC-while retaining wall enum value is potential indicator, retaining wall does not necessarily imply basement wall. Should they be represented as IfcFooting, they are put to 1.1.
2.2 Upper floors	IfcSlab.PredefinedType = FLOOR.	Missing or unexpected slab predefined types are recorded as issues and treated as upper floors.
2.3 Roof structure	IfcSlab.PredefinedType = ROOF & IfcRoof	IfcRoof may be a “parent” group for slab elements, not necessarily always having shape representation, but is still included as information source. Roof coverings are not routed to BEC 2.3, but to roof finishes under BEC 2.5.
2.5 External envelope/roof finishes	IfcCurtainWall-directly. IfcPlate and IfcMember are included only where explicit curtain-wall connection is present. IfcCovering.PredefinedType = ROOFING is routed to roof finishes. Wall routing uses IsExternal = TRUE and/or non-loadbearing envelope evidence.	Facade members without deterministic curtain-wall host or system evidence are warned and skipped from curtain-wall routing. Walls with missing loadbearing evidence may be routed with warning.
2.6 Windows and external doors	All IfcWindow elements are included. IfcDoor elements are retained where Pset_DoorCommon.IsExternal = TRUE or also included if no specification is present.	Internal doors are skipped. Doors with missing external/internal declaration are retained in BEC 2.6 and reported as uncertain.
2.7 Internal walls and partitions	Internal wall evidence is derived from LoadBearing = FALSE, IsExternal = FALSE, or partition-style PredefinedType values such as PARTITIONING and MOVABLE.	Missing LoadBearing, IsExternal, or partition evidence is reported as a warning. If all deterministic signals are missing, the wall remains in the structural/frame-related wall category rather than being inferred as an internal partition.
5.x Building services	Service-specific IFC classes and systems are used, including IfcSanitaryTerminal, IfcDistributionSystem, IfcWasteTerminal, MEP distribution elements, IfcLightFixture, IfcSolarDevice, and IfcFireSuppressionTerminal. Routing uses a mix of IFC class, distribution-system membership, IfcRelAssignsToGroup, and class-specific PredefinedType.	For subcategories that depend on system purpose, deterministic system/group or class/predefined-type is required. If heating or domestic hot-water purpose is not specified as such evidence, elements are not defaulted to BEC 5.2.1. Missing system or group membership is reported.

, including IFC entity class, PredefinedType, type-object relationships, property sets, classification associations, material associations, spatial containment, and system/group assignments. For example, slabs are routed using IfcSlab.PredefinedType: BASESLAB is routed to BEC 1.2, FLOOR to BEC 2.2, and ROOF to BEC 2.3. Wall routing distinguishes structural frame, external envelope, and internal wall cases using Pset_WallCommon.LoadBearing, Pset_WallCommon.IsExternal, and partition-style predefined types (defined in the IFC schema). Ambiguous cases (absent structural/placement info) are retained with warning or information issues, to preserve traceability and prevent the method from overstating IFC certainty.

For building services, elements are assigned to specific BEC subcategories only where explicit IFC evidence supports the service purpose. This evidence may include service-specific IFC classes, PredefinedType, IfcDistributionSystem, IfcRelAssignsToGroup, system membership. Where service elements are present but lack deterministic evidence, they are excluded from subcategory-level readiness scores; the purpose is to avoid assuming category membership based on non-determinstic information.

2.4. Indicator Aggregation and Score Interpretation

For each category c and assessment level L, each check i produces a proportional evidence score $p_{L,i,c}$ between 0 and 1, calculated as the number of applicable elements satisfying the check divided by the number of applicable elements in scope. Empty or non-applicable checks are excluded from the weighted denominator.

The level score is calculated as:

$$S_{L,c}={\displaystyle \frac{{\sum }_{i\in A_{L,c}}{w}_{L,i}{p}_{L,i,c}}{{\sum }_{i\in A_{L,c}}{w}_{L,i}}}$$

where $S_{L,c}$ is the score for level L in category c, $w_{L,i}$ is the predefined weight of check i, and $A_{L,c}$ is the set of applicable checks for that level and category.

The weights are non-normative and are used to structure the interpretation of IFC information readiness. The weights in

Table 3. Prototype weights used to aggregate check percentages into L1-L4b readiness scores.

Level	Check	Weight
L1	In category scope	0.30
L1	Predefined type usable	0.20
L1	Type object assigned	0.15
L1	Classification reference present	0.25
L1	Classification fields usable	0.10
L2	Shape representation present	0.25
L2	Relevant quantity available	0.35
L2	Quantity is positive	0.25
L2	Functional unit basis usable	0.15
L3	Material association present	0.25
L3	Material detail available	0.25
L3	Common property set present	0.15
L3	Document reference present	0.15
L3	Service life present	0.20
L4a	Environmental impact property present	0.25
L4a	Explicit GWP value present	0.25
L4a	Element/type EPD reference present	0.25
L4a	EPD mapping quantity available	0.15
L4a	Material external reference present	0.10
L4b	Manufacturer present	0.25
L4b	Product identifier present	0.25
L4b	Reversible fastener cue	0.20
L4b	Connection element modelled	0.15
L4b	Direct connection modelled	0.10
L4b	System/group membership present	0.05

are prototype reporting weights used to aggregate multiple check-level values into diagnostic readiness indices. They are held constant across the assessed datasets to support internal comparison between IFC exports, but they are not proposed as standardized, normative or empirically validated quality weights. Their purpose is to make category-level comparison possible in the prototype output due to many individual checks per BEC, while the underlying check counts and percentages remain the primary evidence for interpretation.

2.4.1. Process Example: BEC 2.6 Windows and External Doors

BEC 2.6 covers windows and external doors. The prototype collects IfcWindow and IfcDoor entities. Windows are included directly, while doors are treated as external doors when Pset_*Common.IsExternal is explicitly true. If a door lacks an external/internal declaration, the tool records an issue because the BEC assignment is uncertain.

For BEC 2.6, L1 checks include element presence, usable predefined type, classification reference, and populated classification fields. L2 checks include shape representation and relevant quantities such as area, length, or volume. L3 checks include common property sets, material associations, documentation and service-life fields/connections. L4a checks environmental linkability through explicit environmental properties or EPD/document references with machine-readable quantity. L4b checks product traceability and reversible-connection signals, including manufacturer data, product identifiers, direct connection relationships, and modelled mechanical fasteners. For example, if all elements in BEC 2.6 have material associations, but 60% have usable material evidence (association does not equal meaningfulness of information), all have common property sets and none have document references or service-life information, then:

$$L3=0.25\left(1.00\right)+0.25\left(0.60\right)+0.15\left(1.00\right)+0.15\left(0.00\right)+0.20\left(0.00\right)=0.55.$$

2.4.2. Datasets

Two case datasets are used to demonstrate the prototype outputs. Dataset D2,

Table 4. Datasets evaluated with the prototype framework.

Dataset	Source	Stage	Toolchain	IFC ver.
D1.1	Educational building	Design	OpenBuildings Designer	IFC2x3
D1.2	Educational building	Design	OpenBuildings Designer	IFC4
D2.1	NordicLCA BIM4LCA project public data	As-built	Archicad	IFC4
D2.2	NordicLCA BIM4LCA project public data	As-built	Revit	IFC4

, was obtained from the publicly available project (BIM4LCA) repository of NordicLCA and is used solely as an external benchmark; the authors have no affiliation with the data provider and no involvement in the original modelling or publication of the dataset. Example Excel outputs for the public D2 case are provided in the project repository using filenames corresponding to the source IFC files. Dataset D1 is an anonymised education-building design-stage case exported from OpenBuildings Designer in versions IFC2x3 and IFC4. The case was selected because it represents a real project exchange model used in a WLCA workflow and therefore provides a relevant test of IFC exchange-readiness under non-curated project conditions. The authors were not involved in authoring the model. The cases are used to evaluate the diagnostic behaviour of the prototype across schema/export origin, not for evaluating design, modelling quality or sustainability of the project.

D1.1 and D1.2 represent the same anonymised education-building design-stage case exported from OpenBuildings Designer as IFC2x3 and IFC4. D2.1 and D2.2 represent the same public NordicLCA BIM4LCA case exported from Archicad and Revit, both as IFC4. D1 is therefore used to examine schema/export-version sensitivity, while D2 is used to examine export-origin sensitivity. In both cases, it can be expected that the physical building would have foundations, walls/structural elements, floors, finishings, windows, doors, HVAC systems, furniture, lighting fixtures, etc. The framework and prototype helps investigate which of these are schematically clear from the exchanged IFC-based digital model, and what level of information is present for circularity-related or WLCA-type assessment.

3. Results

3.1. Result Overview and Evaluated Datasets

This section reports the outputs produced by the prototype IFC exchange readiness assessment framework and evaluates what the outputs imply for WLCA and circularity-oriented decision readiness. Results are reported as category-wise readiness scores (L1-L4a/L4b) and extract tables supporting semi automated quantity and material summaries. The goal of results is to present the prototype report example and possible use for interpretation/diagnosis.

The prototype generates (split over sheets) element count overview per category, indicators table (category × L1-L4b scores + individual checks), issues log and Elements/bill of quantities (BoQ) table (grouped per-element/type quantities and material descriptors).

3.1.1. Exporter Sensitivity: D2 Paired As-Built Exports

A direct comparison of the D2 assessment outputs,

Table 5. Element counts and material coverage per BEC subcategory for D2 case comparing Revit vs. Archicad exports. Only subcategories with Element count $>0$ in at least one export are shown.

BEC	Subcategory	Revit		Archicad
		Element Count	Assigned Material	Element Count	Assigned Material
1.1	Foundations and piling	0	0	48	48
1.2	Basement retaining walls and lowest slab	2	2	0	0
2.1	Frame	206	206	220	220
2.2	Upper floors	28	28	24	24
2.3	Roof structure	10	9	10	7
2.4	Stairs, ramps and safety guarding	103	95	18	18
2.5	External envelope including roof finishes	51	4	6	6
2.6	Windows and ext doors	140	140	137	0
2.7	Internal walls	210	210	181	181
3.1	Wall finishes	16	16	0	0
3.3	Ceiling finishes	89	89	30	30
4.1	General Furniture fixtures	109	109	81	7
5.1.1	Sanitaryware	43	43	30	0
5.1.3	Drainage and rainwater	14	14	8	0
5.4.1	REG/RES	1	1	1	0
5.5	Life safety, fuel, lifts, and waste	1	1	0	0

and

Table 6. Category profiles for D2 comparing Revit and Archicad-origin IFC. Scores are the per-category level indices (L1-L4b) as defined in the Methodology. Categories shown are those populated in at least one export.

BEC	Subcategory	Element Count		Revit					Archicad
		R	A	L1	L2	L3	L4a	L4b	L1	L2	L3	L4a	L4b
1.1	Foundations and piling	0	48	0.000	0.000	0.000	0.000	0.000	1.000	0.600	0.400	0.350	0.000
1.2	Basement retaining walls and lowest slab	2	0	0.650	0.600	0.400	0.250	0.000	0.000	0.000	0.000	0.000	0.000
2.1	Frame	206	220	0.650	0.600	0.400	0.250	0.008	0.873	0.600	0.423	0.432	0.000
2.2	Upper floors	28	24	0.650	0.600	0.400	0.250	0.000	0.925	0.600	0.410	0.381	0.000
2.3	Roof structure	10	10	0.615	0.575	0.375	0.250	0.000	0.800	0.495	0.325	0.345	0.000
2.4	Stairs, ramps and safety guarding	103	18	0.499	0.448	0.381	0.250	0.000	0.800	0.464	0.400	0.350	0.000
2.5	External envelope including roof finishes	51	6	0.544	0.406	0.170	0.250	0.000	0.800	0.600	0.400	0.350	0.000
2.6	Windows and ext doors	140	137	0.678	0.600	0.400	0.270	0.032	1.000	0.600	0.150	0.250	0.000
2.7	Internal walls	210	181	0.650	0.600	0.400	0.250	0.000	0.876	0.600	0.400	0.350	0.000
3.1	Wall finishes	16	0	0.650	0.250	0.400	0.250	0.000	0.000	0.000	0.000	0.000	0.000
3.3	Ceiling finishes	89	30	0.650	0.427	0.400	0.250	0.000	1.000	0.600	0.442	0.350	0.000
4.1	General furniture fixtures	109	81	0.481	0.260	0.254	0.250	0.007	0.800	0.310	0.075	0.262	0.000
5.1.1	Sanitaryware	43	30	0.780	0.250	0.250	0.343	0.029	0.940	0.250	0.000	0.250	0.000
5.1.3	Drainage and rainwater	14	8	0.650	0.250	0.250	0.250	0.000	1.000	0.250	0.000	0.250	0.000
5.4.1	REG/RES	1	1	0.650	0.250	0.250	0.250	0.000	1.000	0.250	0.000	0.250	0.000
5.5	Life safety, fuel, lifts, and waste	1	0	0.650	0.250	0.400	0.250	0.000	0.000	0.000	0.000	0.000	0.000

, indicates the exchange sensitivity to the IFC export origin. Because the authors did not author the models, the comparison is limited to the information present in the exchanged IFC files and should not be interpreted as a controlled test of the authoring tools. This comparison should be interpreted as a demonstration of the different evidence structures exposed by the framework in two exchanged IFC files associated with the same case. The differences appear in category population, material assignment coverage, quantity availability and readiness profiles.

The Revit-origin IFC exchange contains 1023 assessed elements, while the Archicad-origin IFC exchange contains 794 assessed elements. Material assignment coverage is similarly higher, with 967 out of 1023 elements assigned material information (94.5%), compared with 541 out of 794 elements in the Archicad IFC (68.1%). Quantity availability is high in both exports, Revit reports quantity evidence for 987 out of 1023 elements (96.5%), while Archicad reports quantity evidence for all 794 assessed elements (100%). No explicit EPD availability is detected in either export.

The category distribution differs between the IFCs. Foundations and piling (BEC 1.1) is absent in the Revit-derived output but present in the Archicad-derived output (elementCount = 48). This should not be interpreted as evidence that foundation elements are absent from the Revit source model. Manual inspection in an IFC viewer suggested that footing in the Revit IFC was either not included as explicit footing objects or was represented through wall objects with unclear predefined type, therefore not assigned to BEC 1.1.

The most visible contrast is in BEC 2.6. The Revit IFC exchange has material assignment for all 140 windows and external doors, whereas the Archicad-derived output reports no material assignment for 137 windows and external doors, neither an assignment of potential material name through object type. Additional Archicad material coverage are in BEC 4.1 General furniture fixtures (7/81), BEC 5.1.1 Sanitaryware (0/30), BEC 5.1.3 Drainage and rainwater (0/8), and BEC 5.4.1 REG/RES (0/1). In contrast, the main Revit material-coverage weakness is BEC 2.5 External envelope including roof finishes, where only 4 out of 51 elements have material assignment and 24 out of 51 have quantity evidence.

To summarize readiness across populated categories while accounting for inventory size, weighted averages were computed using each BEC element count as the weight. The resulting weighted scores are:

• L1: Revit 0.620 vs. Archicad 0.903;
• L2: Revit 0.498 vs. Archicad 0.549;
• L3: Revit 0.362 vs. Archicad 0.311;
• L4a: Revit 0.257 vs. Archicad 0.342;
• L4b: Revit 0.008 vs. Archicad 0.000.

The Archicad-derived output therefore scores higher under the present L1 and L4a indicator definitions, because classification was present in the Archicad IFC exchange, yet absent in Revit IFC exchange. The Revit-derived output shows higher overall material coverage and a slightly higher weighted L3 score, but its category-specific weakness in BEC 2.5 reduces both L2 and L3. The L2 scores remain moderate despite high overview-level quantity availability because the L2 indicator is stricter than the has_quantity count and includes additional evidence checks beyond simple quantity presence.

The issue logs clarify the source of several differences. In the Revit-derived output, the largest issue group is facade members lacking deterministic curtain-wall (444 issue rows), followed by missing predefined type issues (154 rows) and missing external/internal door declaration (76 rows). In the Archicad-derived output, the issue log is dominated by missing predefined type issues (358 rows), followed by missing external/internal door declaration (72 rows) and furniture, fixtures and equipment (FF&E) proxy/classification uncertainty (17 rows). These issue patterns support interpreting the results as exchange-readiness diagnostics rather than as direct evaluations of building performance; potentially, while out of scope to assess in detail, this can lead to variability of LCA output when conducting preliminary assessment between the two exchanges.

3.1.2. IFC2x3 vs. IFC4: D1 Schema/Export Sensitivity

The D1 comparison evaluates two exports of the educational building model: D1.1 as IFC2x3 and D1.2 as IFC4. As in

Table 7. Element count and material coverage comparison by BEC between D1 IFC2x3 and IFC4 exports. Only subcategories with elementCount $>0$ in at least one export are shown.

BEC	Subcategory	IFC2x3		IFC4
		elementCount	has_material	elementCount	has_material
2.1	Frame	2440	1354	1634	416
2.7	Internal walls	0	0	507	0
2.2	Upper floors	447	447	447	447
2.4	Stairs, ramps and safety guarding	41	41	41	21
2.5	External envelope including roof finishes	44	44	44	0
2.6	Windows and external doors	108	108	108	108
4.1	General furniture fixtures	316	192	2103	1969
5.1.3	Drainage and rainwater	0	0	56	56
5.2.4	Ventilation equipment	0	0	2025	2025

, the IFC2x3 export contains 3396 assessed elements, while IFC4 export contains 6965 assessed elements. The IFC2x3 assessed inventory is concentrated in frame elements, upper floors, stairs/ramps, external envelope elements, windows/external doors and general furniture fixtures. The IFC4 exports indicate explicit internal walls, drainage/rainwater and ventilation equipment. The largest IFC4 increases occur, in general, furniture fixtures (316 elements in IFC2x3 vs. 2103 in IFC4) and ventilation equipment (absent in IFC2x3 export); this may indicate that the IFC2x3 exchange represented some service-related content through proxy-like objects, or otherwise lacked the explicit evidence required by routing logic.Drainage and rainwater also become populated in IFC4 (0 vs. 56 elements).

Material coverage differs between the exports. IFC2x3 contains material assignments for 2186 out of 3396 assessed elements (64.4%), while IFC4 contains material assignments for 5042 out of 6965 assessed elements (72.4%). Quantity evidence is available for all assessed IFC2x3 elements and for 6892 out of 6965 IFC4 elements (99.0%). However, the level scores indicate that simple quantity or material presence does not fully determine readiness.

The IFC4 export therefore improves element routing and quantity readiness, through internal walls, drainage/rainwater and ventilation equipment. However, this does not translate into uniformly higher material/property readiness. Although IFC4 has overall higher readiness scores as shown in

Table 8. Per-subcategory readiness (L1-L4b) for D1 comparing IFC2x3 and IFC4 exports. Only subcategories with elementCount $>0$ in at least one export are shown.

BEC	Subcategory	IFC2x3					IFC4
		L1	L2	L3	L4a	L4b	L1	L2	L3	L4a	L4b
2.1	Frame	0.375	0.250	0.445	0.000	0.023	0.965	0.600	0.444	0.250	0.008
2.7	Internal walls	0.000	0.000	0.000	0.000	0.000	0.800	0.600	0.650	0.250	0.043
2.2	Upper floors	0.300	0.250	0.399	0.000	0.000	0.458	0.600	0.399	0.006	0.000
2.4	Stairs, ramps and safety guarding	0.402	0.250	0.323	0.000	0.000	0.552	0.128	0.201	0.000	0.000
2.5	External envelope including roof finishes	0.375	0.250	0.250	0.000	0.000	0.800	0.000	0.000	0.250	0.000
2.6	Windows and external doors	0.375	0.250	0.250	0.000	0.000	0.800	0.587	0.394	0.250	0.000
4.1	General furniture fixtures	0.375	0.250	0.152	0.000	0.000	0.443	0.250	0.236	0.000	0.000
5.1.3	Drainage and rainwater	0.000	0.000	0.000	0.000	0.000	0.589	0.250	0.250	0.000	0.000
5.2.4	Ventilation equipment	0.000	0.000	0.000	0.000	0.000	0.642	0.550	0.250	0.000	0.000

, L3 score remains moderate because several large categories lack materials and more detailed properties. BEC 2.5 external envelope including roof finishes contains 44 elements but no material assignment or quantity.

In IFC2x3, the dominant issues are missing predefined types in frame elements and walls retained in frame-related categories because load-bearing, externality and deterministic partitioning is not declared. In IFC4, the issue log is dominated by missing predefined types, in general, furniture fixtures and internal walls, together with a large number of generic proxy elements. Both exports also report that no deterministic cold-water, heating/DHW, cooling, lighting, renewable-generation/storage or 5.5 service systems were found; while this does not mean that they are absent from the source design, they indicate that exchanged IFC did not include enough deterministic information for subcategory assignment.

3.2. Materials and Documentation (L3): Coverage and Specificity

Material assignment coverage was computed as has_material divided by elementCount per BEC subcategory using the Overview sheet, with differences shown in Figure 2. In the D2 case, the Revit-derived output shows high overall material coverage: 967 out of 1023 assessed elements have material assignment (94.5%). Most populated Revit subcategories have complete material coverage, including BEC 2.1 Frame, BEC 2.2 Upper floors, BEC 2.6 Windows and external doors, BEC 2.7 Internal walls, BEC 3.1 Wall finishes, BEC 3.3 Ceiling finishes, BEC 4.1 General furniture fixtures, BEC 5.1.1 Sanitaryware and BEC 5.1.3 Drainage and rainwater. The main exceptions are BEC 2.3 Roof structure (9/10), BEC 2.4 Stairs, ramps and safety guarding (95/103), and especially BEC 2.5 External envelope including roof finishes (4/51).

The Archicad-origin IFC exchange shows lower and more uneven material coverage: 541 out of 794 assessed elements have material assignment (68.1%). Complete material coverage is observed in BEC 1.1 Foundations and piling, BEC 2.1 Frame, BEC 2.2 Upper floors, BEC 2.4 Stairs, ramps and safety guarding, BEC 2.5 External envelope including roof finishes, BEC 2.7 Internal walls and BEC 3.3 Ceiling finishes. However, none in BEC 2.6 Windows and external doors (0/137), BEC 5.1.1 Sanitaryware (0/30), BEC 5.1.3 Drainage and rainwater (0/8), and BEC 5.4.1 REG/RES (0/1), which implies the need for external documentation/investigation for an assessor. BEC 4.1 General furniture fixtures also shows low material coverage (7/81).

The L3 scores follow these patterns only partly because L3 is not only a material-presence metric. It also includes additional evidence such as layer information, common property sets, document references and service-life. Therefore, a category can have high material assignment coverage but still moderate L3 readiness if the material evidence is not accompanied by other structured inventory-readiness information. Conversely, the absence of material assignment in categories such as Archicad BEC 2.6 prevents the model-derived inventory from being parameterised directly without external specifications or manual enrichment.

3.3. Traceability and Evidence Linkability (L4a): References vs. Resolvable Data

Across both D2 exports, explicit EPD availability is zero in the overview-level has_epd field. Therefore, L4a should not be interpreted as verified EPD availability. In this framework, L4a is better understood as environmental linkability or traceability evidence, capturing weaker hooks such as environmental-impact property presence, element/type references, material external references or quantity basis evidence that may support later dataset matching.

The weighted L4a score is higher in the Archicad-derived output (0.342) than in the Revit-derived output (0.257), but this does not mean that Archicad provides verified environmental product data. It indicates that, under the present indicator definitions, Archicad exposes more of the weak linkability signals captured by L4a. Since no explicit EPD availability is detected in either export, both outputs would still require external documentation, manual matching or stricter exchange requirements before product-specific environmental data could be treated as verified.

L4b remains effectively absent in both exports. The Archicad-derived output has a weighted L4b score of 0.000, while the Revit-derived output has only a near-zero weighted L4b score of 0.008. The small non-zero Revit score is caused by limited manufacturer/product-traceability-type signals in a few categories, not by explicit disassembly evidence. Direct connection relationships, realizing connection elements, mechanical fastener evidence and reversible-without-damage signals are not meaningfully present in the assessed outputs. Therefore, the D2 results support interpreting L4b as a circularity-observability boundary: the prototype can identify that connection and reversibility evidence is missing, but it cannot infer technical disassembly, reuse feasibility or recovery outcomes from these exchanged IFC files.

4. Discussion

4.1. Semantic Longevity as a Constraint on IFC-Based Decision Readiness

This study treats IFC quality as a constraint on whether information remains interpretable and verifiable when it is transferred across project phases and stakeholders, not just as prerequisite for extracting quantities and properties. Information management standards explicitly distinguish project information produced during delivery from asset information intended to support operation and maintenance, positioning structured information exchanges as inputs to an Asset Information Model (AIM) defined by Asset Information Requirements (AIR) [19,20].

Systematic reviews and empirical studies report that BIM use in operation and facilities management remains emerging and faces persistent barriers, including organizational/contractual issues, data exchange and interoperability challenges, unclear or inconsistent information requirements and handover practices [20,21,22,23]. Accordingly, this study frames semantic longevity as information-quality consideration that becomes increasingly relevant under lifecycle-oriented standardization and emerging regulatory directions such as whole-life carbon calculation/disclosure and digital building logbook concepts [5,24,25].

In this context, semantic longevity is defined as robustness of meaning under changing tools, organizations, schema versions, emphasizing reliance on stable identifiers, consistent classification, traceable references where possible over reliance solely on free-text which is difficult to standardize across time and toolchains.

4.1.1. Schema Choice and Limitations

Schema evolution and domain-driven extensions are well documented in the IFC research landscape and differences between major versions can be substantial in specific domains [11,26]. Recent interoperability work targeting EPD to BIM automation identified multiple IFC 4.3 gaps for machine-interpretable environmental product data and proposed schema-level adjustments [13], suggesting that schema choice does not resolve interpretability without explicit information structures. Optionality in the schema and specification choices can lead to unmet information requirements unless information needs are explicitly defined and validated [25]. For WLCA/circularity-oriented quality assessment, this motivates defining checks primarily in terms of the intended information outcome (whether elements can be consistently categorized, or whether a product/type can be linked to evidence) while remaining version-based and allowing controlled alternative representations (where justified by schema/toolchain differences).

4.1.2. Modelling Granularity and Semantic Integrity

Evidence from BIM-FM literature indicates that difficulties in integrating BIM into facilities/asset management are frequently associated with organizational and information-management factors (requirements definition, handover quality, interoperability) [22,23], suggesting practical trade-off: increasing modelling detail may improve analytical specificity, but increase information management burden and amplify the consequences if update responsibilities and validation processes are not clearly established.

Therefore, for longevity-oriented assessment, distinction can be made between information that can be maintained as stable backbone (stable identifiers, consistent classification and traceable type-level references aligned with defined AIRs) and information that is better treated as versioned external evidence linked to the model [20,21,25,26]. This supports prioritizing information that can be specified and validated within defined requirements, while treating high-maintenance or weakly governed, i.e., free text fields as context-dependent rather than universally expected.

4.2. Circularity Information Gaps

From a circularity perspective, decision readiness does not conclude solely with element classification and quantities, but is extended by whether the exchanged model can support verifiable queries about deconstruction, reuse, material recovery pathways. In ISO 19650 information management, this is fundamentally requirements-driven [10,26,27,28], with AIR specifying what information must be delivered to support asset operation and lifecycle decisions, which then are intended to inform what is included in the resulting AIM.

4.2.1. Connection Semantics

IFC provides explicit relationship constructs for describing connectivity between elements, including the ability to represent realizing elements that implement a connection [11,29]. Schema documentation for IfcRelConnectsWithRealizingElements explicitly positions such relationships as a way to connect elements while referencing realizing components [11,30], offering machine-readable method of control for how things are joined, central to deconstruction feasibility.

However, the BIM-for-deconstruction literature indicates that disassembly planning typically requires information that is not reliably present in baseline BIM exchanges and often calls for additional parameterization, semantic enrichment or dedicated exchange definitions. For example, recent work on BIM and design-for-deconstruction explicitly defines deconstruction-oriented parameters and develops approaches for semantic enrichment to improve circularity-oriented use of BIM elements [31]. Further, disassembly focused OpenBIM research has argued for extending IFC (or defining explicit Model View Definitions) to carry deconstruction/disassembly information in a consistent exchange, which implies that existing conventional exchanges may not be sufficient or consistently populated for this purpose [32,33,34].

Accordingly, while IFC can express explicit connection semantics, availability of such semantics in typical exchanged models is uncertain and often insufficient for disassembly planning without additional information requirements, enrichment or exchange specifications. Evidence of realized connection modelling in delivered IFCs is mixed and underreported [29], thus should not be asserted quantitatively without dataset-based measurement. This interpretation is consistent with the assessed outputs, where L4b remained near-zero and explicit connection or reversible-fastener evidence was not meaningfully detected.

4.2.2. Disassembly Planning Needs Exceed Touching Geometry

Implementation depends on a combination of information, process, and industry enabling factors (not only modelling capability) [35]. Even if a model is geometrically coordinated, it may still be circularity limited if it does not carry the attributes and relations required to plan disassembly and recovery transparently.

Because literature also proposes semantic enrichment approaches and even IFC extensions/MVDs for disassembly specific exchanges [29,36], circularity relevant data can be expected to be delivered through defined requirements and exchange subsets, rather than assumed to emerge from generic coordination modelling [30,33,36].

4.2.3. Traceability, Interoperability Constraints

Circularity decisions also depend on traceability (the ability to link elements/types to product documentation, specifications, and other evidence). Persistent barriers include interoperability problems and unclear or inconsistent handover/information requirements [27,32,37], which contribute to gaps between what is modelled during delivery and what is needed later for operation and lifecycle decision making. Under ISO 19650 approach, this reinforces the role of AIR-driven exchanges: circularity-relevant identifiers and references should be treated as requirements-based deliverables with verification, rather than as optional best-effort fields [10,27].

4.2.4. Implication for L4b Interpretation

Given the evidence above, L4b indicators in this framework are best interpreted as readiness signals for circularity-relevant information exchange instead of representation of real disassembly outcomes. IFC has constructs that could support connection semantics and related evidence linking [11,30], but the disassembly/circularity literature repeatedly highlights the need for additional, explicitly specified information (parameters, enrichment, or even exchange extensions/MVDs) [31,33,34], to make deconstruction planning reliable and transferable across stakeholders and time. Therefore, absence (or inconsistency) of circularity-relevant relations and identifiers in an exchanged IFC should be framed as a requirements and exchange-definition gap. The prototype of this implementation could help bridge the gap in the implementation by allowing to both check if connections exist, but also checking in which building element categories are they present. While an excel-based sheet does not necessarily allow complete inspection due to inherent text-based representation limitation over 3d visuals, it creates opportunity to surface deeper issues with the exchanged IFC.

4.3. Software Limitations

Interpreting the case-study gaps as purely IFC limitations would overstate the role of the schema and understate the role of exchange definition, toolchain behaviour and validation. IFC permits multiple representations and includes substantial optionality. The content of an exported model is partly determined by what a project specifies as required to deliver and partly what a given toolchain reliably serializes and preserves. For circularity-oriented uses, the decision-relevant question is not whether IFC can theoretically encode a field or relation, but whether lifecycle-oriented information is predictably delivered and verifiable in exchanged files. Information Delivery Specification (IDS) is positioned as a mechanism to make expectations explicit and checkable and the buildingSMART Data Dictionary (bSDD) is presented as an online service to support consistent terminology and properties across stakeholders and tools [11,16]. These standards support that missing or inconsistent semantics are best framed as a requirements-and-governance gap (what was specified, validated, maintained).

Systematic reviews of BIM-integrated LCA [8,16,19,38] report recurring challenges around data mapping between BIM objects/quantities and LCA datasets, as well as inconsistency in data granularity and interoperability between BIM and LCA environments. Representativeness can be sensitive to how assemblies are decomposed in BIM versus how products are represented in LCA databases (element-level parts versus system-level functional units), which complicates automated workflows and comparability across projects. However, AI-based inventory matching tools demonstrate automation able to address some mapping frictions in particular workflows and use cases [39]. Therefore, functional unit and mapping mismatches are widely reported challenges in BIM-LCA integration, while their practical severity depends on the chosen workflow, databases and tooling rather than being a universal limitation of IFC exchange.

Round-trip testing for interoperability could be a meaningful method for examining whether an IFC import/export cycle preserves model content [40]. However, it is not guaranteed across vendor platforms and may require proprietary containers or behave differently across application versions, implying potential loss or transformation of information that a receiving tool does not preserve or interpret, while this does not justify claim that re-export necessarily loses data in all settings, it supports that fidelity of an exchanged IFC is dependent on toolchain-specific import/export behaviours, which strengthens the case for explicit requirements and systematic checking at exchange boundaries. The framework and prototype could surface these issues, enabling a form of “tracking” of quality.

Taken together, limitations should be interpreted as workflow-contingent outcomes at the intersection of what was required and validated for exchange, how consistently terms/properties were defined (via bSDD-aligned conventions) and how the toolchain preserved semantics during export and interoperability cycles.

4.4. Role of the Framework

The multi-level IFC quality framework in this study acts as a diagnostic that surfaces mismatches between current modelling/export practices and the information needs of WLC and circularity assessment. By making these gaps explicit (missing types, broken assemblies, absent connection data), it can inform future guidelines for schema use, IDS definitions and authoring workflows.

4.5. Output Limitations

The framework outputs readiness indicators derived from IFC content, it does not compute whole-life carbon results nor guarantee correctness of downstream LCA outcomes. The assessment is constrained by what is explicitly encoded in the exported IFC. If information exists in the authoring environment but is not exported (or is exported in tool-specific/custom structures), the framework may flag it as missing. The presence of a property does not guarantee its correctness or relevance for a given assessment scope.

Indicator scores are sensitive to mapping decisions and parameter choices. Allocation of elements into WLCA categories (e.g., based on entity type, PredefinedType, classification, or naming conventions) can vary across projects and toolchains. Similarly, weighting choices (across L1-L4a/L4b) reflect a methodological judgement; while useful for prioritization and comparison, they should not be interpreted as universal truth.

Third, the framework identifies information availability and selected consistency issues, but it does not fully validate modelling intent or geometric fidelity. For example, it can flag missing quantities or suspicious representations, yet it does not perform geometric “fix” tasks such as clash-based overlap correction/subtraction or detailed profile verification that would be required to guarantee quantity accuracy.

Fourth, traceability checks (presence of manufacturer identifiers, type references, document links, or EPD-related fields) indicate linkability rather than verified linkage. The framework does not validate external documents, confirm that identifiers/URLs resolve to real products or ensure that selected EPD/LCI datasets are appropriate matches.

Comparability across datasets is conditional. Results are most comparable when the same schema version, export conventions, classification system, and assessment rules are used. When these differ, the framework can still diagnose gaps, but numerical scores should be interpreted with caution and accompanied by the reported schema/export context.

5. Conclusions

This study presents a multi-level IFC exchange-readiness assessment framework to evaluate whether exchanged BIM models provide model-derived information needed for WLCA inventory preparation and selected circularity-oriented interpretation. Checks are organized from entity and classification identification (L1), to quantity extractability (L2), to material/property descriptors needed for parameterisation (L3), to advanced indicators for dataset linkability and circularity relevant cues (L4a, L4b). Results are reported per building element category to reflect heterogeneity in modelling practices across systems.

Across the assessed exchanges, quantification readiness and semantic readiness did not necessarily coincide, with extractable quantities but incomplete, generic or inconsistent material and property evidence, limiting the extent to which inventory inputs can be derived without additional interpretation. Differences observed between exports and toolchains further indicate that the detected readiness profile is sensitive to authoring and export behaviour in the tested cases, such that IFC-based assessment workflows benefit from reporting schema/export provenance and performing QA at the exchange boundary.

The framework contributes a transparent and reproducible method to quantify and localize information gaps in IFC, producing issue lists traceable to element identifiers and enabling targeted updates of information requirements. Limitations are defined by scope: current implementation evaluates presence and extractability of information, rather than geometric correctness, overlap-induced double counting, product/EPD validity or the accuracy of WLCA results. Further, the L4a/L4b indicators are constrained by the availability and consistency of linkability and connection-related semantics in the assessed IFC exchanges.

Future work should validate the robustness of the indicator logic across a broader set of projects, schemas and authoring/export workflows. Further development should also refine circularity-related information checks, especially connection semantics, product traceability, service-life evidence and links to material-passport or deconstruction-oriented information requirements.