Consent-Aware Personalization for Building Service Platforms: A Federated Decision Protocol for Privacy-Bounded Occupant Services

1. Introduction and research question

Building service platforms now combine comfort control, fault detection, energy forecasting, and retrofit guidance in a single software layer. Personalization in this setting is valuable because the same thermal environment is not equally acceptable to all occupants, and the same building does not require the same service policy at all times. The technical difficulty is that personalization commonly depends on occupant-linked telemetry: zone-level motion, access traces, feedback logs, presence estimates, device interactions, and fine-grained temporal patterns. Those signals can improve inference, but they also create privacy exposure and consent conflicts when reused across services. The present protocol asks a narrower question: how can a building service platform personalize service decisions while obeying explicit consent constraints on data use, inference scope, and retention, especially when data are distributed across buildings and cannot be centralized?

This question is grounded in prior work on privacy-preserving, context-aware federated personalization, where data remain local and model updates are aggregated across clients [Karthik et al.]. It also relies on reproducible multi-building HVAC simulation pipelines that make controlled comparison possible without relying on a single building or an undocumented controller [Domingo et al.]. For sensor-linked operation, fault and monitoring studies show that building telemetry is often interdependent and that consistency across sensors is diagnostically informative [Chahine et al., De Jesus et al.]. For optimization, demand forecasting and multi-objective retrofit decision support show how building services can be formulated as prediction plus decision problems rather than as isolated classifiers [Emir et al., Duan et al.]. The present manuscript synthesizes these transferable ideas into a consent-aware protocol rather than a completed empirical study. [1] [2] [3] [4] [5] [6]

2. Evidence scope and synthesis approach

The evidence scope is a targeted narrative synthesis centered on methods that can be transferred to building service platforms with occupant-linked telemetry. The emphasis is on operational structure: where computation occurs, which variables may be shared, what information must remain local, and how optimization is conditioned on consent. This is not a systematic review, and no search count, screening flow, or pooled effect estimate is claimed. The selected sources are used because they support distinct methodological components. The federated learning study provides the strongest direct foundation for local-data constraints and context-aware aggregation [Karthik et al.]. The dataset-generation study provides a reproducible basis for controlled evaluation across multiple buildings and climates [Domingo et al.]. The smart-building sensing studies provide application evidence that telemetry can be interpreted through cross-sensor consistency and deployment-ready metadata structures [Chahine et al., De Jesus et al.]. The demand prediction and retrofit optimization studies provide transferable formulations for forecasting and multi-objective decision support [Emir et al., Duan et al.]. [1] [2] [3] [4] [5] [6]

The synthesis does not treat any cited result as universally generalizable. For example, the heating-load prediction study reports strong predictive performance for a specific building and validation setting, but the passage itself limits interpretation to that case and validation choice [Emir et al.]. Likewise, the sensor-fault study demonstrates cross-system metadata-driven deployment on benchmark simulations, while explicitly noting that simulated data and limited fault classes constrain generalization to live buildings [Chahine et al.]. These limits matter here because consent-aware personalization is only defensible if the system respects deployment boundaries rather than assuming that a model trained on one building or one telemetry regime transfers unchanged to another. [5] [3]

3. Conceptual model of consent-aware personalization

The protocol treats personalization as a constrained mapping from building state to service action. The service action may be a comfort recommendation, HVAC setpoint adjustment, ventilation suggestion, anomaly alert, or retrofit option ranking. The input state is partitioned into four variable classes: environmental variables x_e, system variables x_s, occupant-linked variables x_o, and consent variables c. Environmental variables include outdoor temperature, solar exposure, and zone thermal conditions. System variables include airflow, power, actuator commands, and equipment status. Occupant-linked variables include presence, access-derived occupancy estimates, feedback, and time-pattern features that can identify routines. Consent variables specify which features may be used, for which purpose, under what retention period, and whether raw values may leave the local node.

The core design principle is purpose separation. A feature allowed for fault detection is not automatically allowed for comfort profiling or retrofit recommendation. This principle extends the local-data premise of federated learning in smart environments [Karthik et al.] into building services. It also addresses the practical problem that telemetry useful for prediction can be privacy-sensitive even when aggregated. For example, demand estimation may be built from occupancy-linked histories, but only the minimal derived representation should be shared when the consent profile excludes raw occupancy traces. The protocol therefore distinguishes between raw signals, derived local features, and shared model updates. Only the last category is eligible for cross-building exchange unless the consent policy explicitly allows a richer transfer. [1]

4. Proposed method: consent gate, local inference, and federated aggregation

The proposed method is a three-stage sequence. Stage 1 is consent gating. For each service request r and each user- or zone-linked profile p, the platform constructs an admissible feature set A(r,p) from the current consent record. Stage 2 is local inference. If the service can be computed from A(r,p) and local system variables, the model executes on the building node and returns an action or recommendation without exporting raw telemetry. If the service requires cross-building learning, the node trains locally and shares only model gradients or parameter updates with a coordinator. Stage 3 is policy assembly. The coordinator aggregates updates, distributes a new model, and each node re-evaluates the consent gate before using the model for downstream personalization.

The operational rule is as follows: a request r is admissible if and only if A(r,p) contains every variable required by the model M_r and if no excluded variable is necessary for feature construction, training, or logging. In plain text: execute r only when RequiredFeatures(M_r) is a subset of AllowedFeatures(c,p,r), and deny or downgrade the request otherwise. When the condition fails, the system must fall back to a non-personalized baseline or to a strictly local model that uses only non-sensitive variables. This rule is intentionally conservative. It is designed to prevent silent scope creep, where a model initially approved for comfort adaptation is later reused for occupant profiling or operational analytics. The rule is falsifiable because any violation can be logged as a mismatch between RequiredFeatures and AllowedFeatures.

The local inference component can be implemented with two model families. For time-dependent services such as HVAC personalization and demand prediction, a probabilistic regressor estimates the conditional distribution of the target service metric given consent-permitted features, following the transferable logic of uncertainty-aware heating-load prediction [Emir et al.]. For multi-objective service ranking, a constrained scorer evaluates candidate actions against energy, comfort, carbon, and consent penalties, drawing on the structure of multi-objective retrofit decision support [Duan et al.]. The consent penalty is not a vague ethical score; it is a hard constraint when a variable is disallowed and a soft cost only when the policy permits use under limited retention or limited aggregation. [5] [6]

5. Relation to prior methods and methodological distinctions

The closest methodological foundation is severity-aware federated learning for privacy-preserving indoor emergency recognition [Karthik et al.]. That work demonstrates that hierarchical federated learning can operate under data-local constraints and that context-aware aggregation can be used to preserve utility while reducing exposure. The present protocol transfers the local-learning premise but changes the task: the unit of optimization is not emergency recognition but building service personalization, where the service itself may need to adapt to consent status in real time. This difference matters because emergency recognition is a detection task, whereas consent-aware personalization is a policy-selection task that must decide whether a model may run at all. [1]

The reproducible HVAC dataset method provides another essential foundation [Domingo et al.]. Its value here is not the specific controller but the idea that multi-building, multi-climate data can be generated under a controlled interface with standardized variables. That structure is useful for consent-aware research because consent policies can be simulated as explicit masks over feature access and retention, enabling reproducible comparisons across buildings and policy regimes. By contrast, ad hoc single-building logs would confound consent effects with building-specific sensor layouts and control logic. The protocol therefore adopts the multi-building evaluation logic, while replacing stochastic exploratory control with consent-conditioned feature availability. [2]

The smart-building sensing and monitoring studies offer direct operational evidence. The BRICK-based virtual sensor framework shows that metadata can organize sensor relationships and support scalable deployment across different HVAC systems, but it also depends on fault-free inter-sensor relationships and benchmark simulation [Chahine et al.]. The spike-driven indoor air quality study shows that event-driven sensing can reduce computational cost in multi-zone environments, but its own boundary conditions include single-site validation and the need for further hardware confirmation [De Jesus et al.]. In the present protocol, both studies support a narrow claim: consent-aware platforms should prefer metadata-guided, event-sensitive, and locally evaluated processing rather than indiscriminate continuous export of raw streams. [3] [4]

The prediction and retrofit studies extend the decision layer. The heating-load prediction study supports uncertainty-aware estimation for service optimization, but its passage explicitly cautions that the results are case-specific and dependent on validation settings [Emir et al.]. The retrofit optimization study supports multi-objective ranking that balances energy, carbon, and comfort using surrogate models and Pareto-based search [Duan et al.]. In a consent-aware platform, such ranking should be applied only after the feature gate has removed disallowed inputs. Thus, the novelty of the present protocol is bounded: it is not a new predictor or a new optimizer, but a rule for making those components consent-compliant before they are used in building services. [5] [6]

6. Variables, assumptions, and outcome measures

The protocol defines five primary outcome domains. First, consent compliance: the proportion of service requests whose executed feature set exactly matches the allowed feature set. Second, utility preservation: the degradation in service quality relative to a non-restricted local baseline, measured separately for comfort, energy, and decision ranking. Third, calibration: the agreement between predicted uncertainty and observed error for probabilistic service outputs. Fourth, robustness: stability under missing consent records, delayed updates, sensor faults, or incomplete metadata. Fifth, transferability: performance across buildings, climates, and service types under the same policy language.

The main assumptions are explicit. Consent records are machine-readable and versioned. Feature provenance is known, so the system can determine whether a derived variable depends on a restricted raw signal. Basic building metadata are available, whether through a schema layer or a platform registry. Finally, the platform permits a safe fallback when a request is not admissible. These assumptions are strong but practical. Without them, a consent-aware system would be unable to prove that a personalized recommendation was generated within permitted bounds.

The validation comparator is a conventional personalization pipeline that ignores consent except for post hoc access control. A second comparator is a local-only baseline that never aggregates across buildings. The proposed method should be judged against both, because one comparator tests privacy violation risk and the other tests the utility cost of strict locality. This dual comparison is consistent with the way prior studies compare more than one baseline: the federated emergency system compared against standard federated baselines, and the sensor-fault study compared against PCA [Karthik et al., Chahine et al.]. [1] [3]

7. Prospective evaluation protocol

The evaluation is designed as a staged protocol rather than a claimed experiment. Stage A uses controlled multi-building datasets with explicit feature masks generated from the reproducible HVAC pipeline [Domingo et al.]. For each building-climate pair, the same raw series are partitioned into consent profiles that differ by purpose, retention, and device class. This produces comparable conditions for testing whether the method can preserve utility under progressively stricter feature access. [2]

Stage B evaluates service tasks in three categories. Category 1 is demand forecasting, where the model predicts heating or cooling demand with uncertainty. Category 2 is comfort personalization, where the model recommends setpoint or ventilation adjustments. Category 3 is decision support, where the model ranks retrofit or operational options under multiple objectives. For each category, the validation records performance when all variables are allowed, when occupant-linked variables are partially restricted, and when they are fully restricted. The expected failure mode is graceful degradation, not silent breach. If the model relies on a disallowed variable, it must be rejected rather than approximated.

Stage C introduces stress tests. The platform is exposed to sensor fault scenarios, incomplete metadata, and conflicting consent updates. This stage is motivated by the sensor-fault literature, where closed-loop compensation can hide faults in isolated readings and where sensor consistency carries diagnostic value [Chahine et al.]. It is also informed by the event-driven monitoring study, which shows that multi-zone building sensing can be computationally efficient when processing is tied to meaningful events rather than constant sampling [De Jesus et al.]. The protocol therefore tests whether consent-aware personalization remains stable when the sensing layer itself is imperfect. [3] [4]

The primary reported outputs should be confusion-style counts for admissible versus inadmissible requests, calibration curves for probabilistic outputs, and Pareto-front comparisons for multi-objective recommendations. No numerical threshold is fixed here beyond illustrative, hypothetical examples; any operational cutoff must be chosen by the deployment owner and justified by the risk posture of the building portfolio. The protocol rejects the common shortcut of declaring success from a single aggregate score, because consent violations and utility loss are qualitatively different outcomes.

8. Failure cases, boundary conditions, and conclusion

Several boundary conditions limit generalization. If consent metadata are absent, inconsistent, or unenforced at the source system, the protocol cannot guarantee compliance. If a building has poor sensor provenance, derived features may leak restricted information even when raw data are not exported. If the platform uses occupant-linked telemetry only sporadically, the utility gain from personalization may be too small to justify the governance overhead. These are not minor implementation details; they determine whether the method is usable at all.

Another limitation is domain transfer. The protocol is designed for building service platforms with recurring telemetry and configurable control actions. It is not automatically transferable to one-off analytics or to environments where model updates cannot be isolated by building or purpose. The same is true for cross-building aggregation: the federated layer is appropriate only when the tasks are sufficiently aligned that a shared representation is meaningful. The cited building studies support this caution by emphasizing case specificity, validation settings, and the need for further deployment evidence before broad claims are made [Emir et al., Chahine et al., De Jesus et al.]. [5] [3] [4]

Conceptually, the manuscript establishes a bounded proposition: consent-aware personalization can be expressed as a machine-checkable feature-gating and federated inference protocol for building service platforms. This proposition is supported by prior work on privacy-preserving federated learning, reproducible HVAC data generation, smart-building sensor consistency, demand prediction, and multi-objective decision support [Karthik et al., Domingo et al., Chahine et al., Emir et al., Duan et al.]. What remains untested is whether the proposed policy rule, model architecture, and evaluation design together reduce privacy exposure without eroding service utility in operational buildings. That empirical question requires the prospective validation protocol specified above, not a retrospective claim of performance. [1] [2] [3] [5] [6]

References

1. Karthik, Chembon Rajeendran; Venkatraman, Shyam; K, Hemalatha (2026). Severity-aware hierarchical federated learning for privacy-preserving indoor emergency recognition in BLE-based medical IoT environments. Frontiers in Medical Technology. 8, 1900013. doi:10.3389/fmedt.2026.1900013.
2. Domingo, Ferran Aran; Alonso, Pablo Fraile; Torrentó, Josep Rius; Batalla, Oriol Agost; Vilardell, Ignasi Barri; Mayoral, Jordi Vilaplana; Fornés, Jordi Mateo (2026). A reproducible method to generate multi-building, multi-climate HVAC operation datasets with a stochastic exploratory controller. MethodsX. 16, 103866. doi:10.1016/j.mex.2026.103866.
3. Chahine, Khaled; Noura, Hassan N. (2026). BRICK-Automated Virtual Temperature Sensors for Sensor Fault Detection, Isolation, and Discrimination in Smart-Building HVAC Systems. Sensors. 26(11), 3465. doi:10.3390/s26113465.
4. De Jesus, Luigi Carlo M.; Africa, Aaron Don M.; Illahi, Ana Antoniette C.; Gustilo, Reggie C.; Brucal, Stanley Glenn E. (2026). Spike-Driven Neuromorphic Sensing for Energy-Proportional Indoor Air Quality Monitoring in Multi-Zone IoT-Enabled Smart Building Environments. Sensors. 26(13), 3992. doi:10.3390/s26133992.
5. Emir, Ahmet; Topal, Halil Ibrahim; Ozturk, Suat (2026). Novel hybrid machine learning-based prediction of building space heating load: a comprehensive study. Scientific Reports. 16(1), 24924. doi:10.1038/s41598-026-55342-x.
6. Duan, Zhongcheng; Li, Binhao; Zi, Yilun; Yao, Gang (2025). Building retrofit multiobjective optimization using neural networks and genetic algorithm three for energy carbon and comfort. Scientific Reports. 15(1), 38076. doi:10.1038/s41598-025-21871-0.