Abstract
Building passports are often presented as longitudinal records that connect design intent, construction realization, operation, and later interventions. Their usefulness depends on interoperability: information must retain meaning when it moves between lifecycle stages, organizations, and analytical tools. This article asks how a building passport should be structured so that the same asset record can support consistent data exchange and decision support across design, construction, operation, and retrofit contexts, while also allowing an end-of-life extension. The paper offers a targeted narrative synthesis of six studies selected for their relevance to lifecycle-oriented BIM use, BIM implementation barriers, reproducible HVAC operation datasets, BIM-supported sustainable construction, façade life cycle assessment, and retrofit optimization. On that basis, the article proposes a passport architecture organized around lifecycle handover events, canonical variables, provenance, dependency tracking, and external analysis interfaces. The methodology is specified through registry structures, mandatory and optional fields, an applicability-aware completeness metric, a handover sequence, an interoperability test procedure, comparator conditions, outcome measures, and a prospective validation protocol. One exact rule defines stage completeness as the proportion of applicable mandatory variables that have values, units, and provenance links. End-of-life records are included as a proposed module rather than as an evidence-backed conclusion from the cited studies. The article does not claim empirical validation. Its contribution is a falsifiable design proposal that can be tested for cross-stage data continuity, semantic preservation, reproducibility of derived indicators, and decision latency under realistic organizational constraints.
1. Introduction
A building passport may be defined as a persistent digital record that stores selected information about a building and its changes over time. For such a record to be useful in practice, the central issue is interoperability rather than storage alone. Data created during design must remain interpretable during construction handover; operational records must be usable in later retrofit studies; and analytical outputs must be traceable to the assumptions and data from which they were derived. In this article, “decision-ready” means that a receiving actor or tool can use a passport record for a specified decision without undocumented manual reinterpretation of meaning, units, temporal scope, or provenance.
The selected BIM studies are relevant because they describe lifecycle-oriented information use and limits on interoperability, even though they do not address passport governance directly. One study presents BIM as a framework spanning design, construction, operation, facility management, and sustainability dimensions, and discusses shared data environments at higher maturity levels. Another notes that open standards such as IFC and gbXML support transfer between BIM and simulation tools, while also stating that interoperability still requires further standardization and collaboration among software developers. These passages support treating interoperability as an unresolved problem in lifecycle information exchange rather than as a settled property of BIM adoption. [1] [2]
The same evidence also indicates that information continuity is shaped by organizational and technical conditions. BIM-supported green building adoption has been associated with technological competence, top management support, organizational readiness, external support, sustainability orientation, and perceived relative advantage. A separate barrier study identifies behavioral, managerial, technical, and operational obstacles that affect BIM use differently across design, construction, and operation phases. These studies do not establish how a building passport should be designed, but they do indicate that any proposed passport architecture must tolerate uneven digital capability across lifecycle handovers. [3] [1]
2. Research question and evidence scope
The research question is: how can a building passport be designed so that interoperable, decision-ready information is preserved across design, construction, operation, and retrofit contexts, with a structured extension for end-of-life records? The article is conceptual. It does not evaluate an existing passport implementation and does not report completed experiments.
The evidence scope is a targeted narrative synthesis. The selected studies were chosen because each illuminates one part of the design problem. Three are transferable methodological foundations. First, the BIM adoption study links BIM use to lifecycle performance analysis and information management across stages of urban infrastructure assets. Second, the BIM barrier study distinguishes phase-specific implementation obstacles and therefore helps identify where passport handovers are likely to fail. Third, the HVAC dataset study provides a reproducible method for standardized operation datasets, including explicit variable definitions, common schema elements, and storage in physical units without normalization. Its relevance is specific to operation-data standardization rather than to passport interoperability in general. [3] [1] [4]
Three additional studies are directly relevant to decision applications that a passport may need to support. One analyzes BIM benefits for sustainable construction, including simulation, coordination, data management, and lifecycle performance assessment. One compares façade alternatives through life cycle assessment based on inventoried quantities and producer-based data under national conditions, with hotspot identification. One presents a retrofit workflow that combines building simulation, surrogate modeling, multi-objective optimization, and ranking. From these studies, the article infers requirements for design-analysis exchange, environmental inventory traceability for façade-related records, and structured storage of optimization assumptions and outputs. The cited studies do not provide direct evidence about end-of-life interoperability; that part of the proposal is therefore framed as an extension. [2] [5] [6]
3. Analytical requirements derived from prior work
The first requirement is lifecycle-aware information continuity. The BIM adoption and BIM barrier studies both describe information practices that span multiple project stages. They also show that adoption and effective use depend on organizational readiness, training, and management support. For passport design, this means that a schema should be minimal at its core, because highly demanding data obligations may exceed what many organizations can maintain consistently across handovers. [3] [1]
The second requirement is explicit variable definition for operation records. The HVAC dataset study is instructive because it keeps a minimal common schema across heterogeneous buildings and simulators, stores variables in physical units, and states how indoor air temperature is represented for multi-zone and single-zone models. It also distinguishes standardized interaction interfaces from runtime integration between simulation engines. This supports a passport design in which operation data are standardized at the schema level while analytical engines remain loosely coupled. [4]
The third requirement is traceable environmental inventory for selected components. The façade LCA study emphasizes the identification and inventory of quantitative data, functional-unit-linked analysis, producer-based data sources, and hotspot identification. These passages support a façade module in a building passport that stores material quantities, functional unit mappings, and source metadata. They do not justify a claim that all lifecycle records must take exactly the same environmental form. [5]
The fourth requirement is support for derived decision variables and analytical lineage. The sustainable construction and retrofit studies show that simulation, performance assessment, and optimization depend on data-rich inputs and clearly defined outputs such as energy, carbon, comfort, and ranked alternatives. On that basis, this article proposes that passport records should distinguish raw observations from derived variables and should store the analytical method, parameterization, and version used to generate each derived result. [2] [6]
4. Proposed conceptual model and operational schema
This article proposes a lifecycle-event building passport represented as P = {A, H, V, G, D}. A is the asset registry; H is the handover-event registry; V is the variable registry; G is the dependency and provenance graph; and D is the decision registry. The model is centered on formal handover events rather than on abstract changes in responsibility. A lifecycle transition occurs only when a handover package for the current stage is formally accepted and versioned. This event closes one state snapshot and opens the next. The core states are design, construction, operation, and retrofit. End-of-life is modeled as an extension state that can be added where the governance context requires it.
The asset registry A contains the persistent identifiers needed to anchor all later records. Mandatory fields are: asset_id, site_location, building_use_class, gross_floor_area_unit, geometry_model_reference, system_taxonomy_reference, current_stage, and passport_version. Optional fields include ownership identifier, portfolio identifier, and regulatory classification. geometry_model_reference points to the current authoritative geometry object or file, not necessarily to a single software format. passport_version increments when any accepted handover changes the authoritative state of the passport.
The handover-event registry H records each accepted transition. Mandatory fields are: handover_id, asset_id, from_stage, to_stage, acceptance_date, accepting_role, submitted_package_reference, completeness_score, exceptions_log, and resulting_passport_version. Optional fields include contract package reference and approval workflow metadata. This registry is required because a stage boundary in the proposed model is not merely narrative; it is an accepted event with a package, score, and version outcome.
The variable registry V is row-based. Each variable entry must include: variable_id, asset_id, stage_of_origin, variable_name, value, unit, temporal_scope, spatial_scope, status, acquisition_method, applicability_flag, provenance_node_id, validity_interval, and variable_version. status must take one of four values: declared, verified, observed, or derived. applicability_flag takes {applicable, not_applicable, unknown}. A variable may also include confidence or uncertainty metadata where relevant; for surrogate-generated results, that field is proposed as mandatory.
The dependency and provenance graph G links variables, source records, methods, and derived outputs. Mandatory node types are source_record, method, variable, and model. Mandatory edge types are derived_from, measured_by, substitutes, supersedes, and valid_for. Dependency tracking is defined as follows: a derived variable y is dependent on any variable x for which a path x -> ... -> y exists through one or more derived_from or substitutes edges in G. For composite variables such as embodied carbon, all quantity, density, emission-factor, and boundary-definition inputs are upstream dependencies. For thermal discomfort metrics, upstream dependencies include indoor-temperature series, occupancy or comfort schedule assumptions where used, and calculation method.
The decision registry D stores decision episodes rather than only final choices. Mandatory fields are: decision_id, asset_id, decision_question, decision_stage, input_snapshot_id, method_reference, alternatives_reference, selected_option, justification_text, decision_date, and output_variable_ids. input_snapshot_id points to the exact versioned set of variables used in the analysis. This rule is necessary for reproducibility: a later user must be able to reconstruct not only the result but the state of the passport on which the decision was based.
5. Proposed methodology for interoperability design and handover control
The methodology has five layers: scope definition, variable specification, handover control, external analysis interfacing, and decision recording. Scope definition identifies the building boundary, intended decisions, and required modules. The core scope of this article covers design, construction, operation, and retrofit. The end-of-life module is optional and proposed for later testing, because the selected studies do not directly examine end-of-life passport interoperability.
Variable specification is use-case driven. For design-analysis exchange, examples of mandatory variables may include geometry reference, envelope assembly definitions, system types, occupancy assumptions, and climate-file identifier. For construction handover, examples may include installed product identifiers, substitutions, commissioning dates, and unresolved deviations. For operation records, examples may include timestamped HVAC power, indoor air temperature, setpoints, and weather variables expressed in physical units. For façade LCA, examples may include material quantities, functional unit mapping, and inventory source metadata. For retrofit optimization, examples may include candidate decision variables, objectives, constraints, surrogate-model metadata, and ranking method. [4] [5] [6]
Stage completeness must account for non-applicable fields. Let M_s,u be the set of mandatory variables for stage s and decision use u. Let A(v)=1 if variable v is applicable, A(v)=0 if it is explicitly marked not_applicable, and A(v)=1 by default when applicability is unknown. Let Q(v)=1 if v has a non-null value, recognized unit when numerical, and provenance link; otherwise Q(v)=0. The applicability-aware completeness score is C_(s,u) = [sum over v in M_s,u of A(v)Q(v)] / [sum over v in M_s,u of A(v)]. Variables marked not_applicable are excluded from both numerator and denominator. A handover is accepted only if C_(s,u) >= theta_(s,u), where theta_(s,u) is configurable by stage and decision use. A hypothetical design-analysis threshold may be 0.90, but this value is proposed for evaluation, not treated as validated.
Completeness alone is insufficient. Four rule classes are proposed. Rule class R1, semantic integrity: any numerical variable without unit, temporal scope, or spatial scope fails handover validation for analytical reuse. Rule class R2, substitution control: if a construction variable substitutes a design variable, a substitutes edge must be created in G and all downstream derived variables reachable through G are marked stale. Rule class R3, environmental comparability: any façade LCA record lacking functional-unit mapping or inventory source metadata may remain stored for traceability but is excluded from comparative LCA workflows. Rule class R4, surrogate accountability: if a variable is generated by a surrogate model, the passport must store training-domain description, validation-data scope, uncertainty field, and retraining trigger condition; otherwise the derived variable is not eligible for decision use. [5] [6]
Domain-specific extension modules are governed through a minimal-core plus extension pattern. The core schema controls identifiers, units, provenance, stage logic, and decision linkage. Extension modules define additional mandatory fields for domains such as façade LCA or operation analytics. A proposed governance rule is that an extension can add fields but cannot redefine the meaning of a core field. This constraint is intended to limit schema inflation while preserving domain detail.
6. Interoperability test procedure and lifecycle decision sequence
Because interoperability is defined operationally, a pass/fail test is required. For each intended analytical use, the receiving workflow specifies a required input vector I = {i1, i2, ..., in}. A passport passes the interoperability test for that use if, for every required input ik, the receiving analyst or tool can reconstruct from the passport: value or reference, unit, temporal scope, spatial scope, status, and provenance, without consulting undocumented external assumptions. Failure occurs if any required input is missing, semantically ambiguous, stale, or outside declared model applicability where such limits are mandatory. This procedure yields a binary pass/fail outcome for each use case and can also be summarized as the proportion of required inputs successfully reconstructed.
The lifecycle sequence is therefore defined by handover events rather than by a simple chronological checklist. Proposed Event E1 closes design when the accepted package satisfies the threshold for specified design-analysis uses. Event E2 closes construction handover when substitutions, commissioning records, and exceptions are accepted and stale derived variables are either recalculated or explicitly deferred. Event E3 closes an operation reporting interval when time-series variables are ingested, validated, and versioned for the chosen analysis horizon. Event E4 closes a retrofit study when the selected option and its input snapshot are recorded. Event E5, if activated, closes an end-of-life planning package with material recovery or deconstruction records. This event structure aligns stage changes with accepted data packages rather than with informal role changes.
This sequence differs in scope from the cited application studies. The sustainable construction paper examines BIM benefits such as simulation, coordination, and lifecycle performance analysis. The façade LCA paper examines component-level environmental inventory and hotspots. The retrofit study examines a tri-objective decision chain using simulation, surrogate models, evolutionary search, and ranking. This article does not present an alternative to those domain methods. It proposes a passport layer that can preserve the inputs, outputs, and lineage of such methods across successive handovers. [2] [5] [6]
An illustrative example clarifies the mechanism. A design package includes a façade assembly and preliminary environmental quantities. During construction, the insulation product is replaced. A substitutes edge is added in G, façade-related embodied-impact outputs become stale, and comparative LCA use is blocked until updated quantities and source metadata are supplied. Later, operation records show HVAC power, mean indoor temperature, setpoints, and weather data in standardized units. A retrofit workflow can then request the latest accepted snapshot, generate alternatives under energy, carbon, and comfort objectives, and write back the chosen option together with the method and ranking records. This example is hypothetical and serves only to show how the proposed passport logic would operate. [4] [6] [5]
7. Comparator, outcome measures, and prospective validation protocol
No empirical validation is reported here. Instead, this section specifies a prospective evaluation protocol. The comparator condition is a fragmented digital handover arrangement in which design BIM files, construction records, operation data, LCA files, and retrofit studies are stored separately without a shared canonical schema, dependency graph, or formal handover score. The intervention condition is the proposed passport framework with versioned handover events, applicability-aware completeness scoring, and decision-linked variable snapshots.
Four principal outcome measures are proposed. First, cross-stage data continuity for use u from stage s to stage t is DC_(s,t,u) = N_reusable / N_required, where N_required is the number of required inputs for use u at stage t and N_reusable is the number reconstructed directly from the accepted passport state from stage s without undocumented reinterpretation. Second, semantic preservation is SP = N_consistent / N_reused, where a reused variable is consistent only if unit, temporal scope, spatial scope, and provenance all match the receiving workflow specification. Third, analytical reproducibility is AR = N_reproduced / N_tested, where a tested derived indicator is counted as reproduced only if an independent analyst can regenerate the indicator from the recorded snapshot and method metadata to the same declared output type. Fourth, decision latency is the elapsed time between a decision request timestamp and the time at which an analysis-ready input package is assembled.
A fifth measure addresses the dependency logic: stale-data incidence SI = N_stale / N_derived after a handover involving substitutions or model changes. In the proposed framework, SI should increase immediately after a qualifying substitution because affected outputs are marked stale rather than silently retained; after recalculation, SI should decrease. This measure helps distinguish controlled invalidation from unnoticed inconsistency.
Validation is proposed in three tiers. Tier 1 would use synthetic lifecycle records to test schema conformance, completeness scoring, and dependency invalidation under controlled edge cases. Tier 2 would test whether at least one design-analysis workflow, one façade-LCA workflow, and one retrofit-decision workflow can consume passport snapshots according to the defined interoperability procedure. Tier 3 would simulate organizational handovers using role-based participants to identify failure points associated with training, management support, and workflow burden. These tiers are proposed procedures, not completed tests. [3] [1]
For operation-stage testing, simulated datasets are a reasonable design choice because the HVAC dataset study shows how standardized variables can be produced reproducibly under different buildings and climates while remaining in physical units. In a passport pilot, such datasets could be used to test schema behavior before introducing live portfolio data. This is a methodological choice proposed here; it should not be read as a recommendation established by the cited studies. [4]
8. Assumptions, boundary conditions, and failure cases
The proposal assumes that a minimal core schema can support common decision uses without eliminating domain detail, provided that extension modules are governed consistently. It also assumes that provenance capture, dependency maintenance, and versioned handovers can be performed at acceptable organizational cost. These assumptions are plausible but untested within this article.
The cited studies also indicate boundary conditions. The organizational literature suggests that digital capability, management support, and readiness vary across firms, while the barrier literature shows that technical, managerial, behavioral, and operational constraints differ by project phase. The inference drawn here is that the technical design of a passport may be more straightforward than sustaining the organizational practices required to maintain it. That inference is this article’s synthesis, not a direct finding of the sources. [3] [1]
A second boundary condition concerns analytical heterogeneity. The HVAC dataset study uses a common interface across EnergyPlus-based and Modelica-based settings without runtime coupling of the engines. This indicates that comparable schemas do not erase differences in model fidelity or available outputs. The proposed passport therefore aims for semantic interoperability, not identical physics or universal variable availability. [4]
Three failure cases are especially important. Failure case F1 is semantic collapse: variables are present but lack dependable unit, scope, or provenance metadata. Failure case F2 is silent staleness: upstream substitutions occur but dependent derived variables are not invalidated. Failure case F3 is extension drift: domain modules add fields in incompatible ways and erode the comparability promised by the core schema. For façade-related records, a further failure case is boundary incoherence, where quantities are stored without functional-unit mapping or source metadata, preventing valid comparison in LCA workflows. [5]
The end-of-life extension has the weakest evidence base within the selected references. It is included because a longitudinal passport may reasonably need to store deconstruction, recovery, or residual-material information, but the cited studies do not directly examine those processes. For that reason, no empirical or literature-backed claim is made here that the proposed end-of-life module is already adequate. It should be treated as a structured extension to be tested separately.
9. Conclusion
This article has proposed, rather than empirically established, a framework for building passport interoperability across design, construction, operation, and retrofit stages, with an optional end-of-life extension. The proposal is grounded in a targeted synthesis of studies on lifecycle-oriented BIM use, BIM implementation barriers, standardized HVAC operation datasets, façade LCA, and retrofit optimization. From those inputs, the article develops a lifecycle-event passport model with five registries, applicability-aware completeness scoring, dependency-based stale-data control, and decision-linked snapshots for reproducible analytical use. [3] [1] [4] [5] [2] [6]
The main conceptual claim is limited and testable: passport interoperability should be assessed through accepted handover events and explicit use-case reconstruction tests, not by file exchange alone. The article also specifies unresolved design parameters that require later testing, including stage- and use-specific threshold values theta_(s,u), the minimum mandatory fields for each extension module, the burden of maintaining dependency graphs, and the criteria for acceptable uncertainty metadata in surrogate-generated outputs. Until comparative evaluation is performed, the framework remains a precise design proposal rather than a validated implementation model.
Contribution and availability
The manuscript offers an original conceptual framework for building passport interoperability based on formal lifecycle handover events, canonical variable records, dependency and provenance graphs, and decision-linked snapshots. It translates selected findings on BIM lifecycle use, BIM barriers, operation-data standardization, façade environmental inventory, and retrofit optimization into a testable schema and prospective evaluation protocol for design, construction, operation, and retrofit contexts, while treating end-of-life as a proposed extension.
Funding: Roman Vlasov’s own funds. Editorial responsibility and competing interests: Roman Vlasov is the founder and Editor-in-Chief of Smart World Journal and the creator of the BILDRY construction-planning platform. Other competing interests have not been declared.
This conceptual study reports no newly collected empirical data. Its proposed procedures require the prospective validation described above.
References
- Alsehaimi, Abdullah; Ghani, Muhammad Usman; Baarimah, Abdullah O.; Alawag, Aawag Moshen; Ramu, Madhusudhan Bangalore (2026). Mitigating obstructions to attain successful application and implementation of building information modeling (BIM) in residential construction projects’ lifecycle. Scientific Reports. 16(1), 12389. doi:10.1038/s41598-026-43261-w.
- Daoud, Ahmed Osama; Oke, Ayodeji Emmanuel; Singh, Atul Kumar; Famakin, Ibukun O.; Mahmoud Abdel Aziz, Khaled; Olayemi, Taiwo Matthew (2025). Exploring the building information modelling benefits for sustainable construction using PLS-SEM. Scientific Reports. 15(1), 35781. doi:10.1038/s41598-025-14020-0.
- Alrasheed, Khaled A.; Alotaibi, Abdulaziz; Baarimah, Abdullah O.; Alawag, Aawag Moshen; Almujibah, Hamad; Ramu, Madhusudhan Bangalore (2026). BIM-Supported green building adoption in the construction industry. PLOS One. 21(9), e0356894. doi:10.1371/journal.pone.0356894.
- Domingo, Ferran Aran; Alonso, Pablo Fraile; Torrentó, Josep Rius; Batalla, Oriol Agost; Vilardell, Ignasi Barri; Mayoral, Jordi Vilaplana; Fornés, Jordi Mateo (2026). A reproducible method to generate multi-building, multi-climate HVAC operation datasets with a stochastic exploratory controller. MethodsX. 16, 103866. doi:10.1016/j.mex.2026.103866.
- Burchart, Dorota; Schabowicz, Krzysztof (2026). Environmental Life Cycle Assessment of Selected Materials—Building Façades in Poland. Materials. 19(4), 807. doi:10.3390/ma19040807.
- Duan, Zhongcheng; Li, Binhao; Zi, Yilun; Yao, Gang (2025). Building retrofit multiobjective optimization using neural networks and genetic algorithm three for energy carbon and comfort. Scientific Reports. 15(1), 38076. doi:10.1038/s41598-025-21871-0.