From 712964441ca589a48c9de38302ccc3f6848ac6ca Mon Sep 17 00:00:00 2001 From: ruv Date: Fri, 22 May 2026 01:17:49 -0400 Subject: [PATCH] =?UTF-8?q?research(R14):=20empathic=20appliances=20?= =?UTF-8?q?=E2=80=94=20vision=20+=20ethical=20framework=20+=20infrastructu?= =?UTF-8?q?re=20gap=20inventory?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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. --- .../R14-empathic-appliances.md | 101 ++++++++++++++++++ docs/research/sota-2026-05-22/ticks/tick-7.md | 34 ++++++ 2 files changed, 135 insertions(+) create mode 100644 docs/research/sota-2026-05-22/R14-empathic-appliances.md create mode 100644 docs/research/sota-2026-05-22/ticks/tick-7.md diff --git a/docs/research/sota-2026-05-22/R14-empathic-appliances.md b/docs/research/sota-2026-05-22/R14-empathic-appliances.md new file mode 100644 index 0000000000..d65a7d70a7 --- /dev/null +++ b/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. diff --git a/docs/research/sota-2026-05-22/ticks/tick-7.md b/docs/research/sota-2026-05-22/ticks/tick-7.md new file mode 100644 index 0000000000..481d718cfd --- /dev/null +++ b/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.