Tenant Privacy in Occupancy-Based Energy Control: A Privacy-Preserving Governance Architecture for Smart Building Actuation

1. Introduction

Occupancy-based energy control is attractive because temperature setbacks during apparent vacancy can reduce heating or cooling demand. The same mechanism creates a privacy problem. A controller that reacts to presence, absence, or inferred use of a room must process signals closely tied to habitation. Those signals may be exposed directly as sensor streams, indirectly through model updates, or inferentially through repeated command patterns. In rented dwellings and mixed-use residential buildings, this is a tenant privacy problem in a strict sense: the variable that enables energy savings is a pattern of human occupancy rather than merely a machine state.

A bounded body of direct scenario evidence clarifies where the technical difficulty lies. In a closed-loop study of AI-driven smart-building climate control, governance logic was inserted between a learned setpoint service and actuation. In that studied loop, admission control reduced unsafe physical exposure under distribution shift, rollback added little further in the thermal system examined, and the remaining avoidable exposure was driven by the policy’s estimate of occupancy context. The same paper also limits its claims to the evaluated building-control scenario and a stated class of inertial plants. That bounded finding is nonetheless highly relevant here because it locates residual risk at the interface between occupancy inference and actuation, which is also where privacy-sensitive information is concentrated. [1]

This article asks a narrower question than general smart-building cybersecurity: how can a building controller use occupancy-sensitive context for setback control while reducing disclosure of tenant behavior to servers, operators, and intermediate services? The answer proposed here is conceptual rather than empirical. It is a building-specific governance architecture that combines local occupancy estimation, privacy-preserving collaborative learning, explicit actuation admission rules, and auditable model-update validation. The central claim is not that privacy tools alone solve occupancy control, but that privacy must be designed around occupancy-context handling before commands reach the physical plant.

2. Evidence scope and synthesis method

The manuscript is a targeted narrative synthesis. It does not claim the completeness of a systematic review and does not report search counts. One paper supplies direct application evidence because it studies runtime governance in AI-driven smart-building climate control and explicitly identifies the policy’s estimate of occupancy context as the driver of remaining avoidable exposure in its scenario. Five additional papers provide transferable methodological foundations from IoT and industrial sensor settings: privacy-preserving federated learning, blockchain-assisted validation, poisoning-robust update handling, hierarchical privacy budgeting, client-level differential privacy, secure aggregation, and communication-efficient update release. [1] [2] [3] [4] [5] [6]

Three categories of statements are separated throughout. First, prior findings are restricted to what the cited passages support directly. Second, transferable principles are abstractions from those studies, such as keeping raw data local or adding calibrated privacy noise to updates. Third, the present manuscript proposes a new combination of those principles for occupancy-based HVAC governance; that proposal is not presented as empirically validated.

The building-control study imposes important scope constraints. Its concrete loop is a single-zone climate-control scenario with temperature, occupancy, and CO2 signals; its governance gates check setpoint bounds, metadata integrity, overload throttling, monotonic sequencing, and a hash-linked audit trace; and no physical hardware was operated. The present article therefore uses it as evidence about runtime governance semantics and occupancy-context dependence, not as a universal statement about all building types or all occupancy sensors. [1]

The methodological papers also require cautious transfer. Federated learning maintains data locality, but several sources note continuing vulnerability to inversion attacks, communication overhead, device heterogeneity, and adversarial manipulation. Differential privacy, secure aggregation, homomorphic encryption, adaptive participation, and update-validation layers are proposed responses, yet they introduce utility and resource costs of their own. The design below therefore treats these mechanisms as configurable components whose effect in residential occupancy control remains to be tested rather than assumed. [2] [4] [5] [6] [3]

3. Problem formulation and privacy model

Three terms are used distinctly. Occupancy context means any information used to condition control on room use, including raw sensor features and derived signals. Occupancy probability is the model output p_t = P(o_t = 1 | x_t), where o_t is latent occupancy state and x_t is a local feature vector. Occupancy uncertainty is represented here by binary entropy h_t = -p_t log p_t - (1-p_t) log (1-p_t), with the convention 0 log 0 = 0. Occupancy risk, in this manuscript, means the control-relevant risk that a setback command is inappropriate because occupancy may in fact be present; it is a decision construct derived from p_t and h_t, not a synonym for either variable.

Let u_t denote the candidate HVAC setpoint at time t, T_t the measured zone temperature, and S(o_t) the occupancy-conditioned comfort-safe set. Following the illustrative bands used in the building-governance study, S(1) = [20,25] when occupied and S(0) = [15,30] when vacant. A command that lies within the equipment range can still be inappropriate relative to the narrower occupied safe set. In the cited study, a corrected gate used CO2 as context to reject an energy-setback command when the room was in fact occupied. For tenant privacy, the difficulty is that the same context signal that improves safety and comfort is also the signal most likely to reveal household routines. [1]

A building-specific privacy model for occupancy control has at least four channels. Raw-signal exposure concerns sensor traces or embeddings leaving the dwelling. Update exposure concerns gradients or parameters from which occupancy patterns may be inferred. Metadata exposure concerns timestamps, sequence identifiers, and provenance fields in governance and training pipelines. Actuation exposure concerns the inferential value of accepted setpoint trajectories or downstream energy signatures. The federated-learning sources mainly address the first two channels. Runtime occupancy governance adds the latter two, which are central in tenant settings because a building operator may not need raw occupancy data to infer daily routine from command histories. [2] [6] [3]

4. Prior findings and transferable design principles

The most relevant direct finding from the building-control scenario is not that one controller class is universally safer than another, but that, in the studied thermal loop, prevention outperformed recovery. Admission control removed a material share of unsafe exposure under shift, whereas rollback added little further because governance decisions were fast and physical recovery was slow. The same study states that the remaining avoidable exposure was driven by the policy’s estimate of occupancy context. For the present problem, this supports a bounded design principle: if occupancy-sensitive setback creates the hazard, then governance should scrutinize occupancy-dependent decisions before actuation rather than relying chiefly on rollback afterward. [1]

A second principle is that data locality is useful but incomplete. One IoT paper describes federated learning as a way to train a shared model without sharing raw data, while also noting exposure to inversion attacks, communication overhead, heterogeneity, and power limits in IoT deployments. That same source proposes differential privacy, secure aggregation or homomorphic protection, blockchain-supported validation, adaptive participation, and energy-aware orchestration. A visual-IoT paper likewise emphasizes that data locality alone does not constitute a formal privacy guarantee and motivates client-level differential privacy for released model information under heterogeneous local data. These sources support using federation for occupancy learning only when the release channel is explicitly protected and resource-aware. [2] [6]

A third principle is that privacy and robustness cannot be separated cleanly. SecuFL-IoT combines differential privacy, homomorphic encryption, gradient sparsification, and dynamic filtering of malicious participants, while also noting encryption latency and a static-topology assumption. An industrial federated-learning study argues that privacy leakage and poisoning attacks coexist and proposes hierarchical privacy-budget allocation together with anomaly detection based on direction, scale, inter-layer similarity, voting, and clipping. These papers do not provide a building-ready detector, but they justify building occupancy-learning pipelines that consider poisoning risk at the same time as privacy preservation. [4] [5]

A fourth principle is architectural separation between real-time actuation and trust logging. A blockchain-assisted IoT framework records model updates in a transparent, irreversible trust layer and pairs that layer with homomorphic safeguarding. The same paper also notes that real IoT networks may impose latency, packet loss, and energy constraints beyond local simulation conditions. For occupancy-based HVAC, the implication is practical: immediate command admission should remain local or edge-resident, whereas provenance logging, consensus, and model-version validation should remain outside the control deadline. [3] [1]

5. Proposed architecture: Privacy-Preserving Occupancy Governance for HVAC

This manuscript proposes Privacy-Preserving Occupancy Governance for HVAC, abbreviated PPOG-HVAC. The architecture has two coupled planes. The learning plane estimates occupancy probability collaboratively without exporting raw tenant data. The runtime plane decides whether an energy-saving command may be executed, based on equipment constraints, metadata integrity, occupancy probability, occupancy uncertainty, model freshness, and privacy state. The objective is controlled use of occupancy-sensitive context under bounded release-side privacy loss, not perfect occupancy detection.

Learning plane. Each dwelling gateway, room controller, or trusted local hub stores local feature vectors x_t and trains a local occupancy model f_theta(x_t) -> p_t. Raw x_t never leaves the client. At scheduled federated release rounds r = 1,2,..., the client computes an update delta_k^r, clips it to norm C, adds calibrated privacy noise, optionally sparsifies coordinates, and submits the protected update through secure aggregation. Following the cited federated-learning literature, the privacy-accounting event is the release of protected learning information, not ordinary command execution. Let B_r denote the remaining privacy budget in the current accounting horizon H after release round r has completed. [6] [2]

Trust and robustness path. Because secure aggregation conceals individual plaintext updates from the server, the server cannot inspect single updates before aggregation. PPOG-HVAC therefore places individual screening either on the client itself or on a trusted edge verifier in the same administrative domain before secure-aggregation masking. The screened object is the local update before masking. Screening features are directional consistency with the client’s recent benign updates, scale stability of the update norm, and inter-layer similarity statistics. If the local anomaly score z_k exceeds a threshold z_max, the release for that round is suppressed and the event is logged. After secure aggregation, the server can still reject an entire round or refuse model advancement if round-level consistency checks fail, but it cannot quarantine one mixed client update retroactively. This placement follows directly from the constraint imposed by secure aggregation. [5] [4] [6]

Audit path. Hashes of accepted model versions, policy versions, and release events are appended to a validation log. This path is compatible with blockchain-assisted validation, but it is asynchronous and not part of millisecond-level command admission. Its purpose is accountability for model provenance and policy evolution, not online thermostat control. [3]

Runtime plane. A local control service proposes a command u_t. The governance module first checks equipment bounds, required metadata fields, and sequence integrity in the style of the smart-building governance scenario. If the command is a setback request rather than comfort maintenance, the module applies an occupancy-risk rule that uses only locally held estimates and state flags. Rejected setbacks are replaced by a predefined comfort fallback. Ordinary comfort-maintenance commands may continue even if collaborative learning is temporarily paused, because privacy preservation in the learning plane must not force an unsafe loss of basic climate control. [1]

6. Operational rules, fallback logic, and privacy-state transitions

The variables used in runtime admission are as follows. p_t is local occupancy probability; h_t is occupancy uncertainty; u_t is candidate setpoint; A_t is model age measured as elapsed time since installation of the latest approved global or local occupancy model; m_t is an occupancy-setback mode flag taking values ENABLED or SUSPENDED; and B_t is shorthand for the most recently recorded remaining privacy budget B_r in the current accounting horizon. For illustration, the equipment range is [15,30] degrees Celsius, matching the building-governance scenario; the occupied comfort-safe fallback target is T_comfort = 22 degrees Celsius, also aligned with that scenario’s control target. [1]

The release-side protection rule is plain text: delta'_k = clip(delta_k, C) + n_k, where n_k is Gaussian noise calibrated to the chosen privacy target before secure-aggregation masking. A refined variant may allocate privacy budgets unevenly across layers according to estimated layer sensitivity, following hierarchical privacy-budget allocation methods from industrial federated learning. That refinement changes the update-release process rather than the runtime actuation path directly. [5] [6]

The core runtime admission rule is defined exactly. Admit a setback command u_t only if all five conditions hold: (1) u_t is within equipment bounds [15,30]; (2) required metadata and sequence checks pass; (3) p_t <= theta_vac; (4) h_t <= eta; and (5) m_t = ENABLED and A_t <= tau_max. Otherwise, replace the setback command with fallback u_fb = 22 degrees Celsius. Here theta_vac is the vacancy-confidence threshold, eta is the maximum uncertainty threshold, and tau_max is the maximum admissible model age for occupancy-sensitive setback. Numerical values are hypothetical until calibration; for illustration only, theta_vac may later be swept over 0.1 to 0.3.

The fallback rule is intentionally simple and fully operational. If a setback request fails any condition above, the executed command is the fixed comfort fallback u_fb = 22 degrees Celsius, not the last accepted setpoint and not a new occupancy-dependent estimate. This keeps fallback context-independent and avoids importing additional privacy-sensitive logic into the rejection path. A building-specific deployment could substitute another fixed comfort target, but any such substitution must be declared before evaluation.

The privacy-state transition requires explicit justification because command execution does not itself spend privacy budget. In PPOG-HVAC, privacy exhaustion does not block all HVAC control. It suspends only occupancy-sensitive setback authority. The causal mechanism is model staleness under privacy-limited adaptation: once the remaining release budget in horizon H falls below epsilon_min, the system may no longer be able to refresh the occupancy model adequately within that horizon, and the direct building-governance evidence indicates that unsafe exposure in the studied loop was driven by the policy’s estimate of occupancy context. The architecture therefore treats budget exhaustion as a proxy for reduced right to rely on occupancy inference for energy-saving setbacks, not as a signal to stop basic comfort control. [1]

The exact state transition is: after each federated release round r, compute B_r. If B_r < epsilon_min, set m_t = SUSPENDED immediately after the round commits. While m_t = SUSPENDED, all setback proposals are deterministically mapped to u_fb = 22 degrees Celsius, but non-setback commands that maintain comfort may still pass equipment and metadata gates. The flag remains SUSPENDED until one of two events occurs: a new accounting horizon begins and resets the available privacy budget by policy, or a policy-authorized model-refresh procedure installs an approved model under a replenished budget state. This transition is local and constant-time, so it adds no extra online latency beyond a flag check.

The full decision sequence is therefore as follows. Step 1: collect local occupancy-related features and compute p_t and h_t. Step 2: generate candidate setpoint u_t. Step 3: perform equipment-bound, metadata, and sequence checks. Step 4: if u_t is a setback request, apply the five-condition rule above. Step 5: execute either admitted u_t or fallback u_fb. Step 6: log local command outcome with policy and model version. Step 7: at scheduled training rounds, compute delta_k, perform local or trusted-edge screening, and only then apply clipping, privacy noise, and secure-aggregation masking. Step 8: perform server-side round validation and append approved model-version hashes to the audit path before the next model distribution. [1] [4] [3] [6]

7. Prospective evaluation protocol, comparators, and outcome measures

No experiment is reported here. This section specifies a prospective evaluation protocol. The primary comparator is a context-blind governed controller modeled on the building-governance baseline: equipment-bound and metadata checks admit any in-range setpoint without occupancy-sensitive gating. A second comparator is non-private federated occupancy control, which uses collaborative learning but no differential privacy or secure aggregation. A third comparator is local-only occupancy control with no federation. Optional stress tests may include rollback, although the building-governance study indicates that rollback contributes materially only within a limited operating envelope for inertial plants. [1]

The preferred testbed is a closed-loop software-in-the-loop environment of the same general kind as the smart-building governance study: a controller drives a thermal model, while an independent evaluation oracle computes occupancy-conditional safety outcomes. The oracle belongs to evaluation rather than deployment. Data partitions should follow zone, dwelling, or gateway boundaries so that heterogeneity is preserved. Disturbance scenarios should include occupancy-pattern shift, sensor noise or dropout, communication disruption, and malicious client updates during training rounds. No claim is made that a specific simulator or dataset has already been used. [1]

Primary safety outcome. Unsafe exposure for zone z over episode E is U_z(E) = sum over time steps t in E of Delta t multiplied by d(T_{z,t}, S(o_{z,t})), where d(T,S) = 0 if T is in S and otherwise equals the absolute distance from T to the nearest boundary of S. Aggregate unsafe exposure across a dwelling by summing over its zones, and across a study episode by summing over dwellings. This mirrors the degree-time logic used in the building-governance scenario while remaining agnostic about a particular plant implementation. [1]

Primary privacy outcome. Transcript-level privacy loss over accounting horizon H is epsilon_total(H), computed by the selected privacy accountant from all released protected updates in H. This outcome is reported per client and summarized across clients by median, upper quantile, and maximum, because tenant privacy risk is client-specific even when the global model is shared. A companion operational quantity is suspension time fraction, STF_k(H) = total time client k spends with m_t = SUSPENDED divided by total time in horizon H. [6] [2]

Comfort and control outcomes require exact definitions. Comfort-safe occupancy time fraction for zone z over episode E is CSOT_z(E) = [sum_t Delta t multiplied by I(T_{z,t} in S(o_{z,t}))] divided by [sum_t Delta t]. Rejection rate for setback proposals is RR_z(E) = N_reject,z / N_setback-proposed,z. Fallback fraction is FF_z(E) = N_fallback,z / N_commands,z. Model-refresh interval is MRI_k(H) = average elapsed time between successive approved model installations at client k during horizon H. These metrics are first computed per zone, then aggregated to dwelling and episode summaries.

Energy-related outcomes should remain explicit and interpretable. If outside temperature T_out,t is available in the testbed, define a heating demand proxy for zone z as HDP_z(E) = sum_t Delta t multiplied by max(0, u_{z,t} - T_out,t), and a cooling demand proxy analogously as CDP_z(E) = sum_t Delta t multiplied by max(0, T_out,t - u_{z,t}). If outdoor temperature is not part of the testbed, use the simpler setpoint-severity proxy SSP_z(E) = sum_t Delta t multiplied by |u_{z,t} - T_ref|, where T_ref is a fixed neutral reference declared before evaluation. These are proxies for comparative analysis, not direct energy measurements.

Communication and robustness outcomes are also defined prospectively. Per-round communication load for client k is CO_k^r = transmitted bytes plus received bytes during release round r. Episode-level communication is the sum over rounds. In simulation, where malicious labels are known by construction, the screening mechanism may be evaluated by precision and recall against poisoned-update labels. In deployment, such labels are ordinarily unavailable, so practical observables are screened-update rate, suppressed-release rate, aggregated-round rejection rate, and downstream model-stability indicators. The protocol should not assume access to true poisoning labels in occupied buildings. [4] [5]

The proposed hypotheses are falsifiable rather than reported. H1: compared with context-blind governance, PPOG-HVAC reduces unsafe exposure under occupancy shift. H2: compared with non-private federation, PPOG-HVAC bounds release-side privacy loss and prevents raw-data transfer at some utility cost. H3: compared with privacy-preserving federation without pre-aggregation screening, PPOG-HVAC reduces degradation under malicious updates. H4: compared with dense protected releases, sparsified protected releases reduce communication load without making occupancy-sensitive control unusable. Thresholds for theta_vac, eta, tau_max, epsilon_min, C, and z_max are calibration parameters to be swept rather than validated defaults. [4] [5] [6]

8. Comparison with prior methods, conflicting considerations, and limits of transfer

Relative to the smart-building governance study, PPOG-HVAC preserves the insight that occupancy-context estimation is a central residual source of actuation risk in the evaluated scenario, but it changes where that context is produced and how its use is licensed. The cited study governs intents around a learned setpoint controller and shows that a corrected occupancy-related predicate can improve admission decisions. The present proposal moves occupancy estimation into a privacy-preserving collaborative learning pipeline and adds a deterministic suspension state when privacy-limited adaptation makes occupancy-based setback insufficiently supportable. This is a design extension, not a claimed improvement over the cited controller. [1]

Relative to the hybrid IoT federated-learning framework, the present architecture adopts data locality, differential privacy, adaptive participation, and update validation, but it remains narrower about generative augmentation and blockchain. The cited framework proposes combining federated learning, generative AI, differential privacy, secure aggregation or homomorphic protection, and blockchain-based verification, while also observing that differential privacy can reduce utility when local datasets are small. PPOG-HVAC retains the privacy-preserving learning logic but does not require synthetic occupancy traces, because the realism and possible behavioral leakage of generated occupancy data are unresolved in this context. [2]

Relative to SecuFL-IoT and the industrial poisoning-robust framework, PPOG-HVAC borrows the co-design principle that privacy protection and update robustness must be handled together. It does not import an industrial detector unchanged. Instead, it adapts their update features to local or trusted-edge screening before secure aggregation, because server-side plaintext inspection is incompatible with secure aggregation. This adaptation follows from the mechanics of the privacy protocol rather than from any claim that industrial anomaly signatures are directly optimal for buildings. [4] [5] [6]

Conflicting considerations remain substantial. Differential privacy can reduce model utility when local datasets are small, which is plausible for single apartments, guest rooms, or intermittently occupied spaces. The building-governance study also reports a safety-demand trade-off in its controller comparison, showing that lower unsafe exposure need not coincide with lower modeled heating demand. Blockchain-style audit and cryptographic protection may add latency and energy overhead under realistic network constraints. Finally, privacy in the learning plane does not remove leakage through visible actuation patterns or utility-meter side channels. The proposal is therefore most plausible where local processing is trusted, comfort fallback is acceptable, and collaborative learning yields enough cross-unit structure to justify protected sharing. [2] [1] [3]

9. Conclusion

This manuscript establishes a bounded conceptual result. Within the supplied evidence base, the most relevant direct scenario study shows that, after basic runtime governance, remaining avoidable unsafe exposure in an AI-driven smart-building climate loop depended on the policy’s estimate of occupancy context. That finding motivates a privacy architecture centered on how occupancy context is learned, released, and admitted into actuation, rather than on rollback alone. The manuscript also resolves an implementation issue created by secure aggregation by separating pre-aggregation client or trusted-edge screening from post-aggregation round validation. [1] [4] [5] [6]

The specific proposal is PPOG-HVAC: a two-plane architecture with explicit variables, a mathematically stated uncertainty definition, an exact setback-admission rule, a fixed comfort fallback, and a local state transition that suspends occupancy-sensitive setbacks when privacy-limited model refresh can no longer justify reliance on occupancy inference. The contribution is methodological and building-specific. It links tenant privacy protection to occupancy-context governance in HVAC actuation and makes the learning-plane privacy state operationally relevant through a falsifiable model-staleness mechanism rather than a vague appeal to privacy exhaustion.

What remains untested is substantial. The architecture has not yet been shown to reduce privacy exposure without unacceptable losses in comfort, safety, communication efficiency, fairness across heterogeneous tenant routines, or energy performance. Real buildings may also present stronger connectivity constraints, richer sensor modalities, and more severe actuation-side leakage than this conceptual design assumes. The manuscript should therefore be read as a precise research design for subsequent closed-loop evaluation and staged deployment studies, not as evidence that the proposed architecture already works in practice.

References

1. Saydirasulovich, Norkobil Saydirasulov; Davronbekov, Dilmurod Abdujalilovich; Mubashirovich, Makhmudov Makhsum; Cho, Young Im (2026). A Closed-Loop Measurement Study of Runtime Governance in AI-Driven Smart Building Climate Control. Sensors. 26(15), 4921. doi:10.3390/s26154921.
2. Ramalingam, Venkadeshan; Kumar, Basant; Gupta, Shashi Kant; Alsekait, Deema Mohammed; AbdElminaam, Diaa Salama (2026). A hybrid federated learning framework with generative AI for privacy-preserving and sustainable security in IOT-enabled smart environments. Scientific Reports. 16(1), 3071. doi:10.1038/s41598-025-31769-6.
3. Ahmad, Shahnawaz; Ansari, Mohd. Aquib; Mewada, Arvind; Ahmed, Gulrej (2026). Blockchain-enhanced federated learning for IoT security and privacy using the GSR-C2N model. Scientific Reports. 16(1), 26468. doi:10.1038/s41598-026-52361-6.
4. Alqazzaz, Ali (2026). SecuFL-IoT: an adaptive privacy-preserving federated learning framework for anomaly detection in smart industrial networks. Scientific Reports. 16(1), 4107. doi:10.1038/s41598-025-11883-1.
5. Yin, Huan; Chen, Congwen; Zhang, Jingyi; Yu, Dian; Liu, Shuanggen (2026). Privacy-Preserving and Poisoning-Robust Federated Learning for Industrial IoT. Sensors. 26(16), 5297. doi:10.3390/s26165297.
6. Wang, Shuyi; Wang, Baoping (2026). Privacy-Preserving Federated Learning for Artistic Image Classification in Visual IoT Sensor Networks. Sensors. 26(17), 5654. doi:10.3390/s26175654.