8.1 KiB

Raw Permalink Blame History

R14 — Empathic appliances: physiological-state-aware home automation

Status: speculative 10-20y vision note · 2026-05-22

Premise

We already ship a contactless breathing-rate detector (v1/v2 sensing-server, ADR-029 multistatic fusion). Breathing rate is a documented proxy for arousal/stress in clinical studies (e.g. Bernardi 2002, Vlemincx 2013) and predicts user states finer than HRV in low-SNR conditions. Heart rate is captured concurrently.

The 10-20 year question: what happens when every appliance with a CPU and a WiFi radio knows the occupant's physiological baseline + current state, and modulates its behaviour to support the occupant's wellbeing?

The current RuView stack provides the sensing primitives (breathing rate, heart rate, occupancy, motion intensity, RSSI-only counting per R8). What it doesn't yet provide is the intent-action layer — an appliance that says "the occupant has been breathing fast for 8 minutes; their normal baseline is 12 BPM; let me dim the lights and lower the music."

Three concrete vertical sketches

V1 — Stress-responsive lighting (next 5y, technically tractable)

Sensing	Action
Breathing rate 50% above 7-day rolling baseline for >5 min	Lights gently warm-shift (Kelvin: 4000K → 2700K) and dim 10% over 60s
Sustained low motion + low breathing variability (rest state)	Lights stay where they are
Sleep onset detected (motion=null, breathing<10 BPM for >15 min)	Lights fade to 0 over 8 min following standard Philips Hue "wind down" curve

The hard part is not the sensing — it's the personalisation: a 7-day rolling baseline takes a week of continuous occupancy data to calibrate, and per-person baselines vary by ~30%. Solution: federated per-room calibration that learns continuously, with explicit "this is not me" override.

V2 — Adaptive HVAC for thermal-stress envelopes (10y)

Thermal stress affects breathing-rate envelope (>30°C → +20% baseline RR). A learned per-person mapping from (room_temp, humidity, breathing_rate) → "is the occupant uncomfortable?" lets HVAC pre-emptively adjust before the occupant consciously notices. Saves ~15-20% on cooling energy per published HVAC-personalisation studies (Aryal & Becerik-Gerber 2018), while improving comfort.

V3 — Conversational appliances respecting attention state (15y)

A smart speaker that doesn't interrupt when the occupant's breathing pattern shows high cognitive load (focused reading: shallow + regular). The sensing already exists; the appliance integration is the gap.

Honest scope check: this requires that someone publishes both (a) a reliable shallow-breathing-during-focus signature, and (b) a hands-off way for appliances to receive that signal. RuView ships (a)'s building blocks; (b) needs an MCP-style standard which ADR-104 (@ruv/ruview-mcp) is the first step toward.

Required infrastructure (already in repo or close)

Component	Status	Used for
Breathing/heart rate detector	✅ shipped	physiological state signal
Occupancy presence	✅ shipped (`cog-pose-estimation`, `cog-person-count`)	"is anyone there?" gate
Motion intensity score	✅ shipped	activity-state classifier input
Per-room baseline learner	⚠️ partial (RollingP95 in #491 is the closest existing primitive)	personalised normalisation
State-classifier model	❌ not built	maps `(breathing, heart, motion)` → state
MCP appliance API	✅ partial (ADR-104)	hands-off appliance integration
Consent/opt-in machinery	❌ not built	ethical baseline
Override/correction UI	❌ not built	user-in-the-loop

The four ❌/⚠️ items are the actual work for V1 ship-readiness. Roughly 1-2 quarters of dedicated effort, not a research project.

Ethical framework (drafted, not normative)

Empathic appliances raise three explicit consent questions that smart-speaker-vendors so far have not answered well. Any RuView-based empathic-appliance product should commit to all of these in writing:

Opt-in by default. Sensing is on only if the occupant has actively enabled it. Default = off, not buried in settings.
Data stays on-device. The breathing-rate stream is the most invasive biometric in the building. Per-second values must never leave the local appliance/Cognitum Seed. Only aggregate state (e.g. "stressed" / "neutral" / "asleep") may be exposed to integrations, and only via the user's explicit MCP grant.
Override is one tap. A physical "stop sensing now" gesture or button must work without WiFi, without speech, without the cloud. If consent withdraws, sensing pauses for ≥1 hour before re-asking.

These three constraints are surprisingly load-bearing — they rule out the most common smart-home failure modes (always-on listening, cloud-side aggregation, opaque consent flows).

Privacy threat model

Threat	Mitigation
Compromised appliance leaks breathing rate continuously	Per-device sensing is opt-in; appliances default off
MCP API exposes raw signal to integrations	Only aggregate state passes the MCP boundary; raw stays local (ADR-104 §"Output validation")
Adversarial CSI poisoning makes the occupant look stressed/calm against their interest	R7 Stoer-Wagner multi-link consistency detects this
Long-term baseline learning enables individual identification across moves	Baseline is per-installation; no cloud sync; user can wipe at any time
Insurance / employer access to physiological state	Legal/contractual barrier; not solvable purely technically. Surface this explicitly in onboarding
Children / non-consenting cohabitants	Per-occupant opt-in, not per-installation. Use existing pose-based identity primitives (R3/R9/R15) to gate per-person

Honest scope

The clinical literature on breathing-rate-as-stress-proxy is mostly lab-condition adults. Real-home generalisation isn't proven.
We have no per-occupant identity model yet — single-occupant scenarios only until R3/R15 mature.
The "appliance integration" half is mostly out of repo scope; it requires partner appliances that accept ADR-104-style MCP signals.

What this DOES enable

A clear product roadmap from the existing sensing primitives to a shippable category of appliance behavior that doesn't exist in the market today.
A worked ethical framework that's specific enough to commit to in marketing copy.
A mapping of which existing repo components map to which appliance category (V1/V2/V3).

What this DOES NOT enable

Stress detection without breathing-rate signal. Pure CSI motion isn't a reliable stress proxy.
Detection of psychological states that aren't reflected in breathing/heart rate (cognitive fatigue, mood). Those need physiological signals we can't measure passively.

Connection back

R5 (saliency) — empathic appliance state classification will have its own task-specific saliency, different from counting and structure-detection.
R8 (RSSI-only) — V1 lighting only needs breathing rate, which requires CSI. V3 conversational requires the per-subcarrier shape lost in band-mean. R14 is CSI-only, not RSSI-feasible — bounds the rollout to ESP32-S3-class deployments.
R7 (multi-link consistency) — directly relevant to the adversarial-poisoning threat in the privacy table.
ADR-104 (@ruv/ruview-mcp) — the actual hands-off appliance API. Empathic-appliance integrations subscribe via MCP ruview_vitals_subscribe (not yet built; see HORIZON.md deferred list).
ADR-103 (cog-person-count) — the per-room occupancy gate ("only do empathic actions when an occupant is present and consented").

Next ticks

Per-room baseline learner module (extend RollingP95 to cover breathing-rate + heart-rate over 7-day windows).
State-classifier model architecture (3-class: stressed / neutral / asleep — simple MLP over breathing/heart/motion features).
MCP tool ruview_vitals_subscribe — the hands-off integration that lets a partner appliance subscribe to the aggregate state stream.
ADR for the consent-default-off, override-one-tap, no-cloud-sync constraints. Possibly ADR-105.

8.1 KiB Raw Permalink Blame History