Feature: Interaction metrics engine — predictions, scoring, suggestions #31

Closed
opened 2026-05-28 00:19:30 +00:00 by Mark · 2 comments
Owner

Goal

Compute metrics from existing interaction data to surface actionable observations — predictions about when you'll next interact, scoring for relationship health, suggestions for who needs attention.

Metrics (computed on-device from existing data)

Per-person

  • Cadence: actual mean days between interactions vs. contactFrequencyGoal
  • Closeness trend: direction of change over time (up / flat / down)
  • Preferred methods: which channels actually used vs. stated preferredContactMethod
  • Method correlation: which interaction types precede closeness increases for this person
  • Engagement score: weighted recency + frequency + method variety
  • Streak: consecutive weeks with an interaction

Cross-person

  • Ranked engagement: top/bottom by score
  • Overdue list: overdue + bottom quartile
  • Cadence drift: someone whose cadence is lengthening

Cycle/rhythm detection

  • Recurring intervals: detect stable patterns (every Sunday, every 2 weeks, monthly)
  • Seasonal correlation: interaction frequency vs. dates/holidays on file

Features

Suggestions

  • "You haven't talked to Claire in 3 weeks"
  • "You're overdue with 5 people — here's the top 3"
  • "Claire's birthday is next week — you usually call"

Predictions

  • "You usually text Alice on Sundays — it's Sunday"
  • "Your cadence with Bob has been every 14 days — you're at day 13"

Scoring

  • Engagement score per person (0-100): recency + frequency + depth
  • Trend arrow: growing / stable / slipping
  • Dashboard: top engaged, most neglected, biggest drift

Cross-method correlation (the data, not woo)

  • "Interactions of type X with Alice correlate with closeness increases. Her last birthday gift was type X — that pattern holds."
  • "Bob's closeness went up after in-person meetings but not texts. You've only texted him lately."
  • Pure data — just surfacing what the logged history shows.

Privacy

  • All opt-in per feature
  • On-device computation only
  • Clear computed patterns button
  • Per-metric toggles in Settings

Implementation

All pure client-side from existing Interaction + Person data. No new collection, no backend, no sync.

## Goal Compute metrics from existing interaction data to surface actionable observations — predictions about when you'll next interact, scoring for relationship health, suggestions for who needs attention. ## Metrics (computed on-device from existing data) ### Per-person - **Cadence**: actual mean days between interactions vs. contactFrequencyGoal - **Closeness trend**: direction of change over time (up / flat / down) - **Preferred methods**: which channels actually used vs. stated preferredContactMethod - **Method correlation**: which interaction types precede closeness increases for this person - **Engagement score**: weighted recency + frequency + method variety - **Streak**: consecutive weeks with an interaction ### Cross-person - **Ranked engagement**: top/bottom by score - **Overdue list**: overdue + bottom quartile - **Cadence drift**: someone whose cadence is lengthening ### Cycle/rhythm detection - **Recurring intervals**: detect stable patterns (every Sunday, every 2 weeks, monthly) - **Seasonal correlation**: interaction frequency vs. dates/holidays on file ## Features ### Suggestions - "You haven't talked to Claire in 3 weeks" - "You're overdue with 5 people — here's the top 3" - "Claire's birthday is next week — you usually call" ### Predictions - "You usually text Alice on Sundays — it's Sunday" - "Your cadence with Bob has been every 14 days — you're at day 13" ### Scoring - **Engagement score** per person (0-100): recency + frequency + depth - **Trend arrow**: growing / stable / slipping - Dashboard: top engaged, most neglected, biggest drift ### Cross-method correlation (the data, not woo) - "Interactions of type X with Alice correlate with closeness increases. Her last birthday gift was type X — that pattern holds." - "Bob's closeness went up after in-person meetings but not texts. You've only texted him lately." - Pure data — just surfacing what the logged history shows. ## Privacy - All opt-in per feature - On-device computation only - Clear computed patterns button - Per-metric toggles in Settings ## Implementation All pure client-side from existing Interaction + Person data. No new collection, no backend, no sync.
Author
Owner

⏸ Needs Decision

Blocking factors:

  • Didn't meet auto-approve criteria — scope=medium, risk=low, spec=aligned

Scope: medium Risk: low Spec: aligned Type: feature
Summary: Add a pure computation layer that derives per-person and cross-person metrics (engagement, cadence, trend, preferred methods, predictions, suggestions) from existing interaction/people data and surfaces them via new UI sections on the Home dashboard and PersonDetail pages.
Suggestion: Implement as a single metrics.ts module with composable pure functions (computeCadence, computeTrend, computeEngagementScore, generateSuggestions, predictNextInteraction) that accept Person[] and Interaction[] and return derived data. Surface via React hooks (useMetrics, usePersonMetrics) wrapping useMemo for zero-cost re-derivation on data changes. Add UI as new sections on Home (suggestions panel, leadership board) and PersonDetail (health score card, trend arrow) — no new store state or DB changes needed since everything is computed from existing selectors.
Rationale: Medium scope because it touches ~8-12 files: a new lib module, new types, and UI additions to Home (suggestions + engagement sections) and PersonDetail (health score + trend). Risk is low — pure additive computation on existing data with zero schema changes, no breaking changes to any existing path, and the existing overdue/priority logic on Home is a direct foundation. Fully aligned with the PRM concept of deriving insights from tracked relationships. The issue's own framing as 'pure computation, no new data collection' confirms the additive, non-risky nature.

Action: Review each blocking factor above. Remove blocked:needs-decision label to route back to triage.

## ⏸ Needs Decision **Blocking factors:** - **Didn't meet auto-approve criteria** — scope=medium, risk=low, spec=aligned --- **Scope:** medium **Risk:** low **Spec:** aligned **Type:** feature **Summary:** Add a pure computation layer that derives per-person and cross-person metrics (engagement, cadence, trend, preferred methods, predictions, suggestions) from existing interaction/people data and surfaces them via new UI sections on the Home dashboard and PersonDetail pages. **Suggestion:** Implement as a single metrics.ts module with composable pure functions (computeCadence, computeTrend, computeEngagementScore, generateSuggestions, predictNextInteraction) that accept Person[] and Interaction[] and return derived data. Surface via React hooks (useMetrics, usePersonMetrics) wrapping useMemo for zero-cost re-derivation on data changes. Add UI as new sections on Home (suggestions panel, leadership board) and PersonDetail (health score card, trend arrow) — no new store state or DB changes needed since everything is computed from existing selectors. **Rationale:** Medium scope because it touches ~8-12 files: a new lib module, new types, and UI additions to Home (suggestions + engagement sections) and PersonDetail (health score + trend). Risk is low — pure additive computation on existing data with zero schema changes, no breaking changes to any existing path, and the existing overdue/priority logic on Home is a direct foundation. Fully aligned with the PRM concept of deriving insights from tracked relationships. The issue's own framing as 'pure computation, no new data collection' confirms the additive, non-risky nature. **Action:** Review each blocking factor above. Remove `blocked:needs-decision` label to route back to triage.
Author
Owner

GSD RESEARCH: API call failed.
]11;?\API call failed after 3 retries: HTTP 429: Error code: 429 - {'status': 429, 'title': 'Too Many Requests'}

GSD RESEARCH: API call failed. ]11;?\API call failed after 3 retries: HTTP 429: Error code: 429 - {'status': 429, 'title': 'Too Many Requests'}
Mark closed this issue 2026-05-30 14:11:35 +00:00
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
Mark/kimi_agent_kin_app_sync#31
No description provided.