Skip to content

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

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
ruvnet merged 1 commit into from
May 22, 2026
+135 −0
Merged

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

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
101 changes: 101 additions & 0 deletions docs/research/sota-2026-05-22/R14-empathic-appliances.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -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.
34 changes: 34 additions & 0 deletions docs/research/sota-2026-05-22/ticks/tick-7.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -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.
Loading