Skip to content

Jamie — North Star Meeting Prep

Date: 2026-05-12 Audience: Jamie (design + product roadmap) Purpose: Translate the patent team's "build broadly toward the north star" mandate into concrete BOM and feature decisions for Mark I + Mark II, with the 10–20 year track in view. Context: Builds on Jamie's competitor analysis spreadsheet (Competitor Analysis - Features.xlsx) and the product-team feedback Gene gathered from Matilda, Emil, and Peyman.


Frame for the meeting

Two tracks, in parallel. Both have to work:

Track 1 — Wellness now (Mark I + Mark II shipping)

What we ship in the next 12–18 months. Wellness lane. Real device, real patients, real revenue.

Track 2 — Foundation for 10–20 years

What hardware and software choices today preserve our position as AI becomes the front line of senior care. The patent team is filing broadly so claims survive product evolution; the device has to follow the same logic.

Single principle for both tracks: the algorithm is the moat — not the form factor, not any single sensor. Build hardware that feeds the algorithm well today, and don't lock the algorithm to a single hardware configuration.


Track 1: What ships in Mark I and Mark II

Mark I — shippable today (BOM v7 locked, firmware in progress)

What we ship Built on Confidence
Manual satellite SOS nRF9151 + MAX2693L + nRF5340 High — chips locked, firmware in port from DK
Button-press medication confirmation Single button + FRID-aware backend Medium — gated on single-button gesture firmware
Activity + posture summaries IMU low-g High
Gait pattern descriptor (Steady / Some Change) IMU low-g + algorithm Medium — Matilda's sign-off pending
Impact-event detection + auto-escalate to SOS IMU high-g + algorithm Medium — depends on power budget
Reduced-confidence Balance Meter IMU + pharmacy data + risk frameworks Open — Matilda's Mark I version decision pending

External-positioning note [added 2026-06-29]. The two rows above are an internal engineering-confidence view, not the external/pilot story. For any faculty-facing, partner, or shared deliverable: Mark I = manual SOS / Support-Circle alert only; automatic fall DETECTION (impact-event + auto-escalate) is Mark II (RxBALANCE) and is not presented as a Mark I pilot capability. The "Reduced-confidence Balance Meter" is fall-risk (wellness), never fall detection. Cross-ref Fall_Detection_Reconciliation_Brief_2026-06-17.md (firmware detection exists but is Mark II / in validation).

Mark II — full Balance Meter platform

Hardware add Algorithm unlock Strategic priority
Barometer Tier A height-drop verification — cuts false-positive rate sharply Required. Mark II credibility depends on this.
Dedicated wear-detect (optical green LED + photodiode, or capacitive pads) Robust on-wrist gating — eliminates dropped-device false alarms Required. Foundation under every alert.
PPG — standard, NOT Enhanced SKU only Tier D physiologic — HR, HRV, orthostatic response. Apple Watch ships PPG on every model. Required. Don't gate baseline-competitor features behind a premium SKU.
Two-way speaker + mic upgrade Voice-confirmation flow; live-agent monitoring (if/when we partner) Required. Voice is what closes the AI feedback loop.
Skin temperature sensor Trend-based wellness signal (fever, hypothermia, sleep) Recommended. Trend, not absolute — same accuracy logic as Apple Watch ovulation tracking. Matilda's "wrist temp isn't accurate" concern is correct for diagnostic claims, irrelevant for trend signals.
Indoor location (Wi-Fi beaconing or BLE mesh) Recovery of position signal where GPS fails (homes, facilities) Recommended for Mark II evaluation. Connect America's GoSafe 2 has it.
~~ECG single-lead~~ ~~AFib detection~~ Drop. Triggers 510(k). PPG-derived HRV irregularity is the wellness-lane proxy. Apple does the same thing in their "Heart Rate Notifications."
~~NFC~~ ~~Pill-bottle scanning / tap interactions~~ Drop or defer to V3. Tangential to fall use case. Requires partnered pill bottles to be useful.
Dual-carrier radio (OmniSIM) Rural coverage Evaluate with Emil. Real adoption gap in rural markets. nRF9151 compatibility needs verification.

Firmware-only adds (no new hardware)

  • Sleep monitoring — PPG + IMU give respiratory rate + sleep stages
  • Live HR / vitals display in app — PPG hardware already there
  • Battery status visible to caregiver — BLE characteristic, low effort
  • HRV irregularity proxy for AFib-adjacent wellness — surface in app without diagnostic language

Service / partnership decisions (NOT hardware, but shape it)

  • 24/7 professional monitoring center — #1 purchase driver per Jamie's research; without it, we're not competitive against PERS incumbents for the core demo
  • Direct 911 auto-dispatch — requires monitoring partnership
  • US-based, multilingual monitoring — partnership requirement

These are Peyman + Elliot decisions, not Jamie's, but they influence hardware (especially the speaker/mic spec for live-agent conversations).


Track 2: Foundation for the 10–20 year game

The patent team is filing broadly. The hardware should follow.

Horizon What changes in the environment What our hardware needs to enable
Today → 2 yr AI agents start handling routine senior-care workflows. Voice interfaces ubiquitous. Onboard voice ready (Mark II speaker + mic). Voice-driven event labeling for the AI feedback loop.
3 – 5 yr LLM-powered pharmacist assistants. EHR integration mainstream. Per-user models dominate. API-first architecture. Per-device per-user calibration data. Clean integration points for EHR / FHIR.
5 – 10 yr Agentic AI coordinates routine care across the senior population. Closed-loop interventions. Always-on event labeling. Multi-modal context (motion + meds + voice + environment). Algorithm independence from any single sensor.
10 – 20 yr Wearables go invisible. Sensors woven into clothing, ambient in homes. Rx360 = canonical fall signal upstream of care plans. Form-factor independence. Algorithm-as-a-service. Sensor diversification (wrist, clothing, ambient).

What this means for Mark II hardware decisions today:

  1. Voice + mic spec matters more than it seems. It's not just SOS; it's the labeling engine for the AI feedback loop. Spec for clarity at conversational distance.

  2. Per-user calibration data is the long-term moat. Hardware should support continuous, low-friction baselining (always-on sensors with smart power management).

  3. Don't over-fit to wrist. Patents are being drafted to cover "wearable surface" broadly. The hardware should be modular enough that a Mark III could be neck-worn or clothing-integrated without breaking the algorithm.

  4. Cellular + satellite + BLE + Wi-Fi indoor = the connectivity stack we want long-term. Single-carrier is fine for V1; dual-carrier OmniSIM is right for rural Mark II; indoor location for V2.5 / Mark II Plus.


Decisions Jamie needs to make for her roadmap

Hardware BOM decisions (with my recommendations)

Decision My recommendation Whose buy-in needed
Skin temp on Mark II BOM? Yes. Trend-based wellness signal. ~$8 BOM cost. Matilda (clinical), Emil (power + integration)
PPG standard vs Enhanced SKU? Standard. Don't gate baseline features. Elliot (SKU strategy), Emil (cost), Matilda (clinical)
ECG single-lead? No. 510(k) trigger. PPG HRV proxy instead. Peyman (regulatory)
NFC? Defer to V3. Tangential to fall mission. Elliot (product strategy)
Dual-carrier radio? Evaluate Mark II Plus / V2.5. Emil (modem compatibility), Elliot (target market)
Indoor location? Evaluate Mark II / V2.5. Emil (sensor cost), Patrice (facility ops use case)
Dedicated wear-detect type — optical or capacitive pads? Optical (shares hardware with PPG). Emil (hardware integration)
Two-way speaker + mic — upgrade spec? Yes — conversational-quality (16 kHz already on Mark I, but mic quality and speaker placement need design pass). Emil (engineering), Jamie (industrial design)

SKU strategy

If we drop ECG and put PPG standard, the Enhanced SKU still has a purpose: - Standard Mark II: IMU + barometer + wear-detect + PPG + skin temp + indoor location + dual-carrier - Enhanced SKU (premium): add VO2max capability (extended PPG), advanced sleep analytics, or partner integrations (Apple HealthKit deep sync)

This is more honest than gating the baseline PPG behind a tier.

Industrial design considerations (Jamie's primary lane)

Element Implication
Single button on Mark I Long-press SOS / single-press confirm. Industrial design must communicate which is which (color ring? haptic pattern?).
Two-way voice Speaker + mic placement is acoustic engineering. Need clarity at arm's length without flooding wearer's ear.
Wear-detect upgrade Sensor placement on the underside of the band. Visible green LED ring when active (Apple-style).
Form factor for older adults Larger touch targets. High-contrast display. Easy-to-press button. Cellular antenna doesn't degrade with sleeve coverage.

Open contradictions in the spreadsheet to reconcile

Three things in Jamie's analysis that I'd ask her to clarify before locking the V2 list:

  1. "Automatic fall detection ✓ V1" vs "Two-way voice on device V2" — fall detection that escalates needs voice. Pick one. (My read: voice is V1 if fall detection is V1.)

  2. "IMU V2" in the Feature Comparison — the IMU chip is on Mark I BOM v7 today. What's V2 is the derived features (gait, trunk sway), not the hardware. Rename to "Gait + trunk sway analytics V2."

  3. "Capacitive touch sensor ✓ V1" — this is the Mark I UI cap-touch, not the dedicated wear-detect Matilda spec'd for Mark II. Two different things. Rename or split.


Tasking — who does what

Task Owner Notes
Drug-class mapping expansion + anchor-site validation Gene + product team scope and build; Matilda validates The Rx360 Medication Risk Database v1 already exists (07_Research_Data/Rx360_Medication_Risk_Database_v1.xlsx) — 122 drugs across 63 classes with Beers / STOPP / ACB / DBI / FORTA / FRID / Fall Risk OR all mapped. Work to do: expand from 122 → 500–700 drugs to cover what the anchor site dispenses, fill NDC examples, validate every dispensed drug has a mapping.
Single-button gesture firmware migration Emil Gates med-confirm + SOS + cancel distinct flows on Mark I
Power-domain management firmware Emil Gates any battery-life claim
Mark II BOM updates (skin temp, PPG standard, etc.) Emil + Jamie After this meeting
Voice + mic spec for Mark II Emil + Jamie Industrial design + acoustic engineering
Pharmacist queue view design Jamie + Jack (visual) + Patrice (workflow) Demo has the first cut
Wellness-lane copy / lexicon Ryan + Peyman Existing Wellness Lexicon v1
24/7 monitoring center partnership Peyman + Elliot Largest non-hardware gap
Patent claim scoping Patent team + Gene relay "Build broadly" mandate

  1. Reconcile the three contradictions (10 min) — IMU V1/V2, cap-touch vs wear-detect, voice V1/V2 — these matter for the BOM doc clarity.
  2. Walk the BOM recommendations (15 min) — skin temp YES, PPG standard YES, ECG NO, NFC DEFER, dual-carrier EVALUATE.
  3. Lock the SKU strategy (10 min) — Standard vs Enhanced — what differentiates them.
  4. Industrial-design open items (10 min) — single button, speaker/mic, wear-detect ring.
  5. 10–20 year foundation check (5 min) — does the BOM lock anything that limits the long-game? (Form factor, sensor placement, antenna design.)

Deliverable from the meeting

A locked Mark II BOM proposal that Jamie can hand to Emil. Format: same column as her current spreadsheet, with the V1/V2 split clean and SKU strategy explicit. One-page summary on top, BOM detail below.


What to send to Jamie before the meeting

  • This brief
  • Link to the demo (so she can walk Matilda + Patrice's view)
  • A heads-up that Matilda + Patrice are meeting separately to lock the algorithm side

What to walk out with

  • [ ] Reconciled V1/V2 designations on the contested rows
  • [ ] Mark II BOM proposal (skin temp, PPG-standard, ECG-no, NFC-defer)
  • [ ] SKU strategy (Standard / Enhanced — what's different)
  • [ ] Industrial-design priorities for Mark II
  • [ ] Dependency map (which Mark II features need Emil's firmware work first)
  • [ ] Decision on indoor location + dual-carrier — evaluate now or V2.5 / Mark II Plus