A Review Informed Translation Framework for Mapping Smart Building Services into Smart Readiness Indicator Aligned Assessment

Abstract

Smart building services are increasingly realised through combinations of sensors, actuators, communication infrastructures, software platforms, analytics, and artificial intelligence-based functions. These configurations enable adaptive control, real-time monitoring, contextual automation, predictive support, user interaction, and cross-domain coordination across heating, ventilation, air conditioning, lighting, energy management, security and access control, water management, and user-centric comfort services. At the same time, the European Union Smart Readiness Indicator provides a formal basis for assessing building smartness through technical domains, service functionalities, and multidimensional impact criteria. A systematic basis for translating real-world descriptions of smart building services and their enabling technology stacks into Smart Readiness Indicator-aligned assessment inputs remains underdeveloped. A PRISMA ScR informed review was conducted to identify principal smart building service domains, synthesise their core functionalities, and reconstruct the digital technologies through which these functionalities are realised. The synthesis shows that heating, ventilation, and air conditioning and lighting provide comparatively direct translation pathways to formal Smart Readiness Indicator domains, while energy management operates mainly as a supervisory and cross-domain layer. Security and access control, water management, and several user-centric services contribute meaningfully to building smartness but often show partial or extended formal correspondence. Monitoring and control emerge as a central cross-cutting layer because many higher-order smart building capabilities are expressed through visibility, supervision, orchestration, and digital representation. Building on this review, a methodological framework is established for translating smart building services into Smart Readiness Indicator-aligned assessments. The procedure uses the smart building service instance as the unit of analysis and links service identification, functionality formulation, technology stack reconstruction, formal domain correspondence, impact profiling, maturity classification, and building-level aggregation. This enables heterogeneous service descriptions to be converted into structured readiness profiles while preserving the distinction between operational functionality, enabling technology, formal assessment correspondence, and multidimensional impact contribution. Application of the framework to the IoT Building Cloud platform shows that a substantial share of smart building capability may derive from supervisory digital infrastructure rather than from isolated end-use control alone. The resulting readiness profile is characterised by strong representation in monitoring and control, information to occupants and operators, and maintenance awareness, together with more selective contributions to indoor environmental control and limited flexibility-related capability. The proposed framework supports Smart Readiness Indicator-aligned pre-assessment, comparative analysis, design stage reasoning, and digital tool development by providing a transparent bridge between smart building service descriptions and formal assessment-oriented interpretation.

1. Introduction

Buildings are undergoing a rapid digital transformation driven by increasing demands for energy efficiency, improved indoor environmental quality, operational transparency, and integration with wider energy systems [1,2,3]. The building sector represents a major share of global energy consumption and carbon emissions, making it a central focus of decarbonisation strategies [4]. Advances in sensing, communication, control, and software technologies have enabled buildings to evolve from passive infrastructures into active, data-driven environments capable of monitoring conditions, adapting operations, and supporting users in real time [5,6,7,8]. Within this context, the concept of the smart building has gained prominence as a way to describe buildings that utilise digital technologies to enhance performance [8,9,10,11,12] and usability and system interaction [13,14,15,16].

Despite this development, the understanding of smart buildings remains fragmented. Barriers to adoption are not only technical but also organisational and market-driven, with construction stakeholders often showing conservative behaviour and reluctance to shift toward smart building business models [17,18]. Research is often organised around specific technologies such as Internet of Things architectures, communication protocols, or analytics methods, or around individual application domains such as HVAC optimisation, lighting control, or energy management. While these perspectives provide valuable insight, they tend to isolate components of smart building systems rather than explaining how smartness is realised through coordinated service capability. As a result, it remains difficult to establish a consistent and transferable understanding of how smart building technologies contribute to operational intelligence at the building level [2,11].

A more coherent perspective emerges when smartness is analysed through smart building services. These services represent the operational functions delivered by building systems, including indoor climate regulation, lighting provision, energy monitoring, access control, water management, and occupant interaction. Smartness arises when such services are enhanced through digital technologies in ways that enable adaptive control, contextual response, predictive behaviour, user feedback, and system coordination. In this sense, technologies do not define smartness independently. Their relevance depends on the functionalities they enable within service domains.

At the same time, there is a growing need to evaluate building smartness in a structured and comparable manner. Within the European context, the Smart Readiness Indicator has been developed to assess the capability of buildings to adapt to user needs, optimise energy performance, and interact with the energy system [19,20]. The Smart Readiness Indicator evaluates buildings through technical domains, service functionalities, and multidimensional impact criteria, including energy efficiency, comfort, maintenance, information, convenience, and flexibility [20,21]. This represents a shift from static performance metrics toward a dynamic, service-oriented understanding of building capability.

A fundamental challenge arises from the difference between how smart buildings are described in practice and how they are evaluated within the Smart Readiness Indicator framework. Building descriptions typically focus on installed systems, sensors, control strategies, dashboards, and software platforms. In contrast, the Smart Readiness Indicator operates through formal technical domains and structured service logic. This creates a gap between real-world smart building implementations and assessment-oriented representations [20,22]. Without a structured method for translating between these perspectives, it remains difficult to use available building information as a basis for Smart Readiness Indicator-aligned evaluation.

The existing literature does not yet provide a systematic approach to this translation problem [8]. Studies on smart buildings tend to focus either on enabling technologies, on specific service domains, or on conceptual discussions of smartness and policy frameworks. Connections between these strands remain limited. In particular, there is a lack of structured methods that link smart building services, their enabling technologies, and the formal logic of the Smart Readiness Indicator in a way that supports assessment-oriented interpretation.

To address this gap, a methodological framework is required that can translate smart building service descriptions into Smart Readiness Indicator-aligned assessment logic. Such a framework must begin with service domains, identify their core functionalities, relate these functionalities to enabling digital technologies, and position them within the formal domain structure of the Smart Readiness Indicator. It must also interpret how these functionalities contribute to the multidimensional value dimensions captured by the Smart Readiness Indicator.

The aim is therefore to develop a methodological translation framework that links smart building service descriptions, enabling technology configurations, and Smart Readiness Indicator-aligned assessment logic. The framework addresses a specific gap between the descriptive language of smart building research and practice, where services are commonly described through devices, platforms, control strategies, and digital infrastructures, and the formal logic of the Smart Readiness Indicator, where assessment is structured through technical domains, service functionalities, and impact criteria. This gap limits the reproducibility of assessment-oriented interpretation, especially when building descriptions are heterogeneous, incomplete, or expressed in implementation-specific terminology. Four research questions guide this effort.

• RQ1. What principal smart building service domains and core smart functionalities are reported in the literature?
• RQ2. Which digital technologies enable these functionalities across sensing, actuation, control, communication, software, and intelligence layers?
• RQ3. How do these service domains and functionalities relate to the formal technical domains and impact criteria of the Smart Readiness Indicator?
• RQ4. How can this relationship be translated into a structured, reproducible framework that supports Smart Readiness Indicator-aligned pre-assessment, comparison, and building-level readiness profiling?

The novelty of the contribution lies in the translation logic rather than in the identification of smart building technologies alone. Existing studies commonly review smart building technologies, analyse individual service domains, examine building energy management systems, or discuss the Smart Readiness Indicator as a policy and assessment instrument. However, they do not provide a detailed operational procedure for converting real service descriptions and technology stacks into Smart Readiness Indicator-aligned assessment records. The framework developed here contributes such a procedure by defining the smart building service instance as the unit of analysis, reconstructing the physical, control, digital, and intelligence layers that enable each service, assigning formal Smart Readiness Indicator correspondence, coding multidimensional impact profiles, and aggregating service records into building-level readiness profiles.

The main contributions are fivefold. First, the principal smart building service domains and their core functionalities are synthesised across HVAC, lighting, energy management, security and access control, water management, and user-centric comfort and wellbeing services. Second, the enabling digital technologies underlying these functionalities are structured across sensing, actuation, control, communication, software, analytics, metadata, and integration layers. Third, a correspondence logic is established for relating literature-derived service domains to formal Smart Readiness Indicator domains through direct, partial, cross-domain, and extended relevance categories. Fourth, a stepwise translation and aggregation framework is developed for converting service descriptions and technology configurations into Smart Readiness Indicator-aligned assessment representations. Fifth, the applicability and limits of the framework are demonstrated through the IoT Building Cloud case, with explicit attention to monitoring and control, digital representation, geofence-based interaction, and the distinction between enabling digital infrastructure and directly assessing relevant service functionality.

The remainder of the paper is organised as follows. Section 2 presents the PRISMA-informed methodological design and review procedure underpinning the framework development. Section 3 establishes the Smart Readiness Indicator as the formal assessment reference framework and clarifies its functional logic. Section 4 synthesises the principal smart building service domains and their core functionalities as the operational basis for translation. Section 5 analyses the enabling digital technologies that realise these functionalities across layered infrastructures. Section 6 develops the translation procedure linking service instances, technology configurations, and Smart Readiness Indicator domain correspondence and impact profiles. Section 7 introduces the aggregation framework for deriving building-level readiness profiles from translated service records. Section 8 applies the full methodology to the IoT Building Cloud ecosystem as a case study. Section 9 discusses the methodological implications, limitations, and broader insights for understanding building smartness. Section 10 concludes the paper.

2. Methodology

2.1. Research Design

This study adopts a review-informed framework development design structured in three interrelated phases: literature scoping and knowledge synthesis, framework development, and framework demonstration through case application. The purpose of this design is to move systematically from a heterogeneous body of literature on smart building services and enabling digital technologies toward a structured methodology for translating real building service descriptions into Smart Readiness Indicator-aligned assessment logic.

The first phase establishes the empirical and conceptual basis of the study through a PRISMA ScR-informed scoping review. This phase identifies the principal smart building service domains reported in the literature, reconstructs their core functionalities, and captures the digital technologies through which these functionalities are realised. The second phase transforms this synthesis into a methodological translation framework that links service instances, functionality, technology stack, Smart Readiness Indicator domain correspondence, and impact interpretation. The third phase demonstrates the applicability of the framework through a structured case application to the IoT Building Cloud ecosystem.

This design reflects the actual methodological character of the study. The article does not merely review existing literature on smart buildings and Smart Readiness Indicator-related concepts. It uses the literature as the basis for constructing a translation methodology and then applies that methodology to a concrete smart building service ecosystem. The research design is therefore both integrative and constructive. It combines systematic literature-based knowledge synthesis with methodological development and demonstrative application.

2.2. Rationale for a PRISMA ScR-Informed Approach

A PRISMA ScR-informed approach was selected because the field of smart building services is broad, conceptually fragmented, and methodologically heterogeneous. Relevant studies span building services engineering, building automation, Internet of Things infrastructures, software platforms, energy management, digital twins, indoor environmental control, security systems, water monitoring, and user-oriented building interaction. The literature includes conceptual studies, system architectures, implementation reports, technical evaluations, and application-oriented case studies. A scoping-oriented review logic is therefore appropriate because it supports systematic retrieval and transparent source selection while remaining compatible with conceptual breadth and diversity of evidence.

However, the objective of this study extends beyond literature mapping alone. The work seeks not only to identify what service domains and technologies are present in the literature, but also to derive a structured procedure for translating service descriptions into Smart Readiness Indicator-aligned assessment logic. For this reason, the review is embedded within a broader multi-phase design. The scoping phase provides the evidence base and conceptual structure. The framework development phase translates this structure into a reproducible methodological procedure. The case application phase demonstrates how the resulting framework can be used to interpret a concrete smart building service ecosystem in Smart Readiness Indicator-aligned terms.

This combined design ensures methodological transparency while also making the study constructive and practically relevant. The review corpus is not treated as an endpoint in itself. It functions as the foundation for methodological abstraction, translation logic, and applied demonstration.

The approach is described as PRISMA ScR-informed rather than as a fully registered PRISMA ScR protocol. No prior protocol was registered before the review process. This limitation is acknowledged explicitly because protocol registration would have strengthened methodological transparency and reduced the risk of post hoc adjustment in the review design. To compensate for the absence of protocol registration, the review procedure was documented through predefined eligibility criteria, database-specific search expressions, explicit coding dimensions, and traceable exclusion logic during screening and full-text assessment. The resulting method should therefore be interpreted as a transparent, scoping-inspired framework development process rather than as a formally registered scoping review. The PRISMA checklist is include in the Supplementary Materials.

2.3. Scope and Conceptual Delimitation

The scope of the study covers literature addressing smart building services, their operational functionalities, and the digital technologies that enable those functionalities. Smart building services are understood as building-related service domains whose operation is enhanced through digitally enabled capabilities such as adaptive control, real-time monitoring, contextual automation, remote supervision, user interaction, predictive support, data-driven optimisation, and cross-domain coordination.

Six principal service domains are considered: HVAC, lighting, energy management, security and access control, water management, and user-centric comfort and wellbeing services. These domains recur consistently across the literature and represent the main areas in which digital technologies contribute to operational intelligence in buildings. The study also recognises that smartness increasingly emerges through cross-domain supervisory and integrative digital infrastructures, especially through monitoring and control, dashboards, middleware, and digital representation.

The literature-based service structure does not fully coincide with the formal structure of the Smart Readiness Indicator. HVAC and lighting show relatively direct correspondence to recognised formal domains. Energy management operates mainly as a supervisory and cross-domain layer that relates especially to electricity, monitoring, and control. User-centric comfort services often span several formal domains simultaneously. Security and access control and water management contribute meaningfully to building smartness, but do not map directly to standalone formal Smart Readiness Indicator domains. The study therefore distinguishes among direct correspondence, partial correspondence, cross-domain correspondence, and extended relevance.

Enabling technologies are defined broadly to include sensing devices, actuators, controllers, gateways, communication infrastructures, middleware, cloud platforms, dashboards, mobile applications, metadata structures, digital twins, analytics services, and artificial intelligence-related functions. Both hardware and software layers are included, together with the ways in which they are integrated into coherent smart building service architectures.

The Smart Readiness Indicator is used as the formal assessment reference framework and as the translation target. The study does not attempt to reproduce official Smart Readiness Indicator scoring procedures. Instead, it develops a structured methodology for translating real service descriptions and technology configurations into Smart Readiness Indicator-aligned assessment representations.

2.4. Information Sources and Search Strategy

The literature search was conducted in Scopus, Web of Science, and IEEE Xplore in order to capture research across building engineering, energy systems, smart buildings, thte Internet of Things, automation, and software-oriented system development. These databases were selected because together they provide broad and complementary coverage of the multidisciplinary field addressed in the study.

The search strategy combined three sets of terms: building context terms, service-related terms, and technology-enabling terms. The intention was to capture studies that describe smart building functions in operational terms while also providing sufficient technological detail to support later reconstruction of service functionality and translation logic.

The main search expression used in Scopus was the following: TITLE-ABS-KEY ((“smart building*” OR “intelligent building*”) AND (“building service*” OR HVAC OR heating OR cooling OR ventilation OR lighting OR “energy management” OR “access control” OR security OR “water management” OR comfort OR wellbeing) AND (sensor* OR actuator* OR control* OR software OR platform* OR IoT OR “internet of things” OR automation OR analytics OR “artificial intelligence” OR AI OR “machine learning” OR dashboard* OR monitoring)).

Equivalent expressions were adapted to the syntax of Web of Science and IEEE Xplore. Searches were restricted to peer-reviewed journal articles and conference papers published in English. The search scope was intentionally broad in order to accommodate the diversity of terminology used across the smart building literature. Precision was achieved during the subsequent screening and eligibility assessment stages rather than by imposing narrow search constraints at the outset.

2.5. Eligibility Criteria and Source Selection

Studies were included when they addressed building-related smart services and provided sufficient detail on service functionality, enabling technologies, system operation, or assessment-relevant capability to support service-level interpretation. Inclusion required substantive relevance to at least one of the following analytical dimensions: service domain, smart functionality, technology stack, architectural integration, user interaction, monitoring and control capability, or Smart Readiness Indicator relevant impact.

Studies were excluded if they focused solely on static building properties without digitally enabled service aspects, on generic information technology without explicit building application, on abstract optimisation approaches lacking operational service context, or on simulations that did not describe an implemented or implementable building service function. Editorial material, secondary reviews, and highly superficial descriptions were also excluded because they did not provide sufficient primary detail for reconstructing the translation chain from service description to assessment-aligned interpretation.

Records retrieved from Scopus, Web of Science, and IEEE Xplore were consolidated before screening. Duplicate records were removed, and automated metadata filtering was applied to ensure that bibliographic information was sufficiently complete for screening. Title and abstract screening were then used to identify studies with clear relevance to smart building services and digital enablement. This screening stage resulted in 589 reports being sought for retrieval, of which 540 were assessed for eligibility after unavailable reports had been excluded.

Full-text screening evaluated whether the studies provided sufficient operational, technological, or architectural detail to support coding. Studies were excluded at this stage when they lacked explicit service integration, focused only on isolated devices without functional interpretation, did not describe the operational role of the technology, or could not support reconstruction of at least one service instance. The source selection process prioritised conceptual and methodological relevance rather than maximum corpus size. This was necessary because the framework required studies that could support translation from service domain, to functionality, to enabling technology stack, to assessment-aligned interpretation. The final corpus consisted of 173 studies, comprising 168 studies identified through database searching and 5 additional records identified through other methods, as shown in Figure 1.

2.6. Data Extraction and Coding

A structured coding scheme was applied to each included study in order to reconstruct the service-oriented and technology-oriented logic required for framework development. Six analytical dimensions were extracted from each study:

• Service domain. Each study was classified according to one or more service domains, including cross-domain cases where relevant.
• Functionality. Operational capabilities were identified, such as occupancy-based control, adaptive regulation, monitoring, anomaly detection, feedback provision, scheduling, predictive support, or personalisation.
• Technology stack. Enabling technologies were recorded across sensing, actuation, control, communication, software, analytics, and integration layers.
• Smart Readiness Indicator domain correspondence. Each functionality was positioned relative to the nearest formal Smart Readiness Indicator domain and classified according to correspondence type.
• Architectural logic. Integration patterns were identified, including edge and cloud arrangements, middleware coordination, interoperability mechanisms, metadata structures, and digital representation.
• Impact alignment. Likely contributions to energy efficiency, maintenance and fault prediction, comfort, convenience, health and wellbeing, accessibility, information to occupants, and energy flexibility were interpreted.

This coding scheme enables reconstruction of the full translation chain from service domain, through functionality and enabling technology, to Smart Readiness Indicator-aligned assessment relevance. It also provides the empirical basis for the methodological abstractions introduced in the subsequent phase of the study.

2.7. Coding Governance and Bias Management

The coding process required interpretive judgement because smart building services are not described consistently across the literature and because the Smart Readiness Indicator does not always provide one-to-one correspondence for literature-derived service domains. To reduce subjectivity, coding was governed by a predefined coding structure that separated six analytical dimensions: service domain, primary functionality, technology stack, architectural logic, Smart Readiness Indicator domain correspondence, and impact alignment. This separation was important because it prevented direct movement from technology description to impact attribution without first identifying the operational service function.

Coding followed a rule-based interpretive procedure. A service was first coded according to its operational purpose rather than according to the technology used. The same occupancy sensor could therefore be coded under HVAC when used for ventilation control, under lighting when used for switching or dimming, or under monitoring and control when used primarily for visibility and supervisory awareness. Smart Readiness Indicator correspondence was then assigned only after the functionality and technology stack had been reconstructed. Impact attribution was treated as a separate step and was not allowed to override the formal correspondence classification.

Several consistency checks were applied during coding. First, ambiguous cases were checked against the four correspondence categories used in the framework: direct correspondence, partial correspondence, cross-domain correspondence, and extended relevance. Second, services with overlapping effects were coded across multiple domains only where the source description provided a genuine functional basis for such overlap. Third, each impact criterion was coded explicitly, including cases with no meaningful contribution, to avoid selective attribution of positive impacts. Fourth, case study coding was revisited after aggregation to ensure that the building-level profile could be traced back to individual service records.

No formal inter-rater reliability statistic, such as Cohen’s kappa, was calculated. This is a methodological limitation because kappa-based testing would have provided a stronger quantitative measure of coding consistency. The reason is that the study was designed as a review-informed framework development, where the coding categories were used constructively to build a translation method rather than to test a fixed classification scheme across independent raters. To address this limitation, the framework makes the coding rules explicit, includes worked examples, distinguishes formal correspondence from impact interpretation, and treats the resulting profiles as structured pre-assessment outputs rather than as official Smart Readiness Indicator scores.

Illustrative coding can be summarised as follows. A metadata-driven visualisation service is not coded as “information to occupants” solely because it provides visual output. It is first coded as a monitoring and control-related service if its main function is to make building service infrastructure, sensor deployment, or operational status visible and inspectable. Its impact profile may then include information to occupants or operators as a primary or secondary contribution. This distinction explains why metadata-driven visualisation is positioned under monitoring and control at the correspondence level while still contributing to the information impact dimension.

2.8. Synthesis and Framework Development

Synthesis was conducted as the second phase of the methodological design and served as the basis for framework development. The purpose of this phase was to transform the literature-based coding results into a structured translation methodology that could be applied systematically to smart building service descriptions.

The synthesis proceeded in five analytical stages. First, the principal smart building service domains were identified and stabilised. Second, recurring smart functionalities were reconstructed across those domains. Third, enabling technologies were consolidated into recurring technology configurations spanning physical, control, digital, and intelligence-related layers. Fourth, these functionalities were positioned relative to the formal domain structure of the Smart Readiness Indicator. Fifth, the likely assessment relevance of each functionality was interpreted through the recognised Smart Readiness Indicator impact dimensions.

This process supports both horizontal comparison across service domains and vertical reconstruction from technology, to functionality, to assessment relevance. On this basis, the study develops a translation framework structured around smart building service instances as the central unit of analysis. The framework links service instance identification, functionality formulation, technology stack reconstruction, formal Smart Readiness Indicator correspondence, impact attribution, and aggregation into building-level readiness profiles.

The result is not merely a thematic summary of the literature. It is a methodological framework derived from the review corpus and intended for reproducible use in Smart Readiness Indicator-aligned interpretation of real smart building service ecosystems.

2.9. Framework Demonstration Through Case Application

The third phase of the methodology demonstrates the applicability of the framework through a structured case application. The purpose of this phase is not full external validation in the strict comparative sense, but methodological demonstration. It shows how the framework can be used to decompose a real smart building service platform into service instances, reconstruct its enabling technology layers, assign formal Smart Readiness Indicator correspondence, interpret its impact profile, and aggregate the resulting records into a building-level readiness profile.

The selected case application represents an integrated smart building service ecosystem spanning wireless sensing, gateways, dashboards, metadata-driven visualisation, geometry-based digital representation, and geofence-based access and control. This makes it well-suited for demonstrating the framework’s ability to handle both direct end-use service functions and supervisory digital infrastructures that contribute to monitoring and control, information provision, and contextual building intelligence.

The case application, therefore, serves an important methodological function. It shows that the proposed translation logic can be applied not only to literature abstracts or conceptual examples, but also to a concrete and technically documented service ecosystem. In doing so, it demonstrates that the framework can preserve the complexity of contemporary smart buildings while still producing a structured Smart Readiness Indicator-aligned interpretation.

2.10. Methodological Limitations

Several methodological limitations should be acknowledged. First, the field exhibits high terminological diversity, and some relevant studies may use alternative vocabulary not fully captured by the search expressions. Second, the corpus is selected for conceptual and methodological relevance rather than exhaustive coverage of every possible smart building technology. Third, interpretive judgement remains necessary when assigning Smart Readiness Indicator correspondence and impact relevance, especially for cross-domain or only partially aligned services. This limitation is addressed by explicit correspondence categories and by maintaining a clear distinction between formal domain mapping and impact interpretation.

A further limitation concerns the demonstrative character of the case application. The framework is applied in depth to one integrated smart building platform, which shows its usability and internal coherence, but does not yet establish broader comparative validation across multiple independent building cases. The present study, therefore, demonstrates methodological applicability rather than full cross-case generalisability.

Despite these limitations, the three-phase methodology provides a transparent and robust basis for moving from fragmented smart building literature toward a structured framework for Smart Readiness Indicator-aligned assessment interpretation.

3. The Smart Readiness Indicator as the Formal Assessment Reference Framework

3.1. Relevance of the Smart Readiness Indicator

The Smart Readiness Indicator provides the formal assessment reference structure for the translation developed in the following sections. Its importance lies not simply in its role as a European framework for evaluating building smartness [19,20,22], but in the way it conceptualises smartness through technical services, service functionalities, and multidimensional forms of building value. In contrast to more static approaches to building evaluation, the Smart Readiness Indicator treats smartness as an operational capability. The central question is not whether digital technologies are present, but what building services can do, how adaptively they can do it, and what forms of value emerge from those capabilities for occupants, operators, and the wider energy system.

This logic aligns closely with a service-oriented understanding of smart buildings. Smartness is not adequately described through connected devices alone. It becomes meaningful when sensing, actuation, communication, software, and analytics are configured into service capabilities that support adaptive control, contextual response, user interaction, information provision, and cross-system coordination. A formal assessment structure that recognises smartness through service capability is therefore essential for relating the smart building literature to assessment-oriented reasoning.

A methodological challenge arises because the Smart Readiness Indicator does not organise knowledge in the same way as the smart building literature. Research commonly describes buildings through service domains, technologies, architectures, control strategies, dashboards, data platforms, digital twins, and implementation cases. These descriptions do not directly correspond to formal Smart Readiness Indicator terminology. A translation step is therefore required if literature-derived service descriptions are to support Smart Readiness Indicator-aligned assessment.

For this reason, the Smart Readiness Indicator is used here in two related ways. It functions first as an analytical reference framework for interpreting how smart building services contribute to recognised forms of building smartness. It functions second as the formal assessment target toward which service descriptions and technology configurations must be translated if they are to support structured pre-assessment and comparison. Full official scoring procedures are not reproduced. The aim is to establish a rigorous bridge from real building service descriptions to assessment-aligned representations.

3.2. Functional Logic of Building Smartness

A defining characteristic of the Smart Readiness Indicator is its functional view of technical building systems. Smartness is not assessed merely on the basis of whether automation devices, connected components, or software platforms are present. Assessment relevance emerges when technical systems perform functions that contribute to adaptive, efficient, user-responsive, and energy system-aware operation. This functional orientation provides the conceptual foundation for a service-based translation logic.

In practical terms, a sensor has no direct assessment meaning in isolation. Its relevance emerges when it enables functions such as demand-controlled ventilation, adaptive temperature regulation, daylight-responsive lighting, fault detection, user feedback, or contextual automation. The same holds for gateways, dashboards, analytics modules, and digital twins. Their contribution depends on the service capabilities they support rather than on their mere installation.

This functional logic justifies the use of smart building service functionality as the primary analytical unit [23]. Technologies enable functionalities. Functionalities create service capability. Service capability acquires assessment relevance when it corresponds to formal Smart Readiness Indicator logic and contributes to recognised impact dimensions. This chain is central to the translation developed later.

A further implication follows from this perspective. Smartness cannot be inferred solely from technological density. A building may contain many digital devices and still exhibit limited smartness if those devices do not support adaptive, informative, or coordinated service operation. Conversely, a comparatively modest technology stack may produce substantial smartness when configured into meaningful service functionality. Assessment, therefore, requires interpretation of technological arrangements through their operational role.

3.3. Formal Technical Domains

The formal structure of the Smart Readiness Indicator is organised around technical domains corresponding to major building systems and service areas. These typically include heating, cooling, domestic hot water, ventilation, lighting, dynamic building envelope, electricity, electric vehicle charging, and monitoring and control [20,21]. Within these domains, assessment focuses on the presence and sophistication of service-related capabilities.

This domain structure provides the formal architecture into which smart building services must be translated if they are to support Smart Readiness Indicator-aligned assessment. However, the relationship between literature-derived service domains and formal assessment domains is not uniform. Some service domains align relatively directly with formal domains. HVAC aligns strongly with heating, cooling, and ventilation. Lighting aligns directly with lighting. Other service domains have more complex correspondence patterns. Energy management often overlaps with electricity, monitoring, and control. User-centric comfort services may span heating, ventilation, lighting, and monitoring and control. Security, access control, and water management remain important in the literature, yet do not map directly to standalone formal domains.

This mismatch between research categories and formal assessment categories is one of the main reasons a translation framework is required. Treating literature-derived domains as if they were identical to formal Smart Readiness Indicator domains would overstate the precision of the mapping and obscure important distinctions. Formal domain correspondence must therefore be treated as an explicit analytical step rather than as an assumption.

Three correspondence types are especially useful. Direct correspondence applies where the service domain aligns closely with a formal technical domain. Partial correspondence applies where a service overlaps one or more formal domains but is framed more broadly or differently in the literature. Extended relevance applies where a service contributes meaningfully to smart building operation and assessment of relevant value, yet falls outside the formal standalone domain set. This distinction preserves analytical accuracy while allowing meaningful services beyond the formal domain set to remain visible within the assessment logic.

3.4. Service Logic and Levels of Sophistication

The Smart Readiness Indicator is concerned not only with technical domains, but also with the service logic through which those domains become smart [20,22]. The relevant question is not simply whether heating, lighting, or ventilation exists. The relevant question is whether these services can adapt, respond, inform, optimise, or interact in ways that reflect meaningful smartness. Assessment, therefore, depends on the sophistication of service functionality rather than on the simple presence of infrastructure.

This principle is highly relevant to the smart building literature. Many reported capabilities, such as occupancy-responsive control, predictive scheduling, anomaly detection, dashboard-based visibility, geofence-triggered activation, contextual automation, and cross-domain orchestration, are not merely technological features. They are forms of service logic. Their significance lies in the way they transform technical systems into adaptive, visible, user-responsive, or coordinated services.

Although detailed official service catalogues and exact functionality level definitions are not reproduced procedurally here, the underlying principle remains central. Service descriptions must be interpreted in relation to their level of operational sophistication. A manually adjustable service, a scheduled automated service, a sensor-responsive service, and a predictive or context-aware service differ significantly in their smartness implications, even if they operate within the same technical domain. This observation is crucial for any methodology intended to translate real service descriptions into assessment-aligned logic.

A structured translation, therefore, requires more than domain identification. It requires reconstruction of what the service is capable of doing and how intelligently that capability is realised. Functionality is the layer at which technology becomes operationally meaningful and at which assessment relevance begins to take form.

3.5. Impact Criteria as Multidimensional Value Dimensions

In addition to formal domains and service logic, the Smart Readiness Indicator evaluates smartness through a set of impact criteria. These generally include energy efficiency, maintenance and fault prediction, comfort, convenience, health and wellbeing, accessibility, information to occupants, and energy flexibility [20]. These multidimensional impacts are particularly visible in advanced AI- and IoT-based BEMS, where energy efficiency, operational intelligence, occupant comfort, and grid interaction are pursued simultaneously under regulatory constraints [24,25]. Energy flexibility depends not only on technical capability but also on building readiness, stakeholder coordination, and market conditions, which can significantly constrain its realisation [26]. In critical buildings such as hospitals, these concerns must be balanced carefully because energy efficiency and flexibility must be achieved without compromising reliability, service continuity, or occupant conditions [27]. Together, these dimensions express the idea that building smartness is not reducible to one single outcome. A building may be smart because it operates more efficiently, because it improves visibility and decision-making, because it better supports occupants, because it predicts faults, or because it can respond more effectively to energy system conditions.

These impact criteria provide the evaluative layer through which service functionalities acquire building-level significance. However, they must be applied in a disciplined way. Impact interpretation cannot substitute for formal domain correspondence. It becomes meaningful only when grounded first in service functionality and formal assessment logic. Without this ordering, analysis risks collapsing into a broad but imprecise value narrative disconnected from the formal structure of the Smart Readiness Indicator.

For this reason, the impact criteria are treated as a second interpretive layer. The first layer concerns the service domain and the functionality being delivered. The second concerns the enabling technology stack through which that functionality is realised. The third concerns formal correspondence to Smart Readiness Indicator domains or service logic. Only after those steps does impact interpretation become analytically robust.

This ordering is especially important for services with partial or extended correspondence. Security and access control, water management, and user-centric comfort services may contribute meaningfully to convenience, visibility, health, or fault awareness, yet their formal relation to the Smart Readiness Indicator may be indirect or distributed across several domains. A disciplined separation between correspondence and impact preserves both relevance and precision.

3.6. Mismatch Between Literature Categories and Assessment Categories

A recurring challenge in smart building research is that the categories used in the literature do not map neatly onto formal assessment categories. Research categories are typically shaped by technical inquiry, implementation concerns, application contexts, or architectural paradigms. Formal Smart Readiness Indicator categories are shaped by the need to assess smartness through technical domains and structured service logic. Both perspectives are legitimate, but they serve different purposes.

The literature often organises knowledge around domains such as energy management, indoor comfort, digital twins, Internet of Things ecosystems, or smart access services. Formal Smart Readiness Indicator logic, by contrast, is structured around technical domains and service functionality within those domains. This difference creates a methodological problem whenever research findings are used as the basis for assessment-aligned reasoning.

A two-step bridge is therefore required. The first step identifies the literature-derived service domain, the operational functionality, and the enabling technology stack through which service intelligence is realised. The second step positions that functionality relative to the nearest formal Smart Readiness Indicator domain or service logic and then interprets its likely contribution to one or more impact criteria. This two-step logic avoids two common errors. The first is to treat the Smart Readiness Indicator merely as a list of desirable impacts detached from its service structure. The second is to assume that every service discussed in the literature maps directly and fully onto a formal assessment domain.

The translation developed later rests on this distinction. It preserves the meaning of literature-derived categories while allowing them to be positioned systematically within assessment logic. This is essential if heterogeneous building descriptions are to be translated without either oversimplification or loss of important service detail.

3.7. Suitability of the Smart Readiness Indicator as a Translation Target

The Smart Readiness Indicator is a suitable translation target for several reasons. First, it is specifically designed to assess building smartness through technical services and their operational capabilities. This makes it directly relevant to a service-oriented synthesis of smart buildings.

Second, it combines formal structure with multidimensional value interpretation. A purely technical classification system would not capture the broader significance of smart building services. A purely value-oriented framework would not provide sufficient structure for systematic translation. The Smart Readiness Indicator provides both a formal service reference architecture and a multidimensional evaluative vocabulary.

Third, its growing strategic importance in the European policy and research landscape makes translation into Smart Readiness Indicator-aligned logic practically relevant. [19,23,28,29,30,31] A structured methodology that relates service descriptions and technology configurations to this framework can support early design reasoning, pre-assessment, technology comparison, digital auditing, and future decision support tools [32,33,34,35,36,37,38,39,40,41,42].

Fourth, the Smart Readiness Indicator is sufficiently structured to anchor translation without requiring a claim of full procedural replication. The objective is not to generate official scores directly from literature descriptions. The objective is to establish a reliable methodology through which smart building services can be interpreted in assessment-aligned terms. The Smart Readiness Indicator provides an appropriate formal target for that purpose.

3.8. Role of the Smart Readiness Indicator in the Methodological Arc

The Smart Readiness Indicator is not merely one thematic component among others. It functions as the formal assessment reference framework that gives methodological direction to the broader synthesis. The review of service domains establishes the operational foundation. The review of enabling technologies establishes how service intelligence is realised. Translation then requires a formal structure capable of relating those findings to assessment logic. The Smart Readiness Indicator provides that structure.

The analysis that follows, therefore, proceeds in a layered way. Service domains and functionalities are first stabilised from the literature. Enabling technologies are then reconstructed as service-supporting configurations. These elements are next translated into formal Smart Readiness Indicator correspondence and multidimensional assessment relevance. On that basis, a methodological framework can be developed for translating smart building service descriptions into assessment-aligned inputs.

This role is foundational. Without a formal assessment reference structure, the synthesis would remain a broad and useful review of smart building services and technologies. With the Smart Readiness Indicator as the organising reference, the synthesis supports a constructive methodological contribution capable of bridging real building service descriptions and assessment-aligned interpretation.

4. Smart Building Services as Translation Units for Smart Readiness Indicator Aligned Assessment

4.1. Service-Oriented Perspective on Building Smartness

Smart building services provide the most meaningful operational basis for analysing building smartness. Translation into Smart Readiness Indicator-aligned assessment cannot begin from technologies alone because technologies do not carry assessment meaning independently. Assessment relevance emerges when technologies are configured into service capabilities that support adaptive control, contextual response, user interaction, operational visibility, or coordinated system behaviour. A service-oriented perspective, therefore, offers the most suitable starting point for linking real building descriptions to formal assessment logic.

The literature on smart buildings contains a wide range of application domains, but recurring service categories can still be identified with sufficient consistency to support systematic synthesis. Across the reviewed studies, six domains appear particularly prominent: HVAC, lighting, energy management, security and access control, water management, and user-centric comfort and wellbeing services [2,3,11,43]. These domains differ in operational purpose, technological composition, and degree of formal alignment with the Smart Readiness Indicator. Some correspond directly to formal technical domains. Others overlap several formal domains or extend beyond the formal domain set while still contributing meaningfully to building smartness.

The service perspective also helps stabilise the literature conceptually. Research on smart buildings is often organised around technologies, architectures, algorithms, or implementation cases. While such perspectives are valuable, they can obscure the operational role through which smartness is actually realised. Service domains make it possible to reconstruct what buildings are designed to do, how smart functionality is expressed in practice, and how enabling technologies acquire operational meaning. This provides the first layer of the translation logic developed later.

4.2. HVAC Services

HVAC services occupy a central position in the smart building literature because they directly influence thermal conditions, indoor air quality, occupant comfort, and a large share of total building energy use. They also provide one of the clearest examples of how digital technologies become meaningful through operational functionality. Sensors, controllers, actuators, communication infrastructures, and analytics gain relevance within HVAC not because they are installed, but because they support adaptive indoor climate regulation and responsive service delivery.

Recurring smart HVAC functionalities include zone-level thermal control, occupancy-based setpoint adjustment, demand-controlled ventilation, weather-compensated control, predictive preconditioning, anomaly detection, remote monitoring, and dashboard-based supervision [44,45,46,47,48]. Across the literature, these functionalities are commonly enabled through temperature, humidity, CO₂, VOC, and occupancy sensing combined with smart thermostats, dampers, variable speed drives, programmable controllers, and supervisory software environments [49,50,51,52,53]. In more advanced configurations, predictive analytics and data-driven optimisation strengthen the service by supporting anticipatory behaviour rather than reactive control alone [54,55,56,57,58].

Two characteristics make HVAC especially significant for assessment-oriented translation. The first is a direct functional relation to recognised building value dimensions. Adaptive thermal control and indoor air quality-aware ventilation affect comfort, health, and wellbeing, and energy efficiency in highly visible ways. Fault visibility and diagnostics contribute to maintenance-related intelligence. Remote supervision and user interaction contribute to information provision and convenience. The second is strong formal correspondence to the Smart Readiness Indicator because HVAC functionalities align closely with heating, cooling, ventilation, and monitoring and control [47].

The reviewed literature also shows a progression in the sophistication of HVAC smartness. Simpler systems rely on fixed scheduling and local automation. More advanced systems incorporate sensing-driven adaptation, contextual decision support, and predictive control. This progression is important because it demonstrates that smartness within a service domain is not binary [49,54]. It is expressed through the depth and responsiveness of the functionality delivered. HVAC, therefore, provides one of the strongest and clearest service domains for later translation into Smart Readiness Indicator-aligned assessment logic.

4.3. Lighting Services

Lighting services represent another major smart building domain in which digitally enabled functionality is widely studied and comparatively well structured. Although lighting systems are often simpler in their physical actuation than HVAC systems, they provide a clear example of how sensing, control logic, user interaction, and automation can be combined to create operationally meaningful smartness [4].

Recurring smart lighting functionalities include occupancy-based switching, daylight harvesting, dimming, scene control, schedule optimisation, personalised adjustment, and visual status awareness through control interfaces or dashboards [59,60,61,62]. Common enabling technologies include occupancy sensors, daylight sensors, smart luminaires, dimmers, room controllers, programmable switches, wireless control protocols, mobile applications, and supervisory lighting management software [63,64,65]. In more advanced cases, learning-based control and usage pattern analysis support improved adaptation to user behaviour and environmental conditions.

Lighting services contribute strongly to energy efficiency because they allow lighting provision to respond more precisely to need, presence, and daylight availability [59,61,62,66]. They also contribute to convenience through automatic switching and personalised scene management. Comfort becomes relevant where lighting supports visual quality, user preferences, and ease of interaction with space. Information to occupants or operators becomes relevant where lighting conditions, schedules, or status can be inspected and modified through interfaces. Maintenance-related contributions may also emerge where the service includes fault reporting or status monitoring.

The formal translation path for lighting is comparatively direct [63,67]. The service domain aligns clearly with the formal Smart Readiness Indicator lighting domain, and many smart lighting functionalities also overlap with monitoring and control. This makes lighting, together with HVAC, one of the strongest high-clarity translation units in the smart building literature. At the same time, the literature shows that lighting smartness is not determined by digital connectivity alone. Its assessment relevance depends on whether the service provides responsive and user-meaningful functionality rather than static automation.

4.4. Energy Management Services

Energy management occupies a more complex position in the literature than HVAC and lighting because it is frequently framed not as a single end-use system, but as a supervisory and cross-domain service layer. Rather than acting only within one subsystem, energy management typically integrates data, monitoring, benchmarking, optimisation, and decision support across multiple building services. It often links metering, submetering, dashboards, anomaly detection, renewable generation, storage, and control of other service domains into one broader operational environment.

Recurring energy management functionalities include whole building monitoring, submetering, performance benchmarking, abnormal consumption detection, supervisory optimisation, photovoltaic self-consumption management, battery coordination, load management, and, in some studies, coordination with electric vehicle charging [68,69,70]. Typical enabling technologies include smart metres, submeters, power sensors, gateways, building management system interfaces, dashboards, analytics platforms, forecasting modules, and software services for supervisory coordination [71,72,73,74].

This domain is particularly important because it shows that smart building services do not always map neatly to one formal subsystem. Energy management often acquires meaning through cross-domain visibility and control rather than through one isolated technical component [69,75]. Its contribution lies in integrating and interpreting information from several services, enabling strategic optimisation, and supporting decision-making at the building level. In formal assessment terms, it aligns most closely with electricity and monitoring and control, while in some cases also touching electric vehicle charging, where charging coordination is present.

The literature consistently shows strong relevance of energy management to energy efficiency because monitoring and optimisation support more informed and responsive operation [75]. Strong relevance also appears for information to occupants or operators, where dashboards and reporting interfaces provide transparency [76]. Energy flexibility becomes important where load shifting, storage coordination, renewable integration, or demand-responsive logic are present [77,78,79,80,81,82,83,84,85,86,87]. Maintenance-related value may emerge where abnormal patterns are detected and reported. Comfort and convenience are usually secondary rather than primary contributions, although they may still be affected where supervisory control interacts with user-facing services.

Energy management, therefore, illustrates a critical methodological point. Smart building services may derive assessment relevance not only through direct end-use control, but also through supervisory intelligence, cross-domain coordination, and building-level optimisation. Any translation framework must be able to accommodate this broader and more integrated form of service logic.

4.5. Security and Access Control Services

Security and access control services form a distinct and increasingly digitalised part of the smart building landscape. They are commonly addressed in the literature through digital access management, smart locks, badge or credential-based entry, occupancy inference, event monitoring, intrusion detection, remote visibility, contextual permissions, and service interaction triggered by access events [88,89,90,91,92,93]. These services contribute to building intelligence through awareness of presence, movement, permissions, and events rather than through direct control of environmental conditions [94,95,96,97,98].

The enabling technologies associated with this domain include access readers, motion and contact sensors, smart locks, identity services, event handling software, credential applications, wireless communication components, dashboards, and notification services. In some cases, these services are integrated with HVAC, lighting, or room readiness functions through shared occupancy or access signals.

The significance of this domain lies partly in the fact that it demonstrates the limits of one-to-one correspondence with the formal Smart Readiness Indicator. Security and access control do not align directly with a standalone formal domain [92]. Their closest formal relation is generally through monitoring and control, especially where they provide visibility, event awareness, and operational supervision. In addition, their data may support other service domains indirectly when access or presence events trigger environmental responses.

The literature indicates that security and access control services contribute primarily to convenience, where access becomes seamless, contextual, or user-specific. They also contribute to information provision and situational awareness, where event visibility and system status are available to operators or occupants. Maintenance-related relevance may arise through abnormal event detection and operational monitoring. Energy efficiency contributions are usually indirect and depend on integration with other services. Comfort, health and wellbeing, and flexibility are generally weaker unless the service is tightly linked with broader building operations.

This domain is methodologically important because it demonstrates that meaningful smart building services may have only partial formal correspondence to the Smart Readiness Indicator while still contributing substantially to intelligent operation. A robust translation framework must therefore distinguish clearly between operational relevance and direct formal alignment.

4.6. Water Management Services

Water management has become increasingly visible in the smart building literature as digital technologies have enabled more precise monitoring, fault awareness, and automated response in building water systems. Recurring functionalities include leak detection, abnormal flow recognition, pressure monitoring, consumption tracking, automated shut-off, alerting, and maintenance visibility [99,100,101]. These services contribute to building intelligence through resource awareness, fault prevention, and protective intervention.

Common enabling technologies include flow sensors, pressure sensors, leak sensors, shut-off actuators, gateways, low-power wireless communication, dashboards, alerting services, and maintenance-oriented software interfaces [102,103,104,105,106]. In some implementations, water-related data are integrated into broader facility platforms, allowing water services to be interpreted alongside other building systems [107,108,109].

The formal relation of water management to the Smart Readiness Indicator is more limited than for HVAC or lighting. No standalone water management domain exists within the formal structure. The nearest formal relation is usually through monitoring and control and through broader maintenance-oriented logic. From an assessment perspective, water management therefore represents extended relevance rather than direct domain correspondence.

This limited formal alignment does not diminish its operational importance. The literature shows that smart water services can contribute strongly to maintenance and fault prediction through early leak detection and abnormal flow awareness. They may also contribute to information provision, where dashboards and alerts make water-related conditions visible. Health and wellbeing may be relevant where water events affect the indoor environment or service continuity. Energy efficiency may be supported indirectly, particularly where water services interact with hot water demand or resource efficiency goals. Convenience and flexibility are typically weaker unless specific integrations exist.

Water management, therefore, reinforces the need for a translation logic that preserves the significance of important smart building services even when they do not fit directly within the formal standalone domain structure of the Smart Readiness Indicator.

4.7. User-Centric Comfort and Wellbeing Services

User-centric comfort and wellbeing services represent a growing strand of smart building research that shifts attention from subsystem automation alone toward occupant interaction, personalisation, environmental feedback, and adaptive indoor experience. These services are often organised around the needs and perceptions of users rather than around one single technical subsystem. As a result, they provide an important counterpoint to more infrastructure-centred domains.

Recurring functionalities include personalised comfort adjustment, dashboard-based environmental feedback, local control through mobile or room interfaces, preference-based adaptation, contextual comfort support, and feedback loops between occupants and building systems [110,111], and location-aware interaction [112,113,114,115,116,117,118,119,120,121,122]. The enabling technologies associated with these services include indoor climate sensors, mobile applications, wearable or personal devices, local control panels, room interfaces, dashboards, analytics services, and contextual software layers that connect user state, environmental conditions, and control opportunities [110,112,113,117,123,124].

The significance of this domain lies in the way it reveals a broader human-centred dimension of building smartness. Rather than focusing exclusively on technical automation, it highlights how smartness is experienced through interaction, visibility, responsiveness, and individual adaptation. This often leads to service configurations that overlap several technical domains simultaneously. Heating, ventilation, lighting, and monitoring and control may all be involved in enabling a single user-oriented service.

Formal correspondence is therefore usually partial and cross-domain rather than concentrated in one standalone Smart Readiness Indicator domain. This does not weaken the relevance of the domain. On the contrary, it shows that some of the most meaningful smart building capabilities are organised around service outcomes and user interaction rather than around isolated technical systems.

The literature indicates strong relevance to comfort, convenience, health, and wellbeing, and information to occupants. Energy efficiency may also be supported where personalisation reduces unnecessary conditioning or enables more adaptive interaction with building services. Maintenance and flexibility are typically weaker unless the services are tightly connected to supervisory platforms or wider building optimisation logic. This domain is therefore essential for preserving the occupant-oriented meaning of building smartness within any assessment-aligned translation.

4.8. Comparative Synthesis of Service Domains

After reviewing the principal domains separately, a comparative synthesis is needed to stabilise the service-oriented structure of the field. The purpose of this synthesis is not to reduce domain complexity to a simple inventory but to identify the recurring service level structure through which smart building capabilities are expressed across the literature. This stabilisation is methodologically important because later translation into Smart Readiness Indicator-aligned assessment depends on having coherent service domains, reconstructed functionalities, and clear distinctions in correspondence type.

Across the six domains, several common patterns emerge. First, smartness is consistently expressed through service functionality rather than through technology presence alone. Second, service domains differ not only in operational purpose, but also in how directly they correspond to formal Smart Readiness Indicator domains. HVAC and lighting show strong direct correspondence. Energy management operates more as a supervisory and cross-domain layer. Security, access control, and water management exhibit only partial or extended relevance. User-centric comfort services overlap several domains and are framed around interaction and personalisation.

Third, the literature shows that service domains vary in their dominant value dimensions. HVAC and user-centric comfort services are especially strong in comfort- and health-related contributions. Lighting is prominent in energy efficiency and convenience. Energy management is strong in efficiency, information, and flexibility. Water management contributes mainly through maintenance and visibility. Security and access control contribute primarily through convenience, monitoring, and situational awareness [2,3].

These differences are analytically important because they prevent overgeneralisation. Smart building services do not all contribute to smartness in the same way, and not all services fit equally well into formal assessment categories. A disciplined translation must therefore preserve variation in operational purpose, enabling technologies, and correspondence type rather than imposing uniformity where the literature shows diversity.

4.9. Cross Domain Service Integration

A further recurring finding is that smart building services increasingly operate not as isolated subsystems, but as coordinated service ecosystems linked through shared signals, common digital infrastructures, dashboards, metadata structures, supervisory control, and middleware. This pattern is especially visible where occupancy information, event logic, gateways, or cloud platforms are used across several services at once. Higher-order smartness frequently emerges from this cross-domain coordination rather than from one subsystem in isolation.

Common integration mechanisms include shared occupancy and presence signals, event-driven service orchestration, unified dashboards, middleware-based interoperability, metadata-supported spatial contextualisation, supervisory optimisation, and common user interaction layers [125,126]. These mechanisms allow multiple services to become visible, manageable, and responsive within one broader digital environment. Their significance lies in their ability to create coordinated behaviour across service domains and to support building-level intelligence rather than isolated domain intelligence alone.

This finding is especially important for assessment-oriented translation because many integrated smart building capabilities sit closest to monitoring and control within the formal Smart Readiness Indicator structure. Monitoring and control often function as the cross-cutting formal correspondence layer through which shared visibility, orchestration, and digital supervision become accessible. This does not mean that all integrated features collapse into one formal category. Rather, it means that cross-domain intelligence often becomes legible in assessment terms through monitoring, visibility, and coordinated control.

Cross-domain integration, therefore, demonstrates that smart building smartness is often a property of service ecosystems rather than of individual systems alone. Any methodology intended to translate real building descriptions into Smart Readiness Indicator-aligned logic must account not only for individual service domains, but also for the recurring mechanisms through which those domains become coordinated.

4.10. Synthesis of Service Level Findings

Taken together, the review of smart building services shows that building smartness is realised through a diverse but recognisable set of service domains whose core functionalities differ in operational purpose, technological composition, and degree of formal Smart Readiness Indicator correspondence. Some services provide relatively direct translation pathways because they align closely with formal technical domains. Others operate more as cross-domain supervisory, user-oriented, or extended service layers whose assessment relevance must be interpreted more carefully. This diversity is not a weakness of the field. It is a defining characteristic of smart buildings as service ecosystems.

The synthesis also establishes that service domains alone are not sufficient to explain assessment relevance. Their meaning depends on the functionalities they deliver and on the technological arrangements through which those functionalities are realised. A translation from building description to Smart Readiness Indicator-aligned assessment must therefore move beyond domain labels and engage directly with enabling technologies and operational sophistication.

This service level reconstruction provides the first layer of the broader methodological translation logic. The next step is to examine the enabling digital technologies through which smart building services become operationally intelligent, integrated, visible, and responsive.

5. Enabling Digital Technologies as the Basis for Assessment Relevant Service Functionality

5.1. Technological Enablement of Smart Building Services

Smart building services depend on layered digital infrastructures that allow buildings to perceive conditions, interpret information, coordinate responses, and present meaningful information to users and operators [5,8,12,127]. Service domains alone do not explain how smartness is realised. Operational intelligence emerges through combinations of sensing, actuation, control, communication, software, and analytics that transform technical systems into responsive services. A service-oriented assessment logic, therefore, requires a corresponding technology-oriented reconstruction.

The significance of enabling technologies lies not in their isolated presence but in the role they play within service capability. Sensors, controllers, gateways, dashboards, and analytics modules acquire assessment relevance only when they contribute to adaptive regulation, contextual automation, fault visibility, supervisory coordination, or user interaction. The same technology may therefore have very different significance depending on the service logic in which it is embedded. This is why the technological layer must be interpreted through functionality rather than through device categories alone.

Across the literature, enabling technologies recur in a recognisable set of roles. Sensors provide awareness of environmental, operational, and contextual conditions. Actuators and controllers translate digital logic into physical intervention. Communication infrastructures connect devices and subsystems into distributed service environments. Gateways and middleware enable interoperability across heterogeneous components. Software platforms support orchestration, visualisation, persistence, and user interaction. Analytics and artificial intelligence-related functions strengthen service intelligence through prediction, inference, optimisation, and anomaly detection. These roles form the second layer of the translation logic because they explain how smart building services become operationally realisable and assessment relevant [2,8].

5.2. Sensing as the Basis of Service Awareness

Sensing technologies form the perceptual foundation of smart building services. They provide the environmental, operational, and contextual information through which a service can become adaptive, informative, and responsive. Without sensing, a building service remains largely static, scheduled, or manually driven. With sensing, it can react to occupancy, temperature, air quality, daylight, flow conditions, access events, or patterns of use.

The literature shows broad use of sensing across all principal service domains. HVAC services rely on temperature, humidity, CO₂, VOC, occupancy, and sometimes particulate sensing to support thermal regulation and indoor air quality control [47,49]. Lighting services depend on occupancy and illuminance sensing for switching, dimming, and daylight harvesting [59,60,61,62]. Energy management uses metering and submetering to generate visibility into electricity consumption, production, and system performance [68,69,71,72]. Security and access control services use motion, contact, credential, and event sensing to infer presence, permissions, and abnormal activity [88,90,92,93,94,96,97,98]. Water management relies on flow, pressure, and leak sensing to detect anomalies and initiate protective action [99,100,101]. User-centric comfort services often combine environmental sensors with mobile or local user input channels to connect measured conditions with perceived experience.

Sensing is especially important because it frequently marks the transition from automation to context awareness. A scheduled service may operate automatically, but it becomes smart in a stronger sense when its behaviour depends on observed conditions. Occupancy-based ventilation, daylight-responsive lighting, leak detection, access-aware room readiness, and dashboard-based environmental feedback all depend on this shift from fixed logic to sensed context.

At the same time, sensing alone does not create assessment-relevant smartness. The literature consistently shows that sensor data become meaningful only when they are linked to control, supervision, user information, or higher-order decision support. A sensor-rich environment with no adaptive response or operational interpretation remains limited in its smartness. Sensing, therefore, provides the informational basis of service intelligence, but not its full realisation.

5.3. Actuation and Control as the Basis of Operational Response

If sensing provides awareness, actuation and control provide the capacity for operational response. In smart building services, actuators and control logic translate digital information into physical effects through heating adjustment, ventilation regulation, lighting response, valve positioning, access actions, and protective shut-off functions. This layer is central because many assessment-relevant functionalities depend not only on awareness but also on the ability of a service to adapt its behaviour purposefully in response to changing conditions.

The literature demonstrates that actuation and control are present across the service domains in different forms and at different levels of sophistication. HVAC services use thermostatic control, dampers, variable speed drives, and zone controllers to regulate indoor climate adaptively [47,54]. Lighting services rely on dimmers, programmable switches, smart luminaires, and room-level control devices to implement occupancy response and daylight adaptation [63,64,65,66]. Water management services use shut-off valves and related protective actuators to intervene when abnormal flow or leakage is detected [101]. Security and access services use smart locks, access permissions, and event handling logic to regulate entry or service triggering. Energy management may act through supervisory control layers that influence other domains rather than through one dedicated actuator set.

Control logic is equally important. A service becomes meaningfully smart not merely because an actuator is present, but because the service can apply appropriate decision logic to intervention. This logic may take the form of schedules, rule-based responses, sensor-driven adaptation, contextual conditions, predictive control, or supervisory optimisation. The literature shows a clear progression from simple automation toward more adaptive and anticipatory forms of control, especially in HVAC, lighting, and energy management [49,54,55].

This progression matters for assessment-oriented translation because it reflects increasing functional sophistication. Passive observation, fixed scheduling, responsive control, and predictive adaptation do not represent equivalent forms of smartness even when they involve the same general service domain. Actuation and control, therefore, constitute a decisive layer in the interpretation of service intelligence.

5.4. Communication Infrastructures and Distributed Service Operation

Communication infrastructures provide the connective layer through which sensors, actuators, controllers, gateways, and software services can function as coordinated systems rather than isolated technical elements. In the smart building literature, this includes both wired and wireless protocols, local message exchange, cloud connectivity, and bridging arrangements that connect legacy building systems with newer digital architectures. Their importance lies not merely in technical connectivity, but in the operational possibility they create for distributed service intelligence.

A wide range of communication technologies appears across the reviewed studies, including BACnet, Modbus, KNX, DALI integration layers, MQTT, Zigbee, Thread, Wi Fi, Bluetooth, LoRaWAN, HTTP-based APIs, and proprietary interfaces. [5,128,129,130,131]. The literature shows that communication choices are shaped by service domain, building context, device constraints, retrofitting conditions, and integration ambitions [128]. Field-level control may rely on established building automation protocols, while low-cost wireless sensing often depends on Zigbee or similar technologies. Higher-level orchestration commonly uses middleware connectors, APIs, message brokers, or cloud interfaces.

Communication matters methodologically because it influences whether a smart building service remains local and isolated or becomes integrated, visible, and coordinated at the building level. A sensor connected only to a local controller provides a different level of service intelligence from one that can feed dashboards, trigger cross-domain actions, or contribute to supervisory optimisation. Communication also determines whether heterogeneous devices can participate in one service ecosystem and whether data can be reused across several functionalities.

The literature repeatedly shows that distributed smartness depends on communication architectures capable of supporting both local responsiveness and broader system integration. Services such as event-driven access interaction, cross-domain dashboards, predictive energy management, and digital twin integration all rely on this communicative layer. Communication infrastructures are, therefore, enabling conditions for many of the higher-order smart functionalities that later acquire assessment relevance.

5.5. Gateways, Middleware, and Interoperability

Gateways and middleware occupy a particularly important position in smart building architectures because they mediate among heterogeneous devices, protocols, platforms, and service environments. They frequently provide protocol translation, buffering, local processing, interoperability, and access to higher-level software services [128,132]. In practice, they often mark the architectural point at which fragmented technical elements begin to operate as coherent smart services.

The literature shows gateways performing several recurring roles. They connect low-level sensing and actuation devices to message brokers or cloud platforms. They bridge legacy automation protocols with newer IoT-oriented infrastructures. They support local decision-making and buffering where connectivity may be intermittent. They aggregate data from multiple devices and provide a stable interface to dashboards, analytics services, and supervisory platforms. In some cases, they also support local fault tolerance and latency-sensitive control.

Middleware performs a related but broader coordination function. It links services across protocols, manages data exchange, supports rule execution, and enables orchestration among devices, user interfaces, databases, and external services. Middleware is particularly significant where smart building services extend across domain boundaries, as in energy management platforms, access-driven service interaction, or integrated dashboards. It is also central where digital twins, metadata layers, or cloud-based analytics must connect to operational building systems.

This layer is crucial for assessment-oriented interpretation because it explains how isolated digital components become interoperable service infrastructures [132,133]. A building may contain advanced sensing and actuation devices, yet still exhibit limited smartness if integration remains poor. By contrast, comparatively modest devices may support high functional sophistication when gateways and middleware enable coherent coordination, visibility, and reuse of information across domains. This makes interoperability a central condition of service-level smartness.

5.6. Practical Implementation Parameters for Replicable Technology Stack Reconstruction

Technology stack reconstruction should record not only the presence of devices and software components, but also the implementation parameters that determine whether a service can be replicated, evaluated, and maintained. For practitioners, the most important parameters are communication protocol, data granularity, sensing accuracy, actuation interface, interoperability mechanism, cybersecurity mechanism, and operational maintainability.

At the field level, HVAC and indoor environmental services should record sensor type, measured variable, placement logic, sampling interval, calibration requirement, and expected accuracy class, where available. CO₂, temperature, humidity, VOC, occupancy, illuminance, flow, and pressure sensors support different forms of service functionality and should not be treated as interchangeable. For example, demand-controlled ventilation requires air quality or occupancy signals that are sufficiently reliable for control use, whereas dashboard-based awareness may tolerate lower temporal precision if the purpose is information rather than closed-loop control.

At the communication level, the coding should record whether services rely on established building automation protocols such as BACnet, KNX, Modbus, DALI, or OPC UA, or on IoT-oriented protocols and interfaces such as Zigbee, Thread, LoRaWAN, Wi Fi, Bluetooth, MQTT, CoAP, HTTP, or REST-based APIs. The purpose is not to prescribe a single preferred protocol, but to make visible whether the service can support local control, low-power wireless sensing, cloud integration, event streaming, or cross-platform interoperability. MQTT may be appropriate for publish–subscribe telemetry from distributed sensors and gateways, while CoAP may be relevant for constrained devices and lightweight request–response interaction. BACnet, KNX, Modbus, DALI, and OPC UA remain important where integration with established building automation and control systems is required.

At the software and integration level, the coding should record whether the service uses a local controller, gateway, cloud backend, middleware layer, digital twin environment, dashboard, mobile application, or building management system interface. It should also record whether data exchange is proprietary or based on documented interfaces. This is important because replicability depends not only on the technical capability of individual components but also on whether their data and control interfaces can be inspected, reused, and maintained by building operators or third-party integrators.

At the operational level, the coding should record maintenance requirements, power supply constraints, connectivity dependencies, data retention logic, access control, and privacy-relevant data categories. A service based on battery-powered wireless sensors, for example, may be attractive for retrofit deployment but depends on battery replacement procedures and signal reliability. A geofence based service may improve convenience and energy efficiency, but requires clear privacy governance, local data processing where possible, and transparent user communication.

These implementation parameters strengthen the practical replicability of the framework. They allow the translation record to function not only as an assessment-oriented interpretation, but also as a technical checklist for smart building service documentation.

5.7. Software Platforms, Dashboards, and Service Orchestration

Software platforms, dashboards, and orchestration layers provide the digital environment in which smart building services become manageable, visible, interactive, and scalable. They support data persistence, visualisation, automation logic, rule execution, workflow coordination, and user interaction. Their importance lies in the way they transform raw technical connectivity into operationally meaningful service environments.

The literature indicates several recurrent software roles. One is data management, including storage, retrieval, and contextual linking of service information. Another is visualisation, where dashboards and interfaces make system states, alerts, trends, and environmental conditions visible to operators or occupants. A third is orchestration, through which services, events, and control logic are coordinated across devices and domains. A fourth is user interaction, where mobile applications, room interfaces, or web portals allow occupants or operators to inspect, influence, or customise service behaviour. A fifth is integration with broader digital ecosystems, including digital twins, spatial interfaces, and external analytics environments.

Dashboards are especially prominent because they provide a direct link between digital infrastructure and building-level intelligibility [68,70,134,135]. They make energy use, indoor climate conditions, access events, water alerts, and system states visible in ways that support supervision, diagnosis, and informed decision making. This visibility is central for assessment relevance in domains associated with information provision, convenience, and maintenance-related awareness.

Software also shapes whether a technological configuration remains a local control setup or becomes a building-wide smart service [134,136]. A rule implemented in supervisory software, a dashboard exposing environmental conditions, or an orchestration layer linking access and HVAC events can change the significance of an otherwise ordinary device arrangement. This means that service intelligence often depends as much on software architecture as on field hardware.

5.8. Analytics and Artificial Intelligence Related Functions

Analytics and artificial intelligence-related functions strengthen the digital technology stack by moving services from reactive operation toward anticipatory and interpretive forms of intelligence [2,12,72,127,136,137,138,139]. The literature reports these functions in different forms and at different levels of maturity, ranging from trend analysis and anomaly detection to forecasting, preference modelling, optimisation, occupancy inference, contextual recommendation, and predictive control [140,141,142,143,144,145,146,147,148].

In some studies, these functions are explicitly described as artificial intelligence or machine learning. In others, they appear as advanced analytics, predictive algorithms, or rule-enhanced optimisation. Regardless of terminology, their significance lies in the way they extend service functionality beyond immediate sensing and response. Instead of reacting only to current conditions, services can infer patterns, predict near-future states, support earlier intervention, and optimise more strategically.

Analytics functions appear across the service domains. HVAC studies report predictive control, occupancy inference, anomaly detection, and indoor climate optimisation [55,56,149]. Lighting studies describe usage pattern analysis and adaptive control refinement. Energy management includes forecasting, abnormal consumption detection, optimisation of storage and self-consumption, and supervisory decision support [68,69,72]. Water management uses anomaly recognition for leak and abnormal flow detection. User-centric services use preference modelling and contextual interpretation. Cross-domain platforms increasingly support coordinated event reasoning and system-level pattern analysis.

These functions are important for translation into assessment logic because they often indicate higher levels of operational sophistication. A service that can predict, infer, or optimise represents a stronger form of smartness than one limited to fixed rules or passive monitoring. Analytics and artificial intelligence-related functions should therefore be treated as part of the enabling technology stack rather than as separate optional additions. They shape how services become adaptive, anticipatory, and operationally intelligent.

5.9. Metadata, Spatial Context, and Digital Representation

Metadata structures and spatial representations are essential where smart building services must operate across heterogeneous devices, rooms, zones, and assets [150]. They support the linking of technical components to locations, service roles, and contextual meaning, thereby enabling the interpretation of building systems at a higher semantic level. This is increasingly important in complex service ecosystems where operational intelligence depends not only on device signals, but also on understanding where those devices are located, what spaces they affect, and how they relate to other system elements.

The literature shows metadata and digital representation being used in several ways. Devices may be associated with rooms and zones through registries or deployment tools [150,151]. Sensor data may be contextualised through floor plans, maps, dashboards, or three-dimensional representations [152,153,154]. Digital twins and spatial information models may link building components, operational data, and user interfaces within one visual and semantic environment [126,155,156,157,158,159,160]. Metadata also supports automation, because rule execution and service coordination often require a more structured understanding of building context than raw device identifiers can provide.

This layer is particularly significant for future assessment-oriented tools. Translation from real building descriptions to Smart Readiness Indicator aligned logic at scale will require more than isolated device data. It will require semantically structured representations of services, spaces, assets, and interactions. Metadata and digital representation therefore act as enabling conditions for more systematic and scalable forms of service assessment and interpretation.

5.10. Cybersecurity, Privacy, and Operational Robustness

Cybersecurity, privacy, and operational robustness are integral to the realisation of trustworthy smart building services [161,162,163,164,165]. Although they do not usually define formal Smart Readiness Indicator domain correspondence directly, they shape whether intelligent services can be deployed, sustained, and relied upon in practice. Smartness that cannot be governed, trusted, or maintained under operational conditions remains fragile and of limited practical value.

The literature emphasises several concerns. Increased connectivity expands the attack surface of building systems [161,162,163,164,165]. Integration across platforms and protocols introduces additional security and reliability dependencies. User-facing services such as contextual access, dashboards, and mobile applications raise privacy and data governance questions [5,161,162,163]. Low-cost wireless architectures may create challenges related to reliability, latency, or interference. Cloud-based and distributed systems introduce further requirements for resilience, authentication, and continuity of operation.

These concerns matter because many smart building services depend on ongoing data exchange, contextual awareness, and digitally mediated control. A service that supports predictive maintenance, access-aware room readiness, or dashboard-based supervision only remains meaningful if its digital infrastructure is sufficiently robust and trustworthy. The literature, therefore, suggests that building smartness is not just a matter of technological sophistication, but also of operational credibility and governability.

From an assessment-oriented perspective, cybersecurity, privacy, and robustness often function as preconditions for sustainable smartness rather than as direct indicators of service capability. They do not replace the functional logic of smart building services, but they shape the practical viability of deploying and using those services in real buildings.

5.11. Comparative Synthesis of Enabling Digital Technologies

A comparative synthesis of the enabling technologies reveals a set of recurring technological roles that cut across the service domains while still allowing domain specific variation. Sensors create awareness of environmental, operational, and contextual conditions. Actuators and controllers translate digital logic into physical effect. Communication infrastructures enable distributed coordination and information exchange. Gateways and middleware support interoperability across heterogeneous devices and systems. Software platforms provide persistence, orchestration, dashboards, and user interaction. Analytics and artificial intelligence-related functions strengthen adaptive and anticipatory service behaviour. Metadata and spatial representations provide semantic and locational coherence. Cybersecurity, privacy, and robustness shape the trustworthiness of the overall service environment.

Domain-specific patterns remain visible within this broader convergence. HVAC and lighting rely strongly on field sensing, actuation, and local control. Energy management depends heavily on metering, dashboards, analytics, and supervisory software. Security and access control rely on event handling, identity services, and contextual permissions. Water management depends on anomaly sensing and alerting. User-centric services require stronger interaction layers, mobile interfaces, and preference-oriented logic. Cross-domain platforms rely particularly on gateways, middleware, metadata, and software orchestration.

This comparative structure is important because it makes visible how service intelligence is actually implemented. Smartness depends not only on local technical capability, but also on whether heterogeneous systems can be integrated into coherent digital infrastructures that support visibility, decision support, contextual reasoning, and coordinated response. Technology therefore acquires assessment relevance through its role within service functionality and system integration.

5.12. Synthesis of Technology Level Findings

The review of enabling digital technologies shows that assessment-relevant smart building services depend on layered digital infrastructures that extend far beyond isolated devices. Sensors create environmental, operational, and contextual awareness. Actuators translate digital logic into physical effect. Controllers, gateways, and edge components organise local intelligence, protocol mediation, and service coordination. Communication infrastructures enable distributed exchange across devices, subsystems, and platforms. Software layers provide persistence, orchestration, analytics, visualisation, and user interaction. Analytics and artificial intelligence-related functions strengthen this stack by supporting anomaly detection, prediction, optimisation, inference, and increasingly adaptive or anticipatory service logic. Interoperability, metadata, and spatial representation determine whether these technological layers can function coherently at the building level, while cybersecurity, privacy, and reliability determine whether they can do so in a trustworthy and operationally robust manner.

This technology-level reconstruction provides the second layer of the broader translation logic. Service domains identify what buildings do. Enabling technologies explain how those services become operationally intelligent, integrated, visible, and responsive. The next step is to translate the reviewed service domains and their enabling technology configurations into formal Smart Readiness Indicator domain correspondence and assessment-relevant logic.

6. Translating Smart Building Services into Smart Readiness Indicator-Aligned Assessment

6.1. Translation Objective and Unit of Analysis

Descriptions of smart buildings are usually expressed through installed systems, implemented functionalities, and enabling technologies, whereas the Smart Readiness Indicator is structured through formal technical domains, service logic, and impact dimensions. A translation procedure is therefore required to convert operational service descriptions into assessment-aligned representations.

Figure 2 provides a schematic overview of the translation workflow. The workflow begins with a source description of a smart building service, decomposes it into service instances, reconstructs the enabling physical, control, digital, and intelligence layers, assigns Smart Readiness Indicator domain correspondence, codes the impact profile, and aggregates the resulting service records into a building-level readiness profile. The workflow separates service instance identification, functionality formulation, technology stack reconstruction, formal domain correspondence, impact profile assignment, maturity classification, and building level aggregation. The figure is intended to make the framework reproducible and to clarify that the proposed procedure is a structured pre-assessment and interpretation method, not an official Smart Readiness Indicator scoring procedure.

The smart building service instance constitutes the unit of analysis. A service instance denotes one concrete operational capability implemented in the building and expressed through one dominant smart functionality. This unit is more precise than a broad service domain, such as HVAC or lighting, and more meaningful than an isolated technical component, such as a sensor, controller, or dashboard.

A valid service instance must satisfy three conditions. It must refer to a building-related service. It must express one identifiable operational function. It must be enabled by a recognisable technical configuration. Examples include demand-controlled ventilation in meeting rooms, occupancy-based lighting control in office zones, dashboard-based energy monitoring for facility managers, leak detection with automatic shut-off in water systems, and geofence-based heating activation for users. Labels such as HVAC system, lighting infrastructure, or building management system do not constitute valid service instances because they do not specify the smart functionality being translated.

Where a source description contains several smart functions, the description must be decomposed into multiple service instances. Translation is conducted one service instance at a time.

6.2. Service Instance Identification

The first analytical step consists of extracting distinct service instances from the source description. Extraction is based on operational capability rather than on equipment grouping. Three questions guide this step. What service is being delivered? What smart capability differentiates it from a conventional service? Can that capability be analysed independently from the other capabilities described in the same source?

An affirmative answer to the third question indicates a separate service instance. A description stating that occupancy sensors are used both to regulate ventilation and to switch lighting, therefore, contains two service instances because the two capabilities belong to different services, even though they share one sensing source.

For each extracted service instance, one primary functionality statement is formulated in operational language. The statement describes what the service does rather than what components it contains. A useful formulation pattern is verb, controlled object, and decision basis. Examples include regulating ventilation based on CO₂ and occupancy, adjusting lighting based on daylight and presence, detecting abnormal water flow and initiating shut-off, providing real-time energy visibility to operators, and modifying heating setpoints based on user presence.

Each service instance is then assigned to one literature-derived service domain. The available domains are HVAC, lighting, energy management, security and access control, water management, user-centric comfort and wellbeing services, and cross-domain supervisory services where no single domain dominates. Domain assignment is based on service purpose rather than on technology. Occupancy sensing used for ventilation regulation belongs to HVAC, whereas the same sensing used for lighting control belongs to lighting. The outcome of this step is illustrated in

Table 1. Service instance identification.

ID	Source Description Excerpt	Service Domain	Service Instance	Primary Functionality
1	CO2 and occupancy are used to regulate meeting room ventilation automatically	HVAC	Meeting room ventilation control	Regulates ventilation based on CO2 and occupancy
2	Presence and daylight are used to switch and dim office lighting	Lighting	Office lighting control	Adjusts lighting based on presence and daylight
3	Water leak sensors trigger alarms and shut off valves	Water management	Automatic leak protection	Detects leakage and initiates shut-off

.

6.3. Coding the Physical and Control Layer

Once the service instance and primary functionality have been established, the enabling technology stack is reconstructed. The first part of this reconstruction concerns the physical and control layer. Four fields are recorded: sensing layer, actuation layer, control logic, and communication infrastructure.

The sensing layer includes all sensing elements necessary to realise the primary functionality. The actuation layer includes all physical effectors through which the service changes the system state. The control logic field records the mode of decision-making, such as manual override support, scheduled automation, rule-based control, sensor-responsive control, or predictive control. The communication infrastructure field records the basic mechanism through which the components exchange data, such as a building automation network, wireless field communication, API-based exchange, or a message broker.

The coding remains functional rather than exhaustive. The purpose is not to reproduce a complete device inventory, but to capture the minimum technical structure required to realise the service capability.

Table 2. Recording for Physical and control layer.

ID	Sensing Layer	Actuation Layer	Control Logic	Communication Infrastructure
1	CO2 sensor, occupancy sensor	VAV damper	Automatic rule-based ventilation control	Building automation network
2	Presence sensor, daylight sensor	Dimmable luminaires	Sensor-responsive lighting control	KNX or equivalent room network
3	Leak sensor	Shut off valve	Automatic protection logic	Wireless sensor network

illustrates the recording of the physical and control layers.

6.4. Coding the Digital and Intelligence Layer

The second part of the technology stack concerns the digital and intelligence layer. Four fields are recorded: software layer, analytics or artificial intelligence layer, user interaction layer, and integration or orchestration layer.

The software layer records the software environment directly supporting the service, such as a dashboard, mobile application, cloud platform, rule engine, or supervisory interface. The analytics or artificial intelligence layer records functions such as anomaly detection, forecasting, optimisation, predictive control, preference modelling, or none where no such capability is present. The user interaction layer records the channel through which operators or occupants inspect or influence the service. The integration or orchestration layer records cross-system coordination functions such as gateway integration, API based exchange, middleware orchestration, metadata linkage, or none, where integration is absent.

This distinction between the physical and control layer and the digital and intelligence layer improves analytical precision. The physical and control layer captures whether the service can sense, decide, and act at the field level. The digital and intelligence layer captures whether the service can be supervised, visualised, integrated, interpreted, or made more adaptive through software and data-driven functions.

Table 3. Coding for Digital and intelligence layer.

ID	Software Layer	Analytics or Artificial Intelligence Layer	User Interaction Layer	Integration or Orchestration Layer
1	Indoor climate dashboard	None	Facility manager dashboard	Building management system interface
2	Lighting management software	None	Occupant wall panel or mobile interface	Room-level lighting controller
3	Water monitoring dashboard	Threshold-based anomaly detection	Facility manager alert interface	Gateway-based alert routing

illustrates how the digital and intelligence layer is coded for the same three service instances introduced in Table 1 and Table 2.

6.5. Assigning Formal Smart Readiness Indicator Correspondence

Formal Smart Readiness Indicator correspondence is assigned after the service functionality and enabling technology stacks have been identified. Three outputs are required: the nearest formal Smart Readiness Indicator domain or domains, the correspondence type, and the Smart Readiness Indicator relevant service interpretation.

The formal domain is selected from the recognised Smart Readiness Indicator structure, including heating, cooling, ventilation, lighting, electricity, electric vehicle charging, dynamic building envelope, domestic hot water, and monitoring and control. Multiple domains are used only where the functionality genuinely spans them.

The correspondence type is assigned according to four rules. Direct correspondence applies where the functionality clearly performs a recognised smart function within one formal Smart Readiness Indicator domain. Partial correspondence applies where the functionality overlaps one or more formal domains but is framed more broadly or differently than the formal structure. Cross-domain correspondence applies where the functionality supervises, coordinates, or integrates several formal domains without fully belonging to one of them. Extended relevance applies where the functionality contributes meaningfully to building smartness but has no direct, standalone formal Smart Readiness Indicator domain equivalent.

The Smart Readiness Indicator’s relevant service interpretation reformulates the primary functionality in assessment-oriented language. Examples include demand-controlled ventilation with monitoring, occupancy and daylight responsive lighting control, supervisory energy monitoring, contextual access management, and automated leak monitoring with shut off. This interpretation is illustrated in

Table 4. Domain correspondence for Smart Readiness Indicator.

ID	Formal SRI Domain	Correspondence Type	SRI Relevant Service Interpretation
1	Ventilation; Monitoring and Control	Direct correspondence	Demand-controlled ventilation with monitoring
2	Lighting; Monitoring and Control	Direct correspondence	Occupancy and daylight-responsive lighting control
3	Monitoring and Control	Extended relevance	Automated leak monitoring and shut-off

.

6.6. Assigning the Smart Readiness Indicator Impact Profile

Impact attribution follows formal correspondence. Each service instance is evaluated against the seven Smart Readiness Indicator impact dimensions: energy efficiency, maintenance and fault prediction, comfort, convenience, health and wellbeing, accessibility, information to occupants, and energy flexibility.

Each impact dimension is assigned one of four contribution levels. Primary contribution applies where the functionality is explicitly designed to deliver that impact. Secondary contribution applies where the impact follows clearly from the functionality but is not its main purpose. Enabling contribution applies where the functionality mainly creates conditions for later or indirect smartness rather than delivering the impact directly. No meaningful contribution applies where no substantial functional relation exists.

All seven dimensions are coded for every service instance. Empty fields are not permitted. This ensures systematic evaluation and prevents selective attribution.

Table 5. Impact profile for Smart Readiness Indicator.

ID	Energy Efficiency	Maintenance and Fault Prediction	Comfort	Convenience	Health and Wellbeing and Accessibility	Information to Occupants	Energy Flexibility
1	Primary	Enabling	Primary	Secondary	Primary	Secondary	No meaningful contribution
2	Primary	No meaningful contribution	Secondary	Primary	Secondary	Secondary	No meaningful contribution
3	Secondary	Primary	No meaningful contribution	Secondary	Secondary	Secondary	No meaningful contribution

shows the recording of this impact profile.

6.7. Summary of Worked Example

The outcomes of the multi-step procedure were illustrated in the previous table using the concrete source description: CO₂ sensors and occupancy sensors in meeting rooms regulate ventilation automatically through variable air volume dampers. Facility staff monitors room air quality through a dashboard.

The executed steps included:

• The service instance is first identified: The source contains one dominant service instance because the primary smart function concerns ventilation control. The service domain is HVAC. The service instance is meeting room ventilation control. The primary functionality is formulated to regulate ventilation based on CO₂ and occupancy.
• The physical and control layer is then coded. The sensing layer consists of CO₂ sensors and occupancy sensors. The actuation layer consists of VAV dampers. The control logic is automatic, rule-based ventilation control. The communication infrastructure is a building automation network.
• The digital and intelligence layer is then coded. The software layer is an indoor climate dashboard. The analytics or artificial intelligence layer is none. The user interaction layer is an operator dashboard. The integration or orchestration layer is none.
• Formal Smart Readiness Indicator correspondence is assigned next. The nearest formal domains are ventilation, monitoring, and control. The correspondence type is direct correspondence because the functionality clearly performs a recognised smart function within a formal domain. The Smart Readiness Indicator relevant service interpretation is demand-controlled ventilation with monitoring.
• The impact profile is then assigned. Energy efficiency is primary because ventilation is regulated according to actual need. Maintenance and fault prediction are enabled because the dashboard and monitoring environment may support later fault awareness, but this is not the main purpose of the functionality. Comfort is primary because ventilation quality affects indoor environmental conditions. Health and wellbeing and accessibility are primary because the functionality directly supports indoor air quality. Convenience is secondary because automation reduces manual intervention. Information to occupants is secondary because staff can inspect the room air quality through the dashboard. Energy flexibility is assigned no meaningful contribution because the functionality, as described, does not explicitly support load shifting or grid interaction.

The translation yields one linked set of records for each service instance across Table 1, Table 2, Table 3, Table 4 and Table 5. The records establish the service identity, the primary functionality, the enabling physical and digital layers, the formal Smart Readiness Indicator correspondence, and the impact profile. These records form the analytical basis for subsequent aggregation and building-level interpretation.

6.8. Boundary Conditions of the Translation Framework

The framework provides Smart Readiness Indicator-aligned assessment representations, but it does not replace official Smart Readiness Indicator assessment, certification, or scoring. Its function is to translate heterogeneous service descriptions into structured records that can support pre-assessment, design review, comparison, digital tool development, and preparation for formal assessment. The output is therefore an assessment-aligned readiness profile rather than an authorised Smart Readiness Indicator score.

The framework can support five types of analytical tasks. First, it can identify and structure smart building service instances from engineering descriptions, technology descriptions, system documentation, or case study material. Second, it can reconstruct the technology stack that enables each service instance across physical, control, digital, and intelligence layers. Third, it can assign formal Smart Readiness Indicator domain correspondence using transparent correspondence categories. Fourth, it can interpret likely contributions to Smart Readiness Indicator impact dimensions. Fifth, it can aggregate service records into a building-level profile showing the distribution, maturity, and impact orientation of smartness.

The framework cannot determine whether a building satisfies national implementation rules for an official Smart Readiness Indicator assessment. It cannot replace an authorised assessor, official service catalogue interpretation, or formal weighting procedure. It cannot infer performance outcomes where the source description lacks operational evidence. It also cannot automatically validate whether a service is actually used, accepted by occupants, maintained over time, or operated according to design intent. These aspects require site inspection, stakeholder engagement, operational data, and formal assessment procedures.

This boundary is methodologically important. The framework is designed to improve the quality and reproducibility of assessment-oriented interpretation before formal scoring. It supports structured reasoning about readiness, but it does not claim certification equivalence.

7. Aggregation Framework for Building Level Smart Readiness Indicator-Aligned Assessment

7.1. Aggregation Objective

Service instance translation produces a structured record of functionality, enabling technologies, formal Smart Readiness Indicator correspondence, and impact contributions for each smart building service. Building level interpretation requires a second analytical step in which these service level records are aggregated into a coherent readiness profile. This aggregation is needed because smartness at the building level is not defined by one service alone, but by the distribution, diversity, correspondence pattern, and maturity of the full-service portfolio.

The aggregation developed here is profile-based rather than score-based. It does not reproduce official Smart Readiness Indicator weighting, domain scoring, or certified assessment procedures. Instead, it generates a building-level Smart Readiness Indicator aligned profile grounded in the translated service records established in Section 6. The resulting profile supports structured comparison, design review, pre-assessment, and systematic interpretation of building smartness.

Three aggregation layers are used. The first layer establishes the formal Smart Readiness Indicator domain profile of the building. The second layer establishes the impact profile across the seven Smart Readiness Indicator dimensions. The third layer establishes the functional maturity profile of the service portfolio. These three layers are then synthesised into one building-level readiness interpretation.

7.2. Aggregation Logic and General Rules

Aggregation is performed on translated service instances rather than on device counts or broad system labels. This distinction is essential because a building may contain many connected components without providing a correspondingly rich set of smart service capabilities. The aggregation, therefore, reflects service instance frequency, functional diversity, correspondence pattern, and impact contribution rather than technological density.

Each translated service instance may contribute to more than one formal Smart Readiness Indicator domain, where the correspondence established in Section 6 genuinely spans several domains. In such cases, the service instance is counted in each relevant domain for the purpose of structural presence. However, its shared character must be taken into account during interpretation so that domain breadth is not overstated. Domain counts, therefore, indicate formal presence and distribution rather than mutually exclusive service totals.

Aggregation remains descriptive and analytical rather than weight-based. A service instance with limited strategic importance and a service instance with central operational importance each contribute one record unless additional weighting is introduced in a later stage. The framework, therefore, captures the structure of translated smartness, not its economic or formal scoring weight.

All aggregation steps must use the same service instance identifiers established in Section 6. This preserves traceability from building-level synthesis back to the underlying service records.

7.3. Domain Level Aggregation

Domain-level aggregation groups all translated service instances by the formal Smart Readiness Indicator domains assigned in Table 4. Where a service instance has direct or partial correspondence to more than one formal domain, it is included in each relevant grouping. Service instances classified as extended relevance are recorded separately so that meaningful smartness outside the formal standalone domain set remains visible.

Four indicators are recorded for each formal domain.

The first indicator is the number of service instances assigned to the domain.

The second indicator is functional diversity. Functional diversity is defined as the number of distinct primary functionality categories represented within the domain, where distinct categories differ in operational purpose rather than in minor implementation detail. Occupancy-based lighting control and daylight-responsive dimming, therefore, count as two distinct functionality categories, whereas two similar implementations of occupancy-based lighting control count as one.

The third indicator is the dominant correspondence type, defined as the most frequent correspondence classification within the domain.

The fourth indicator is the dominant service interpretation. Dominant service interpretations are the one or two most frequently occurring Smart Readiness Indicator-relevant service interpretations within the domain. Where no single interpretation is clearly dominant, two representative interpretations may be listed.

These indicators establish the structural profile of building smartness in formal domain terms. A domain with several service instances, high functional diversity, and predominantly direct correspondence indicates strong and explicit smartness concentration. A domain with few service instances or mostly partial, cross-domain, or extended relevance cases indicates a weaker or more indirect concentration.

Table 6. Domain level aggregation of translated service instances.

Formal SRI Domain	Number of Service Instances	Functional Diversity	Dominant Correspondence Type	Dominant Service Interpretations
Heating	2	2	Direct correspondence	Adaptive thermal regulation; presence-based heating activation
Ventilation	3	2	Direct correspondence	Demand-controlled ventilation; air quality responsive ventilation
Lighting	2	2	Direct correspondence	Occupancy responsive lighting control; daylight responsive dimming
Electricity	1	1	Cross-domain correspondence	Supervisory energy monitoring
Monitoring and control	6	5	Cross-domain correspondence	Dashboard-based visibility; supervisory monitoring
Extended relevance	2	2	Extended relevance	Automated leak monitoring and shut-off; contextual access management

records the domain-level aggregation.

7.4. Impact Level Aggregation

Impact level aggregation consolidates the contributions assigned in Table 5 across the seven Smart Readiness Indicator impact dimensions: energy efficiency, maintenance and fault prediction, comfort, convenience, health and wellbeing, accessibility, information to occupants, and energy flexibility.

For each impact dimension, three contribution counts are recorded: primary, secondary, and enabling contributions. No meaningful contribution is not counted as a positive contribution. Two summary measures are then derived.

The first measure is impact breadth, defined as the total number of contributing service instances across primary, secondary, and enabling levels.

The second measure is impact strength, interpreted from the distribution among primary, secondary, and enabling contributions.

Dominant impact dimensions are identified using a two-part rule. First, the impact dimensions with the highest impact breadth are identified. Second, where two or more dimensions have similar breadth, the number of primary contributions is used to distinguish stronger from weaker dominance. This prevents dimensions with many weak enabling contributions from being interpreted as equally central as dimensions with several strong primary contributions.

Table 7. Aggregated Smart Readiness Indicator impact profile.

Impact Dimension	Primary Contributions	Secondary Contributions	Enabling Contributions	Total Contributing Service Instances
Energy efficiency	4	1	1	6
Maintenance and fault prediction	1	1	3	5
Comfort	3	2	0	5
Convenience	1	4	0	5
Health and wellbeing and accessibility	3	2	0	5
Information to occupants	1	4	1	6
Energy flexibility	0	1	1	2

records the aggregated impact profile.

This table reveals whether building smartness is concentrated mainly in indoor environment quality, supervisory visibility, operational maintenance awareness, or energy system interaction.

7.5. Functional Maturity Aggregation

The translated service portfolio must also be interpreted in terms of functional maturity. The combination of primary functionality, control logic, analytics layer, and user interaction structure provides a basis for qualitative maturity classification at the service instance level.

Four maturity classes are used.

Basic digital support applies where the service provides visibility, status awareness, manual digital assistance, or simple reporting without automatic adaptive response. Typical examples include passive dashboards, alarm displays, and digital access to service information without control adaptation.

Automated service logic applies where the service executes fixed schedules, predefined rules, or simple automatic actions without continuous adaptation to changing sensed environmental, operational, or user conditions. Typical examples include scheduled lighting control and fixed threshold protection logic.

Responsive service intelligence applies where the service changes behaviour dynamically in response to real-time sensed environmental, operational, or user-related conditions. Typical examples include demand-controlled ventilation, occupancy-based lighting control, and presence-based thermal adjustment. Where a service responds dynamically to real-time sensed conditions, it should be classified as responsive service intelligence even if the underlying control logic is rule-based. Automated service logic should therefore be reserved for fixed schedules or simple automatic actions that do not continuously adapt to changing sensed conditions.

Adaptive or anticipatory intelligence applies where the service uses prediction, optimisation, inference, learned patterns, or context-aware logic to modify future behaviour proactively rather than only reacting to present conditions. Typical examples include predictive thermal optimisation, forecasting-based energy management, and preference-based adaptive comfort control.

Each service instance is assigned to one maturity class only. Classification is based on the highest level of operational intelligence clearly evidenced in the service record. Advanced software infrastructure alone does not justify a higher maturity class unless the primary functionality itself operates at that level.

Table 8. Functional maturity profile of the translated service portfolio.

Maturity Class	Number of Service Instances	Representative Service Examples
Basic digital support	1	Dashboard based energy visibility
Automated service logic	2	Automatic leak protection; scheduled lighting control
Responsive service intelligence	5	Demand controlled ventilation; occupancy-based lighting control; presence-based heating activation
Adaptive or anticipatory intelligence	1	Predictive thermal setpoint optimisation

records the maturity aggregation.

The maturity profile clarifies whether the building’s translated smartness is predominantly informational, automated, responsive, or anticipatory.

7.6. Building Level Readiness Synthesis

Building level readiness synthesis integrates the domain profile, impact profile, and maturity profile into one structured interpretation. To improve reproducibility, the synthesis must follow a fixed reporting sequence derived directly from Table 6, Table 7 and Table 8.

The first synthesis statement identifies the dominant formal Smart Readiness Indicator domains. These are the domains with the greatest concentration of service instances and the highest functional diversity, as recorded in Table 6.

The second synthesis statement identifies the dominant impact dimensions. These are the dimensions with the greatest impact breadth, interpreted together with the number of primary contributions, as recorded in Table 7.

The third synthesis statement identifies the prevailing functional maturity class. This is the maturity class with the greatest number of service instances in Table 8.

The fourth synthesis statement identifies the balance between direct and indirect correspondence. This statement is derived from the correspondence distribution recorded in Table 6 and should indicate whether the building’s translated smartness is grounded mainly in direct formal Smart Readiness Indicator correspondence or whether partial, cross domain, and extended relevance services play a strong role.

The fifth synthesis statement identifies the principal gaps or weakly represented smartness dimensions. These are the domains or impact areas with low concentration, limited diversity, or very low contribution breadth.

The sixth synthesis statement formulates the overall readiness character. This is a qualitative synthesis label derived from the preceding five statements and should be treated as an interpretive summary rather than as a formal metric.

Table 9. Building-level smart readiness profile.

Analytical Dimension	Building Level Interpretation
Dominant formal SRI domains	Ventilation, lighting, and monitoring and control dominate the translated service portfolio
Dominant impact dimensions	Energy efficiency and information to occupants show the greatest breadth, while comfort, health and wellbeing show the strongest primary contributions
Prevailing maturity class	Responsive service intelligence dominates, with limited anticipatory capability
Balance of correspondence types	Direct correspondence dominates core environmental services, while monitoring and control provide a strong cross-cutting layer, and extended relevance remains limited but significant
Principal gaps	Flexibility-related capability and advanced predictive maintenance remain weakly represented
Overall readiness character	Indoor environment-oriented and supervision-rich smart building with limited flexibility-related capability

provides the synthesis template.

This synthesis template ensures that building-level interpretation is derived systematically from the aggregated evidence rather than from open-ended narrative judgement.

7.7. Procedural Application

Aggregation is applied after completion of the service translation records in Section 6. The procedure follows five steps:

• First, all service instances are grouped by the formal Smart Readiness Indicator domain using Table 4.
• Second, the number of service instances, functional diversity, dominant correspondence type, and dominant service interpretations are recorded in Table 6.
• Third, all impact contributions from Table 5 are aggregated into Table 7, and dominant impact dimensions are identified using the breadth and primary contribution rule.
• Fourth, each service instance is assigned to one maturity class using the decision rules in Section 7.5, and the results are recorded in Table 8.
• Fifth, the building-level Smart Readiness profile is written in the fixed reporting sequence and recorded in Table 9.

This sequence produces a structured building-level profile that can be compared across buildings, service portfolios, or design alternatives without relying on informal summary judgement.

7.8. Analytical Value and Limits

The aggregation framework provides a building-level Smart Readiness Indicator aligned profile grounded in explicit service translation records. It preserves traceability from building-level interpretation back to individual service instances. It maintains the distinction between formal correspondence and impact interpretation. It also preserves the multidimensional character of smartness by allowing strong representation in some dimensions and weak representation in others.

At the same time, the framework remains profile-based rather than score-based. It does not reproduce official Smart Readiness Indicator weighting, certified calculation procedures, or authorised assessment outcomes. Its function is to reveal the structure, concentration, and maturity of translated smartness in a rigorous and comparable way.

This approach is especially useful for buildings whose smart services are unevenly distributed. Strong environmental services may coexist with limited flexibility. Rich supervisory visibility may coexist with weak predictive maintenance. Extended relevance services, such as water monitoring or contextual access management, may contribute substantially even though they remain outside the formal standalone domain set. A differentiated aggregation framework makes these patterns visible and analytically usable.

7.9. Differentiated Application Guidelines

Application of the framework should be adapted to the building context because smart building services differ significantly across new smart office buildings, older buildings with weak technical foundations, industrial facilities, and buildings in low-income or resource-constrained regions. The same translation logic can be used across these contexts, but the expected service portfolio, technology stack, evidence availability, and implementation barriers will differ.

For digitally mature office buildings, the framework can usually be applied with detailed service records, sensor inventories, dashboard documentation, gateway descriptions, digital twin models, and operational software evidence. In such cases, the main analytical challenge is not a lack of data, but the need to distinguish enabling digital infrastructure from direct assessment of relevant service functionality.

For older buildings with limited automation, the framework should be used as a staged retrofit assessment tool. The first stage should identify existing manually operated or scheduled services. The second stage should identify low-cost sensing, gateway, and dashboard opportunities that can create basic monitoring and control capability. The third stage should identify services that could realistically progress from basic digital support to responsive service intelligence. In this context, the framework should not assume that advanced IoT infrastructure is already present.

For industrial facilities, the framework should be adapted to recognise process-related constraints, operational continuity requirements, safety systems, production schedules, and specialised control environments. Industrial buildings may contain advanced automation, but their service logic may not align neatly with office-centred smart building examples. Translation should therefore distinguish building service smartness from process automation and should treat safety, resilience, and operational continuity as key contextual constraints.

For buildings in low-income or resource-constrained regions, the framework should support minimum viable smart readiness pathways. These may rely on low-cost wireless sensors, open protocols, basic dashboards, mobile-based interaction, and staged deployment rather than comprehensive building management systems. In such contexts, cost, maintainability, local technical capacity, data connectivity, and vendor lock-in may be more decisive than the availability of advanced analytics. The framework should therefore be applied with explicit attention to affordability, robustness, training needs, and incremental implementation.

Table 10. Context-sensitive application guidelines for the translation framework.

Building Context	Typical Evidence Basis	Main Translation Focus	Main Barrier	Practical Adaptation
Digitally mature office building	Sensor inventory, dashboards, gateways, metadata, digital twin models	Distinguishing supervisory infrastructure from direct service functionality	Overlapping service functions and complex platforms	Use full-service instance decomposition and aggregation
Older building with weak technical foundation	Limited automation records, manual controls, retrofit plans, partial metering	Identifying staged retrofit pathways	Missing sensors, legacy systems, and limited connectivity	Begin with monitoring and control services and low-cost sensing
Industrial facility	Automation records, process schedules, safety documentation, and control system descriptions	Separating building services from process automation	Operational continuity and safety constraints	Add context notes for process dependence and criticality
Low-income or resource-constrained region	Minimal technical documentation, low-cost devices, mobile interfaces	Identifying minimum viable smart readiness pathways	Cost, maintainability, connectivity, and local capacity	Use open protocols, staged deployment, and simplified templates

provides differentiated application guidelines.

7.10. Case Application Basis

A procedural aggregation framework becomes methodologically convincing only when applied to a concrete service ecosystem. The next section applies the translation and aggregation procedure to a documented smart building case. The service portfolio is decomposed into service instances, translated into Smart Readiness Indicator aligned records, aggregated into domain, impact, and maturity profiles, and synthesised into a building-level readiness interpretation.

8. Case Study Application: Translating the IoT Building Cloud Service Platform into Smart Readiness Indicator-Aligned Assessment

8.1. Case Selection and Empirical Basis

The case study addresses the IoT Building Cloud service platform as deployed in university buildings in Denmark and Malaysia [166]. The case is suitable because the underlying system spans the full chain from wireless sensing and gateway infrastructure to backend integration, dashboards, mobile access, metadata-driven visualisation, and geometry-based sensor placement [167], and geofence-based access and control [168]. Across the associated studies, the ecosystem is described as a cost-effective IoT and cloud-based solution for monitoring and optimising energy use and indoor climate through wireless sensors, gateways, dashboards, mobile applications, and QR-based installation workflows [169]. The platform provides real-time status of sensors and gateways, monitoring of temperature, air quality, CO₂, and related variables, access through mobile and web interfaces, QR-based installation and extension, and visual dashboards for building performance communication.

The Danish deployment at the Mærsk Mc Kinney Møller Institute (MMMI) building at the University of Southern Denmark is the main application context because several of the source studies describe concrete installation, monitoring, visualisation, and digital twin functions in this setting. The building is a 2560 m² two-floor office building used as a living laboratory for indoor environmental monitoring and energy optimisation. The geometry-driven digital twin study reports that the building is equipped with more than 300 operational sensors, while the geofence and access control study reports 297 sensors, 13 gateways, and 85 registered rooms at the time of testing. Figure 3 and Figure 4 show the deployment of IoT Building Cloud at the MMMI building.

The empirical basis for the translation, therefore, consists of five complementary capability strands. The first is QR code-based registration and autoconfiguration of sensors and gateways in buildings [169]. The second is the open source Zigbee and MQTT-based edge gateway architecture for large-scale building IoT [170]. The third is metadata-driven automatic building visualisation [171]. The fourth is geometry-driven automatic digital placement of IoT sensors in BIM-based digital twins [167]. The fifth is geolocation-based, privacy-aware access and indoor climate control through mobile geofencing [168]. Together, these strands describe a coherent smart building service ecosystem rather than one isolated function.

8.2. Service Instance Decomposition

Application of the translation procedure begins by decomposing the IoT Building Cloud case into distinct service instances expressed through one dominant functionality each. Although the underlying platform is integrated, the documented capabilities can be separated into operational service instances that correspond to the methodological unit of analysis defined earlier. The decomposition yields six service instances that are sufficiently distinct in functionality and sufficiently well documented across the case material.

The first service instance is a QR-based sensor and room registration for large-scale deployment. The dominant functionality is the registration of devices and physical locations through QR codes and the automated association of sensors, gateways, and room metadata. The second service instance is an automatic gateway to sensor configuration in the wireless IoT network. The dominant functionality is the establishment and maintenance of communication pairings between sensors and gateways according to signal and deployment logic. The third service instance is real-time indoor climate and installation monitoring through dashboards. The dominant functionality is the provision of real-time visibility into installation state, indoor climate, and network configuration. The fourth service instance is metadata-driven building visualisation and digital representation of the installation. The dominant functionality is the generation of visual building and network representations from IoT metadata. The fifth service instance is geometry-driven digital placement of sensors in the building model. The dominant functionality is the automatic derivation of plausible digital sensor positions from building geometry. The sixth service instance is geofencing-based mobile access and indoor climate control. The dominant functionality is the granting of access and triggering of climate-related actions based on local geofence evaluation and user presence. The result of the Service Instance Identification for the IoT Building Cloud case study is shown in

Table 11. Service Instance Identification for the IoT building cloud case.

ID	Service Domain	Service Instance	Primary Functionality
1	Monitoring and control	QR-based installation and registration	Registers devices and locations through QR codes and associates them automatically
2	Monitoring and control	Automatic gateway and sensor configuration	Pairs sensors and gateways automatically according to deployment logic
3	Monitoring and control	Real-time dashboard monitoring	Provides real-time visibility into indoor climate, energy-related data, and installation status
4	Monitoring and control	Metadata-driven visualisation	Generates visual building and network representations from installation metadata
5	Monitoring and control	Geometry-driven digital sensor placement	Determines plausible digital positions of sensors from building geometry
6	User-centric comfort and wellbeing services	Geofence-based access and climate control	Governs data access and triggers climate control actions based on local geofence evaluation

.

8.3. Physical and Control Layer Coding

The service instances differ substantially in their physical and control characteristics. The QR-based installation service relies primarily on mobile scanning and backend registration rather than direct field actuation. The auto configuration service relies on Zigbee sensors and gateways, backend pairing logic, and communication quality evaluation. The dashboard monitoring service depends on sensors, gateways, MQTT communication, backend processing, and data visualisation. The visualisation and digital placement services operate mostly in the digital layer, but both still depend on the existence of an installed sensor network and on room, floor, or building geometry as their underlying spatial substrate. The geofence-based access and climate control service combines mobile geolocation, backend logic, and actuation through thermostats or building systems.

Table 12. Physical and control layer.

ID	Sensing Layer	Actuation Layer	Control Logic	Communication Infrastructure
1	Mobile QR scan and device identity capture	None	Registration and association logic	Mobile app, HTTP, backend
2	Zigbee sensors, gateway signal status	Gateway pairing state	Automatic pairing and reconfiguration logic	Zigbee, MQTT, OPC UA, backend
3	Indoor climate sensors, occupancy-related sensors, gateway status	None	Real-time monitoring and alert logic	Zigbee, MQTT, backend
4	Installed IoT metadata and room assignments	None	Metadata-driven rendering logic	Backend data exchange
5	BIM geometry, room meshes, walls, and opening detection	None	Geometry-based rule logic	Browser executable model processing
6	Mobile geolocation, indoor climate sensors	Thermostats and climate control endpoints	Geofence-triggered access and actuation logic	Mobile app, backend API, actuator integration

shows the coding for the MMMI building.

8.4. Digital and Intelligence Layer Coding

The digital layer is unusually rich in this case and represents one of the strongest sources of smartness. The QR-based installation service includes a mobile application, backend persistence, and dynamic QR code handling. The auto configuration service includes middleware, backend services, and pairing strategies such as round robin and historical or physical constraint-based approaches. The monitoring service includes web dashboards, graph-based network views, playback of historical changes, and device-level data visualisation. The visualisation service includes metadata-driven generation of building representations from resource allocation, signal strength, and related metadata. The geometry-driven digital placement service includes browser-executable spatial analysis over BIM geometry. The geofence service includes Flutter-based mobile applications, client-side geofence evaluation, convex hull computation, DBSCAN clustering, Angular dashboards, and integrations with indoor climate access and thermostat actuation.

Table 13. Digital and intelligence layer.

ID	Software Layer	Analytics or AI Layer	User Interaction Layer	Integration or Orchestration
1	Mobile registration app, backend, database	None	Installer mobile app	Dynamic QR and location association
2	Backend auto configuration service	Pairing strategy logic	Backend managed	MQTT and OPC UA integration
3	Web dashboard, database, monitoring views	Event and status processing	Web dashboard and TV dashboards	Real-time monitoring integration
4	Visualisation engine and metadata processing	Metadata-driven layout logic	Web visualisation	BMS metadata integration
5	Web-based BIM viewer with three.js	Geometry-driven placement logic	Interactive BIM viewer	BIM to digital twin linkage
6	Flutter mobile app, Angular dashboard, backend	DBSCAN clustering, convex hull computation, and local geofence evaluation	Authenticated and guest mobile app	Access control and thermostat trigger integration

shows the coding for the MMMI building.

8.5. Formal Smart Readiness Indicator Correspondence

Formal Smart Readiness Indicator correspondence is strongest in monitoring and control, but the case also touches ventilation, heating, and user-centred comfort-related logic through indoor climate monitoring and geofence-triggered thermostat control. The QR registration and automatic pairing services have no direct, standalone, user-facing environmental function, yet they contribute strongly to monitoring and control because they enable structured installation, device visibility, and large-scale service operability. The dashboard monitoring service maps directly to monitoring and control and indirectly supports several environmental domains through visibility into temperature, air quality, and related variables. The metadata visualisation and geometry-based digital placement services also align primarily with monitoring and control because they strengthen system visibility, digital representation, and inspectability rather than direct end-use control. The geofence-based service has partial and cross-domain correspondence because it governs access to indoor climate data and triggers thermostat or climate responses based on user presence.

Table 14. Smart Readiness Indicator domain correspondence.

ID	Formal SRI Domain	Correspondence Type	SRI Relevant Service Interpretation
1	Monitoring and Control	Cross-domain correspondence	Automated installation, registration, and device association
2	Monitoring and Control	Cross-domain correspondence	Automatic IoT network configuration and pairing management
3	Monitoring and Control	Direct correspondence	Real-time indoor climate and installation monitoring
4	Monitoring and Control	Cross-domain correspondence	Metadata-driven visualisation of building service infrastructure
5	Monitoring and Control	Cross-domain correspondence	Geometry-driven digital sensor placement and digital twin alignment
6	Heating; Ventilation; Monitoring and Control	Partial correspondence	Geofence-based climate data access and presence-triggered indoor climate control

shows the domain correspondence for the MMMI building.

8.6. Impact Profile Assignment

The impact profile of the IoT Building Cloud case is multidimensional. The monitoring- and control-centric services contribute most strongly to information to occupants or operators and to maintenance and fault awareness because they create installation visibility, sensor status awareness, historical replay, and inspectable system state. The QR installation and auto configuration services are primarily enabling services. They do not directly improve comfort or energy efficiency on their own, but they make large-scale deployment feasible and support the operation of higher-order services. The dashboard monitoring service contributes secondarily to energy efficiency and comfort through improved operational awareness and potentially serves as a primary source of information. The metadata-driven visualisation and geometry-based sensor placement services contribute to maintenance, information, and later digital twin-based optimisation by improving spatial and operational intelligibility. The geofence-based service contributes primarily to convenience and information access governance and secondarily or primarily to energy efficiency and comfort, depending on how the thermostat logic is configured, because entry events can trigger preconditioning while exit-related absence logic can support setbacks.

Table 15. Smart Readiness Indicator impact profile.

ID	Energy Efficiency	Maintenance and Fault Prediction	Comfort	Convenience	Health and Wellbeing and Accessibility	Information to Occupants	Energy Flexibility
1	Enabling	Enabling	No meaningful contribution	Secondary	No meaningful contribution	Secondary	No meaningful contribution
2	Enabling	Primary	No meaningful contribution	Secondary	No meaningful contribution	Secondary	No meaningful contribution
3	Secondary	Primary	Secondary	Secondary	Secondary	Primary	No meaningful contribution
4	Enabling	Secondary	No meaningful contribution	Secondary	No meaningful contribution	Primary	No meaningful contribution
5	Enabling	Secondary	No meaningful contribution	No meaningful contribution	No meaningful contribution	Secondary	No meaningful contribution
6	Primary	No meaningful contribution	Primary	Primary	Secondary	Primary	No meaningful contribution

shows the impact profile for the MMMI building.

8.7. Worked Translation Example from the IoT Building Cloud Case

A concrete example clarifies how the framework translates a documented IoT Building Cloud capability into Smart Readiness Indicator-aligned assessment logic. The geofence-based access and climate control service is selected because it combines user interaction, privacy-aware data access, indoor climate information, and actuation-related functionality.

The source description can be formulated as follows. A mobile application evaluates whether a user is located within a defined building or room-related geofence. If the user is within the authorised geofence, access to indoor climate data can be granted, and selected climate control actions can be triggered through thermostat or building system integration. The service is therefore not merely an access control feature. It links user presence, contextual data access, and indoor climate-related service response.

The service instance is identified as geofence-based access and climate control. The primary functionality is formulated to govern data access and trigger climate control actions based on local geofence evaluation. The service domain is user-centric comfort and wellbeing services because the function is organised around user location, access rights, and indoor climate interaction rather than around one isolated HVAC component.

The physical and control layer contains mobile geolocation as the contextual sensing element, indoor climate sensors as environmental information sources, and thermostat or climate control endpoints as the actuation layer, where control integration is enabled. The control logic is geofence-triggered access and actuation logic. The communication infrastructure consists of the mobile application, backend API, and actuator integration. This coding makes clear that the service depends on both mobile computing and building system integration.

The digital and intelligence layer contains the Flutter mobile application, Angular dashboard, backend services, DBSCAN clustering, convex hull computation, and local geofence evaluation. The user interaction layer is the authenticated or guest mobile application. The integration layer connects access control, climate data access, and thermostat trigger functionality.

Formal Smart Readiness Indicator correspondence is partial and cross-domain. The service relates to heating and ventilation, where it triggers climate-related actions, and to monitoring and control, where it governs contextual visibility and access to indoor climate information. It should not be coded as direct HVAC correspondence unless the source evidence shows that the service performs a recognised HVAC control function with sufficient operational specificity. This distinction prevents overclaiming while still preserving the assessment relevance of the service.

The impact profile is mixed. Convenience is a primary contribution because the service simplifies contextual access and interaction. Information to occupants is primary because the service governs access to indoor climate data. Comfort is primary where the service triggers climate actions that affect thermal or indoor environmental conditions. Energy efficiency is primary or secondary, depending on whether absence logic, setback control, or preconditioning is implemented as part of the control sequence. Health and wellbeing and accessibility are secondary because access to indoor climate information may support environmental awareness, but the source evidence does not establish direct health outcome improvement. Maintenance and fault prediction have no meaningful contribution unless diagnostics or abnormal operation detection are included. Energy flexibility has no meaningful contribution unless the service is connected to load shifting, demand response, or grid interactive control.

This example shows how overlapping mappings are handled. A single service instance may contribute to multiple Smart Readiness Indicator domains when its functionality genuinely spans them. However, the correspondence type must record whether this relationship is direct, partial, cross-domain, or extended. Multiple impact contributions are allowed, but each must be justified by the service functionality rather than by the mere presence of technology.

8.8. Building Level Aggregation

Aggregation of the translated service instances shows a strong concentration in monitoring and control, with limited but important extension into heating and ventilation through the geofence-based climate control function. Monitoring and control dominate both by the number of service instances and by functional diversity, because installation automation, gateway pairing, dashboards, metadata visualisation, geometry-based placement, and privacy-aware access control all depend heavily on supervisory, digital, or representational functions rather than on direct standalone environmental control alone. This makes the case particularly valuable as an example of smart building intelligence built around digital infrastructure and operational visibility.

At the impact level, information to occupants or operators is the strongest dimension because nearly all service instances contribute to system visibility, inspectability, or controlled data access. Maintenance and fault prediction are also strongly represented because network status, pairing state, alarm visibility, replayability, and inspectable sensor infrastructure improve diagnosis and operational oversight. Energy efficiency is represented both directly and indirectly. It is direct in the geofence-based climate control logic and indirect in the monitoring, deployment, and digital twin services that make targeted control and insight possible. Comfort and health-related value are more selective and arise mainly where indoor climate data and control are directly involved. Energy flexibility is only weakly represented in the available case material because the demonstrated services focus primarily on installation, monitoring, visualisation, and local control rather than load shifting or grid interaction.

Maturity aggregation indicates a portfolio dominated by responsive service intelligence and automated service logic, with selected elements of adaptive or anticipatory behaviour. The QR installation, auto pairing, and dashboard functions are largely automated or supervisory. The geometry-based digital placement and metadata-driven visualisation services are higher-order digital support functions. The geofence-based access and climate control service introduces responsive intelligence because it changes behaviour according to local geofence events, and it begins to approach anticipatory logic where entry events are used for thermal preconditioning before full room occupancy. This means that the case does not yet represent a deeply predictive autonomous building, but it does represent a mature and operationally rich supervisory smart building platform.

Table 16. Building-level Smart Readiness Profile for the IoT building cloud case.

Analytical Dimension	Building Level Interpretation
Dominant formal SRI domains	Monitoring and control dominate, with selective extension into heating and ventilation
Dominant impact dimensions	Information to occupants and operators, maintenance and fault awareness, and energy efficiency
Prevailing maturity class	Responsive and supervisory service intelligence
Balance of correspondence types	Cross-domain and monitoring-centred correspondence dominate, while direct environmental correspondence is narrower
Principal gaps	Limited explicit energy flexibility and limited evidence of advanced predictive multi-domain optimisation
Overall readiness character	Supervision-rich, digitally integrated smart building platform with strong operational visibility and emerging context-aware climate control

shows the Smart Readiness Profile for the MMMI building.

8.9. Interpretation of the Case in Relation to the Proposed Framework

Application of the framework to the IoT Building Cloud ecosystem shows that the translation method can handle service portfolios in which the most important smartness does not arise from one classical end-use subsystem alone. Instead, smartness is distributed across installation automation, communication infrastructure, dashboards, visualisation, digital twin alignment, and privacy-aware access and control. The framework is therefore able to preserve an important reality of contemporary smart buildings, namely that much of their intelligence is embodied in cross-cutting digital infrastructure and supervisory capability rather than only in isolated HVAC or lighting functions.

The case also illustrates the value of keeping formal correspondence separate from impact interpretation. Several services, especially QR-based registration, auto configuration, metadata visualisation, and geometry-based placement, would be difficult to classify if assessed only through direct environmental function. Yet they make a substantial contribution to building smartness by enabling scalable deployment, system transparency, digital representation, and inspectable operation. Treating them as monitoring and control-related or cross-domain services preserves this contribution without overstating their direct equivalence to formal end-use domains.

The case further shows that the proposed framework can differentiate between enabling smartness and directly assessing relevant smartness. The IoT Building Cloud platform contains several enabling services that do not directly change comfort or energy use but are necessary for large-scale deployability and operational intelligence. At the same time, the geofence-based access and climate control function demonstrates how those enabling layers can mature into direct assessment-relevant environmental services. This confirms that the framework is capable of representing both infrastructural and operational expressions of smart readiness within one coherent analytical structure.

8.10. Qualitative Validation of the Case Application

The case application provides qualitative validation of the framework in three ways. First, it tests whether the framework can decompose an integrated smart building platform into distinct service instances without losing the coherence of the overall ecosystem. The IoT Building Cloud case contains installation automation, gateway configuration, dashboards, metadata-driven visualisation, digital twin alignment, and geofence-based interaction. These capabilities are technically interdependent, but the framework separates them into service instances that can be coded and traced individually.

Second, the case tests whether the framework can handle services that do not map directly to classical end-use domains. QR-based registration, gateway pairing, metadata-driven visualisation, and geometry-based sensor placement are not equivalent to heating, cooling, ventilation, or lighting services. Nevertheless, they contribute to smart readiness by enabling monitoring, control, visibility, maintainability, and digital representation. The framework captures this through cross-domain correspondence and monitoring and control alignment while avoiding the stronger claim that these services directly produce environmental control outcomes.

Third, the case tests whether the framework can produce a building-level readiness interpretation that is more informative than a simple technology inventory. The resulting profile shows strong concentration in monitoring and control, strong contributions to information and maintenance awareness, selective indoor climate-related value, and limited evidence of energy flexibility. This pattern is consistent with the documented capabilities of the case and demonstrates that the framework can identify both strengths and gaps.

The validation remains qualitative and internal to one case. It does not establish statistical generalisability or external reliability across independent assessors. Its purpose is to demonstrate procedural robustness, traceability, and interpretive usefulness. Broader validation requires application across multiple buildings, comparison with formal Smart Readiness Indicator assessments where available, and independent coding by multiple analysts.

9. Discussion

9.1. Principal Findings

Three findings emerge from the synthesis and the case application.

The first is that smart building intelligence is most coherently understood at the level of service functionality rather than at the level of isolated technologies or broad system labels. Across the reviewed literature, smartness is realised when digital technologies support identifiable operational capabilities such as adaptive thermal regulation, demand-responsive ventilation, occupancy-based lighting control, supervisory energy monitoring, automated leak protection, contextual access control, and user-oriented environmental interaction. This service-centred perspective is important because it shifts attention away from technology accumulation and toward the practical capabilities through which buildings sense, decide, respond, inform, and coordinate.

The second finding is that the enabling technology stack of smart building services is layered and structurally recurrent across domains. Sensing creates awareness of environmental, operational, and contextual conditions. Actuation and control create the possibility of operational response. Communication infrastructures enable distributed service coordination. Gateways and middleware support interoperability across heterogeneous systems. Software platforms and dashboards provide visibility, orchestration, and user interaction. Analytics and artificial intelligence-related functions increase adaptivity, anticipation, and optimisation. This layered structure explains why smartness cannot be inferred from one technology category alone. Meaningful smartness emerges only when these layers are configured into coherent service architectures.

The third finding is that the relationship between smart building services and the Smart Readiness Indicator is strong but internally differentiated. Some service domains, especially HVAC and lighting, align closely with formal Smart Readiness Indicator domains and provide comparatively direct translation pathways. Others, especially energy management, act as supervisory and cross-domain layers that must be interpreted through electricity, monitoring, and control. Security and access control, water management, and many user-centric services remain important to building smartness even though their formal correspondence is only partial or extended. This confirms that Smart Readiness Indicator-aligned assessment requires a translation procedure rather than a simple one-to-one matching exercise.

9.2. Methodological Contribution

The central methodological contribution lies in establishing a structured translation and aggregation procedure that links real smart building service descriptions to Smart Readiness Indicator-aligned assessment logic. Translation begins from discrete service instances rather than from broad domains or isolated devices. Each service instance is expressed through one dominant functionality, reconstructed through a physical and control layer and a digital and intelligence layer, mapped to formal Smart Readiness Indicator correspondence, and then assigned a multidimensional impact profile. Aggregation then consolidates these service records into formal domain profiles, impact profiles, maturity profiles, and a building-level readiness interpretation.

This sequence addresses an important gap in the literature. Existing work often explains smart building technologies, individual service domains, or the conceptual purpose of the Smart Readiness Indicator, but it rarely provides an explicit and reusable procedure for moving from one to the other. The framework developed here contributes to such a procedure. Its value does not lie in reproducing official Smart Readiness Indicator scoring. Its value lies in creating a consistent analytical bridge from operational service descriptions to assessment-aligned representations.

The distinction between translation and scoring is methodologically important. Building service portfolios is typically documented in engineering language, vendor language, deployment language, or system architecture language. The Smart Readiness Indicator, by contrast, is structured through formal technical domains and service logic. Translation is therefore a necessary intermediate step. Without it, the practical use of Smart Readiness Indicator-aligned reasoning remains limited to settings in which the analyst already possesses assessment-ready service descriptions.

A second methodological contribution lies in separating formal correspondence from impact interpretation. This distinction makes it possible to treat water management, contextual access services, metadata-driven visualisation, and similar functions in a disciplined way. Such services may contribute substantially to operational intelligence, supervision, and user interaction even when they do not correspond directly to a formal, standalone domain. Preserving this distinction avoids both overclaiming and underrepresenting relevant smart building capabilities.

9.3. Implications for Understanding Building Smartness

The findings support a broader conceptual shift in how building smartness is understood. Smartness is not adequately captured by counting devices, naming technologies, or referring generically to automation. Nor is it adequately captured by treating building intelligence as a purely digital overlay added to conventional systems. Smartness is better understood as an emergent property of service capability. It arises where technical and digital elements are configured into operational functions that alter how the building behaves, how users interact with it, how information is made visible, and how the building relates to the wider energy system.

This perspective also clarifies the role of digital infrastructures that do not directly regulate indoor conditions. Dashboards, metadata structures, installation automation, digital twin representations, middleware, and access management are sometimes treated as secondary support functions. The synthesis shows that they can instead form essential components of building smartness, particularly through monitoring and control, information provision, maintenance visibility, and cross-domain coordination. Smartness, therefore, resides not only in end-use control but also in the infrastructures that make building services visible, configurable, scalable, and governable.

The strong role of monitoring and control across the findings is particularly noteworthy. In many contemporary smart buildings, monitoring and control functions are the formal layer through which cross-domain digital intelligence becomes accessible. This helps explain why integrated platforms and supervisory infrastructures are increasingly central to smart building performance, even when they are not tied to one single environmental subsystem. Monitoring and control are, therefore, not merely an auxiliary domain. It is often the formal expression of distributed building intelligence.

9.4. Implications for Smart Readiness Indicator-Aligned Assessment

Several implications follow for the Smart Readiness Indicator-aligned assessment.

First, building-level assessment should begin from a structured inventory of implemented smart service instances rather than from a generic list of technologies. The evidence reviewed here shows that technologies only become assessment meaningful when expressed through service functionality. A structured service inventory, therefore, offers a stronger analytical basis than a technology inventory alone.

Second, assessment-aligned reasoning requires modular rather than monolithic analysis. The separation of service instance identification, technology stack reconstruction, formal correspondence mapping, impact attribution, and aggregation improves traceability and reduces interpretive ambiguity. It also makes the analytical procedure easier to communicate and potentially easier to digitise in future tool support.

Third, not all building intelligence should be forced into direct formal domain equivalence. This is particularly important for buildings whose smartness relies heavily on supervisory and digital infrastructure. Extended relevance and cross-domain correspondence are not methodological weaknesses. They are necessary categories for representing the actual structure of intelligent service ecosystems. Ignoring them would produce an artificially narrow interpretation of smart building capability.

Fourth, profile-based building-level outputs can already provide substantial practical value even in the absence of official scoring. A building-level readiness profile derived from translated service instances can show where smartness is concentrated, which impact dimensions dominate, what maturity level prevails, and where gaps remain. This type of output can support design review, retrofitting strategy, capability benchmarking, and investment planning before a formal Smart Readiness Indicator assessment is attempted.

9.5. Relationship to LEED, BREEAM, and Multi-Criteria Building Assessment

The proposed framework is complementary to broader building certification systems such as LEED [172] and BREEAM [173]. The Smart Readiness Indicator focuses specifically on the smart readiness of building technical services, including their ability to adapt to occupants, optimise operation, and interact with the energy system. LEED and BREEAM address broader sustainability performance, including energy, materials, water, indoor environmental quality, management, site issues, health, and wider environmental impacts. The translation framework should therefore not be interpreted as a replacement for these certification schemes. It provides a service-level smart readiness layer that can support multi-criteria decision-making alongside broader sustainability assessment.

The relationship is clearest in the energy domain. A Smart Readiness Indicator aligned with energy flexibility or monitoring and control capability may support better operational energy management, but it does not automatically demonstrate improved energy performance under LEED or BREEAM. LEED energy performance credits and BREEAM energy-related criteria normally require evidence such as energy modelling, metering, commissioning, operational performance, or compliance with specific scheme requirements. The translation framework can help identify which smart services may support such evidence generation, but the certification outcome remains governed by the relevant LEED or BREEAM methodology.

A practical integration roadmap can be structured in four steps. First, the building’s smart services are translated into Smart Readiness Indicator-aligned service records using the framework developed here. Second, the resulting service records are mapped to broader certification evidence categories, such as energy monitoring, automated control, commissioning support, indoor environmental quality monitoring, water leak detection, or occupant information. Third, the translated records are linked to documentary evidence required by the certification scheme, such as design specifications, metering plans, commissioning records, operational data, or occupant interface documentation. Fourth, the Smart Readiness Indicator aligned readiness profile is used as a complementary decision layer in retrofit or design planning, together with energy performance, cost, carbon, health, comfort, and resilience criteria.

This relationship can be illustrated by the energy flexibility dimension. Within the Smart Readiness Indicator, energy flexibility concerns the capability of building services to support interaction with the energy system, for example, through load shifting, demand response, storage coordination, or electric vehicle charging control. Within LEED or BREEAM, related value may appear through energy performance, metering, demand response readiness, commissioning, operational optimisation, or management evidence, depending on the specific scheme version and project type. The same smart service may therefore support multiple assessment logics, but it must be translated carefully because Smart Readiness Indicator smartness, LEED energy performance, and BREEAM sustainability credits are not equivalent metrics.

Table 17. Indicative alignment between Smart Readiness Indicator logic and broader certification evidence.

SRI Aligned Dimension	Typical Smart Service Evidence	Possible Relevance to LEED or BREEAM Assessment	Required Caution
Energy efficiency	Automated control, monitoring, optimisation, metering	May support energy performance, metering, commissioning, and operational optimisation evidence	Does not prove energy performance without scheme-specific calculation or measured data
Energy flexibility	Demand response logic, storage coordination, EV charging control, load shifting	May support demand response, resilience, operational management, or grid interaction, with evidence where recognised	Not equivalent to energy performance credit achievement
Information to occupants	Dashboards, feedback interfaces, and environmental displays	May support occupant engagement, operational transparency, or management evidence	User access and actual use must be documented
Maintenance and fault prediction	Fault detection, alarms, diagnostics, asset visibility	May support commissioning, management, maintainability, and operational quality evidence	Predictive capability should be distinguished from basic alarms
Health, wellbeing, and accessibility	Indoor environmental monitoring, comfort feedback, and user interfaces	May support indoor environmental quality, health, and wellbeing related evidence	Sensor presence does not prove improved occupant outcomes

summarises this complementary relationship.

9.6. User Acceptance, Privacy, Training, and Organisational Readiness

Smart building readiness is not only a technical property. Services that appear strong in an assessment-aligned translation may fail to deliver their intended value if users reject them, operators do not understand them, data governance is unclear, or organisational routines do not support their use. This is particularly important for occupant-facing services such as geofence-based access, occupancy-based lighting, personalised comfort control, indoor climate dashboards, and mobile building interaction.

User acceptance should therefore be treated as an implementation condition for assessment-relevant smartness. Occupancy-based lighting may reduce energy use and improve convenience, but occupants may experience automatic switching or dimming as a loss of control if override options are absent. Geofence-based access and climate control may support convenience and energy efficiency, but they may also raise privacy concerns if users do not understand where location data is processed, whether tracking is continuous, and how access rights are governed. Indoor climate dashboards may increase transparency, but they may also create frustration if users can observe poor conditions without having any channel for response or feedback.

Training costs and organisational readiness are also important. Facility managers must understand how translated service capabilities relate to actual operation, maintenance, fault response, and user communication. A dashboard that is not integrated into daily operational routines contributes less to practical readiness than its technical description suggests. Similarly, predictive maintenance functions require staff capacity to interpret alerts, verify faults, and act on recommendations. Smart services, therefore, require organisational embedding, not only technical deployment.

Privacy and data protection must be considered, especially where services process occupancy, location, access, comfort preference, or behavioural data. Privacy by design principles should be reflected in service documentation, including data minimisation, local processing where feasible, role-based access, transparent user communication, retention limits, and clear governance of data sharing. These conditions do not change the formal Smart Readiness Indicator correspondence of a service, but they affect whether the service can be responsibly implemented and accepted.

For this reason, future applications of the framework should include a contextual readiness note for each service instance. This note should record user-facing implications, training needs, privacy-relevant data categories, organisational dependencies, and likely barriers to adoption. Such a note would not replace the Smart Readiness Indicator-aligned coding, but it would make practical feasibility visible alongside technical smartness.

9.7. Insights from the IoT Building Cloud Case

The case application reinforces and extends the broader findings. The IoT Building Cloud ecosystem shows that a smart building service portfolio may derive much of its intelligence from supervisory digital infrastructure rather than from direct end-use optimisation alone. Installation automation, gateway pairing, dashboards, metadata-driven visualisation, geometry-based digital placement, and geofence-based control together create a service ecosystem in which monitoring, control, access, visibility, and contextual action are tightly interwoven.

This case is especially valuable because it demonstrates that monitoring and control can dominate the formal correspondence profile without reducing the practical richness of the building’s smartness. On the contrary, the case shows how supervisory infrastructures enable service deployability, inspectability, operational oversight, and selective environmental control. It also demonstrates that enabling services and direct assessment of relevant services often coexist in one ecosystem. QR-based registration and metadata-driven visualisation do not directly regulate thermal comfort, yet they remain important because they support the deployability and coherence of the smart service environment. Geofence-based climate control, by contrast, shows how these supporting layers can evolve into directly assessment-relevant functions.

The case also reveals a specific readiness pattern. Smartness is concentrated strongly in monitoring and control, information to occupants or operators, maintenance and fault awareness, and selected indoor climate-related capabilities. Flexibility-oriented capability remains limited. Predictive multi-domain optimisation also remains relatively weak compared with visibility, deployment, and context-aware control. This suggests that digitally mature smart buildings may still be uneven in their smartness profile. Strong supervisory intelligence does not automatically imply strong flexibility or advanced anticipation.

9.8. Practical Implications

Several practical implications follow for building owners, designers, system integrators, and technology providers.

For building owners and operators, a service-based translation framework offers a clearer basis for understanding what smartness is already present in a building and where the main gaps remain. Many building portfolios contain a mixture of dashboards, sensors, room controls, access systems, and local automation rules without a structured representation of how these elements contribute to overall smartness. Translating these capabilities into service instances and building-level profiles can support more deliberate planning of retrofits, platform integration, and capability upgrades.

For designers and system integrators, the framework highlights the importance of specifying services in functional terms rather than only in technical terms. Design decisions become more comparable when expressed as smart service capabilities with explicit technology layers, formal correspondence, and expected impact contributions. This can improve communication across disciplines and reduce the ambiguity that often surrounds digital building solutions.

For technology providers, the framework makes visible the difference between enabling technologies and assessment-relevant service contributions. Sensors, gateways, dashboards, and analytics modules are not valuable solely because they are advanced or connected. Their value depends on the operational functionalities and readiness dimensions they support. This shift from product-centric description to capability-centric description may support clearer value propositions and more transparent building-level integration.

9.9. Limitations

Several limitations should be acknowledged.

The first limitation concerns the breadth and heterogeneity of the literature. Smart building research spans multiple disciplines, and terminology remains inconsistent. Although the review and coding strategy were designed to capture this diversity, some relevant studies may use alternative terms, sector-specific language, or implementation descriptions that were not fully represented in the corpus. This may affect the completeness of the service domain synthesis.

The second limitation concerns the absence of a registered review protocol. The methodology follows a PRISMA ScR informed logic, but the protocol was not registered before the review was conducted. This limits procedural transparency compared with a fully registered scoping review. The revised methodology mitigates this limitation by clarifying search sources, eligibility criteria, coding dimensions, and the constructive role of the review in framework development, but it does not remove the limitation.

The third limitation concerns interpretive judgement in coding. Even with explicit rules, assigning service domains, correspondence types, contribution levels, and maturity classes requires analytical interpretation, especially where services are cross-domain or where source descriptions are incomplete. The framework reduces ambiguity by separating service functionality, technology stack, formal correspondence, and impact interpretation, but it does not eliminate subjectivity. Formal inter-rater reliability testing was not conducted, and future work should apply independent coding and kappa-based consistency analysis to strengthen reliability.

The fourth limitation concerns the case study design. The IoT Building Cloud case demonstrates procedural applicability and internal traceability, but it is centred on a digitally mature university office building context with relatively advanced IoT infrastructure. The case does not prove that the framework will operate with equal ease in older buildings, industrial facilities, low-income regions, or buildings with weak digital foundations. The framework is intended to be transferable, but its application must be adapted to local technical maturity, cost constraints, organisational capacity, and evidence availability.

The fifth limitation concerns generalisability. The framework identifies a structured translation logic, but the empirical demonstration remains limited to one integrated smart building platform. Broader validation across building types, climatic regions, ownership models, and digital maturity levels is required before robust claims can be made about general applicability. Comparative studies should include buildings with minimal automation, buildings undergoing retrofit, industrial buildings, residential buildings, and public buildings in regions with different economic and regulatory conditions.

The sixth limitation concerns the count-based character of aggregation. The building-level profile reflects service instance frequency, functional diversity, correspondence pattern, and contribution type rather than official Smart Readiness Indicator weighting or strategic service importance. A building with many narrow smart functions may therefore appear broad in profile terms, while a building with fewer but more operationally important services may appear narrower. This limitation can be addressed in future work through weighting, confidence scoring, and closer integration with official service catalogues.

The seventh limitation concerns the relationship to formal assessment and certification systems. The outputs generated here are Smart Readiness Indicator-aligned representations, not official Smart Readiness Indicator scores, LEED credits, BREEAM credits, or certified assessment outcomes. Formal certification, national implementation details, and authorised assessment procedures remain outside the scope of the framework. The proposed method should therefore be used as a structured pre-assessment and interpretation tool rather than as a certification substitute.

The eighth limitation concerns social and organisational factors. The framework primarily translates technical service capability. It does not fully evaluate user acceptance, privacy perception, training effort, organisational resistance, operational routines, or long-term maintenance capacity. These factors may determine whether smart services deliver value in practice. Future versions of the framework should incorporate contextual readiness indicators for user acceptance, governance, organisational embedding, and operational sustainability.

9.10. Practical Outputs and Template Development

The framework can be operationalised through standardised templates that reduce the effort required to apply the method in practice. A minimum template should contain one row per service instance and should include the following fields: source description, service domain, service instance name, primary functionality, sensing layer, actuation layer, control logic, communication infrastructure, software layer, analytics or artificial intelligence layer, user interaction layer, integration or orchestration layer, formal Smart Readiness Indicator domain, correspondence type, impact profile, maturity class, evidence source, confidence level, and contextual readiness note.

Such a template would support consistent use across projects and would make the method more accessible to practitioners. It would also allow the framework to be implemented in open-source tools, where drop-down lists, rule-based prompts, and validation checks could reduce coding inconsistency. For example, a tool could require the user to define a primary functionality before selecting impact contributions, require every impact dimension to be coded, prevent empty correspondence fields, and flag services where the selected impact profile is inconsistent with the described functionality.

Open templates would also support comparative studies. If multiple buildings are coded using the same service instance structure, their readiness profiles can be compared across formal domains, impact dimensions, maturity levels, and contextual constraints. This would help identify common gaps, retrofit priorities, and recurring patterns of smart building development across different building types and regions.

9.11. Directions for Future Work

Several directions for future work follow directly from the framework, findings, and limitations.

A first priority is broader empirical validation across diverse building types and contexts. Future studies should apply the framework to older buildings with limited automation, industrial facilities, residential buildings, public buildings, educational buildings, and buildings in low-income or resource-constrained regions. Such studies would clarify how the translation logic performs under different levels of technical maturity, evidence availability, cost constraints, and organisational capacity.

A second priority is independent coding validation. Future applications should involve multiple coders and should calculate inter-rater agreement for service domain assignment, correspondence type, impact contribution level, and maturity class. This would make it possible to evaluate the reliability of the coding scheme and to refine ambiguous decision rules.

A third priority is the development of standardised templates and open digital tools. The modular tables introduced here can be transformed into spreadsheet templates, web forms, or open-source software components for service instance extraction, technology stack coding, correspondence mapping, impact attribution, maturity classification, and building-level aggregation. Such tools would lower the practical application barrier for researchers, consultants, building owners, and technology providers.

A fourth priority is integration with digital building models and asset registries. If smart building services can be represented consistently in BIM, digital twin environments, building management systems, or structured asset databases, translation into Smart Readiness Indicator-aligned logic could begin earlier in the building lifecycle and could be updated as services are installed, commissioned, modified, or retired.

A fifth priority is the development of differentiated guidance for specific building contexts. Older buildings may require staged retrofit pathways and low-cost monitoring first. Industrial facilities may require stronger attention to process constraints and operational continuity. Low-income regions may require minimum viable smart readiness pathways based on robust, maintainable, and affordable technologies. Digitally mature office buildings may require more advanced handling of overlapping digital services and supervisory platforms.

A sixth priority is stronger alignment with broader certification and decision frameworks. Future work should examine how Smart Readiness Indicator-aligned service records can support evidence preparation for LEED, BREEAM, energy performance certification, digital building logbooks, and building renovation planning. Such integration would strengthen the practical value of the framework in multi-criteria decision making.

A seventh priority is the inclusion of social, organisational, and governance readiness indicators. Future versions of the framework should record user acceptance risks, privacy implications, training needs, data governance requirements, operational routines, and maintenance capacity. This would help prevent technically advanced services from being interpreted as practically mature when organisational conditions are weak.

10. Conclusions

Buildings are increasingly characterised by digitally enabled services that extend operational capability beyond conventional control and automation. Sensors, actuators, communication infrastructures, software platforms, dashboards, metadata structures, digital twins, and analytics functions allow buildings to monitor conditions, adapt behaviour, support users, and coordinate across systems. At the same time, the Smart Readiness Indicator provides a formal European framework for assessing smart readiness through technical domains, service logic, and multidimensional impact criteria. A structured connection between these two perspectives is required because real building descriptions are often expressed through implementation-specific technologies, while assessment logic requires formal service interpretation.

A service-oriented perspective provides the basis for this connection. Smartness is not adequately described through the presence of technologies alone. It is realised through the functionalities that building services perform and through the value these functionalities deliver. The smart building service instance is therefore used as the unit of analysis for translating building descriptions into Smart Readiness Indicator-aligned assessment representations.

A methodological procedure has been developed to support this translation. Each service instance is identified, expressed through a primary functionality, and reconstructed through physical, control, digital, and intelligence layers. The functionality is then mapped to formal Smart Readiness Indicator domains, classified according to direct, partial, cross-domain, or extended relevance correspondence, and interpreted through a structured impact profile. This procedure makes explicit how coding decisions are made and how overlapping mappings are handled.

Aggregation of service-level records yields a building-level readiness profile. Domain aggregation reveals where smart functionalities are concentrated within the formal structure of the Smart Readiness Indicator. Impact aggregation shows which dimensions of smartness are most strongly represented across the service portfolio. Maturity aggregation distinguishes between basic digital support, automated service logic, responsive service intelligence, and adaptive or anticipatory intelligence. The resulting profile supports structured pre-assessment, comparison, design stage reasoning, and digital tool development, but it does not replace official Smart Readiness Indicator scoring or certification.

Application of the method to the IoT Building Cloud ecosystem demonstrates that contemporary smart buildings may derive a significant share of their intelligence from supervisory and digital infrastructure rather than from isolated end-use control alone. Installation automation, gateway configuration, dashboards, metadata-driven visualisation, digital twin alignment, and geofence-based access and climate control form an integrated service environment in which monitoring, visibility, coordination, and user interaction are central. The case produces a readiness profile characterised by strong representation in monitoring and control, information to occupants and operators, and maintenance awareness, with more selective contributions to indoor environmental control and limited evidence of energy flexibility.

The findings highlight that smart building readiness is multidimensional, uneven, and context-dependent. Strong supervisory visibility does not automatically imply strong energy flexibility, predictive optimisation, or occupant acceptance. Buildings with advanced IoT infrastructures, older buildings with weak technical foundations, industrial facilities, and buildings in resource-constrained regions require different application pathways. The framework remains transferable because the translation logic is generic, but implementation must account for technical maturity, cost constraints, organisational readiness, privacy governance, user acceptance, and local capacity.

The framework is also complementary to broader certification systems such as LEED and BREEAM. It can help structure smart service evidence that may support energy management, monitoring, commissioning, indoor environmental quality, and operational transparency, but it does not replace the scheme-specific methods used to determine credits or certification outcomes. Its contribution is a service-level smart readiness layer that can support broader multi-criteria decision making.

Future work should validate the framework across multiple building types and regions, apply independent coding and inter-rater reliability analysis, develop open templates and digital tools, integrate the method with BIM and digital twin environments, and include contextual readiness indicators for privacy, training, user acceptance, and organisational embedding. These extensions would strengthen the framework as a practical bridge between smart building engineering descriptions and formal assessment-oriented interpretation.

A structured understanding of smart building services, their enabling technologies, and their relation to assessment logic provides a foundation for more transparent, comparable, and actionable interpretations of building intelligence.