4f076c927d
## M0p1 — Embeddable Runtime Skeleton (329 tests)
- TidalDb with builder(), health_check(), close(), and Drop-based cleanup
- TidalDbBuilder fluent API: ephemeral(), with_data_dir(), wal_dir(), cache_dir()
- Config, StorageMode, ConfigError types; Config(ConfigError) variant on LumenError
- Paths: single source of truth for directory layout (wal, items, users, creators, cache)
- TempTidalHome: test isolation helper gated behind #[cfg(test)] / test-utils feature
- 8 integration tests: tests/sandboxed_storage.rs
## M0p2 — Tooling & Diagnostics (349 tests)
- Workspace root Cargo.toml (members: ["tidal", "tidalctl"])
- tidal/build.rs: BUILD_HASH from GIT_HASH with option_env!() fallback to "dev"
- MetricsState: always-compiled Arc-shared atomics (uptime, health_ok)
- MetricsHandle (metrics feature): hand-rolled TcpListener HTTP, zero new deps
- GET /healthz → {"status":"ok","uptime_secs":N}
- GET /metrics → Prometheus text (tidaldb_uptime_seconds, health_ok, info)
- TidalDbBuilder.enable_metrics(addr) starts background metrics thread
- tidalctl binary: status + paths commands, manual std::env::args() parsing
- 7 metrics integration tests, 9 tidalctl CLI tests
## m1p4 Signal Ledger (in-progress)
- SignalLedger: DashMap<(EntityId, SignalTypeId), EntitySignalEntry>, WAL-first writes
- HotSignalState: #[repr(C, align(64))], lock-free CAS decay, out-of-order handling
- BucketedCounter: 60 per-minute + 168 per-hour circular buffers, trigger-based rotation
- CheckpointMeta + serialize/restore: 983-byte fixed records, atomic WriteBatch
- Property tests: running score matches analytical to 1e-6, decay monotonic, non-negative
- Proptest regression: signals/warm.txt
## Documentation and planning
- ROADMAP: m0p1 COMPLETE (329), m0p2 COMPLETE (349), product track milestones
- PRODUCT_ROADMAP: P0-P4 product milestone track (personal briefing beachhead)
- Milestone planning docs: milestone-0 (phases 1-3), milestone-p (phases 1-5)
- docs/research/tidaldb_tooling_and_diagnostics.md
- ARCHITECTURE.md, CLAUDE.md, VISION.md updates
## Site
- Blog: every-platform-builds-the-same-6-systems.mdx (new)
- Blog: why-tidaldb.mdx (updated)
- next.config.ts, layout.tsx, blog/page.tsx updates
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
260 lines
9.4 KiB
Markdown
260 lines
9.4 KiB
Markdown
# Use Case: Personal Briefing Feed (Knowledge Workers + Consumers)
|
|
|
|
**Date:** 2026-02-21
|
|
**Author:** @tidal-visionary
|
|
**Status:** Proposed beachhead
|
|
|
|
---
|
|
|
|
## 1. One-Line Definition
|
|
|
|
A daily and in-the-moment briefing feed that ranks what matters most for a person right now, adapts immediately to lightweight feedback, and explains why each item is shown.
|
|
|
|
---
|
|
|
|
## 2. The User (Not Developers)
|
|
|
|
### Primary Persona
|
|
|
|
**Information-overloaded decision maker**
|
|
|
|
- Works in product, strategy, operations, media, investing, policy, or as a highly engaged consumer.
|
|
- Consumes content to make decisions, not just to be entertained.
|
|
- Feels overwhelmed by tabs, newsletters, feeds, podcasts, and chatbots.
|
|
- Wants control over what appears (`more`, `less`, `hide`, `mute`) without heavy setup.
|
|
- Expects trust signals and source quality, not clickbait recirculation.
|
|
|
|
### Secondary Persona
|
|
|
|
**Curious consumer with intent**
|
|
|
|
- Follows multiple topics (career, health, finance, AI, hobbies).
|
|
- Wants a short, high-value briefing instead of infinite scroll.
|
|
- Will use the product if value appears on day 1 with minimal configuration.
|
|
|
|
---
|
|
|
|
## 3. User Job To Be Done
|
|
|
|
### Functional Job
|
|
|
|
"Help me understand what matters now in my domains without spending an hour hunting."
|
|
|
|
### Emotional Job
|
|
|
|
"Make me feel informed and in control, not behind and overwhelmed."
|
|
|
|
### Social Job
|
|
|
|
"Help me sound current and prepared in meetings and conversations."
|
|
|
|
---
|
|
|
|
## 4. Two-Sentence Hook
|
|
|
|
Every morning, get a briefing ranked for what actually matters to you right now, with clear "why this" reasons and no endless scrolling.
|
|
Tap `more`, `less`, or `hide` once, and the next refresh immediately adapts so your feed gets smarter in minutes, not weeks.
|
|
|
|
---
|
|
|
|
## 5. End-to-End User Experience
|
|
|
|
### 5.1 Day-0 to Day-1
|
|
|
|
1. User picks 5-10 interests, desired depth, and hard excludes.
|
|
2. User chooses time budget (`5 min`, `10 min`, `20 min`) and preferred formats.
|
|
3. Product delivers first `Today Brief` with 10-20 ranked items.
|
|
4. Each card shows a short explanation:
|
|
- "Trending in your cohort"
|
|
- "Matches your finance + AI priority"
|
|
- "New source for exploration"
|
|
5. User gives 3-5 feedback actions (`more`, `less`, `hide topic`, `mute source`, `save`).
|
|
6. Feed refresh shows immediate adaptation.
|
|
|
|
### 5.2 Daily Loop
|
|
|
|
1. Morning brief arrives via app/email/push.
|
|
2. User scans top cards quickly.
|
|
3. User opens selected cards for deeper summary/source context.
|
|
4. User gives lightweight feedback.
|
|
5. System updates ranking immediately for next retrieval.
|
|
6. Midday and evening updates are optional and scoped by time budget.
|
|
|
|
### 5.3 Session-Aware Interaction
|
|
|
|
1. User asks: "Only show items relevant to this week's strategy memo."
|
|
2. Session context constrains ranking while preserving global user profile.
|
|
3. Session expires or is closed; long-term profile remains stable.
|
|
|
|
---
|
|
|
|
## 6. Pressure Test (From the User Point of View)
|
|
|
|
### 6.1 Test Method
|
|
|
|
Pressure test assumes a skeptical user comparing against current habits:
|
|
|
|
- Existing feeds (X, LinkedIn, YouTube, Reddit, news apps)
|
|
- Newsletters and podcasts
|
|
- General AI assistants
|
|
|
|
The product only wins if the user can feel practical value within 1-3 sessions.
|
|
|
|
### 6.2 Core User Questions and Required Answers
|
|
|
|
| User Question | User Risk | Product Must Prove |
|
|
|---|---|---|
|
|
| "Why not just use my current feeds?" | No reason to switch | Better relevance + less noise + explicit control in one place |
|
|
| "Will this take too much setup?" | Onboarding drop-off | First useful briefing in < 3 minutes |
|
|
| "Can I trust this?" | Wrong or low-quality items | Clear source quality signals + transparent "why this" |
|
|
| "Will it trap me in a bubble?" | Repetitive narrow feed | Enforced diversity + exploration budget |
|
|
| "If I say less of this, does it actually change?" | Learned helplessness | Visible adaptation on next refresh |
|
|
| "Does it respect my time?" | Fatigue and churn | Time-budget mode with 5-minute high-value brief |
|
|
| "Can I safely use this for work decisions?" | Reputation risk | Freshness guarantees, quality gates, and easy source verification |
|
|
| "Is my data private?" | Trust barrier | Explicit controls for retention, session scope, and deletion |
|
|
|
|
### 6.3 Failure Modes That Kill Adoption
|
|
|
|
| Failure Mode | User Reaction | Severity |
|
|
|---|---|---|
|
|
| Feed still noisy after 2 days | "This is another feed app." | Critical |
|
|
| Feedback actions appear ignored | "I have no control." | Critical |
|
|
| Explanations are generic or fake | "This is smoke and mirrors." | High |
|
|
| One source dominates repeatedly | "Biased and boring." | High |
|
|
| Important updates are stale | "I cannot rely on this." | High |
|
|
| Too many notifications | "Annoying, uninstall." | Medium |
|
|
| Onboarding asks too much | "Not worth it." | Medium |
|
|
|
|
### 6.4 Pass Criteria (User-Perceived)
|
|
|
|
1. User can identify at least 3 briefing items as "actually useful" in first session.
|
|
2. User sees obvious feed adaptation after 3 feedback actions.
|
|
3. User can explain why each top card appeared using the provided reason labels.
|
|
4. User does not feel forced to scroll endlessly; time-budget mode feels real.
|
|
5. User returns on Day 2 without a reminder from support or onboarding prompts.
|
|
|
|
---
|
|
|
|
## 7. Why This Beachhead Fits tidalDB
|
|
|
|
This use case directly exercises tidalDB primitives without requiring a broad horizontal platform story on day 1:
|
|
|
|
- **Signals:** real-time positive and negative feedback.
|
|
- **Ranking profiles:** configurable briefing logic by context and time budget.
|
|
- **Diversity:** hard constraints to avoid source/topic over-concentration.
|
|
- **Cohorts:** "trending for people like me" layer.
|
|
- **Sessions:** short-lived task context (memo prep, market scan, exam prep).
|
|
- **Closed feedback loop:** next retrieval reflects feedback immediately.
|
|
|
|
This is materially different from search-first systems and generic chat assistants because ranking quality improves through continuous, explicit user control.
|
|
|
|
---
|
|
|
|
## 8. Product Requirements (User-First)
|
|
|
|
### 8.1 Must-Have V1 Capabilities
|
|
|
|
1. `Today Brief` ranking with clear reasons.
|
|
2. Lightweight controls: `more`, `less`, `hide topic`, `mute source`, `save`.
|
|
3. Immediate feedback reflection on next refresh.
|
|
4. Time-budget view (`5/10/20` minute mode).
|
|
5. Diversity constraints for source and topic spread.
|
|
6. Baseline cohort view: "trending for people like you."
|
|
7. Source transparency and one-tap source access.
|
|
|
|
### 8.2 Should-Have V1.5 Capabilities
|
|
|
|
1. Session-scoped task mode ("for this meeting only").
|
|
2. Morning/midday/evening briefing cadence controls.
|
|
3. Digest email + mobile app parity.
|
|
4. Credibility filters (verified sources, quality thresholds).
|
|
|
|
### 8.3 Explicit Non-Goals for Beachhead
|
|
|
|
1. Building a developer platform first.
|
|
2. Full social graph product.
|
|
3. Monetization optimization surfaces.
|
|
4. End-to-end enterprise admin suite in V1.
|
|
|
|
---
|
|
|
|
## 9. User-Facing Metrics
|
|
|
|
### 9.1 Activation
|
|
|
|
1. First briefing completion rate.
|
|
2. Median time to first "useful item saved."
|
|
3. Feedback action rate in first session.
|
|
|
|
### 9.2 Retention
|
|
|
|
1. D1, D7, D30 return rate.
|
|
2. Average sessions per active day.
|
|
3. Percentage of users using briefing at least 4 days per week.
|
|
|
|
### 9.3 Quality
|
|
|
|
1. "Useful item rate" per session.
|
|
2. Repeated-unwanted-item rate after negative feedback.
|
|
3. Diversity score by source/topic in top 10 results.
|
|
4. Freshness score for time-sensitive domains.
|
|
|
|
### 9.4 Trust
|
|
|
|
1. Explanation usefulness rating.
|
|
2. Source credibility acceptance rate.
|
|
3. Reported "feed felt biased/repetitive" rate.
|
|
|
|
---
|
|
|
|
## 10. Launch Plan (Beachhead Scope)
|
|
|
|
### Phase A: Concierge Pilot (20-50 users)
|
|
|
|
1. Target one segment: strategy/product/analyst professionals.
|
|
2. Run daily brief with strong manual QA on source quality and reasons.
|
|
3. Capture explicit user interview feedback after each week.
|
|
|
|
### Phase B: Productized Beta (200-500 users)
|
|
|
|
1. Self-serve onboarding under 3 minutes.
|
|
2. Reliable immediate feedback loop.
|
|
3. Basic cohort view and time-budget mode.
|
|
|
|
### Phase C: Scaled Consumer Entry
|
|
|
|
1. Multi-domain templates (finance, tech, health, creator economy).
|
|
2. Push/email cadence personalization.
|
|
3. Quality and trust controls as default UX, not advanced settings.
|
|
|
|
---
|
|
|
|
## 11. Strategic Risks and Mitigations
|
|
|
|
| Risk | Impact | Mitigation |
|
|
|---|---|---|
|
|
| Trying to solve too many surfaces at once | Slow execution, weak product feel | Ship one briefing surface first |
|
|
| Over-personalization creates bubble | Reduced discovery trust | Enforce exploration/diversity budgets |
|
|
| Weak source quality gates | Credibility collapse | Add quality floor and transparent sourcing |
|
|
| Slow adaptation to user feedback | Perceived irrelevance | Prioritize immediate write-to-read reflection |
|
|
| Too much AI summary, not enough evidence | Trust erosion | Keep source links and quote-backed rationale visible |
|
|
|
|
---
|
|
|
|
## 12. Kill Criteria (Be Honest Early)
|
|
|
|
Stop or pivot if any of the following remain true after two iteration cycles:
|
|
|
|
1. D7 retention remains below acceptable threshold for target segment.
|
|
2. Users do not perceive adaptation after direct feedback actions.
|
|
3. "Useful item rate" fails to outperform a simple baseline feed.
|
|
4. User interviews repeatedly describe the product as "another noisy feed."
|
|
|
|
---
|
|
|
|
## 13. Decision
|
|
|
|
This is the right forward-looking beachhead for tidalDB if the goal is knowledge workers and consumers rather than developers.
|
|
|
|
It is narrow enough to ship, painful enough to matter, and aligned with tidalDB's actual architectural advantage: real-time, feedback-aware ranking with explicit user control and transparent reasons.
|