Phase 3 · Edge Cases · Clear Day

When things
don't go to plan.

Three scenarios that happen every week in real homes. Most products leave them undesigned. Reflekt doesn't. Each scenario has a complete conversation script, full screen states for both surfaces, and engineering logic that governs the recovery path.

Design Philosophy for Edge Cases

The recovery is the product. In normal states, every product looks the same. Edge cases are where trust is either built or permanently lost. A senior who feels stupid after Luma mishears will stop talking to it. A family member who gets a false alert and can't figure out what happened will stop trusting real alerts.

Every recovery must feel like a thoughtful friend catching themselves and correcting gracefully — not like a system throwing an error.

S1 · Mishear
Happens daily. Senior speaks, Luma doesn't understand or misunderstands. Three sub-cases. If handled badly, the senior stops using voice entirely.
S2 · False Alert
Most emotionally loaded scenario. Sensor fires incorrectly. Family panicking. Senior confused. Trust with both users on the line simultaneously.
S3 · No Response
Most common "false alarm" in elder care. Senior is fine — visiting family, sleeping in. System must not over-escalate but must not suppress real signals either.
Scenario 1

Luma Mishear Recovery

Luma mishears or misinterprets. The senior must never feel stupid. The recovery must be faster than the original interaction. Three sub-cases, each with a different script and different emotional register.

S1
When Luma doesn't understand, it owns it.
The worst recovery is asking the senior to repeat themselves multiple times, or giving a robotic "I didn't catch that." The best recovery is brief, honest, and gives the senior a clear path forward. Luma never blames the senior.
Stakes: If Luma is difficult to talk to, seniors stop trying. Every awkward recovery accelerates abandonment.
S1-A Total Mishear — Luma heard nothing
Senior
"Luma, remind me to call the doctor tomorrow."
System · ambient noise / quiet voice
Luma detects that someone spoke but cannot parse the content. Confidence score < 0.4.
Luma
"Sorry, Mary — I didn't catch that. Could you say it once more, a little closer?"
One retry request only. Suggests physical fix (move closer), not a cognitive one (speak differently).
Senior repeats
"Remind me to call the doctor tomorrow."
Luma · understood
"Got it — I'll remind you to call the doctor tomorrow morning."
If second attempt also fails
Luma
"I'm having a little trouble hearing today. Your family can set this up for you in the app."
Offers an alternative. Never says "speak louder" — dignity rule. Notifies family that Luma had hearing issues.
Luma Screen · During Recovery
Listening
10:47
Friday · February 27
Sorry, Mary —
I didn't catch that. Could you say it once more, a little closer?
"I'm listening."
Screen shows the request — gives visual confirmation Luma is trying
Only one retry request — never more
"I didn't understand you" — implies fault with senior
"Please speak more clearly" — condescending
S1-B Wrong Interpretation — Luma heard wrong thing
Senior
"Luma, remind me at eleven."
Luma · always repeats back before confirming
"A reminder at eleven o'clock — shall I add that?"
Luma always paraphrases before confirming any action. This is the catch-net for wrong interpretations.
Senior catches the error
"No — eleven-thirty."
Luma
"Eleven-thirty — got it. Shall I add that?"
Senior
"Yes."
Luma
"Done."
The Paraphrase Rule — Non-Negotiable

For any action that creates or modifies a reminder, sends a message, or triggers a system event — Luma always paraphrases before executing.

This single rule catches the majority of misinterpretations before they become mistakes. The paraphrase must be shorter than what the senior said. Never a full echo.

Paraphrase Quality Check
✗ Wrong

"You said: remind me at eleven o'clock. Is that right?"

Full echo + formal phrasing. Sounds robotic, not natural.
✓ Right

"A reminder at eleven — shall I add that?"

Shorter, conversational, easy to correct. Senior just says "no" or states the correction.
S1-C Mid-Sentence Change of Mind
Senior
"Luma, remind me to call — actually, never mind."
Luma
"Of course. I'm here whenever you're ready."
No questions. No "Are you sure?" Just acknowledgement and presence. The senior has the right to change their mind without explanation.
Design Rule · Respecting Autonomy

Seniors change their minds. They trail off. They forget what they were saying. Luma never asks "Are you sure?" or "What did you want to say?" That feels like being watched and judged. Luma simply acknowledges and waits.

Ready
10:47
Friday · February 27
Good morning, Mary.
I'm here whenever you're ready.
"Just say my name."
Screen returns immediately to CALM state. No record of the incomplete request. Senior's dignity is protected.
Engineering Logic · Scenario 1
ASR confidence threshold: < 0.4 → total mishear path · 0.4–0.75 → paraphrase-first path · > 0.75 → paraphrase-first (always) then execute on confirmation
Max retry attempts: 1 retry for total mishear · if second attempt fails → offer family-app alternative · never ask 3+ times
Paraphrase rule: all create/modify/delete actions require paraphrase confirmation before execution — no exceptions
Abandoned utterance detection: "never mind" / "forget it" / "doesn't matter" / trailing silence > 3s after "actually" → cancel, return to CALM, no logging
Mishear logging: repeated mishears (3+ in one session) → flag luma_hearing_issues event → family app quiet notification: "Luma had some difficulty hearing today"
Never log: abandoned utterances, mid-sentence changes of mind. Privacy rule.
Scenario 2

False Alert Recovery

The sensor fires incorrectly. The senior is fine. The family member is already alarmed. This is the most trust-critical moment in the entire product. The recovery has three simultaneous audiences: the senior, the family, and the system itself.

S2
Handled well, trust increases. Handled badly, it's over.
A false alert that resolves cleanly — where the family knows quickly, the senior doesn't feel surveilled, and the system learns from it — can actually increase trust. The family sees: "This system responds. It can be wrong, but it's honest about it and it adapts." That's not a flaw. That's a trustworthy product.
Stakes: One handled false alert can build more trust than ten accurate ones. One badly handled false alert can end the product.
Complete Event Timeline
T+0s · Trigger
Fall sensor fires
fall_detected event generated. System enters ALERT state. Luma immediately asks senior: "Mary, I'm a little worried. Are you okay?"
T+5s · Notification
Family App push sent
"Lily may need attention — possible fall in the living room. We're checking in with her now." Family opens app, sees ALERT state. CTA: "Call Lily directly."
T+12s · Senior responds
Senior confirms she's fine
Senior says "I'm fine" / "I'm okay" / "it was just the sofa cushion." Luma confirms: "Good to hear, Mary. I'll let Lily know you're doing fine."
T+15s · Resolution
Family App updates immediately
App state returns to CALM. One-time resolution message appears. Family receives a clear, honest explanation of what happened and what was done.
T+24h · Learning
Post-event feedback
Family App shows quiet feedback prompt: "Was this alert helpful?" Two options. Data used for system calibration. Never shown during the emergency.
Luma — During ALERT
Checking in
14:30
Friday · February 27
Mary, I'm a little worried.
Are you okay?
"Say 'I'm okay' — or anything at all."
Luma — After Senior Confirms Fine
All well
14:30
Friday · February 27
Good to hear, Mary.
I'll let Lily know you're doing fine.
"I'm here if you need me."
Luma · to senior after resolution
"Good to hear, Mary. I'll let Lily know you're doing fine."
Doesn't apologise — "Sorry for the false alarm" makes the senior feel surveilled. Just moves on warmly.
Family App — Resolution Screen
2:31●●●
Reflekt
J
Resolved
Safe right now
Lily confirmed she's okay at 2:30 PM. The earlier alert has resolved.
2:30 PM · resolved
Alert Resolved
Lily heard Luma checking in and confirmed she's fine. The sensor may have detected a sudden movement nearby. No action needed.
Glad this worked out
We'll keep watching quietly.
Home
Messages
Reminders
Profile
24h Later — Feedback Prompt (quiet)
"Was this alert helpful?"
Yes, useful
Not really
If "Not really" — system shows: "Thank you. We'll learn from this to be quieter next time." Data feeds into false-positive calibration.
Before / After — The Recovery Copy
✗ Wrong — damages trust

"False alarm. The fall detection was incorrect. Please disregard the previous alert."

Clinical, cold, makes family feel the system is unreliable. Offers no context. "Please disregard" sounds like a legal disclaimer.
✓ Right — builds trust

"Lily confirmed she's okay at 2:30 PM. The earlier alert has resolved. The sensor may have detected a sudden movement nearby. No action needed."

Human, specific, explains what happened without technical language. "No action needed" explicitly closes the loop.
Engineering Logic · Scenario 2
Resolution trigger: senior_confirmed_okay event → immediately update app state to CALM · log false_positive_candidate
Resolution copy: always include: confirmed time · "alert has resolved" · neutral explanation of possible cause · "no action needed"
Emotional closure: one-time "Glad this worked out" message → auto-disappears after family member reads it (seen = dismissed)
False positive logging: false_positive { timestamp, trigger_type, resolution_time, confirmed_by: "senior_voice" } — used for sensor calibration
Feedback timing: show feedback prompt minimum 4 hours after resolution, maximum 24 hours. Never during or immediately after the event.
Calibration: 3+ false positives of same type within 7 days → auto-adjust detection threshold for that sensor and that senior
Scenario 3

Extended No-Response Handling

The senior hasn't interacted with Luma for 48–72 hours. Not because of an emergency — they went to stay with their daughter, or they went on a short trip, or they simply ignored the device for a few days. The system must navigate a narrow path: not escalate unnecessarily, but not suppress a real signal either.

S3
The most common "false alarm" in elder care.
Every elder care product struggles with this. The senior is fine — they just went somewhere and didn't tell the system. Over-escalating causes alarm fatigue. Under-responding misses real emergencies. The solution is a staged response that increases gently, uses multiple signals to distinguish "away" from "in trouble", and always keeps the family informed without panicking them.
Stakes: False escalations train families to ignore alerts. But missing a real emergency is unacceptable. The staged response is the only responsible design.
5-Stage Staged Response System
T+4h
Stage 1 · Normal check-in
Luma says morning greeting as normal. No special behaviour. System notes low activity but takes no action. This is within normal variation.
Family App: no change. CALM state.
T+24h
Stage 2 · Gentle direct check-in
Luma says: "Mary, it's been a quiet day. Just checking in — are you doing okay?" Waits 2 hours for any response. Any movement, any voice, any activity resets the counter.
Family App: quiet in-app note only. No push. "Luma checked in with Lily — no response yet."
T+36h
Stage 3 · Family soft notification
Push notification to family: "Luma hasn't heard from Lily since yesterday. She may be away. Worth a quick call when you have a moment." Tone is calm, not alarming. Suggests a simple action.
Family App: REMINDER state. CTA: "Call Lily when you can." No urgency language.
T+48h
Stage 4 · Elevated notification + multi-signal check
System checks all available signals: radar activity, wearable data, door sensors if connected. If any signal shows normal movement → hold at Stage 4. If no signals of life → escalate to Stage 5.
Family App: ALERT state. Push: "We haven't heard from Lily in 48 hours. We recommend calling directly." CTA: "Call Lily directly."
T+72h
Stage 5 · HELP state — full escalation
72 hours of no signals of life across all sensors. System enters HELP state. Persistent push to family. Emergency contacts notified. This stage should be extremely rare if the senior has wearable or other sensors active.
Family App: HELP state. "We have had no sign of life from Lily for 72 hours. Please call immediately or contact a neighbour."
Family App · Stage 3 (T+36h)
11:30●●●
Reflekt
J
Checking in
Worth checking in
Luma hasn't heard from Lily since yesterday. She may just be away.
Yesterday · last contact
Call Lily when you can
No urgency
This could mean she's visiting someone. A quick call is the simplest way to check.
Home
Messages
Reminders
Profile
Family App · Stage 4 (T+48h)
11:30●●●
Reflekt
J
48 hours · No contact
Needs attention
We haven't heard from Lily in 48 hours. We recommend calling directly to check in.
2 days ago · last contact
📞 Call Lily directly
Multi-signal check
Radar shows some movement detected. This reduces concern — she may be home but not interacting with Luma.
Home
Messages
Reminders
Profile
Family App · After Confirmation
11:42●●●
Reflekt
J
Confirmed well
Safe right now
You confirmed Lily is okay. Luma is back to normal monitoring.
Just now
One thing to consider
If Lily plans to be away again, you can let Luma know in the app. It prevents unnecessary check-ins.
Home
Messages
Reminders
Profile
Feature Opportunity — "Away Mode"

After the first S3 event, the resolution screen should offer a simple feature: "If Lily plans to be away again, you can let Luma know." Family taps it → sets a date range → Luma says to the senior: "Mary, I heard you might be away this week. Have a lovely time."

This single feature eliminates most S3 false escalations and makes both the senior and family feel the product understands their real life. Low engineering, high trust payoff.

Engineering Logic · Scenario 3
Activity baseline: build 14-day baseline of normal activity patterns per senior · use this to distinguish unusual inactivity from normal sleep/rest patterns
Stage escalation clock: reset on ANY signal — voice, radar motion, wearable HR, door sensor, app interaction by family. Not just Luma voice interaction.
Stage 3 notification copy: always include "She may just be away" — sets expectation this is likely non-emergency. Reduces panic response.
Stage 4 multi-signal check: aggregate all available sensors before escalating. If radar shows recent movement → hold and note in app. Only escalate to Stage 5 if NO signals of life across ALL sensors.
Away Mode: away_mode_active flag · suppresses Stages 1–3 · still monitors for fall/emergency signals · Luma acknowledges departure and return
Family confirmation: family marks "I've spoken to Mum, she's fine" → resets all counters, returns to CALM, stores confirmed_well event
Universal Principles

What all three scenarios share.

Six rules that govern every edge case in Reflekt. If a new edge case arises that isn't in this document, apply these six rules first.

1 · Own it, don't explain it
When something goes wrong, Luma acknowledges it directly and moves forward. No lengthy system explanations. No blame. "I didn't catch that" — not "The audio recognition module failed to parse your input."
2 · Recover faster than the original interaction
The recovery should take less time than what triggered it. A 10-second interaction gone wrong should recover in 5 seconds. Brevity is dignity.
3 · Never assign fault to the senior
"I didn't hear you" — not "You weren't clear." "I may have been mistaken" — not "The sensor detected a fall." The system is always the one that got it wrong.
4 · Tell the family three things
In any error notification: what happened · what the system did about it · what the family should (or doesn't need to) do. Never just "alert resolved."
5 · Log everything, show only what matters
Every edge case is logged internally for system learning. But only information that requires action is surfaced to users. A false positive logged silently is better than a false positive that creates anxiety.
6 · Leave the door open
After any recovery, Luma ends with a presence statement: "I'm here if you need me." It doesn't apologise. It doesn't dwell. It signals: this is still a safe, available relationship.
Phase 3 complete. What comes next.
Phase 4 · Generative Layer
Onboarding arc with Day 1→7 visual progression and three key designed moments. Memory Prompt feature. The screens that make the product feel alive, not just safe.
Phase 5 · Validation
Testing protocol with 5 family members + 3 seniors. Three measurements: 3-second test, senior comfort score, family anxiety reduction score.