Review 5 of 6: UX, interruption management, explainability

Reviewer lens: what Byron actually sees and feels on his phone. Inputs: docs/PRD-original.md and docs/DESIGN-DRAFT.md (2026-10-03).

Android behaviors that I have not verified on a device are marked [verify] and collected in §S. Do not take them as fact.

TL;DR

1. Annotate mode stays the default, with one change: no annotation for Recognized senders. Annotate only messages from senders who aren't Recognized. The sidecar's note must vanish when the original is read or dismissed. Show a tiny persistent "sidecar active" indicator so "no note" never gets confused with "sidecar dead".
2. Rename "Quiet unknowns" to "Re-ring" mode and ship it only with three failsafes.

• (a) Top contacts are set as Android Priority conversations, so they ring on their own without the sidecar [verify, #1 spike item].
• (b) A watchdog posts a loud alert if the listener has been disconnected for more than 2 minutes.
• (c) Snoozes are always finite. The draft's "cancel" option is never used.

3. Lead the verdict card with a chip plus one plain sentence. The five dimensions go into a four-cell strip (Who / Context / Risk signals / Visibility). Raw numbers sit behind a "Scores" expander. Unknown senders get a grey chip, never amber, and no verdict ever uses the word "spam".
4. "Ask who this is" is the primary action for Unrecognized messages only. Hide it for Likely scam, for tripwires, for short codes and alphanumeric senders, for group threads, and for Cannot assess. Next to it, offer "Wait for them" (a reminder in 2 h). Most real people follow up anyway.
5. Be honest about the value case. Detection will be worse than Google's, and Google-filtered spam is invisible to the sidecar anyway. The sidecar is worth it for five things:

• explanations,
• the expected-senders ledger,
• interruption control,
• reading a preview without sending an RCS read receipt,
• trusting a sender without adding them to Contacts.

Kill criterion: see §7.

---

§1. Re-notify modes: Annotate vs Quiet unknowns

1.1 Failure modes in the draft

1.2 What Android and Google Messages actually let the user configure

• App-level channels. Google Messages exposes its own notification channels in Settings > Apps > Messages > Notifications, for example incoming messages and other categories. Names vary by version [verify on his build]. The user can set a channel to Silent. A third-party app cannot change another app's channels.
• Per-conversation (Android 11+). Long-press a Messages notification, then choose Priority, Default or Silent for that conversation. Android creates a conversation-specific child channel. This works for existing conversations only. A brand-new unknown sender is a brand-new conversation, so there's nothing to pre-set. Conclusion: the user cannot natively say "unknown-sender conversations are silent". That's exactly the gap Re-ring fills.
• Google Messages in-app per-conversation settings. Conversation > Details > Notifications gives a per-thread sound or silence. Same limitation: existing threads only.
• Native unknown-sender filtering. Google Messages has region-gated "unknown senders" or "known / unknown" filtering in some markets [verify whether it exists on his build/region]. If it does, it may do part of Re-ring for free.
• DND. Rules like "allow messages from contacts only" or "priority conversations only" are a zero-code way to quiet unknowns. They're too blunt for all-day use, because they also silence other apps. Recommend them only as a "focus hours" complement.
• Listener APIs that help.
• NotificationListenerService.Ranking.getChannel() and getImportance() (API 26+) tell us the original's channel and importance.
• Ranking.getLastAudiblyAlertedMillis() (API 29+) tells us whether the original actually made a sound. Use this to dedupe F4: if the original alerted within the last ~2 s, don't re-ring.
• Ranking.isConversation() and getConversationShortcutInfo() (API 30+) tell us whether it's a conversation and which shortcut it belongs to.
• snoozeNotification(key, durationMs) and cancelNotification(key) act on the original.
• Do not rely on these. NotificationListenerService.updateNotificationChannel() and getNotificationChannels() can modify another app's channels, but only for listeners with a CompanionDeviceManager association. Getting one for a sideloaded phone-only app is a hack, and Android can close the loophole at any point.

1.3 Recommended design

Mode A: Annotate (default, zero risk to reachability)

• Recognized. Post nothing. Silence is the verdict, and Recognized is the majority of traffic, so this stops it from doubling the shade.
• Every other verdict. Post one silent companion notification (importance LOW, no sound or vibration). It sits in the sidecar's own group, with setSortKey placing it next to Messages where the launcher honours that.
• Lifecycle link (fixes F1). Key every companion by the original sbn.key plus the message timestamp.
• onNotificationRemoved(original): cancel the companion, for any reason. The user read it, replied, swiped it, or it was read on another device.
• Dismissing the companion does not touch the original.
• Thread growth (fixes F6). Dedupe on (conversation key, message timestamp, sender) from android.messages. Classify only the new tail entries. Update the existing companion in place with setOnlyAlertOnce(true) rather than posting a new one.
• Sidecar-active indicator. One ongoing, MIN-importance notification (it collapses to a single line at the bottom of the shade) or a Quick Settings tile showing state. "Message check: on · last saw Messages 4 min ago". If he swipes it away, a Quick Settings tile is the fallback indicator.

Mode B: Re-ring (opt-in, labelled "Quiet unknowns (re-ring)")

Setup is guided, with screenshots, and the sidecar checks every step itself:

1. Mark the top 5 to 15 people as Priority conversations in Android. These ring through Android directly. This is the failsafe that keeps the most important people reachable even when the sidecar is dead. It depends on spike item S1: a Priority conversation must still alert when the parent channel is Silent. If S1 fails, Re-ring is not shippable on that device, and the setup flow must say so.
2. Set the Google Messages incoming channel to Silent. Not Off: messages stay in the shade and on the lock screen, they just don't make a sound.
3. Sidecar routing. It posts on its own per-verdict channels, so Byron tunes alerting with Android's native UI instead of an in-app settings screen.

4. Ring fast (fixes F4). Re-ring decisions come from the deterministic engine only, with a budget under 300 ms from onNotificationPosted. The LLM, if enabled, can update the card afterwards but never gates the ring.
5. Ring the companion, keep the original (fixes F1 in Re-ring). Post the companion as heads-up with setTimeoutAfter(~10 s). It rings, shows the verdict chip, then disappears and leaves the original Messages notification (with its inline reply) as the one shade entry. The verdict stays one tap away in the sidecar app.

Failsafes for F2 (sidecar dead means silent messages):

The residual risk the watchdog can't cover is a force-stopped app: Samsung "deep sleeping", or a user force-stop, which kills alarms too. That's why the Samsung "Never sleeping apps" step in §4 is mandatory for Re-ring and checked at runtime. If the app is not on that list, Re-ring refuses to turn on.

Lock screen (fixes F8): every sidecar notification uses VISIBILITY_PRIVATE with a text-free publicVersion, for example "Message check: Unknown sender". Quoted spans never reach the lock screen.

---

§2. Verdict card: presenting five dimensions without overwhelming

2.1 Principles

• One chip, one sentence, one obvious next step. Everything else is behind a tap.
• Collapse the five dimensions into four plain-language cells. legitimacy_confidence is derived from the others, and showing it next to scam_risk invites the "these should sum to 100" misreading. It appears only in the Scores expander.
• Evidence is quoted, not paraphrased. Every reason code renders the exact span from the message with a highlight, plus the weight direction (raises risk / raises legitimacy / identity).
• Show a counterfactual on every card. "What would change this verdict" is generated deterministically from the decision table, not by the LLM.
• Colour is never the only signal, and Unknown is grey. Amber or yellow for Unknown would bring back "unknown = bad" through the back door.

2.2 The six verdicts: chip, colour, one-line "why" template

The golden case, "Are you working today?", renders as:

UNKNOWN · "Not in contacts. No name, no link, no request. Real people and wrong-number scams both open like this, so I'll watch the next message."

2.3 "What would change this verdict" (deterministic counterfactuals)

2.4 Scores expander

For Byron, who is technical, keep the numbers one tap away:

Scores                         (log-odds view: on)
  identity       12  ##........   UNKNOWN_SENDER (-0.1)
  context         0  ..........   -
  scam_risk      18  ##........   GENERIC_OPENER (+0.4), prior 0.08
  legitimacy     10  #.........   derived: identity + context - risk
  completeness  100  ##########   full text, sender id present
  rule fired:  #6 "otherwise -> Unrecognized"
  engine: deterministic v0.3 · LLM: off · network: none

---

§3. "Ask who this is"

3.1 Draft options (user picks a default; always editable in Google Messages)

1. Neutral (default): "Hi, sorry, I don't have this number saved. Who is this?"
2. Warmer: "Hi! This number isn't in my phone. Who am I talking to?"
3. Business-aware (offered when the text claims an org): "Hi, which company is this from? I'll follow up through your official number."
4. New-number friend (when the text claims a relationship, such as "it's me, new phone"): "Hey, new number? Remind me who this is, and send a quick hello from your old number or email so I know it's you."

Rules every draft follows:

• No name, location, employer or schedule. Never answer the embedded question. "Are you working today?" gets a question back, not "yes".
• No "wrong number". That phrase is exactly the hook a wrong-number / pig-butchering pivot is waiting for.
• No "STOP" in drafts. If a sender is unwanted, that's a block in Google Messages.
• Nothing from the message is echoed back (no links or codes are quoted).
• Drafts 3 and 4 push verification out of band. That's the only verification that actually works.
• Mechanism: ACTION_SENDTO smsto: with sms_body. Google Messages opens an editable compose screen and Byron taps send himself. Per the draft, RemoteInput is never fired.

3.2 When to offer it

Always offer "Wait for them" next to it. It's a sidecar-local reminder: "Remind me in 2 h if they don't say more". Legitimate senders usually follow up with context (a name or a reason) within minutes. The reminder needs no reply, so it confirms nothing.

3.3 The hidden win: read without a read receipt

Opening the thread in Google Messages sends an RCS read receipt (if read receipts are on). That tells a scammer the number is live and someone read the message.

The sidecar card shows the full preview the listener already received, without opening Messages, and the sidecar never fires the "Mark as read" action. Say this on the card for UNKNOWN, CAUTION and SCAM PATTERN: "Read here: the sender won't get a read receipt." [verify: read receipts and typing indicators fire only on open in Messages, not on notification delivery]

---

§4. Onboarding

Target: under 4 minutes, with every step self-verified by the app. No "did you do it?" checkboxes.

4.1 Expected-senders ledger entry: make it 5 seconds

The ledger is the product's main differentiator (draft §B), and it dies if adding an entry feels like a form. Entry points, fastest first:

1. From a card, after the fact: "I was expecting this". One tap adds the sender and entity to the ledger and trusts the thread. This is the highest-volume path.
2. Share sheet: share a booking-confirmation email, calendar invite or screenshot text into the sidecar. A local deterministic parser (brand dictionary plus date words) proposes "FedEx · until Fri" and he confirms with one tap. No network.
3. Quick Settings tile and launcher long-press shortcut "Expecting…" These open a one-line field with type chips: Delivery Appointment Service visit New job/colleague Travel Person.
4. Voice: use the keyboard mic (Gboard / Samsung voice typing) in that one-line field. Don't add our own speech recognizer: it adds no permission, and our app keeps no INTERNET. Be honest that the keyboard's recogniser may use the network, depending on Gboard's offline setting.

Parsing examples. The default expiry is 7 days for deliveries, the event date plus 1 day for appointments, and 30 days for people.

"fedex this week"            -> Delivery · FedEx · expires Sun
"dentist thu bright smile"   -> Appointment · Bright Smile Dental · Thu (+1d)
"carlos building ashford"    -> Person · Carlos · The Ashford · 30d

Ledger entries render as chips on the main screen with a countdown. Swipe to delete. An expired entry fades for a day before it's removed.

---

§5. Feedback UX (low effort)

• No thumbs up/down on every card. Ask only where it helps the model.
• Unknown cards: two notification action buttons, I know them (→ trust sender, optional name, never touches Contacts) and Not wanted (→ local label plus a deep link to block in Messages).
• Caution and scam cards: a single This is real action. It opens the card, asks "Which signal was wrong?" with the reason codes as tappable chips, and records a per-code correction.
• Known and likely-OK cards: a single Something's off action.
• Implicit signals, used carefully. These are weak positive context signals only, never risk reduction:
• He replied in the thread (visible in the MessagingStyle tail).
• He added a contact after the fact.
• He tapped "Open in Messages" and didn't block.
• Undo everywhere. A snackbar for 10 s, and a full undo list in sender history.
• Weekly 30-second review (optional). "6 unknown senders this week." Each one is a swipeable card: right = know them, left = not wanted, up = skip. It runs on demand, never as a notification nag.
• Show the effect. After any correction, show one line: "Future texts from this number start as KNOWN" or "CAUTION weight for PLATFORM_SHIFT reduced for this sender only." That's the explainability promise applied to feedback.

---

§6. Review screen and sender history

The main screen has three zones: "Needs a look", "Expecting", and "Recent". The sender page shows the trajectory as a vertical timeline, so the multi-message pivot (draft §A, the stateful differentiator) is visible:

 +555 0142  (unnamed)                           [ UNKNOWN -> CAUTION ]
 ---------------------------------------------------------------------
  Tue 09:12  UNKNOWN   "Are you working today?"
             GENERIC_OPENER
  Tue 09:40  UNKNOWN   "Sorry wrong number! I'm Amy, nice to meet you"
             WRONG_NUMBER_PIVOT  (+ trajectory: opener -> pivot)
  Tue 10:05  CAUTION   "...chat on [WhatsApp]?"
             PLATFORM_SHIFT      (+ trajectory: 3-step pattern)
 ---------------------------------------------------------------------
  Pattern: opener -> wrong-number pivot -> platform shift
  This sequence is typical of investment/romance scams. Any one
  message alone was not enough.
 ---------------------------------------------------------------------
  [ Block & report in Messages ]  [ I know them ]  [ Forget sender ]

• Message bodies appear only if 7-day body retention is on (draft §G). Otherwise only codes plus the matched spans remain, after the OTP, financial and health scrubbers run.
• "Forget sender" deletes the per-sender state and history. Global "Delete everything" sits in Settings with a 2-step confirmation.
• Filters: verdict, date, "changed verdict", "I corrected".

---

§7. Why install this over Google Messages' built-in protection (honest)

What Google Messages already does better:

• Server-side spam filtering, trained on traffic at a scale a rules engine can't match.
• On-device conversational Scam Detection, which is availability-gated [verify on his Samsung model and region].
• Link warnings and sensitive-content warnings.
• Messages Google files as spam post no notification, so the sidecar never sees them. Recall on novel scams will be worse than Google's. The sidecar should never be sold as a better detector.

What the sidecar does that Google Messages doesn't:

1. Explains. Google says "suspected spam". The sidecar says which words, which domain, which rule, and what would change its mind.
2. The expected-senders ledger. It knows he's expecting FedEx or that Carlos manages his building. Google can't.
3. Treats unknown as unknown, not bad. It quiets unknowns without calling them spam (Re-ring mode), and native Android can't silence "new unknown conversations" at all.
4. Reads without a read receipt. He can triage UNKNOWN and CAUTION without telling the sender the number is live.
5. Trusts senders without polluting Contacts, and keeps an inspectable per-sender history with the trajectory view.
6. Auditable privacy. No INTERNET permission, enforced by the manifest.

Kill criterion (propose to the consolidator): run the Phase 0 probe in shadow for 14 days. If it sees fewer than ~5 unknown-sender, non-short-code messages per week, or Google's own filtering already handles nearly all the scams he gets, the value is too thin. In that case ship only the probe plus the expected-senders card, or stop. Byron should set the actual threshold.

---

§W. Wireframes (ASCII)

W1. Notifications: Annotate mode, Unknown (expanded) under the original

+---------------------------------------------------------------+
| Messages · now                                                |
| (555) 010-0142                                                |
| Are you working today?                                        |
|  [Reply]  [Mark as read]                                      |
+---------------------------------------------------------------+
| Message check · now                                (silent)   |
| [ UNKNOWN ]  (555) 010-0142                                   |
| Not in contacts. No name, no link, no request.                |
| Not enough to judge either way.                               |
|  [Ask who this is]   [I know them]   [Wait 2h]                |
+---------------------------------------------------------------+
 lock screen public version:  "Message check: Unknown sender"

W1b. Re-ring heads-up, Likely legitimate (auto-dismisses after ~10 s)

+---------------------------------------------------------------+
| Message check · now                              (rings)      |
| [ LIKELY OK ]  72789 · "FedEx: your package arrives today..." |
| Short code matches FedEx; you're expecting FedEx (till Sun).  |
+---------------------------------------------------------------+

W1c. Scam pattern (original snoozed 8 h; this card is MIN/silent)

+---------------------------------------------------------------+
| Message check                                                 |
| [ SCAM PATTERN ]  +1 (888) 555-0199                           |
| Link goes to ezdrive-pay.top, not a government domain.        |
|  [See why]   [Block & report in Messages]   [This is real]    |
+---------------------------------------------------------------+

W2. Verdict card (bottom sheet opened by tapping the notification)

+---------------------------------------------------------------+
|  ____                                                         |
| [ CAUTION ]                       +1 (555) 010-0177  · 10:05  |
|                                                               |
| Asks you to continue on WhatsApp: a common scam step.         |
| Could still be real.                                          |
|                                                               |
|  Who        Context      Risk signals     Visibility          |
|  Unknown    None         2 found          Full text           |
|                                                               |
| "Hi it's Amy again :) can we chat on [WhatsApp]? My number    |
|  is [+44 7700 900123]"                                        |
|   ^ highlighted spans = evidence                              |
|                                                               |
| Read here: the sender won't get a read receipt.               |
|                                                               |
| v Why (3)                                                     |
|   ! PLATFORM_SHIFT     "chat on WhatsApp"         raises risk |
|   ! WRONG_NUMBER_PIVOT  earlier: "Sorry wrong number!"  risk  |
|   . UNKNOWN_SENDER     not in contacts        (weak, capped)  |
|                                                               |
| v What would change this                                      |
|   - A payment or code request -> SCAM PATTERN                 |
|   + Nothing in their texts can clear this; verify another way |
|                                                               |
| > Scores (numbers, rule fired, engine version)                |
|                                                               |
| [ Open in Messages ]  [ Block & report in Messages ]          |
| [ This is real ]      [ Sender history ]                      |
+---------------------------------------------------------------+

W3. Main screen

+---------------------------------------------------------------+
| Message check            ( * ) on · last seen Messages 2m ago |
+---------------------------------------------------------------+
| EXPECTING                                         [+ Expecting]|
|  ( Delivery · FedEx · 3d )  ( Appt · Bright Smile · Thu )     |
|  ( Person · Carlos/Ashford · 27d )                            |
+---------------------------------------------------------------+
| NEEDS A LOOK (3)                                              |
|  [ UNKNOWN ]  (555) 010-0142   "Are you working today?"  9:12 |
|  [ CAUTION ]  (555) 010-0177   "chat on WhatsApp?"      10:05 |
|  [ CAN'T SEE ] 72000            preview hidden by Android 10:30|
+---------------------------------------------------------------+
| RECENT                                         filter: all  v |
|  [ SCAM PATTERN ] (888) 555-0199  toll link (snoozed 8h)  8:01 |
|  [ LIKELY OK ]    72789 FedEx     matches Expecting        7:40|
|  (KNOWN messages are not listed unless "show known" is on)    |
+---------------------------------------------------------------+
| [ Review week (6) ]                  [ Settings / Privacy ]   |
+---------------------------------------------------------------+

---

Changes I'd make to DESIGN-DRAFT

§S. Spike items from this review (feed into PRD §6.2)

← Back to the proposal