Priya Raghavan’s third question was about data conflict. She had the residency model. She had the clinical integration architecture. Now she wanted to know what happens when the data disagrees with itself.
The scenario she constructed was this: a wearable reports heart rate at 82 beats per minute. A home sensor equipped with a ballistocardiography mat under the mattress reports heart rate at 78. The person mentions in conversation that she feels her heart racing. Three data sources, three signals, none of them wrong in isolation. The wearable measures photoplethysmography at the wrist, which is influenced by motion artifact and peripheral vasoconstriction. The mattress sensor measures mechanical cardiac impulse, which is influenced by body position and mattress damping. The person’s subjective perception reflects her internal experience, which may or may not correspond to either measurement. Priya asked: which source does the system believe?
Four data sources#
The sensor fusion architecture draws from four categories of input, each with different characteristics.
Wearable sensors provide continuous physiological data. Heart rate, heart rate variability, blood oxygen saturation, skin temperature, accelerometry for activity and sleep staging. The data arrives at roughly one-second intervals for most metrics, with higher frequency for accelerometry. Wearables are the highest-frequency data source. They are also the most susceptible to motion artifact, poor skin contact, and environmental interference.
Home sensors provide ambient environmental and behavioral data. Room temperature, humidity, light levels, air quality from environmental sensors. Motion patterns, room occupancy, gait speed from passive infrared and radar-based sensors. Sleep quality indicators from mattress sensors. Appliance usage from smart plugs. The data arrives at intervals ranging from every ten seconds for environmental readings to event-based for motion detection. Home sensors are lower-frequency but higher-reliability for their specific domains. A room temperature sensor is unlikely to give a false reading. A motion sensor occasionally triggers on a pet.
Smart home devices provide indirect behavioral indicators. When the lights turn on in the morning. When the stove activates. When the television turns off at night. These are event-based, irregular, and individually uninformative. Collectively, they form a pattern of daily routine that becomes significant when the pattern changes. The person who normally starts the coffee maker at 6:45am and today has not started it by 9:30am has deviated from a baseline. The deviation may mean nothing. It may mean something.
User interaction patterns provide cognitive and emotional indicators. Conversational response latency, vocabulary complexity, topic coherence, typing speed and error rate, voice tone and prosody. These are event-based and arise from the person’s direct engagement with the system. They are the least physiologically precise and the most behaviorally rich. A person whose conversational responses have shortened by 40% over three days while her vocabulary complexity has declined and her response latency has increased is showing a pattern. The pattern may reflect fatigue, medication side effects, mood change, or early cognitive decline. The pattern is real. The cause requires clinical interpretation the system does not provide.
Where the fusion happens#
The fusion architecture runs in two stages. The stages map differently to zones depending on the subscriber’s deployment path.
Stage 1 is raw sensor signal processing and local pattern detection. Wearable sensor data (heart rate, accelerometry, blood oxygen saturation, skin temperature) is ingested, cleaned, and processed to produce processed signals: heart rate variability trends, activity classification, sleep stage estimation, anomaly flags. Home sensor data (ambient temperature, motion patterns, mattress signals) is processed similarly.
For subscribers with a Local Pane (Phase 2 onward), Stage 1 runs in Zone 1 on the Local Pane. Raw sensor data never leaves Zone 1. The wearable’s continuous heart rate stream at one-second resolution does not transit beyond the Local Pane. What leaves the home is the derived signal: “heart rate variability declining over the past forty-five minutes, anomaly confidence 0.72,” not the underlying time series that produced the assessment.
For subscribers without a Local Pane, Stage 1 runs in the subscriber’s upstream zone (Zone 2 if she lives in a region with a Community Pane, Zone 3 otherwise). The raw sensor data transmits from the wearable to that zone under the consent the subscriber has granted at onboarding, governed by the DPA for Zone 3 and by BlueMirror’s regional infrastructure controls for Zone 2. The privacy posture for raw sensor data is weaker than the Zone 1 path: the raw signals leave the home. This difference between deployment paths is structural to the architecture, not a footnote.
Stage 2 is cross-domain fusion. The processed signals from Stage 1 are combined with the subscriber’s full MoC context (health records, medication list, activity history, cognitive trajectory) to produce actionable insights. A heart rate variability anomaly in isolation is data. The same anomaly correlated with a recent medication change, a sleep disruption pattern, and a cognitive fluctuation event is a clinical signal worth escalating. Cross-domain fusion is what turns sensor data into care intelligence. The reasoning requires the full MoC and multiple specialized models. It runs in whichever zone holds the subscriber’s full MoC: Zone 2 for subscribers in a region with a Community Pane, Zone 3 otherwise.
At Phase 1, no Zone 1 or Zone 2 deployments exist for any subscriber. Both Stage 1 and Stage 2 run in Zone 3 for every subscriber. Sensor data transmits from the subscriber’s wearable to Zone 3 under the DPA. The Zone 3 provider processes raw sensor data, produces the derived signals, and performs the cross-domain fusion against the MoC context that resides in BlueMirror’s data infrastructure wrapping Zone 3. As Phase 2 brings Zone 1 online for subscribers who acquire a Local Pane, Stage 1 for those subscribers shifts locally and raw sensor data stops transiting to Zone 3. As Phase 3 brings Zone 2 online in served regions, Stage 2 for subscribers in those regions migrates from Zone 3 to Zone 2. For Zone 3-only subscribers in any phase, both stages remain in Zone 3 indefinitely. The fusion logic is identical across paths and phases. What changes is which zone executes the logic and where the raw sensor data travels.
Temporal alignment#
The four data sources operate on different clocks. The wearable streams data at one-second resolution. The home environmental sensors report every ten seconds. Motion detection is event-driven, with no fixed interval. Conversational interaction happens when the person talks to the system, which may be three times a day or thirty.
Temporal alignment is the process of placing all these signals on a single coherent timeline. The architecture uses a four-stage fusion pipeline at the data level: ingestion, normalization, alignment, and synthesis. Ingestion receives raw sensor data in its native format and frequency and happens in the Stage 1 zone (Zone 1 for subscribers with a Local Pane, otherwise the subscriber’s upstream zone). Normalization, in the same zone, converts each stream to a common representation: timestamped observations with a data type, a value, a unit, a source identifier, and a confidence metric derived from the sensor’s known accuracy profile. Alignment places all normalized observations on a single timeline using a sliding window approach: for any given moment, the system assembles the most recent reading from each source category, time-stamped to a common reference clock. Synthesis is the Stage 2 step that combines the aligned observations into composite assessments, applying the conflict resolution rules described below when sources disagree.
Readings within a defined recency window (configurable by data type, typically 30 seconds for physiological data and 5 minutes for environmental data) are treated as contemporaneous. Readings outside the recency window are treated as stale and weighted accordingly. A wearable heart rate reading from 45 seconds ago is usable but carries less weight than a reading from 2 seconds ago. A wearable heart rate reading from 10 minutes ago is marked as outdated and excluded from the current composite unless no more recent source is available.
The challenge is not the alignment itself. Clock synchronization across devices on a local network is a solved problem. The Local Pane maintains a reference clock synchronized to NTP, and all sensor data is timestamped relative to this reference. Sensors that drift (a wearable whose internal clock skews by 200 milliseconds per day) are corrected during normalization. The challenge is what to do with gaps. A wearable that runs out of battery at 2pm stops reporting. The system does not conclude that heart rate became zero at 2pm. It marks the wearable stream as unavailable and increases its reliance on other sources (mattress sensor for overnight heart rate, activity inference from motion sensors) until the wearable stream resumes.
Gap handling follows a principle of graceful degradation. The system’s confidence in its composite picture decreases as data sources become unavailable. A full-sensor deployment with wearable, home sensors, smart devices, and active interaction produces a high-confidence picture. A smartphone-only deployment with no wearable and no home sensors produces a low-confidence picture composed almost entirely of interaction patterns and self-reported information. Both are valid. The system communicates its confidence level internally (to the health concierge, which adjusts its alert thresholds) but does not burden the person with uncertainty metrics. She does not need to know that the system’s sleep quality estimate has a wider confidence interval tonight because her wearable was charging. She needs to know the estimate, and the health concierge needs to know its reliability.
Conflict resolution#
Priya’s heart rate scenario has a clear answer within the architecture. When two physiological sensors disagree, the system applies a resolution hierarchy with three factors: sensor accuracy (calibrated measurement precision for this specific metric), recency (more recent readings preferred, all else equal), and domain relevance (the source most appropriate for this specific measurement type).
For heart rate, the wearable’s photoplethysmography is the primary source during waking hours because it measures continuously and directly. The mattress sensor is the primary source during sleep because the person is stationary, eliminating the motion artifact that degrades wearable accuracy. When both are available simultaneously and disagree beyond a defined tolerance (the difference threshold for heart rate is 8 bpm), the system flags the disagreement, records both values, and uses the source with higher domain relevance for the current context.
The person’s subjective report (“my heart feels like it’s racing”) does not override the sensors. It augments them. The system records the subjective report as a symptom observation and correlates it with the sensor data. If the sensors show 80 bpm and the person reports palpitations, the system notes the discrepancy. Subjective palpitation with normal sensor readings is clinically meaningful. The health concierge surfaces this combination to the person’s data for the next clinical visit, not as a diagnosis but as a documented observation: on March 14 at 3:20pm, the person reported palpitations while sensor-measured heart rate was 80 bpm.
For environmental data, conflict resolution is simpler. Two temperature sensors in the same room should agree within their rated accuracy. If they diverge beyond tolerance, one sensor is likely malfunctioning. The system flags the sensor for calibration check and uses the reading from the sensor with more recent calibration verification.
For behavioral data, conflict resolution introduces a different kind of challenge. Smart home devices indicate the person made coffee at 6:45am. The motion sensor in the kitchen does not show motion until 7:10am. The discrepancy may mean the coffee maker was pre-programmed the night before. The system does not assume malfunction. It considers alternative explanations and flags the discrepancy for correlation with other sources rather than forcing a resolution. Behavioral inference tolerates ambiguity in ways that physiological measurement does not.
What sensor fusion enables#
The value of sensor fusion is not in any individual data stream. It is in the correlations that no single stream can reveal.
Consider a pattern that emerged during the architecture validation: the correlation between bedroom temperature, sleep fragmentation, morning blood pressure, and conversational engagement. A person whose bedroom runs warm (above 72 degrees) sleeps more restlessly (higher movement count, more sleep stage transitions). Restless sleep correlates, for this person, with elevated morning systolic blood pressure (8 to 12 mmHg above her baseline). Elevated morning blood pressure correlates, again for this person, with shorter conversational responses and lower vocabulary diversity in her first interaction of the day.
No single sensor tells this story. The bedroom temperature sensor shows the room is warm. The mattress sensor shows restless sleep. The wearable shows elevated morning blood pressure. The interaction analysis shows reduced engagement. Only the fusion of all four sources, aligned on a timeline, reveals the causal chain. The home environment concierge can then suggest adjusting the bedroom temperature. The health concierge can note the blood pressure pattern for clinical review. The cognitive concierge can adjust its morning interaction complexity to match the person’s current engagement level.
This kind of multi-source correlation is what the architecture was designed to produce. Each individual sensor provides data. Sensor fusion provides understanding. The understanding remains within the system’s monitoring role. It does not cross into diagnosis. It identifies patterns and presents them, to the person and to her clinicians, as observations with temporal context.
Priya’s audit conclusion on sensor fusion was pragmatic. The architecture is well-specified for the sensors it integrates today. The open question is what happens as new sensor types emerge. The fusion framework is extensible by design, with a standardized integration interface for new data sources, but each new source requires its own conflict resolution rules, its own accuracy calibration, and its own privacy classification. The system will grow more capable as it integrates more sensors. Each integration adds complexity. The architecture handles that complexity. The question is whether the build team can validate each new integration quickly enough to keep pace with the sensor market. That is an operational question, not an architectural one.
Cross-References#
BMT-01.12 The Home Environment Concierge. The concierge agent that acts on the environmental patterns sensor fusion reveals, including the bedroom temperature correlation described here.
BMT-06.03 Edge Intelligence. The edge compute architecture that processes sensor data locally, enabling the latency requirements for real-time fusion.
BMT-01.02 The Health Concierge. The concierge agent that uses fused vital signs data for health trend monitoring and clinical data write-back.
Technical Appendix BMT-07.03-A is available to partners and investors at partners.bluemirror.tech.