Lifeline

1. Problem Statement

The user maintains ongoing conversations with a small set of important people (spouse, close friends, family) across iMessage, WhatsApp, and email. These threads contain implicit commitments, promises, purchase requests, reading recommendations, and event reminders that get buried in message history and are frequently forgotten.

No existing system does all of the following:

1. Extracts these items automatically from casual conversation — not formal task language
2. Learns what actually matters to this specific user, rather than applying static rules
3. Detects when an item has already been resolved using external data (email, calendar) without requiring manual check-off
4. Presents the result in a UI that adapts to context rather than a fixed dashboard layout

2. Scope

• Initial conversation sources: 5 threads (iMessage, WhatsApp, email), expected to grow
• People: spouse, 2–3 friends, 1 family group — mix of 1:1 and group threads
• Platform: native iPhone app. This is the primary and only client for MVP
• Usage pattern: morning check-in expected daily (ranked briefing), plus ad-hoc opens throughout the day with live state updates

3. Data Sources & Access

4. System Architecture

5. Extraction Pipeline

Input: raw message/email text plus metadata (sender, timestamp, thread ID).

Classification Taxonomy

Output Schema Per Item

{
  "id": "uuid",
  "source": "imessage|whatsapp|gmail",
  "thread_id": "string",
  "person": "string",
  "timestamp": "ISO-8601",
  "type": "purchase|event|promise|followup|reading|question",
  "raw_text": "string",
  "entities": { "item": "string|null", "date": "ISO-8601|null", "link": "string|null" },
  "suggested_action": "string (LLM-generated, e.g. 'Buy the bag by Friday')",
  "suggested_reply": "string|null (LLM-drafted response, optional per user config)",
  "status": "pending|completed|snoozed|dismissed",
  "created_at": "ISO-8601"
}

Re-extraction should run incrementally on new messages only — not re-process full history each time.

6. Importance Ranking / Learning Engine

This is the core differentiator and should be treated as first-class, not a stretch feature.

6.1 Interruption Levels

Modeled on Apple's notification framework:

• Time-Sensitive — hard deadline approaching, dependent actions (e.g., travel booking tied to an event date)
• Active — default level; requires eventual action, no immediate deadline pressure
• Passive — low-stakes, explicitly flexible, or historically low-priority for this sender/type — batched into a collapsed summary rather than surfaced individually

6.2 Signals Feeding the Importance Score

A weighted, multi-signal model — not a single rule:

• Response latency — how fast the user historically responds to this sender / item type
• Action-immediacy signal — acting on an item immediately after it surfaces is a strong positive signal for that sender/type combination going forward
• Sender identity/weight — learned per-person, not hardcoded
• Revisit frequency without action — an item opened repeatedly with no action is a signal, interpreted per Section 6.3
• Time-of-day engagement pattern — see Section 6.4
• Explicit signals — starred/flagged in Gmail, pinned conversation, etc.

6.3 Avoidance vs. Deprioritization

The system must distinguish "the user is avoiding this" from "the user genuinely doesn't care," because they require opposite responses — surface more insistently, versus stop surfacing entirely.

6.4 Time-of-Day Awareness

Circadian/attention research indicates people are more accurate on analytical, novel tasks in mid-morning — and morning check-in is the user's stated primary usage window. Weight the morning briefing toward decision-requiring items (Time-Sensitive, Active); hold Passive items for whenever the user has idle time.

7. Completion Detection Engine

Goal: close the loop without requiring manual mark-done, using Gmail and Calendar as primary evidence.

1. Background job polls Gmail/Calendar for new data
2. For each pending item, attempt to match new data against it (entity match: item name, person, date, amount)
3. High-confidence match (exact product name in a receipt, calendar event confirmed past with no cancellation) → auto-close, notify with a positive message, log which signal closed it
4. Low-confidence match (fuzzy name, ambiguous timing) → do not auto-close; surface as "possible match, confirm?"
5. No signal found → item remains in its current state, subject to re-ranking over time

Manual override is always available. A manual close also feeds the learning engine — it tells the system this item type doesn't reliably produce an external signal, and future similar items should weight manual-confirmation patterns accordingly.

8. UI/UX Requirements

8.1 Presentation Philosophy — Adaptive, Not Fixed

Per Contextual Adaptive Visualization Environment (CAVE) research (Bai, White & Sundaram, 2012): the interface should sense and respond to changes in problem, purpose, and user context rather than presenting one static dashboard layout.

• Grouping and ordering of items changes based on time of day, day of week, and current item mix — five Time-Sensitive items compress everything else; an empty queue shows a genuinely different, quieter state, not an empty dashboard shell
• Level of detail per item adapts to urgency — Time-Sensitive items get full context up front; Passive items collapse into a single summary row
• Layout is system-determined based on context, not manually configured by the user, consistent with CAVE's "sense → analyze → respond" loop

8.2 Core Views

• Today — ranked briefing, grouped by interruption level, Passive items batched
• Threads — per-person view, all pending items from that conversation only
• History — completed items, how each was closed (auto-detected vs. manual), streak/pattern visibility

8.3 Interaction Requirements

• Tap to expand → suggested action, optional drafted reply, and a short "why this is ranked here" explanation — transparency into the learning engine, not a black box
• Mark Done / Snooze actions available per item
• Celebratory, non-intrusive feedback on auto-detected completions

8.4 Notification Model

Modeled on Apple's own approach: interruption levels map directly to push urgency (Time-Sensitive can break through Focus/DND-equivalent states; Passive items never push, they only appear in-app). Batch Passive items into a single periodic summary notification rather than one-per-item.

9. Tech Stack Recommendation

• iOS app: SwiftUI, Core Data or SQLite via GRDB for local storage
• Extraction/classification: Claude API for LLM classification, called from a lightweight backend or via a server-side proxy for API key security
• Backend: minimal service (Python/Node) for OAuth token handling, Gmail/Calendar polling, extraction orchestration, and pushing updates to the device via APNs and sync to local store
• Auth: OAuth 2.0 for Gmail + Google Calendar
• iMessage/WhatsApp ingestion: neither has a public read API on iOS — MVP should support a manual/periodic export-and-import flow rather than assuming live streaming access. This is a real constraint, not a shortcut.

10. Build Milestones

Dependency-ordered, not time-boxed. Each milestone should be independently testable against real (or realistic sample) data before moving to the next.

11. Open Decisions

• Suggested replies: draft actual reply text, action items only, or both — configurable per item type?
• Snooze behavior: fixed re-surface interval, or learned per item?
• Should avoidance-flagged items ever be shown differently in copy/tone, or purely in ranking position?
• Data residency: fully on-device, or an encrypted backend store for cross-device continuity later?

12. Privacy & Security

• Gmail/Calendar access via OAuth only — no credential storage
• Conversation data (iMessage/WhatsApp) stored locally on-device by default
• No data leaves the device except: (a) LLM classification calls — text sent to Claude API, (b) OAuth-scoped reads from Google APIs
• User can purge all extracted data and re-sync from scratch