research(R14): empathic appliances — vision + ethical framework + infrastructure gap inventory (#709)

Speculative 10-20y vision thread covering three concrete vertical sketches:

* V1 stress-responsive lighting (5y) — breathing-rate baseline + warm-shift lights
* V2 adaptive HVAC for thermal-stress envelopes (10y) — published HVAC-personalisation 15-20% energy savings
* V3 conversational appliances respecting attention state (15y) — don't interrupt during focused work

Maps existing RuView components to each: 5 already shipped (breathing rate
detector, occupancy gates via cog-pose / cog-count, motion intensity, partial
RollingP95 baseline learner, MCP API via ADR-104), 4 still to build (full per-room
baseline learner, state classifier model, MCP vitals subscribe tool, consent UI).

Ethical framework drafted as binding constraints any product must honour:
1. Opt-in by default — sensing on only after active enable
2. Data stays on-device — per-second values never cross the building boundary
3. Override is one tap — physical kill switch must work without WiFi/cloud

6-row privacy threat model with mitigations: compromised appliance, MCP raw-signal
leak, adversarial poisoning (mitigated by R7 multi-link consistency), long-term
re-identification, insurance/employer access, non-consenting cohabitants.

Honest scope: clinical breathing-rate-as-stress literature is lab-condition adults;
real-home generalisation unproven. R14 is CSI-only (RSSI loses the per-subcarrier
shape needed for shallow-breathing-during-focus signature), bounds rollout to
ESP32-S3-class deployments.

Connections established to R5, R7, R8, ADR-103, ADR-104. Identifies ruview_vitals_subscribe
as the highest-leverage next MCP tool addition.

Coordination: ticks/tick-7.md, no PROGRESS.md touch.

docs/research/sota-2026-05-22/R14-empathic-appliances.md

@@ -0,0 +1,101 @@
+# 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:
+
+1. **Opt-in by default.** Sensing is on only if the occupant has actively enabled it. Default = off, not buried in settings.
+2. **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.
+3. **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.

docs/research/sota-2026-05-22/ticks/tick-7.md

@@ -0,0 +1,34 @@
+# Tick 7 — 2026-05-22 05:14 UTC
+
+**Thread:** R14 (empathic appliances)
+**Verdict:** Speculative 10-20y vision note with concrete vertical sketches, ethical framework, privacy threat model, and infrastructure-gap inventory.
+
+## What shipped
+
+- `docs/research/sota-2026-05-22/R14-empathic-appliances.md` — research note covering:
+  - Three concrete vertical sketches (stress-responsive lighting / adaptive HVAC / attention-respecting conversational appliances) with timelines (5y / 10y / 15y).
+  - **Infrastructure inventory** — which existing RuView components map to which empathic-appliance category. 5 ✅ in-repo, 4 ⚠️/❌ to-build.
+  - Ethical framework (opt-in-by-default, data-stays-on-device, override-one-tap) committed in writing as constraints any product must honour.
+  - 6-row privacy threat model with concrete mitigations.
+  - Honest scope: lab-condition literature doesn't validate real-home generalisation; no per-occupant identity yet; appliance integration half is out of repo scope.
+
+## Why this matters for the loop
+
+R14 is the **first explicitly speculative** vision thread (R5/R7/R8/R9/R10/R12 were all experimental or physics). It catalogues the **product-level surface area** for the longest-horizon items, which informs:
+
+- Which sensing primitives we should invest in next (per-room baseline learner is the clearest gap).
+- Which ADRs to write next (consent/override is a separate ADR — possibly ADR-105).
+- Which MCP tools to add to `@ruv/ruview-mcp` (the deferred `ruview_vitals_subscribe` is now the highest-leverage next addition per ADR-104 + R14).
+
+## Connections established
+
+- R14 explicitly cross-links to R5 (saliency is task-specific), R8 (CSI required, not RSSI), R7 (adversarial poisoning defence), ADR-104 (hands-off appliance API surface), ADR-103 (per-room occupancy gate).
+- The infrastructure-gap inventory (5 in-repo, 4 to-build) is a useful artefact for any future product roadmap discussion.
+
+## Coordination
+
+`ticks/tick-7.md` convention. No PROGRESS.md touch.
+
+## Major notes from prior tick
+
+R10 (PR not auto-created due to bash flow issue) ended up committed directly to main and pushed in this tick. Future-tick reminder: always check `git branch --show-current` before `git commit`. The cron prompt assumes branch hygiene that the bash plumbing sometimes breaks under back-to-back tick pressure.