Standardizing Design-Stage Digital-Twin Assets in a Smart Home for Building Data Management: Workflow Design and Validation Based on IfcGUID Compliance

Abstract

In smart home projects, building data management at the design stage increasingly relies on digital-twin assets delivered via game engines. Without a clear governance workflow, however, these practices tend to generate non-standard building data on the consumption side, causing broken data chains and increasing construction and management risks. To address this problem, this study proposes a traceability-oriented governance workflow that strengthens IfcGUID compliance and automatically detects and converts inconsistent digital-twin assets into IFC-compliant, auditable data, thereby reducing data chain breakage and improving cross-system traceability in building data management. The workflow uses IfcGUID as a cross-system primary key and is evaluated in a virtual smart home project through a pre-test–repair–post-test experiment at the design stage. We examine four indicators of IfcGUID quality—completeness, validity, uniqueness, and stability—together with a bridge recognition rate that reflects game engine interoperability on the consumption side. The results show that all four IfcGUID indicators converge towards 1 after applying the workflow, and the bridge recognition rate approaches 100%, indicating that the risk of data chain breakage, measured on an IFC basis, is substantially reduced. Within existing toolchains, this workflow provides design teams, visualization teams, clients, and auditors with a low-cost and reproducible path for standardizing design-stage digital-twin assets and establishing a traceable, auditable baseline for cross-system interoperability and lifecycle building data management and data reuse.

1. Introduction

Smart home building data management has become a global concern as cities pursue low-carbon operation, resilient housing, and accountable information flows across the building lifecycle. A smart home here refers to a residential building where sensors, devices, and data services are systematically embedded to provide data-driven support for occupant experience, energy efficiency, and operations and maintenance [1,2]. Recent reviews and practice reports highlight digital-twin adoption—especially for operations and energy analytics—but evidence from the design stage remains limited, particularly on object-level identity governance, consumption-side handover, and auditable processes [3,4,5,6]. This study responds by focusing on design-stage digital-twin assets and game engine interoperability in smart home projects and by proposing a traceability-oriented governance workflow based on Industry Foundation Classes Globally Unique Identifier-22 (IfcGUID-22) compliance to keep cross-system data chains auditable from the design model to downstream visualization and game engine environments.

In this context, digital-twin assets denote object-level digital representations on the consumption side—such as visualization and game engines and operations-and-maintenance platforms—that can be used directly for rendering, interaction, and business linkage and that act as data carriers connecting the design-stage model with downstream applications [3,4]. In practice, once the consumption side (for example, the representative game engine Unity) accumulates non-standard data—object identifiers that are inconsistent, missing, or invalid—cross-system reconciliation and traceability are quickly blocked, leading to rework and a broken chain of evidence. This research therefore targets the non-standard data that emerge when digital-twin assets are generated at the design stage of smart home projects and proposes and validates a practical “non-standard to standard” workflow. The aim is to convert consumption-side non-standard data into standard-compliant, auditable data streams already at the design stage, serving Building Information Modeling (BIM) and building data management in the Common Data Environment (CDE), as well as visualization and engine teams and owners and auditors, by reducing data chain breakage and rework at the source. Industry studies likewise show that the cost of such “bad data” is substantial [7,8].

Building data management for smart homes concerns the organization, quality control, and traceability-oriented governance of lifecycle models, metadata, and versions. Its management anchor is the CDE: under ISO 19650 [9] and the UK BIM Framework [10], each information container should have a unique identifier, follow agreed naming conventions, and pass through controlled processes for creation, review, and release [9,10]. In this study, we implement traceability-oriented governance in the CDE by registering paths, timestamps, and checksums for key inputs and outputs, measurement configurations, and results so that every reported number along the design-stage digital-twin asset workflow can be traced back to a concrete file and command [11].

Cross-system consistent identification in building data management depends on robust object-level primary keys. At the open-standards layer, buildingSMART’s Industry Foundation Classes (IFC, ISO 16739-1) provide the international standard for cross-platform exchange and sharing [12]. Each IfcRoot object carries an object key, IfcGUID, with a fixed 22-character exchange representation, and toolchains are expected to convert this consistently to and from the underlying globally unique identifier (GUID), a property we refer to as IfcGUID compliance [12,13]. In this study, IfcGUID compliance covers four aspects: existence, format validity, uniqueness, and cross-version stability. If any of these fail, cross-system comparison and reuse collapse into pseudo-comparisons of “the same object with different identifiers (ID)” [14,15].

On the consumption side of smart homes, game engines act as real-time 3D platforms that integrate multi-source data such as BIM and IoT for visualization, simulation, and interactive presentation to support collaborative decision-making; Unity is a representative engine widely used in digital-twin integration scenarios [16,17]. Game engine interoperability is therefore a critical part of smart home digital-twin assets. However, engine-side identifiers are typically project-internal: for example, Unity writes an asset’s unique identifier (ID) into a local meta file, and if that file is lost or recreated, a new GUID is generated, which is inherently unsuitable as a minimal cross-platform mutual recognition key [18,19]. It is thus necessary to bridge engine assets to IfcGUID-22 and to register that mapping, together with its context, in the CDE so that references remain consistent and replayable along the “IFC to engine assets to audit and reconciliation” chain [9,12,13,18].

Existing reviews and practice largely emphasize digital-twin research and evidence on the operations and energy side; integrated mechanisms that connect object key governance, consumption-side handover, and evidencing at the design stage are under-reported [3,4,5,6]. BIM–engine integration studies also tend to focus on visualization and interaction rather than on quantitative, auditable ID–mapping–verification pipelines and measurement conventions [16,17]. Accordingly, our entry point is to embed IfcGUID compliance and traceability-oriented governance at the design stage and to close the loop via engine-side handover and cross-system alignment, turning “source-side compliance (IFC and IfcGUID) to consumption-side acceptance (engine and assets) to cross-system reconciliation (CDE and audit)” into executable processes with evidence [9,11,12,13,18].

Based on the above, this study addresses two research questions:

RQ1 (governance): At the design stage, how can multi-source data be incorporated into a controlled BIM-standard project environment and managed with unified, stable object identity across teams, systems, and versions so that they can be aligned and compared and support accountable traceability, thereby reducing data chain breakage and rework caused by non-standard data? [9,10]

RQ2 (engineering): How can a verifiable, low-cost, and transferable process convert consumption-side non-standard data into compliant data streams, create a complete chain of evidence, and support sustained reuse across projects and version evolution? [11,13,14,18]

To answer these questions, we build a virtual experimental platform aligned with design-stage building data management requirements for smart homes. We freeze data assets, lock environments and execution entry points, and register hashes for key executables, configurations, and all inputs/outputs. Using a unified denominator $U_0$, we define and compute four integrity metrics—completeness, validity, uniqueness, and stability—to form the pre-test baseline. We then implement an IfcGUID↔engine bridging and minimal repair mechanism and conduct same-convention post-tests with paired reruns, reporting changes in the metrics as absolute percentage-point differences under a stable denominator. This end-to-end, evidence-oriented pipeline is validated in a virtual smart home setting and is designed to be reproducible within existing toolchains.

2. Literature Review

2.1. Smart Home Management Requirements

The smart home market has entered a high-growth, large-scale phase and is now a significant segment of the building sector [20,21,22]. Compared with traditional residences organized around siloed building service systems (Heating, Ventilation, and Air Conditioning (HVAC), lighting, and so on), smart homes integrate multiple functional clusters; systematic reviews identify five core functions: device management, energy management, healthcare, intelligent interaction, and security [1,2]. This shift from “single systems” to “multi-cluster integration” directly expands the objects of building data management—more numerous, more heterogeneous, and more tightly coupled—thereby raising design-stage requirements for data identifiers, naming consistency, and cross-platform mappings [8,23,24,25]. Accordingly, at the design stage, we structure the boundary and inventory of management objects as inputs to subsequent measurement and governance workflows (see

Table 1. A comparison of building data management objects in a typical residential space: traditional residences vs. additions in smart homes.

Space	Traditional Home	Smart Home (New Additions)
Entrance	Entrance doorway dimensions; door leaf/hinge/lock identifiers (door schedule). Doorbell circuit and wire specifications (lighting/low-voltage circuit schedule). Wall light fixture type tag (Fixture Tag). Switch panel location information (plan + index). Light fixture model and load (lighting circuit schedule).	Smart-Lock Device GUID Occupancy Sensor Tag Door-Cam Device GUID
Living room	Outlet/circuit number (Power Plan). Split AC unit location; refrigerant pipe diameter (MEP configuration sheet). Supply/return air grille/register number (HVAC schedule). Ceiling/pendant light fixture tag.	AV Device GUID HVAC Sensor Matrix Scene Preset ID
Bedroom	Outlet and data jack location and circuit number. Wall-mounted AC indoor unit location; refrigerant line length. Window/curtain box dimensions (elevation drawing metrics).	Circadian Lighting Profile ID Smart-Blind Actuator GUID Sleep-Mat Sensor Tag
Bathroom	Ceiling/vanity light fixture tag GFCI outlet number (branch-circuit no.). Exhaust fan model, airflow, and duct routing. Hot and cold water/drain pipe diameters, slope (P&ID).	Water-Leak Sensor GUID Humidity Sensor Tag Exhaust-Fan Rule ID
Study room	Desk lighting fixture tag. Dedicated outlet circuit number (UPS/IT). Low-voltage info point (Cat6) coordinates. Acoustic/sound-absorbing material specification (detailed list).	Task-Light Script ID (dynamic task lighting) Mesh-AP Node MAC Comfort-AI Model Hash
Multimedia room	Theater lighting list and dimming circuit number. Acoustic panel/sound absorption specs. Dedicated HVAC airflow and sound level requirement (HVAC schedule). AV/HDMI/fiber panel outlet coding.	Video-Preset GUID Lighting Rhythm Script ID Window-Switch Actuator GUID
Garage	Ceiling and motion sensor fixture tag. Rolling gate motor spec and control wire number GFCI/20. Socket location and circuit number. Garage drain/floor drain number.	Gate-Motor Actuator ID (automatic roll gate) EV-Charger OCPP Station ID LPR-Camera GUID (license-plate-recognition camera)

).

2.2. Design-Stage Applications and Management Status of Smart Home Digital-Twin Assets

At the design stage of smart homes, digital twins (DTs) are increasingly recognized in systematic reviews as an emerging means of management and delivery: by linking design semantics with device logic in a virtual environment, they enable interactive verification and visualization, bringing data governance and scenario checking forward in design while supporting downstream phases [3,4,5,6]. This study adopts the previously defined management object inventory and discusses multiple functional clusters—lighting, HVAC, security, energy, and interaction—within a unified framework [1,2]. In the design and schematic phase toolchain, real-time game engines (with Unity as a representative) have become common platforms for Building Information Modeling (BIM) integration and scenario-driven simulation to support visualization, interaction, and scheme verification; at this stage, DT work primarily simulates owner–scene interactions within design options [16,17].

In the smart home context, design-stage DTs for HVAC remain constrained: much of the building DT literature concentrates on operations and maintenance (O&M) and relies on operational data and calibration—systematic reviews expressly focus on O&M applications, while American Society of Heating, Refrigerating and Air-Conditioning Engineers (ASHRAE) guidance notes that calibration typically requires seasonal measured data, which are not available at the design stage [3,4,5,6,12].

Authoritative guidance frames smart home building data management within an ISO 19650-based, lifecycle Common Data Environment (CDE) process: information containers carry unique identifiers and controlled metadata (revision, status, classification) and progress through controlled workflows across planning, design, construction, and O&M; the UK BIM Framework Part C further specifies exchange and container management requirements for consistent lifecycle delivery and acceptance [9,10,26].

2.3. IfcGUID Generation and Validation Methods

In object-level, traceable building data management, a GUID or UUID is a 128-bit identifier that uniquely identifies objects across systems and time. Originating in distributed computing and standardized by the Internet Engineering Task Force (IETF) as UUID (Request for Comments (RFC) 4122), often called GUID, it provides uniqueness “across space and time” without central registration, laying the foundation for its later role as an object primary key in Architecture, Engineering and Construction (AEC) Information Delivery Specification (IDS) exchange [19,27]. The AEC domain institutionalizes this via Industry Foundation Classes (IFC): since IFC 1.0, the base class IfcRoot has carried a GlobalID for independent entities, and the standard established the 22-character compressed IfcGloballyUniqueId to convey the underlying UUID’s uniqueness and traceability, making object-level identifiers a hard constraint for model exchange [12,13,14]. This mechanism is published internationally as ISO 16739-1, enabling multi-software exchange and delivery across construction and facility management; accordingly, IfcGUID has become a common institutional arrangement in building data workflows [12,14].

For mainstream generation and validation, practice follows buildingSMART and open-source implementations: it converts between a standard UUID and IFC’s 22-character encoding, an IFC-specific Base64 variant, typically using IfcOpenShell (ifcopenshell.guid.compress/expand) for reproducible conversion and batch legality checks on length, character set, and reversibility [13,14]. For uniqueness, automatic checks such as “Require Unique IFC GUIDs (Unique in One or All Models)” are applied at the single-model and federated-model scales [28]. For stability, authoring tool exports enable writing the GUID back to an element parameter, for example “Store the IFC GUID in an element parameter after export”, to prevent primary key drift across repeated exports and to support version tracking in the Common Data Environment (CDE) [15]. For delivery compliance, requirements such as “must exist, be unique, and be reversible” are encoded as machine-readable information requirements and checked automatically with IDS v1.0, a buildingSMART final standard, embedding “generate–validate–compliance check–archive” in the CDE workflow from Work in Progress (WIP) to Shared to Published [27].

For subsequent pre-test and post-test reuse, the compliance basis, derived rules, and indicators are summarized in

Table 2. Object-level data reliability rules (R1–R4) under IFC/ISO standards.

Derived Rule (R)	Metric	Computation	Authoritative Basis
R1 Completeness: Every IfcRoot instance under test shall have GlobalId.	Completeness rate	Parse IfcRoot.GlobalId; count non-empty, decodable IDs for objects in I = A∪BI = A\cup BI = A∪B.	“All entities having semantic significance derive from IfcRoot, where instances are identifiable within a data set using a compressed globally unique identifier (IFC-GUID).” [21]
R2 Validity: GlobalId must be 22 characters, have a valid charset, and be round-trip-convertible.	Validity rate	Regex 22-char check; verify 22↔36/32 via ifcopenshell.guid.expand/compress.	“The resulting string is a fixed 22 character length string.” [23]
R3 Uniqueness: GlobalId must be unique within the same IFC file.	Uniqueness rate	Build duplicate clusters over GlobalId within I ; numerator = items not in any duplicate cluster.	“An IfcGloballyUniqueId holds an encoded string identifier … used to uniquely identify an IFC object.” [8]
R4 Stability: GlobalId remains unchanged across repeated exports/versions.	Stability rate	Under controlled, identical export settings, compute set overlap of GlobalId between v1 and v2; S_ifc is the authoritative comparator on the IFC side.	“This identifier must never change during the lifetime of an object …” [8]

.

2.4. Research Gaps

Recent systematic reviews concur that digital-twin (DT) research for smart buildings still centers on construction and operations and maintenance, with limited evidence on design-stage data management [3,4,5,6,29,30]. Empirical work on interactive visualization is mostly evaluated for communication and collaboration and decision support, seldom unifying “visualization experience” with “data governance (identification, mapping, checking)” in a single workflow and lacking unified quantitative metrics [16,17,31,32]. This points to a shared view: executable compliance gates should be moved upfront to design to pre-empt downstream data breakage [3,4,5,6,23,29,30,33].

At the standards and implementation level, the ISO 19650 and UK BIM Framework require unique identifiers for information containers in the Common Data Environment (CDE), with status, revision, and classification metadata and audit trails for traceable governance across planning, design, construction, and operations and maintenance. However, industry reports persistent rollout difficulties and inconsistent processes, which increase rework and coordination costs [7,8,23,28]. A gap lies in how to translate these textual requirements into verifiable registrations and logs to form a cross-phase, consistent chain of delivery evidence [9,10,23,28].

For semantic interoperability, prototypes and tools for Industry Foundation Classes (IFC) to BACnet and Building Management System (BMS) use Information Delivery Manual and Model View Definition methods to define stable minimal subsets for cross-platform exchange, yet many studies note unresolved gaps in BMS–IFC integration, requiring stable unique identifiers and standardized subsets to sustain digital-twin construction [34,35]. In the smart home endpoint ecosystem, Matter 1.2 already covers cluster-level semantics for devices such as door locks and thermostats, but systematic mappings to IFC, for example the Building Control Domain, and a transferable pipeline remain to be validated [36].

3. Materials and Methods

In terms of methodology, we adopt a staged design that reflects how design-stage digital-twin assets are created and managed in smart homes. First, based on the use scenarios defined earlier, we construct a virtual smart home experimental object and build its design-stage digital twin using a mainstream game engine (Unity), achieving a unified and controllable representation of both the BIM model and the digital-twin assets. Second, we freeze all BIM and digital-twin assets produced at this stage and treat them as a unified denominator ${\mathrm{U}}_0$, providing a fixed object set for subsequent measurement and comparison. Third, in the pre-test, we apply four IFC-based integrity metrics—completeness, validity, uniqueness, and stability—under the unified denominator ${\mathrm{U}}_0$ to quantify data chain breaks and identify weaknesses in identifier management. Based on these pre-test findings, we then propose, in the governance workflow section, an IfcGUID-oriented bridging and management process to carry out targeted governance at the design stage. Finally, in a separate post-test, we rerun the same metrics and interoperability checks under the same denominator $U_0$ and the same measurement conventions to evaluate whether the workflow effectively reduces data chain break risks and improves identifier compliance and game engine interoperability. The research framework is shown in Figure 1.

3.1. Experimental Platform Setup and Metric Definition

This subsection describes how we construct the experimental platform and define the metrics used to evaluate IfcGUID-based compliance and interoperability at the design stage. First, we outline the scope and construction of a virtual smart home environment and its digital-twin assets so that the building model and the visualization/interaction side can be studied in a controlled setting (Section 3.1.1). Second, we explain how we freeze the export and consumption pipelines and designate IFC as the single source of truth, ensuring that design-stage BIM and digital-twin assets form a stable object set for pre- and post-tests (Section 3.1.2). Third, we define the unified denominator ${\mathrm{U}}_0$ and the associated metrics—completeness, validity, uniqueness, stability, and interoperability indicators (BRR, DR)—which serve as the quantitative basis for all subsequent analyses.

3.1.1. Scope Definition and Platform Construction

To support comparable IfcGUID measurement and re-testing, we build the virtual smart home platform in stages—defining requirements, fixing the scope, designing the layout, modeling, and generating digital-twin assets—while keeping each step feasible and reproducible.

First, we define the requirements. Based on the interaction tasks sampled in Section 2, we construct a virtual smart home scenario that can be verified in a closed loop at the design stage. The platform focuses on four systems—security and access, lighting, entertainment, and communication—to ensure the coverage of typical interactions while remaining implementable. HVAC, which depends more on operational IoT data and control strategies, is excluded at this stage.

Next, we fix the scope. To avoid denominator drift between the pre-test and post-test, objects are partitioned into a unified denominator ${\mathrm{U}}_0$, which enters the measurement and repair loop, and an extended set $U^{+}$ used for coverage statistics. Both sets are defined through an asset list and a boundary configuration stored in the Common Data Environment (CDE), and the same conventions are reused in Section 3.3 and Section 3.4.

After completing the floor layout and system placement, we select two representative spaces as the testbed: the Entrance and the Multimedia Room. The Entrance covers access control, security, and lighting with presence-based linkage; the Multimedia Room covers audio-visual, lighting, and communication linkages. Together they cover the main interaction combinations listed in Table 2 while keeping scale and complexity within implementable bounds. Figure 2 illustrates the selection of the Entrance and Multimedia Room as typical spaces covering access, lighting, AV, and communication interactions, and Figure 3 shows the system design for these spaces in the virtual smart home experiment platform.

Finally, we build the BIM model and the digital-twin assets. After modeling in SketchUp with unified naming and hierarchy, we export IFC as the sole data source; in Unity, we construct the corresponding interactive scenes and object mappings to form the runtime environment for measurement and re-testing. Object references are registered in the CDE and reused under the same conventions in subsequent stages. The CDE directory map and registry roles are summarized in Appendix B.1.1 and Appendix B.1. Figure 4 and Figure 5 present the live digital-twin demonstration scene used to validate interactive behaviors and provenance logging under the frozen environment.

3.1.2. Export Pipeline and Asset Freezing

To ensure that measurements are comparable and auditable, we apply a one-time freeze to design-stage digital-twin assets. Project coordinates, units, and naming are first harmonized and then locked, and an asset inventory and a data boundary are exported to define the evaluation set $U_0$. The export pipeline is fixed as SketchUp → IFC with a single, consistent strategy so that IFC serves as the sole data source. Under identical environment and configuration settings, two baselines (v1/v2) are exported to support subsequent checks on GlobalId stability. All write operations are confined to tool-generated containers, leaving the original project files unchanged. In a single controlled registration step, we record the baselines, inventories, environment snapshots, and checksums in the CDE to support reruns and audits. Key baselines and locks (coordinates/units, naming and hierarchy, export channel, environment snapshot, and CDE register) are summarized in

Table 3. Key baselines and locks.

Baseline/Lock	What is Frozen	Evidence/Output (Where)
Coordinates and Units	Project base point, unit set	export_config.yaml
Naming and Hierarchy	Space–System–Device–Script	unity_asset_inventory.csv
Export Channel	SketchUp→IFC, options	baseline_v1.ifc/baseline_v2.ifc
Env Snapshot	Unity version/manifest	unity_env/…
CDE Register	One-transaction log + checksums	cde_register.csv/checksums.txt

, and full environment pins and checksums are provided in

Table A1. Versions and SHA-256 hashes of key executables and configurations.

Component	Version	Path_Rel	Sha256	Timestamp
Python	3.12.7	<python>		2025-09-23T18:52:52
CDE register		cde_register.csv	6cebea79e20d836dbc2bfc2e1c77aa27bda394209dccb852561980eb2fdcbb5f	2025-09-23T18:52:52
Checksums list		checksums.txt	7fcb41bf881fe65e2d2c08ae1143bdfd5df1a19e5015c490994dc72cc1133e29	2025-09-23T18:52:53

, Appendix A.2 and Appendix A.3.

3.1.3. Metric Definitions and Statistics

To obtain comparable and reproducible conclusions in the pre-test and post-test, we define a unified denominator and a compact set of metrics that quantify IfcGUID-based integrity and interoperability in a consistent way. All metrics are reported as proportions in $[0, 1]$. Four core metrics describe the integrity of IfcGUID on the IFC side—completeness, validity, uniqueness, and stability—while two additional indicators summarize interoperability between IFC and Unity: the bridge recognition rate (BRR) and Disconnect Rate (DR). The four integrity metrics follow the common data quality and identifier governance dimensions used in BIM/FM practice—completeness, validity, uniqueness, and stability—as summarized in Section 2, and they are here specialized to the semantics of IfcGUID.

We use a unified denominator $U_0$ to represent the set of objects that fall within the evaluation scope (Section 3.1.1) and are expected to carry a valid identifier. All IFC-side integrity metrics are computed on $U_0$. Interoperability metrics are computed on the set of object pairs that are intended to be bridged between IFC and Unity (the mapping set) and are reported in parallel.

• R1 Completeness (C).
  Meaning: The proportion of objects in ${\mathrm{U}}_0$ that have a resolvable GlobalId.
  Definition: The number of objects in ${\mathrm{U}}_0$ whose GlobalId is present and can be parsed into a valid IfcGUID-22 exchange string, divided by the total number of objects in ${\mathrm{U}}_0$.
• R2 Validity (V).
  Meaning: The proportion of objects in ${\mathrm{U}}_0$ whose GlobalId satisfies basic format and standard checks.
  Definition: The number of objects in ${\mathrm{U}}_0$ whose GlobalId has the correct length and character set and passes IfcOpenShell/IFC validation, divided by $\mid {\mathrm{U}}_0\mid$.
• R3 Uniqueness (U).
  Meaning: The proportion of objects in ${\mathrm{U}}_0$ that are not involved in any GlobalId duplication.
  Definition: The number of objects in ${\mathrm{U}}_0$ whose GlobalId occurs exactly once within ${\mathrm{U}}_0$, divided by $\mid {\mathrm{U}}_0\mid$. When duplicate clusters exist, all members of a cluster are counted as non-unique.
• R4 Stability (S).
  Meaning: The proportion of objects in ${\mathrm{U}}_0$ whose GlobalId remains stable across exports.
  Definition: Given two IFC baselines (v1 and v2) exported under identical settings, the number of objects in ${\mathrm{U}}_0$ whose GlobalId is identical in v1 and v2, divided by $\mid {\mathrm{U}}_0\mid$.

Interoperability is summarized over the explicit mapping between IFC objects and Unity assets. Each mapping entry links one IfcGUID to one Unity asset GUID. For this mapping set, we define the following:

• BRR (Bridge Recognition Rate).
  Meaning: The share of mapping entries where the Unity asset can be successfully resolved and recognized in the project.
  Definition: The number of mapping entries whose Unity GUID can be resolved to a valid asset/scene reference, divided by the total number of entries in the mapping set.
• DR (Disconnect Rate).
  Meaning: The share of mapping entries where the Unity side is missing, i.e., a planned link from IFC to Unity is broken.
  Definition: The number of mapping entries whose Unity asset is missing or cannot be resolved, divided by the total number of entries in the mapping set.

For pre-/post-test comparison, we keep the denominator $U_0$, the interpreter, and the measurement functions unchanged. Changes in C/V/U/S and interoperability metrics are reported as absolute percentage-point differences between Pre-test and Post-test, accompanied by the corresponding counts. The formal statements of metric invariants and paired rerun matching rules are given in Appendix C.

3.2. Pre-Test (Baseline)

This section establishes a baseline measurement without altering the source data. Under the unified denominator $U_0$, we compute the four IfcGUID integrity metrics (C/V/U/S) and summarize interoperability, using a consistent workflow of extracting, validating, aligning, measuring, summarizing, and registering the results. This baseline is later used for pre–post comparison and for auditable reruns.

We first establish an IfcGUID compliance baseline without any repair. Within the frozen object scope defined in Section 3.1 and the controlled export pipeline, we generate two IFC baselines (v1 and v2) and, under the same denominator $U_0$, compute completeness, validity, uniqueness, and stability while reporting an IFC-side comparator $S_{\mathrm{ifc}}$ in parallel. This stage corresponds to the “pre” condition; the “post” recomputation in Section 3.4 follows the same conventions.

Execution in the pre-test is strictly read-only. All inputs are taken from controlled information containers in the CDE so that the statistical denominator, export settings, and runtime environment remain identical; no writes are made to the IFC or Unity sources. An automated routine loads the IFC baselines and the Unity inventories, detects missing and invalid identifiers, checks the reversibility of IfcGUID-22, identifies duplicate clusters to support the uniqueness metric, and aligns IFC objects with Unity assets to produce an object-level table. Summary-level metrics are then computed, and both input fingerprints and output indices are registered so that paired reruns remain auditable.

3.2.1. Pre-Test Pipeline

The pre-test pipeline implements five steps—Detect, Normalize, Align, Measure, and Register—in a single automated routine:

• Detect. Load the two IFC baselines and the controlled lists (asset list, scene list, object boundary); parse IfcRoot.GlobalId, identify missing and invalid values, and locate duplicate clusters, outputting object-level flags.
• Normalize. Standardize the representations of IfcGUID and engine-side GUIDs (e.g., case, separators, whitespace) so that set operations and matching follow a single convention and the unified denominator $U_0$ is fixed consistently.
• Align. Perform explicit IfcGUID → Unity GUID alignment to obtain the hit set; verify that referenced assets and scenes exist and are resolvable; generate an object-level alignment table; and assign hit/missing reasons for the later interpretation of the BRR and DR.
• Measure. Compute C/V/U/S on the unified denominator $U_0$ and report $S_{\mathrm{ifc}}$ in parallel; all calculations are read-only and do not modify the IFC or Unity sources.
• Register. Record input/output manifests and hashes; attach timestamps, operator, and run configuration; update the CDE index; and output object-level tables and summary reports to support paired reruns and auditable reproduction.

A reproducibility checklist is provided in Appendix A.3, and field semantics are summarized in Appendix B.3. Acceptance gates and relevant IDS rule excerpts referenced in the pre-test are listed in Appendix C (

Table A6. Gate catalog.

Gate_Id	Scope	Rule_Summary	Evidence_Source	Pass_Condition	Fail_Action	Log_Key
G01_IFCGUID	Model IfcRoot	All IfcRoot instances must have valid 22-char IfcGUID	bSI IfcGUID guidance; IFC IfcGloballyUniqueId	0 failures	reject and re-export	G01_IFCGUID
G02_CONTAINER_NO	CDE containers and filenames	Container sequential Number must be 4–6 digits; other fields follow project information standard	ISO 19650 UK National Annex container naming	0 failures	flag and fix then resubmit	G02_CONT_NO
G03_CLASS_LINK	IfcElement	Elements reference an approved classification via IfcClassificationReference	IFC ClassificationReference; project-approved code list	0 failures	map to approved code then resubmit	G03_CLASS
G04_UNITS	Model units	Quantities and units consistent with project IfcUnitAssignment unique per unit type	IFC IfcUnitAssignment semantics	0 failures	correct unit assignment then resubmit	G04_UNITS
G05_PROVENANCE	CDE evidence records	sha256 is 64 hex; timestamp is ISO 8601; path_rel is POSIX-style relative path	Project CDE provenance Appendix A and Appendix B	0 failures	fix metadata and re-register	G05_HASH

). Figure 6 outlines the pre-test metric pipeline.

3.2.2. Execution and Outputs

The pre-test routine is executed within the CDE under a locked environment snapshot, using the frozen IFC baselines, Unity inventories, and configuration files as inputs. The routine runs the full “extract–validate–align–measure–register” sequence in a single pass and produces both object-level and summary-level artifacts. These outputs, together with their paths and checksums, are registered in the CDE so that the pre-test can be rerun under identical conditions. Core file types and their roles are documented in Appendix A, and the corresponding schemas and data dictionaries are provided in Appendix B.

3.3. Bridging Game Engine Digital-Twin Assets and Minimal Repair

Under the unchanged pre-test conventions, we design a self-check and batch repair workflow. The objective is to keep IfcRoot.GlobalId stable, complete the mapping keys and consistency metadata, and produce auditable repair artifacts and mapping lists, thereby supplying like-for-like inputs for the subsequent post-test.

3.3.1. Where the Chain Breaks: Pre-Test Insights

When a game engine is introduced to produce design-stage digital-twin assets for the smart home, the main data chain problems appear not in the IFC model itself but at the point where data are handed over to the engine.

The pre-test shows that most object-level identifiers on the IFC side are present and stable: IfcGUID is largely complete and consistent across the two IFC baselines. However, the chain from IFC to Unity is often broken. In practice, three typical situations dominate:

• No explicit mapping from IFC objects to Unity assets: The engine-side project uses its own internal identifiers, but there is no stable key that tells the engine which asset corresponds to which IfcGUID.
• Missing or moved Unity resources: Some assets referenced in the intended mapping are no longer present or no longer resolvable in the Unity project, even though the IFC objects themselves exist and are well-formed.
• Unclear or unresolved paths: Asset and scene paths are stored in a way that cannot be resolved under the current environment, so links cannot be followed or verified.

In addition, the pre-test reveals a small number of non-standard identifier encodings and duplicate clusters on the IFC side. These records do not necessarily break the model, but they undermine the assumptions behind uniqueness and stability and therefore must be detected and clearly flagged. Importantly, all of this must be performed without changing the object primary key (IfcRoot.GlobalId); otherwise cross-version traceability would be lost.

From the perspective of smart home digital-twin design, these findings mean that the “data chain” breaks between the BIM model and the game engine: the model has IDs, and the engine has assets, but the bridge between the two is weak, partial, or undocumented. The goal of this section is therefore to construct a governance and repair workflow that (i) restores this bridge in a controlled way and (ii) does so without damaging the original IFC identifiers.

3.3.2. Governance and Minimal Repair Pipeline

To address the above problems, we implement a bridging and minimal repair workflow that treats the game engine as a consumer of design-stage data and adds a thin but explicit governance layer between IFC and Unity. The workflow has four practical objectives:

• Standardize IfcGUID representations so that identifiers can be compared reliably across tools.
• Detect and label duplicate clusters so that uniqueness problems are visible and can be managed.
• Establish a verifiable IFC–Unity object mapping, making clear for each object whether it is recognized by the engine or not.
• Record repair actions and mapping lists with CDE registration so that changes are auditable and can be rerun.

Concretely, the workflow proceeds in five steps:

• Diagnose issues.
  Under the frozen conventions of the pre-test, we rerun read-only checks on the IFC baselines and controlled lists, confirming for each object whether its identifier is missing, invalid, or duplicated and whether a planned link to Unity is present, missing, or unresolved. This step turns the pre-test findings into a concrete list of problem cases.
• Normalize identifiers.
  We then standardize the representation of IfcGUID to a fixed exchange form (e.g., consistent 22-character string, unified case, and whitespace handling). This does not change IfcRoot.GlobalId itself, but it ensures that any comparison or matching across software uses the same representation, reducing spurious mismatches caused by formatting differences.
• Build the IFC–Unity bridge.
  For objects in scope, we compile an explicit mapping between their IfcGUID and the corresponding Unity asset identifier, using the controlled asset and scene inventories. Each mapping entry is checked to see whether the referenced Unity asset actually exists and whether its path can be resolved. The result is a structured mapping table that records, for every IFC object intended to appear in the digital twin, whether the game engine recognizes it and, if not, why (e.g., no mapping, missing asset, bad path).
• Apply minimal repair.
  When the problem can be fixed by a clear, rule-based adjustment—for example, filling a missing mapping entry from an unambiguous match or normalizing a non-standard encoding—we apply the smallest possible repair and record it. In all other cases, we leave the source unchanged and keep the issue as a labeled exception. A repaired IFC copy and an external mapping list are produced, both preserving the original IfcRoot.GlobalId values but improving the ability of the game engine to recognize and track objects.
• Register evidence.
  Finally, we register the inputs, outputs, and run metadata (paths, checksums, timestamps, operator, and configuration) in the CDE. This step turns the bridging and repair actions into an auditable chain of evidence and ensures that the same process can be rerun under identical conditions for verification and for the post-test in Section 3.4.

The whole workflow runs under the controlled environment described in Section 3.1, with the original IFC and Unity projects kept read-only. From a smart home perspective, this means that design-stage digital-twin assets produced by the game engine are now anchored back to stable IFC identifiers through an explicit, documented bridge, reducing data chain breaks while respecting existing modeling practices. The workflow is shown in Figure 7.

3.4. Re-Test and Paired Rerun

This section evaluates the effectiveness of the bridging and minimal repair workflow by rerunning the metrics under identical conditions and comparing the pre–post results. The data scope, denominator $U_0$, interpreter, and measurement functions are kept unchanged, and all metrics are recomputed on two input states: the originally frozen assets (pre) and the standardized assets produced in Section 3.3 (post). Any differences can therefore be attributed to the governance and repair workflow rather than to changes in environment or conventions.

The post-test uses the same IFC baselines (v1/v2), the controlled Unity inventories, and the explicit IFC–Unity mappings as inputs. Under the unified denominator $U_0$, we recompute the four integrity metrics (C/V/U/S) and the interoperability indicators (BRR and DR) and then compare pre and post on a like-for-like basis. The results are reported both as absolute values and as percentage-point changes (post−pre), accompanied by the corresponding counts. If reruns under the same settings reproduce the same outputs, the process is considered stable; when differences arise, they can be traced back through the registered inputs, logs, and mapping tables.

Post-Test Pipeline

The post-test and paired comparison follow a lightweight, automated procedure that mirrors the pre-test:

• Fix conventions.
  We adopt exactly the same denominator $U_0$, object scope, measurement definitions, and environment snapshot as in the pre-test and load both the pre-state (frozen assets) and post-state (standardized assets) as separate inputs.
• Rerun measurements.
  Using the same interpreter and measurement program, we run the full “extract–validate–align–measure” sequence for the pre- and post-states in turn. For each state, the routine aligns IFC objects with Unity assets using the explicit mappings, then computes C/V/U/S on $U_0$ and derives the interoperability summaries in parallel.
• Compute deltas.
  For each metric, we compute the change as post minus pre on the same denominator and produce side-by-side tables that list pre values, post values, absolute percentage-point differences, and supporting counts. This provides a compact view of how completeness, validity, uniqueness, stability, and interoperability have improved (or not) under the proposed workflow.
• Register outputs.
  Finally, we register the pre–post comparison artifacts, together with their paths, checksums, timestamps, operator, and run configuration, in the CDE. This turns the re-test into an auditable, rerunnable step and closes the loop between baseline measurement, governance and repair, and post-test evaluation.

Pass/fail thresholds, acceptance gates, and pairing rules for pre–post comparison are summarized in Appendix C.1 and Appendix C.2. Figure 8 illustrates the post-test and paired comparison workflow under the unified denominator.

3.5. Use of Generative AI (GenAI) Tools

During method development and manuscript preparation, the authors used ChatGPT (GPT-5 Thinking; OpenAI web app, accessed on 29 September 2025, UTC+8) in a limited way to (i) suggest code refactoring and minor bug fixes for preprocessing scripts and (ii) assist in the translation of technical phrases from Chinese to English for terminology harmonization. All code and text were reviewed and edited by the authors, who take full responsibility for the final content.

4. Results and Discussion

4.1. Design-Stage Compliance Workflow for IfcGUID-Oriented Digital-Twin Assets

Within a controlled information environment, this study establishes a design-stage compliance workflow that treats IfcGUID as the object-level primary key and uses the CDE as the single carrier of the chain of evidence. From a building data management perspective, the workflow gives BIM and CDE managers, game engine and visualization teams, and owners and auditors an executable pathway to assign object-level unique identifiers to digital-twin assets and to register them in an auditable way at the design stage. It operationalizes the ISO 19650/UK BIM Framework requirement for unique identifiers in the CDE, adopts the 22-character exchange representation of IfcGUID-22 as the cross-system key, and bridges it to Unity asset identifiers. In doing so, it reduces cross-system reconciliation breaks and rework caused by bad data and restores the traceability and reuse of smart home digital-twin assets at the design stage.

Workflow details are as follows:

• Freezing assets and boundaries. Define the evaluation set $U_0$ and the extended asset set; harmonize coordinates, units, and naming; and output an asset inventory that fixes the denominator and value domain.
• Freezing export and consumption pipelines. Use IFC as the sole data source, export two baselines $v_1$ and $v_2$ under identical settings for robustness and channel variance control, and lock the Unity environment, asset libraries, scene snapshots, and mapping templates.
• Automated compliance checking. Under $U_0$ and a single interpreter, load $v_1$, $v_2$, and the Unity inventories, and then run extract → validate → align → measure → summarize → register in a read-only manner, computing completeness, validity, uniqueness, and stability and record bridge recognition rates and disconnection points.
• Bridging and minimal repair. Normalize Unity identifiers to IfcGUID-22, verify round-trip reversibility, and apply minimal repairs without changing IfcRoot.GlobalId, generating a standardized post-test copy and bridge table and writing them back to the CDE.
• Self-test closure. With the same interpreter, measurement program, object set, and denominator, rerun the workflow to obtain post–pre changes in the four metrics and to evaluate primary key stability and channel variance.
• Evidence archiving. In a single controlled transaction, register paths, hashes, timestamps, operator, and stage for key inputs, outputs, and configurations so that, given the same inputs and program version, the workflow remains auditable and reproducible.

Figure 9 depicts the IfcGUID-oriented standardization workflow that turns consumption-side non-standard data into compliant, auditable data streams.

4.2. Pre-/Post-Test Data Results

4.2.1. Pre-Test Results

Under the unified denominator ${\mathrm{U}}_0=820$, we performed read-only extraction, validation, alignment, and aggregation to obtain the pre-test baseline for the four integrity metrics and the IFC-side comparator ${\mathrm{S}}_{\mathrm{ifc}}$. Inputs comprised two IFC baselines (${\mathrm{v}}_1$/${\mathrm{v}}_2$) and the Unity asset and scene inventories; outputs included object-level records, summary statistics, and interoperability indicators, all registered in the CDE with checksums.

• Overall summary (U₀ scope).
  On the unified denominator ${\mathrm{U}}_0$, R1 Completeness $\mathrm{C}=0.05$ (5.24%), R2 Validity $\mathrm{V}=0.05$ (5.24%), R3 Uniqueness $\mathrm{U}=0.05$ (5.12%), and R4 Stability $\mathrm{S}=0.05$ (5.24%), with the IFC-side comparator ${\mathrm{S}}_{\mathrm{ifc}}=1.00$. Within ${\mathrm{U}}_0$, all IFC elements in the interoperability set $\mathrm{M}=43$ had a valid 22-character IfcGUID (${\mathrm{N}}_{\mathrm{ifc}\_\mathrm{valid}}=43$, ${\mathrm{N}}_{\mathrm{ifc}\_\mathrm{invalid}}=0$), yet model-level uniqueness over ${\mathrm{U}}_0$ remained low (about 5%). The overall pre-test metrics on the unified denominator U₀ are summarized in

  Table 4. Pre-test summary on ${\mathrm{U}}_0$.

  Metric	Value	Objects_in_U0	Duplicate_Members	Aligned_with_Unity_Rate	S_ifc	Notes
  R1_Completeness	0.05	820	1	0.00	1.00	Denominator U0 = 820
  R2_Validity	0.05	—	—	—	1.00	—
  R3_Uniqueness	0.05	—	1	—	1.00	—
  R4_Stability	0.05	—	—	—	1.00	Measured between v1 and v2
  BRR (bridge recognition rate)	0.00	—	—	—	—	recognized_pairs = 0 of M = 43
  DR (break rate)	1.00	—	—	—	—	break_missingUnity = 43

  .
• Interoperability alignment.
  No IFC–Unity pairs were recognized at this stage: $\mathrm{recognized}\_\mathrm{pairs}=0/43$, $\mathrm{recognized}\_\mathrm{in}\_\mathrm{scenes}=0$, bridge recognition rate (BRR) = 0.00, and break rate DR = 1.00. All 43 breaks were classified as missingUnity, with no badPath cases.
• Duplicates.
  Within M, one duplicate member was detected (in IfcPropertySet; see the object-level table).
• By type and by issue.
  Among the 43 objects in $\mathrm{M}$, the main IFC types were IfcWall (16), IfcDoor (5), IfcFurnishingElement (5), and IfcWindow (4). For each type within $\mathrm{M}$, R1–R4 = 1.00 (complete, valid, unique, and stable across ${\mathrm{v}}_1$/${\mathrm{v}}_2$), indicating good required field quality on the IFC side. Issue composition was dominated by Not_aligned_to_Unity_lists = 43 (≈98% of classified issues; 5.24% of ${\mathrm{U}}_0$); Duplicate_cluster_members = 1 accounted for the remaining ≈2% (0.12% of ${\mathrm{U}}_0$). No illegal length/characters or cross-version instability appeared in the pre-test. The breakdown of these metrics by IFC object type within the interoperability set M is given in

  Table 5. Pre-test by object type on ${\mathrm{U}}_0$.

  IfcClass	N_in_M	R1_Completeness	R2_Validity	R3_Uniqueness	R4_Stability	Aligned_with_Unity_Rate	Duplicate_Members
  IfcWall	16	1.00	1.00	1.00	1.00	0.00	0
  IfcDoor	5	1.00	1.00	1.00	1.00	0.00	0
  IfcFurnishingElement	5	1.00	1.00	1.00	1.00	0.00	0
  IfcWindow	4	1.00	1.00	1.00	1.00	0.00	0
  IfcRoof	3	1.00	1.00	1.00	1.00	0.00	0
  IfcBeam	2	1.00	1.00	1.00	1.00	0.00	0
  IfcSlab	2	1.00	1.00	1.00	1.00	0.00	0
  IfcBuilding	1	1.00	1.00	1.00	1.00	0.00	0
  IfcBuildingStorey	1	1.00	1.00	1.00	1.00	0.00	0
  IfcProject	1	1.00	1.00	1.00	1.00	0.00	0
  IfcPropertySet	1	1.00	1.00	1.00	1.00	0.00	1
  IfcSite	1	1.00	1.00	1.00	1.00	0.00	0
  IfcStair	1	1.00	1.00	1.00	1.00	0.00	0

  . Issue composition by category in the pre-test is summarized in

  Table 6. Issue composition in pre-test.

  Issue_Category	Count	Share_in_Issues	Share_in_U0
  Illegal_length_22char	0	0.00	0.00
  Illegal_characters	0	0.00	0.00
  Duplicate_cluster_members	1	0.02	0.00
  Cross_version_unstable	0	0.00	0.00
  Not_aligned_to_Unity_lists	43	0.98	0.05
  Other	0	0.00	0.00

  .

In practical terms, the pre-test reveals a typical breakpoint: although the IFC side within $M$ is present, valid, unique, and stable, it fails to pair with the Unity asset and scene inventories (BRR = 0.00; DR = 1.00), leaving the interoperability chain fully broken on the consumption side. This sets the priority for §4.3 Bridging and minimal repair: first restore Unity-side mapping and recognition, and then address the isolated duplicate member.

Controlled inputs and hash proofs are listed in Appendix A.2.

4.2.2. Post-Test Results

Under the same denominator U₀ and the same interpreter and rules as the pre-test, we recompute the four primary metrics, keeping IFC as the sole data source and maintaining read-only constraints. Relative to the pre-test, the post-test enables upgraded bridging and probes on the interoperability side, expanding the enumeration/recording of consumption-side object pairs and introducing finer recognition/break statistics and provenance/attribution outputs. This yields a more complete interoperability view without changing the definitions or conventions of R1 Completeness, R2 Validity, R3 Uniqueness, or R4 Stability, ensuring direct comparability with the pre-test.

The coverage of the interoperability set is expanded from the pre-test’s small subset to a full scan of consumption-side object pairs. Newly recorded are the bridging recognition rate, break rate, recognized-in-scenes count, and total pairs, together with object-level interoperability details, provenance summaries, and a Pareto list of issues. The four primary metrics continue to be reported on the unified denominator U₀, while interoperability metrics are reported on the expanded set of object pairs.

On the unified denominator U₀ = 820, the post-test metrics are as follows:

R1 Completeness = 1.00; R2 Validity = 1.00; R3 Uniqueness = 0.98; R4 Stability = 1.00. The parallel IFC-side comparator S_ifc = 1.00. These overall post-test metrics on the unified denominator U₀ are summarized in

Table 7. Post-test summary on ${\mathrm{U}}_0$.

Metric	Value	Objects_in_U0	Duplicate_Members	Aligned_with_Unity_Rate	S_ifc	Notes
R1_Completeness	1.00	820	1	1	1.00	Denominator U0 = 820
R2_Validity	1.00	—	—	—	1.00	—
R3_Uniqueness	0.98	—	1	—	1.00	—
R4_Stability	1.00	—	—	—	1.00	Measured between v1 and v2
BRR	1.00	—	—	—	—	recognized_pairs = 777 of M = 778
DR	0.00	—	—	—	—	break_missingUnity = 1, break_badPath = 0
recognized_in_scenes	18	—	—	—	—	interoperability view on expanded pair set

.

On the interoperability side, BRR = 1.00; total pairs M = 778; recognized pairs = 777; DR = 0.00; total breaks = 1 (with missingUnity = 1; badPath = 0); and recognized_in_scenes = 18.

Duplicates are reduced to one remaining member; there are 0 illegal length/characters and cross-version instability.

Within the IFC object set I = 43, each type attains 1.00 on R1, R2, and R4. The only type not reaching 1.00 on R3 is IfcPropertySet (one duplicate member); all other types achieve R3 = 1.00. The breakdown of these post-test metrics by IFC class within I is given in

Table 8. Post-test by IFC class on I.

IfcClass	N_in_I	R1_Completeness	R2_Validity	R3_Uniqueness	R4_Stability	Duplicate_Members
IfcWall	16	1.00	1.00	1.00	1.00	0
IfcFurnishingElement	5	1.00	1.00	1.00	1.00	0
IfcDoor	5	1.00	1.00	1.00	1.00	0
IfcWindow	4	1.00	1.00	1.00	1.00	0
IfcRoof	3	1.00	1.00	1.00	1.00	0
IfcBeam	2	1.00	1.00	1.00	1.00	0
IfcSlab	2	1.00	1.00	1.00	1.00	0
IfcPropertySet	1	1.00	1.00	1.00	1.00	1
IfcSite	1	1.00	1.00	1.00	1.00	0
IfcStair	1	1.00	1.00	1.00	1.00	0
IfcBuilding	1	1.00	1.00	1.00	1.00	0
IfcBuildingStorey	1	1.00	1.00	1.00	1.00	0
IfcProject	1	1.00	1.00	1.00	1.00	0

. The issue set converges to two categories, Not_aligned_to_Unity_lists = 1 and Duplicate_cluster_members = 1; all others are 0. The issue composition in the post-test is summarized in

Table 9. Issue composition in post-test.

Issue_Category	Count	Share_in_Issues	Share_in_U0
Illegal_length_22char	0	0.00	0.00
Illegal_characters	0	0.00	0.00
Duplicate_cluster_members	1	0.50	0.00
Cross_version_unstable	0	0.00	0.00
Not_aligned_to_Unity_lists	1	0.50	0.00
Other	0	0.00	0.00

.

Without changing conventions or the denominator, the post-test increases validity, completeness, and stability to full values and narrows residual uniqueness issues to a single member. The interoperability chain is almost fully restored, with only one remaining consumption-side break and effective scene-level recognition established. These results verify the substantive improvement delivered by the bridging and minimal repair strategy on consumption-side interoperability.

Interoperability fields and registry schema are documented in Appendix B (

Table A2. cde_register.csv schema.

Field	Example	Role	Required_by	Remarks
rel_path	02_Published/unity_env/Packages/manifest.json	POSIX-style relative path from CDE root; primary locator for evidence and assets	Gate G05_PROVENANCE; audit trail; Appendix B usage	Must use forward slashes; no drive letters; regex ^(?![A-Za-z]:)[^\\]*$
sha256	C31805E4…CBAEA620	File content fingerprint for provenance and integrity checking	Gate G05_PROVENANCE; reproducibility checks; Appendix A/Appendix B	64 hex characters; case-insensitive; recommended lowercase; regex ^[0-9a-fA-F]{64}$
modified_iso	2025-08-20T16:05:12+08:00	Evidence timestamp for the registered artifact	Audit trail; IDS time semantics; Appendix C.2	ISO 8601 with timezone, e.g., YYYY-MM-DDThh:mm:ss±hh:mm; prefer Z or +08:00
category	evidence	Normalized top-level class for CDE items	Appendix B.1.1 mapping; reporting filters	Allowed set: evidence, tools, environment, lists, published, temp; lowercase
purpose	provenance	Functional purpose of the item within the CDE workflow	Appendix B.1.1 purpose; audit rationale	Allowed set: provenance, baseline, script, config, inventory, archive; lowercase

and

Table A4. checksums.txt examples.

sha256	File_Relpath
8D9096C2DB6B168EF8AA5C7431F83C02F48D6E5AE45777397989DD5F94CEB316	02_Published/ProjectX_ARCH_baseline_v1.ifc
BB97BF0FE35AB3417734C10C10964ADBC9D11BAD13C5EAC114A3E680654F86DB	02_Published/ProjectX_ARCH_baseline_v2.ifc
7FC9DEFCD22E8216574FE762382CD12FB51C989DCD863268BD9C144DD47AAAED	02_Published/export_config.yaml
B416B712248801F7895F56CF01272C8C292E8634A15E4AEF40074209A1E81097	02_Published/unity_env/ProjectVersion.txt
0B3C3DBAC25875621C37BE55C86C1933F9418CAD302780AABBF481F7E1D36C3A	02_Published/unity_env/manifest.json
9CF548F8AAF84CDCBB1EDBBD0F2BA2F3AAA25E9645D116B4D520DEFBF95D328C	02_Published/unity_lists/guid_mapping_template.csv
3B37FB30A08EA105B9E34B0D00949767CF819D0D9DC822EE9D4323A6575B8979	02_Published/unity_lists/unity_asset_inventory.csv
C33FA05C625B5D0782836FDE823B310163C8815EAE2E08B89596110DDBAB61E9	02_Published/unity_lists/unity_scene_inventory.csv
32CB6C78194F1318C965A35618F5C285AE4EB0B92B1D94AEA5D2A0D2FBC8C984	asset_list.csv
09828E81D573331871F8F1E321BA1184F4A5C3FA93CB673065D2F07E210B0913	information_standard/data_boundary.yaml
65262AAA4332B38F71D8F9B3002EF8FB05F4A963C22ABF96330599728A74EBE4	information_standard/guid_rules.ids

).

4.2.3. Change Metrics and Pass/Fail Determination

Under the same conventions and denominator as the pre-test (definitions and rules for the four primary metrics unchanged), we summarize post vs. pre deltas. All four primary metrics—R1 Completeness, R2 Validity, R3 Uniqueness, and R4 Stability—increase markedly:

R1/R2/R4 absolute gains are +0.95 (post−pre, likewise below), R3 gains +0.93. Interoperability indicators also improve substantially: recognized pairs rise from 0 to 777 (scene recognitions to 18), while total breaks fall from 43 to 1 (missingUnity from 43 to 1, badPath remains 0).

Table 10. Delta summary (post−pre).

Metric	Pre	Post	Delta_abs
R1_Completeness	0.05	1.00	0.95
R2_Validity	0.05	1.00	0.95
R3_Uniqueness	0.05	0.98	0.93
R4_Stability	0.05	1.00	0.95

reports the post–pre delta summary for the four primary metrics,

Table 11. Interoperability deltas (post−pre).

Metric	Pre	Post	Delta_abs
|M| (pairs enumerated)	43	778	735
recognized_pairs	0	777	777
recognized_in_scenes	0	18	18
break_total	43	1	−42
break_missingUnity	43	1	−42
break_badPath	0	0	0
BRR	0.00	1.00	1.00
DR	1.00	0.00	−1.00

summarizes the interoperability deltas (post–pre), and

Table 12. Delta of main metrics (post−pre).

Metric	Delta_abs
R1_Completeness	0.95
R2_Validity	0.95
R3_Uniqueness	0.93
R4_Stability	0.95

lists the deltas of the main metrics. Figure 4, Figure 5 and Figure 6 visualize the absolute gains for the four metrics (bar chart). A formal pass/fail check (e.g., thresholds C/V/S = 1.00, U ≥ 0.95, BRR ≥ 0.95, DR ≤ 0.05) can be annotated directly in Table 10, Table 11 and Table 12; in this run, post-test values meet these stringent gates, with uniqueness not reaching 1.00 only due to one historical duplicate yet still exceeding common thresholds.

Gate catalog and criteria are provided in Appendix C (Table A6).

Under the unified denominator, the workflow increases completeness, validity, and stability to 1.00 and drives uniqueness close to 1.00 (with only one residual duplicate). Interoperability improves from BRR = 0/DR = 1 to approximately BRR ≈ 1/DR ≈ 0, leaving only one explainable breakpoint.

4.3. Improvement Results

From a building data management perspective, the proposed workflow brings design-stage digital-twin assets into a controlled CDE, using consistent container identifiers and provenance to support version reconciliation and evidence archiving and to form a traceable, rerunnable, and auditable chain. This yields concrete, verifiable benefits for different roles: BIM and CDE managers achieve the closed-loop governance of object primary keys at the design stage; engine and visualization teams use IfcGUID-22 as the minimal mutually recognized key to stably map Unity asset identifiers to object identity, enabling cross-system consistent referencing and replay; owners and auditors can compare pre- and post-states under the same conventions, with mapping details, baselines, and logs together constituting a verifiable registration chain that markedly reduces cross-system breaks and rework caused by bad data.

Under the same denominator U₀ = 820, rules, and interpreter as the pre-test, we compare post (after bridging and minimal repair) against pre item by item. Among the four integrity metrics, completeness, validity, and stability (R1/R2/R4) rise from about 0.05 to 1.00, while uniqueness (R3) reaches 0.98, leaving only one historical duplicate (Table 10). On the interoperability side, the chain changes from fully broken to almost fully connected: the BRR increases from 0.00 to approximately 1.00, with 777 of 778 pairs correctly recognized, and the DR drops from 1.00 to approximately 0.00 (one missingUnity, zero badPath; Table 11), while scene-level recognition is established for the first time (18 items; Table 10, Table 11 and Table 12). Although the post-test extends the scan on the consumption side from ∣M∣ = 43 to ∣M∣ = 778, the four primary metrics are always computed on the same U₀, ensuring direct comparability with the pre-test (see Table 10, “conventions” note).

Taken together, the evidence shows that, when Unity is the consumption side, once its asset identifiers are stably bridged to IfcGUID-22 and the chain of evidence is registered in the CDE, design-stage digital-twin assets can be transformed into compliant data streams that are comparable, traceable, and replayable (Table 7). The main pre-test breakpoint stemmed from misalignment with Unity inventories, indicating that without bridging and templated mapping, even complete IFC-side primary keys are difficult for the consumption side to recognize as the same object. In the post-test, by freezing export settings and preserving the original GlobalId, cross-version consistency reaches 1.00, making the interpretation “version differences = entity changes” valid and removing ambiguity sources in differencing (see Table 6, “Stability”). Residual issues on uniqueness converge to a minimal set of historical duplicates, which can be further reduced in the minimal repair step (see the duplicate cluster detail link associated with Table 6).

4.4. Research Comparison

Regarding research object and stage, existing reviews and empirical work largely place digital-twin (DT) emphasis on operations and maintenance (O&M) and energy scenarios: for example, systematic reviews in Buildings and assessments in Energy Informatics summarize major applications as operational monitoring, anomaly detection, energy optimization, and predictive maintenance, with relatively sparse design-stage evidence [5,29]. In contrast, this study targets design-stage object-level primary key governance and traceable registration: rather than proposing new operational control or energy strategies, we address object identifier consistency and cross-platform traceability along the modeling–export–consumption chain under the unified denominator U₀, with pre–post and bridging statistics.

Regarding task focus in Building Information Modeling (BIM)–game engine integration, prior work mainly centers on visualization, interaction, and training. Typical studies emphasize geometry and material conversion, real-time rendering, and user experience improvements but seldom propose a verifiable workflow of “object primary-key governance to stable mapping to provenance logging” as an auditable process [16,17,34,35,36]. Recent reviews likewise note that current BIM–engine contributions cluster around visualization, immersive applications, and process integration challenges, while data consistency and identifier persistence remain difficult [17,34].

Regarding data quality and delivery, facility management (FM)-oriented approaches such as Construction Operations Building Information Exchange (COBie) and FM-BIM stress list-based constraints on completeness and consistency and quality-control processes to provide usable data at handover [23,37]. However, these pipelines typically pivot on as-built and handover time points and pay limited attention to design-stage object-level primary key compliance, cross-version stability, and engine-side recognizability. Our contribution is to front-load primary key governance into executable artifacts at the design stage, through a six-step workflow, and to form an auditable, replayable chain of evidence using the unified denominator U₀ and pre–post Δmetrics.

Regarding problem evidence and engineering pain points, long-standing issues in the ecosystem include IfcGUID loss, duplication, and cross-tool inconsistency, for example missing and duplicate cases in Revit import and export and buildingSMART forum discussions on cross-platform GUID stability, which directly break cross-system reconciliation and traceability [14,15,28]. Our work not only quantifies IfcGUID completeness, validity, uniqueness, and stability, but it also explicitly addresses the ambiguity “engine-internal ID change does not equal object change” by establishing a stable mapping from Unity meta unique IDs to IfcGUID-22 and recording mapping details, baselines, and logs in the Common Data Environment (CDE), turning these “do it right” conditions into a reusable minimal constraint [11,18,27].

4.5. Threats to Validity

Statistical. Using percentages of percentages can exaggerate changes, especially when residual cases are rare. We mitigate this by keeping the unified denominator ${\mathrm{U}}_0$ throughout, reporting percentage-point differences (post—pre) and providing count metrics at the interoperability layer (for example, recognized_pairs and break_total). A residual risk is that relative changes on very small bases can still appear magnified.

Internal. Threats arise from export and consumption channel variance, tool upgrades, and unstable object primary keys. We control these by freezing modeling and export settings and the Unity environment, executing the post-test as a read-only rerun, preserving GlobalId, adopting IfcGUID-22 as the object key, and fixing the IfcOpenShell validation path and commands. A residual risk is that hidden defaults in third-party plug-ins may introduce minor deviations; to address this, we rely on Common Data Environment (CDE) path and checksum registration to support rerun auditing and issue tracing.

Construct. The key question is whether the four core metrics (completeness, validity, uniqueness, stability), plus the BRR and DR, adequately represent “IfcGUID-based compliance and consumption-side usability.” We control for this by treating IfcGUID-22 legality and uniqueness as hard criteria, enforcing unique identifiers and metadata governance at the container level, and materializing compliance as machine-checkable via ifcopenshell.validate and JSON reports. A residual limitation is that deeper semantic consistency is out of scope; therefore, we report IFC-side comparators and interoperability details in parallel to avoid over-interpreting the metrics.

External. The present context is limited to the design stage and the SketchUp to IFC to Unity toolchain. Our reuse premises are as follows: IfcGUID-22 compliance; unique identification and checksum registration of information containers in the CDE; and frozen export and consumption channels with bridging templates. Migration to other engines or toolchains will still require adapted mappings and probes; however, the reproducible artifacts and registrations enable independent verification and repeat experiments, aligning with current artifact review and reproducibility practices [11].

Provenance artifacts and checksums are summarized in Appendix A, and the exceptions policy is detailed in Appendix C.4.

5. Conclusions

This study focuses on the risk of data chain breakage that arises in smart homes when game engines are introduced for digital-twin workflows at the design stage. In response, we propose and validate a “non-standard to standard” governance workflow: IfcGUID-22 is used as the minimal mutually recognized object-level primary key; container-level identification and provenance logging are enforced in the CDE; and Unity’s unique asset IDs (.meta) are stably bridged to IfcGUID. In this way, design-stage digital-twin assets are transformed into comparable, traceable, and replayable data streams, and traceability-oriented governance is concretized at the design stage as a practical pattern for game engine interoperability.

In a virtual smart home case with a unified denominator ${\mathrm{U}}_0= 820$ covering both BIM model assets and digital-twin assets, the workflow increases the four IFC-based traceability metrics—completeness, validity, and stability—from low baselines to 1.00 and increases uniqueness to about 0.98. On the interoperability side, the bridge recognition rate (BRR) approaches 1.00, with only one residual break and stable recognition across multiple scenes. All of these improvements are achieved without changing the primary keys in the source models. In practice, BIM/CDE managers can embed IfcGUID compliance and CDE registration as a design-stage quality gate to reduce the risk of bad data; engine/visualization teams can adopt the IfcGUID↔Unity mapping template as a standard step in digital-twin asset delivery to safeguard the traceability of smart home virtual assets; and owners and auditors obtain a verifiable chain that links object-level changes to specific IFC files, Unity assets, and log commands, supporting auditing and root-cause analysis. Together, these improvements help close building data management gaps created when new tools are introduced at the design stage of smart buildings and are expected to reduce rework and the likelihood of broken evidence chains caused by bad data.

The proposed workflow is not limited to a single project but can be extended to larger building portfolios. Because all metrics are defined at the level of individual objects and computed under the same denominator $U_0$, portfolio managers can use a common set of integrity metrics (completeness, validity, uniqueness, stability) and interoperability indicators (BRR, DR) to compare the “readiness” of different design-stage models and their digital-twin assets. The same traceability-oriented governance pattern—using IfcGUID as the primary key, assigning clear identifiers to information containers in the CDE, and freezing export and consumption channels—can be reused across projects to support cross-building comparison and the planned reuse of digital-twin assets.

The study also provides a starting point for extending design-stage identifier governance into operational digital twins. Once IfcGUID-based identities are stably established and registered in the CDE and game engines, the same primary key can be carried into O&M platforms and IoT/BMS integrations, providing a consistent object spine for time-series analysis, fault detection, and energy optimization. Although detailed operational strategies are beyond the scope of this paper, the results suggest that robust identifier governance at the design stage can noticeably reduce integration friction later and provide a more reliable data foundation for full-lifecycle digital-twin assets.

Naturally, this study has limitations. The evidence comes from a single context (design-stage smart homes), a single export/consumption toolchain (SketchUp → IFC → Unity), and one pre/post recomputation within a single project. Even with a unified denominator, read-only reruns, and CDE registration to mitigate internal threats, the generalizability of the findings remains limited. Our metrics focus on four IfcGUID-based core indicators and interoperability recognition; deeper semantic consistency, cross-toolchain differences, and quantified time/cost impacts are not analyzed and should not be over-interpreted.

Future research can proceed in three directions. First, replicate and evaluate the workflow in more real projects and larger smart home portfolios, covering different community types, development stages, and technology stacks, to test robustness and transferability under more complex interoperability conditions. Second, analyze the relationship between the quality of design-stage identifier governance and operational outcomes such as energy performance, fault response, and occupant comfort, in order to evaluate the practical benefits of “cleaner” design-stage data for later decision-making. Third, investigate how the workflow can be embedded into project governance and business processes—for example, in development, procurement, auditing, and regulation—so as to form actionable guidelines or contractual clauses that support consistent management and knowledge reuse for smart homes at the estate, district, and city scales.