Balance Meter — Hardware Truth Synthesis¶
Date: 2026-05-04 Author: Gene Lang, Director of Pharmacy Operations · Rx360 Status: Phase 0a deliverable — synthesis of engineering Confluence sources to inform v0.5 spec Sources: Confluence Eng-space exports (downloaded 2026-05-03 to ~/Downloads), filed locally
Purpose¶
This document captures the canonical engineering reality for Mark I and Mark II hardware as it pertains to the Balance Meter feature build. It supersedes any informal product-spec assumptions that conflict with engineering documents. It is not a spec — it is the truth-source layer that v0.5 of the Balance Meter spec must align to.
It exists to prevent v0.5 from re-litigating questions already answered in the Engineering Confluence space.
1. Mark I — confirmed hardware and feature scope¶
Codename: RxSIDEKICK / RxCOMPANION (the wearable band).
Form factor: Wrist-worn band. Voice/audio + haptic + LED visual indicators. No display screen (per Mark II Feature List explicit framing: "voice-only experience, no breakable screens" — this Mark II positioning implies Mark I is also screen-free).
Confirmed sensors and components:
| Component | Status | Source |
|---|---|---|
| LSM6DSV320 6-axis IMU (320 Hz accel + gyro) | ✅ confirmed | Wearable Firmware v0.2 State Machine |
| GPS (GNSS) | ✅ confirmed | Mark I Feature List (RxSIDEKICK group, "Required Hardware: GPS Location Tracking") + Wearable Fall Detection Sensors Overview |
| BLE | ✅ confirmed | Wearable Firmware v0.2 (med nudge phone-BLE write trigger; event codes 0x02/0x03/0x04/0x05/0x06) |
| LTE-M cellular | ✅ confirmed | Wearable Firmware v0.2 (primary SOS path; 10s timeout before NTN fallback) |
| NTN satellite radio (3GPP) — NOT Iridium | ✅ confirmed | Wearable Firmware v0.2 explicit |
| Microphone + speaker | ✅ confirmed | Wearable Firmware v0.2 (audio reminders, configurable intensity) |
| Capacitive touch (AT42QT2030) | ✅ confirmed | Wearable Firmware v0.2 (UI input; medication nudge interaction) |
| Battery + magnetic-puck charging | ✅ confirmed | Wearable Firmware v0.2 + Wearable Indicators and Interactions |
Mark I product feature scope (per Mark I Device Feature List, Confluence):
- RxCOMPANION (the wearable hardware): Med Reminders + Easy-Fit Wristband
- RxCONCIERGE (Schedules & Alerts software): RxScheduler · RxConfirmations · RxAlerts
- RxPASSPORT (medication ledger software): Medication Inventory · Medication Importer (admin photo-of-printed-Rx-list flow) · optional Conditions/Scripts/EHR connectors
- RxCIRCLE (caregiver software): RxCircle Contacts · optional Shared Schedules/Passport
- RxINSIGHTS (reporting software): Dashboard Report summaries · optional Detailed Reporting
- RxSIDEKICK (formerly SOS): GPS Location Tracking + Circle Alert (manual SOS trigger)
Critical: Mark I Feature List has NO fall detection at the product-feature level. This is a load-bearing fact that v0.5 must respect.
Critical: Mark I has NO PPG (heart rate / SpO2). Tier D and Tier E of the v0 Balance Meter framework cannot run on Mark I.
Firmware v0.2 behavior (Mark I):
- IMU fall-candidate detection cascade: free-fall → impact → 1-s observation → still-still → FALL_DETECTED (BLE 0x02)
- 30-s SOS guard window opens after FALL_DETECTED
- NO auto-SOS in v0.2 — manual confirmation required (button press or phone BLE cancel)
- Battery <5% Reservation Mode: SOS path preserved, audio suppressed, low-battery haptic warning
- BLE event-code grammar: 0x02 FALL_DETECTED · 0x03 SOS active cancel · 0x04 button cancel · 0x05 FALL_CANDIDATE (silent) · 0x06 FALL_RECOVERED
2. Mark II — confirmed scope and ecosystem¶
Codename: RxBALANCE (the band) — but Mark II is an ecosystem, not just a band.
The Mark II ecosystem includes four physical products:
- The wearable band (voice-only, no screen)
- Base Station Mark II — interactive screen + AI response window + fingerprint unlock + USB wall plug + non-slip base + night-light LED
- Pill Bottle Confirmation accessory — RFID radio tag reading + camera/OCR fallback + green/red confirmation LED
- Smart Pill Dispenser accessory — content truncated in source doc; full scope TBD
This is a major architectural reframe vs. v0 Balance Meter spec (which treated Mark II as a single device).
NEW features in Mark II band (per Mark II Device Feature List):
- RxASSISTANT (Software): RxAssistant-Chat + RxAssistant-Answers + RxAssistant-Accountability + Pharmacy/Physician Connect
- Two-way Voice/Audio Interactivity from RxCompanion (Hardware/Software)
- RxBALANCE — Fall Detection (Hardware/Software):
- Automatic Emergency Calling For No Response
- Satellite Alert System & GPS Tracking
- 24-7 Monitoring
- Water-resistant and durable construction ("voice-only experience, no breakable screens")
Sensor stack — engineering canonical minimum set for fall detection (per Wearable Fall Detection Sensors Overview):
| Sensor | Role | Spec hints |
|---|---|---|
| 6-axis IMU (accel + gyro) | Primary fall signature; free-fall → impact → stillness state machine | ±16-32g accel range, low noise <150 µg/√Hz, 100-400 Hz, ±2000 dps gyro |
| Barometric pressure sensor | Verifies height loss to floor (~12-25 Pa delta from standing → floor) — disambiguates "sit hard" vs true fall | <1 Pa resolution, 1-5 Hz baseline, burst 10-25 Hz on trigger |
| Wear-detection sensor | On-skin confirmation; suppresses dropped-device false alarms | Optical (single green LED + photodiode) OR capacitive/conductive skin contact pads |
Enhanced set (stricter false-positive suppression):
| Sensor | Role |
|---|---|
| PPG (heart rate) | Post-event physiological corroboration (stress tachycardia or bradycardia raises confidence) |
| Microphone | "I'm okay" voice cancel + 9-intent classification (required anyway for AI voice flow) |
Canonical fall-detection state machine (per same source):
free-fall (IMU) → impact (IMU) → altitude drop (barometer) →
post-impact stillness/orientation (IMU) →
voice prompt (mic + speaker) → intent classification → resolution
This explicitly aligns with the 5/1 overlay's recommendation (threshold + signal-shape + post-event immobility, not threshold-only). Engineering and the UX critique are pointing at the same architecture.
Mark II AI voice flow (per SOS_Fall+Detection+AI+Voice+System doc + the Fall detection use cases@2x.png flowchart):
Fall detected → wearable vibrates →
"It looks like you may have fallen. Did you fall?" →
microphone listens (speech-to-text + intent classification) →
9 intent categories →
resolution logic →
outcome
The 9 intent categories (defining the AI voice classifier's bounded vocabulary):
- Confirm fall ("yes" / "I fell" / "I'm on the floor" / "help" / etc.)
- Deny / cancel ("no" / "I'm okay" / "false alarm")
- Request help (general)
- Request specific named contact ("call my daughter")
- Request emergency services ("call 911")
- Ask question / confused ("what happened?" / "what should I do?")
- Express distress (incomplete utterances, "I'm hurt," panicked tone)
- Ambiguous / unclear (low classifier confidence)
- Silence / no response (no speech, possibly background noise only)
The 5 outcomes: Cancel · Dispatch support circle · Call named contact · Call 911 · Continue escalation · Fail safely
3. Mark I BOM redesign (HW Tiger Team, Feb 2026)¶
Per Mechanical+Impacts+-+Architecture+Options.doc (Approver: Emil Mikhailov; Contributors: Adam Haggett · Wendy Dou · Ricardo Salinas; Due 2026-02-27):
"The current RX360 design does not adequately address all of the PRD requirements and has necessitated a significant change in direction. A HW Tiger Team has been created to best define and complete the design change. The hardware team is investigating the selection of which Satellite Module, MCU/SoC, GPS, and other support chipsets will be used on the RX360 Mark 1. The goal is to freeze the BOM in this weeks Tiger Team efforts ending on 02/27/2026."
Six satellite-module candidates evaluated (final selection lives in Apr-5 Hardware page, not yet downloaded):
- Semtech HL7810
- Quectel BG95-S5
- Murata LBAD0XX1SC
- Iridium 9603N
- Iridium 9604
- U-Blox SARA-S528NM10
PCB area constraint: 628 mm² per side single PCB. Packaging factor ~1.2. Every additional sensor competes for area. This explains why PPG is "Enhanced Set" only — Mark I PCB area is already tight.
Implication: Mark I post-Tiger-Team scope may differ from the (older) Mark I Feature List. Specifically, the Tiger Team appears to have been responding to fall-detection-related PRD requirements ("Mechanical Impacts" = fall mechanics) — which suggests post-Tiger-Team Mark I may include some level of fall-detection signal path that pre-Tiger-Team Mark I lacked.
This is the source of the Mark I Feature List vs. Wearable Indicators and Interactions contradiction.
4. Critical contradiction — fall detection on Mark I¶
| Source | Says | Likely date |
|---|---|---|
Mark I Device Feature List (Confluence) |
NO fall detection on Mark I (RxSIDEKICK is GPS + Circle Alert manual SOS only) | Pre-Tiger-Team (likely 2025 or early 2026) |
Wearable Indicators and Interactions (Confluence) |
"Fall Detection (RxBalance): Simple version (M1), AI version (M2)" | Post-Tiger-Team (likely Mar-Apr 2026) |
Wearable Firmware v0.2 State Machine (Engineering canonical) |
Fall-detection cascade exists in firmware: free-fall → impact → stillness → manual confirmation. "NO auto-SOS in v0.2." | Engineering canonical post-Tiger-Team |
Reading: Mark I post-Tiger-Team likely DOES have a basic fall-detection signal path (firmware v0.2 confirms this — IMU detection logic is present), but it does NOT have auto-SOS escalation. The Wearable Indicators framing of "Simple version M1" probably refers to: IMU detects → user gets a prompt → user manually confirms or cancels → SOS triggered only on manual confirm. Mark II's "AI version" replaces manual confirmation with the 9-intent voice classifier and adds auto-emergency-calling for no-response.
This needs final confirmation from the Apr-28 Engineering Confluence page ("RX360 Band Product Decisions: Button Gestures and LED Behavior" — Emil Mikhailov), which has not been downloaded.
5. Mark II ecosystem — implications for Balance Meter UI¶
The v0 Balance Meter spec assumed two UI surfaces: a wellness view and a clinical view. The Mark II ecosystem creates four potential surfaces, not two:
| Surface | What it shows | Audience | Notes |
|---|---|---|---|
| Band — voice prompts only | Today's band trend if asked verbally | Wearer | "Your balance has been steady this week." Mark II has no screen; visual surfaces live elsewhere. |
| Phone companion app | Full wellness view + clinical view (if pharmacist/researcher) | Wearer + caregiver | Canonical surface for the 3-band display. |
| Caregiver app | Daily digest + push on band-change events | Caregiver only | Already specified in v0; preserved. |
| Base Station Mark II screen ⭐ NEW | Wellness view at home — possibly contextualized ("Today: Steady. Some Change yesterday — likely tied to new metoprolol.") | Wearer at home | Could be primary self-facing surface in domestic context. The fingerprint-unlock requirement makes private data accessible without phone. |
Question for v0.5: Where does the Balance Meter wellness view canonically live, and how do the four surfaces stay in sync? Recommendation: phone app is canonical store-of-truth; band serves voice queries; caregiver app pulls daily digest; base station screen mirrors phone-app wellness view with home-contextual overlays.
6. UX patterns engineering already specifies (and where they conflict with the 5/1 overlay)¶
Per Wearable+Indicators+and+Interactions.doc, the M1 medication reminder pattern is documented as:
| Phase | Audio | Visual | Haptic | Interaction | Time-critical med |
|---|---|---|---|---|---|
| Initial | Beep .5s on/off × 5, rest 25s, repeat 10 min | Solid Light, Rx Brand color, 10 min | Vibrate matching pattern | 1 tap = sleep 5 min · 2 taps = dismiss | If yes, user CANNOT dismiss |
| Grace period | None | Flash .5s on/off, 1 hour | Vibrate every 5 min | (none specified) | If yes, set grace period to 20 minutes |
| Reminder after sleep ends | Same as initial | Same as initial | Same as initial | 1 tap = sleep 5 min · 2 taps = dismiss | If yes, cannot dismiss |
Conflicts directly with the 5/1 overlay:
| Overlay finding | Engineering spec today | Resolution required |
|---|---|---|
| 5-min snooze too short (geriatric workflow is 8-12 min) | M1 spec: 1 tap = sleep 5 min | Engineering must change default to ~10 min, configurable |
| Hostile alert pattern (10 min beeping = #1 abandonment driver) | M1 spec: beep + light + vibrate all run 10 min concurrently | Engineering must implement escalating modalities (haptic-only first 60-90s → visual at 2 min → audio after 3 min) |
| Single-button SOS paradigm with 6 distinct actions creates tremor failures | M1 button = 1 tap / 2 taps / short push / long push + plus interaction-with-AI; SOS specifically shares the same button | Engineering should add dedicated SOS button (recessed, distinct texture) |
| "Time-critical" med flag undefined (who marks it, why 20 min) | M1 spec hard-codes 20-min grace + cannot-dismiss for time-critical | Pharmacist sign-off rule needs definition |
| No "I already took it" gesture | M1 has 1 tap (snooze) + 2 taps (dismiss) only | Need third primitive: "mark taken" |
| No fill-status / sleep / wear gating | M1 spec does not gate on any of these | Engineering needs wear-detection sensor (now confirmed in Mark II minimum BOM — does Mark I have it?) |
The 4-tap NFC scan and "Voice (M2 AI)" primitives are listed but not yet specified in detail.
Mark stages of indicator-types (per indicators doc):
- SOS (RxSidekick): Simple version M1, AI version M2
- Fall Detection (RxBalance): Simple version M1, AI version M2
- AI Assistant: M3 (uncertain — the doc itself flags "is this correct?")
7. Lexicon and regulatory boundaries (already settled)¶
FDA Jan 2026 guidance unlock: Three-band categorical risk-score outputs are now permitted in wellness lane. "Evaluation by HCP may be helpful" is explicitly allowable phrasing. This is the regulatory pathway Balance Meter ships under.
Mandatory rename per Matilda's v1 tech-inputs (4/27): "Fall Barometer" → "Balance Meter." Any artifact still using Fall Barometer is outdated.
Three lexicon fixes from v0 §8.3 mockups (P0 before any external circulation): - "Fall Risk" header → "Balance Meter" - "Frailty" label → "Activity & Endurance" - "Review orthostatic HR" recommendation → Apple-allowable HCP-evaluation phrasing
Apple Walking Steadiness lexicon precedent is the safest banding language. v0 §10.3 recommends "Steady / Some Change / Worth a Look" for the 3-band wellness view. Final wording requires Matilda + legal sign-off.
WHOOP precedent (warning letter Jul 14, 2025) establishes that "medical-grade" / "clinically validated" / similar hedging language alone triggers device classification. Auto-SMS on missed dose is a similar pattern that the 5/1 overlay flagged for removal.
8. RX360 internal AI infrastructure (referenced for Phase 4 engineering handoff)¶
Gene's downloaded set includes 8 docs about the RX360 internal AI agent infrastructure:
Rx360 AI Infrastructure — Architecture(× 2 versions)Decomposer Agent ArchitectureInitializer AgentE2E Autonomous AI Development Pipeline — Quick Start and Pipeline StagesE2E Pipeline Flow — Orchestrator, Agents & DeploymentKnowledge Graph ArchitecturePRD Vector Knowledge Base for AI Agent Context Retrieval
Relevance to Balance Meter: These describe the engineering-internal AI tooling that Phase 4 (engineering ticket carve-up) will leverage. Not directly relevant to v0.5 spec scope, but useful context for who-builds-what when Balance Meter moves into engineering hands. The Rework page (Apr 10, Emil) "Engineering Architecture - AI-Native Software Development at rx360" is the canonical entry point — not yet downloaded but discoverable from Engineering Hub index.
9. What's resolved (closing the v0.5 P0 gates)¶
| v0 §11 P0 question | Resolution |
|---|---|
| PPG on Mark I/II BOM? | Mark I = NO PPG. Mark II = PPG is "Enhanced Set" (valuable but not minimum BOM). v0 Tier D + Tier E weights need recalibration: drop Tier D from Mark I; preserve as optional in Mark II "Enhanced." |
| Lock score-scale option | Recommend Option C (hybrid: numeric clinical view, banded wellness view) per v0 §10.3. |
| Approve Fall Barometer → Balance Meter rename | Matilda already did in v1 tech inputs (4/27). Treat as confirmed. |
| Lock 3 mockup fixes | Engineering-side: Fall Risk → Balance Meter; Frailty → Activity & Endurance; "Review orthostatic HR" → Apple-style HCP-evaluation phrasing. |
| 510(k) lane vs wellness lane | Wellness lane confirmed (Jan 2026 FDA permits 3-band). |
| Apple Watch companion scope | Defer to Pilot 2 (Mark I/II band-only Pilot 1). |
| STEADI-Rx Pilot 1 | Paper form in Phase 0 / Pilot 1; digital integration in Pilot 2. |
| v0.5 NEW questions raised by 5/1 overlay | Resolution |
|---|---|
| Wear-detection sensor on BOM? | YES — confirmed required minimum set on Mark II (optical green LED + photodiode OR capacitive pads). Mark I status: TBD (likely yes post-Tiger-Team). |
| Fall-detection algorithm refinement (threshold + signal-shape + post-event immobility) | Engineering canonical state machine already specifies this exact architecture. v0.5 just needs to reference it. |
| Auto-SOS roadmap | Mark I = manual-only (firmware v0.2). Mark II = "Automatic Emergency Calling For No Response" via AI voice flow + 9-intent classifier. Roadmap clarified. |
| NEW questions from engineering docs that v0.5 must address | Resolution |
|---|---|
| Add barometric pressure sensor to Mark II minimum spec | Engineering already specifies it. v0.5 adds it to Tier A signal stack (height-loss-to-floor). |
| 4 UI surfaces (band-voice / phone / caregiver / Base Station screen) | v0.5 §8 addresses canonical store-of-truth + sync model. |
| 9-intent voice classification for fall response | v0.5 §8.7 documents Mark II AI voice flow + can optionally feed Balance Meter trend context into the post-fall classifier ("balance trending lower this week" raises confidence on confirm-fall intent). |
10. What's still open¶
Highest priority remaining (Gene's task — ~5 min Confluence pull):
- Apr 5 "Hardware" Confluence page (Author: Monika Marko-Holguin) — chip-level BOM for post-Tiger-Team Mark I. Closes the simple-fall-detection-on-Mark-I question definitively.
- Apr 28 "RX360 Band Product Decisions: Button Gestures and LED Behavior" (Author: Emil Mikhailov) — directly addresses overlay's button-paradigm critique. May supersede the Wearable Indicators interaction spec.
Lower-priority remaining:
- Caregiver-as-primary-buyer GTM lock — Peyman + Elliot decision. Field evidence overwhelming; needs formal lock for Pilot 1 onboarding flow + pricing + recruitment.
- Score-scale band-label final wording — Matilda + legal sign-off. v0 §10.3 recommends "Steady / Some Change / Worth a Look."
- FDA AI/Wearables guidance (
FDA-NewAI&WearablesGuidance_MWE011226.pdf) — needs poppler-utils to read; can be deferred or Gene can convert manually. - Smart Pill Dispenser accessory scope —
(B2)doc was truncated; full Mark II ecosystem accessories list incomplete. - Mark III status — referenced in Wearable Indicators ("AI Assistant: M3 — is this correct?") but never defined. Treat as out of scope for Balance Meter; flag for clarification when convenient.
Dependent on engineering follow-up (NOT escalation memo material — these are engineering's normal cadence):
- NTN provider final selection (one of 6 candidates evaluated).
- PCB layout completion under 628 mm²/side constraint.
- v0.3 firmware roadmap (auto-SOS in Mark II).
11. Source files¶
All sources are Confluence MHTML exports (.doc extension, openable via macOS textutil) or PDFs/PNGs, currently in ~/Downloads/. Recommend Gene migrate the load-bearing ones to a tracked 00_Context/_Engineering_Reference/ folder once the worktree merges back to main.
Load-bearing for v0.5: - Mark I Device Feature List (1).doc - Mark II Device Feature List (1).doc - Wearable Fall Detection Sensors Overview.doc - SOS_Fall Detection AI Voice System_ User Intent Handling and Response Flow.doc - Wearable Indicators and Interactions.doc - Mechanical Impacts - Architecture Options.doc - (B1) Base Mark I Feature Overview (1).doc - (B2) Base Mark II Feature Overview (1).doc - Engineering Hub.doc - Fall detection use cases@2x (1).png
Context / referenced: - Rx360 Wearable Experience Spec.doc - Home Dashboard Dynamic Messaging Spec.doc - Support Circle Member PRD.doc - Rx360 Support Circle Multi Profile Switching PRD.doc - Possible Base Station Ecosystem.doc - Base Station for Mark II Use Cases.doc - Balance Meter — Rx360 Mockup wellness.pdf - Balance Meter — Rx360 Mockup clinical.pdf - Balance_Meter_Dashboard_Mockup.html - Rx360 Product Daily Sync notes (Apr 22, 28, 29, 30 — 4/30 transcript empty) - RX360 Design Progress 6.pptx - FDA-NewAI&WearablesGuidance_MWE011226.pdf
AI infrastructure (Phase 4 reference): - Rx360 AI Infrastructure — Architecture.doc (× 2) - Decomposer Agent Architecture.doc - Initializer Agent.doc - E2E Autonomous AI Development Pipeline.doc - E2E Pipeline Flow — Orchestrator, Agents & Deployment.doc - Knowledge Graph Architecture.doc - PRD Vector Knowledge Base for AI Agent Context Retrieval.doc
13. Late-update — Apr 5 Hardware page + Apr 28 Button Gestures page (downloaded 2026-05-04 evening)¶
These two Confluence pages were the highest-priority remaining gaps. Both are now in ~/Downloads/. They confirm and refine the synthesis above; key updates:
13.1 — Mark I chip-level BOM (Apr 5 "Hardware" page, Author: Monika Marko-Holguin)¶
Selected components (highlighted green = post-Tiger-Team final selection):
| Function | Selected part | Notes |
|---|---|---|
| Cellular + Satellite | Nordic nRF9151 | Cellular IoT SoC with optional NTN sat. SoftSIM via monogoto for dev. Replaces the 6-candidate evaluation. |
| MCU | Nordic nRF5340 | Higher-performance Nordic SoC. Plus +1 nRF52840. |
| PMIC | Nordic nPM1300 | Power management. |
| BLE | Integrated into main SoC | Nordic nRF family has BLE. |
| Microphone | Infineon IM72D128 | Selected over TDK ICS-43434. |
| Audio Driver | MAX98357 | Selected over DA7212, MAX98091. |
| IMU | LSM6DSV320 | Matches firmware v0.2 spec. |
| Magnetometer | AKM AK09940A | Selected over MMC5603. |
| Flash | Winbond W25Q256JV | — |
| Capacitive Sensor | AT42QT1010 | Single-channel. Differs from AT42QT2030 referenced in firmware spec — likely simpler revision. |
| Speaker | CMS-150803-088S-X8 | — |
| Haptic | Vybronics VG0415001W-240H | — |
| Battery | 10C rating, 250 mAh single cell | — |
LED hardware (per Hardware page): - 4× WS2812 RGB LEDs (top side) - 2× white LEDs for button SOS state indicator - 1× red LED for Mute - 1× RGB LED for Battery
Critical gap finding — Mark I BOM is missing three sensors that the Mark II minimum fall-detection set requires:
| Sensor | Mark I BOM | Mark II minimum (per Wearable Fall Detection Sensors Overview) | Implication for Balance Meter |
|---|---|---|---|
| Barometric pressure | ❌ NOT on Mark I | ✅ Required minimum | Mark I cannot do height-loss-to-floor verification. Tier A signal stack on Mark I is IMU + magnetometer only. |
| PPG (HR) | ❌ NOT on Mark I | "Enhanced Set" only | Tier D physiologic signals impossible on Mark I — already known. |
| Dedicated wear-detection | ❌ NOT a distinct part on Mark I | ✅ Required minimum (optical green LED + photodiode OR capacitive pads) | Mark I cap sensor (AT42QT1010 single-channel) likely doubles as wrist-on detection for UI input, but is not a formal wear-detection sensor. All alert gates on Mark I therefore lack the foundation the 5/1 overlay flagged as critical. |
The contradiction is now formally resolved: Mark I has fall-detection signal capability (IMU + magnetometer can register impact + orientation change), but Mark I lacks the multi-sensor corroboration (barometer + dedicated wear-detect) that engineering's own canonical state machine requires for productized fall detection. Mark I "Simple version" is therefore IMU-only, manual-confirm, with reduced confidence vs Mark II. Productized Balance Meter as a 3-band wellness score requires Mark II hardware.
This sharpens the "Phase Zero on Mark I" framing: Mark I can run STEADI-Rx + medication-class scoring + IMU motion-tier, but cannot run the full Balance Meter framework. v0.5 must be explicit that Mark I is a constrained subset.
13.2 — Apr 28 Button Gestures and LED Behavior page (Author: Emil Mikhailov; Owners: Jack, Peyman, Faraz)¶
Source of truth: GitHub docs/INTERACTION_MODEL.md (firmware repo). This Confluence page mirrors firmware repo decisions for Product team review and decision-making. Last synced 2026-04-28.
4 gestures + 5 contexts:
| Gesture | Idle | Med nudge | Fall alert | SOS guard | Active SOS |
|---|---|---|---|---|---|
| Short press | Wake / ack | Confirm taken ⭐ | Cancel ("I'm OK") | Confirm escalate | (no-op) |
| Double press | (no-op) | Snooze | Escalate to SOS | (no-op) | (no-op) |
| Long press (3 s) | Trigger SOS | Breaks out → SOS | Breaks out → SOS | (no-op) | Cancel SOS |
| Very long press (10 s) | Factory reset | Same | Same | Same | Same |
12 product decisions Emil is asking for (6 gestures + 6 LEDs). Engineering recommendations included:
| # | Question | Engineering recommendation |
|---|---|---|
| 1 | Tremor tolerance on double press (400 ms reliable under stress?) | Prototype with 3-5 users (overlay's exact concern) |
| 2 | Factory reset: very-long-press vs boot-combo? | Boot-combo for production, very-long for dogfood (overlay's exact recommendation) |
| 3 | Uniform vs context-specific gestures? | Keep 4 gestures uniform for learnability |
| 4 | Triple-press for "non-urgent help"? | Defer to v2 — keep gesture set small |
| 5 | Different haptic per gesture? | Yes — improves learnability |
| 6 | Onboarding (how user learns gestures)? | All three: app tutorial + printed card + in-app cheat sheet |
Major reconciliation with 5/1 overlay: Engineering's button-gesture map already incorporates the overlay's concerns:
| Overlay finding | Apr 28 engineering page |
|---|---|
| "Move factory reset off SOS button — paperclip pinhole or app-only" | Q2 explicitly recommends boot-combo for production |
| "Add 'I already took it' device-side gesture" | Already in gesture map: short press during med nudge = "Confirm taken" ✅ |
| "Voice confirm or any-press-cancels for fall confirmation" | Short press during fall alert = "Cancel (I'm OK)" — addresses cognitive-load concern |
| "Tremor users struggle with double-press / 3-s hold" | Q1 explicitly asks tremor tolerance + Q2 widening to ~600 ms is on the table |
| "Single-button paradigm has 6 distinct actions" | Currently 4 gestures × 5 contexts = up to 20 distinct actions, but most contexts are sparse (no-op cells); learnable map exists |
Resolution: The button-paradigm critique from the 5/1 overlay is largely already engineered for. v0.5 should reference this Apr 28 page as the canonical interaction model rather than re-litigating the gesture set.
Remaining overlay concerns NOT resolved by the gesture map: - Configurable hold-time for tremor users (Q1 still open) - Voice-confirm option as ALTERNATIVE to button-press during fall alert (Mark II AI-voice flow has this; Mark I does not) - Cascading support-circle timing (different layer entirely — escalation logic, not button input) - Fall-detection algorithm: threshold-only vs threshold + signal-shape + post-event immobility (firmware-layer, not button-layer)
LED behavior (truncated in extract): RGBW LED color meaning starting to be defined; full LED state-machine spec not extracted — reread source for v0.5 §8 LED behavior section.
13.3 — Updated implication for v0.5 spec¶
- Mark I scope is sharper than previously stated: Phase Zero on Mark I is paper STEADI-Rx + medication-class scoring + IMU motion-tier signal only. No 3-band consumer wellness output. Mark II is the consumer-output product.
- The button gesture map (Apr 28) is the canonical interaction model. v0.5 §8 references it; does not redefine.
- The 5/1 overlay's button-paradigm critique is ~70% already engineered for. v0.5 §8 captures the remaining 30% (tremor configurability, voice-confirm alternative, escalation timing, fall-algo refinement).
- Time-critical med snooze rule needs clarification with Emil + Jack: Wearable Indicators says "if time-critical, set grace period to 20 minutes" but doesn't define who flags time-critical. v0.5 needs pharmacist-flag rule.
12. Summary in one paragraph¶
Mark I is RxSIDEKICK — a wrist-worn voice/haptic/LED band with IMU + GPS + LTE-M + NTN + BLE + mic/speaker, NO PPG, NO display, manual SOS only, and (post-Tiger-Team) likely a basic IMU-based fall-detection signal path that prompts the user but does not auto-escalate. Mark II is the RxBALANCE ecosystem: same band hardware augmented to "Enhanced Set" with PPG + barometer + wear-detection sensor, paired with a Base Station with interactive screen, a Pill Bottle accessory with RFID/OCR, and a Smart Pill Dispenser. Mark II adds the AI voice flow (9-intent classifier, "Did you fall?" voice prompt, automatic emergency calling on no-response). The canonical fall-detection state machine — free-fall → impact → altitude drop → post-impact stillness → voice prompt → intent classification → resolution — already aligns with the 5/1 overlay's recommendations. Balance Meter v0.5 should declare Mark stage on every tier, drop Tier D from Mark I, add barometer to Tier A, treat the 4-surface UI architecture (band-voice / phone / caregiver / base station) as the canonical sync model, and reference the Apr 28 Button Gestures page (when downloaded) for the lexicon and interaction-grammar canonical answers.