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>
218 lines
6.6 KiB
Markdown
218 lines
6.6 KiB
Markdown
# Product Roadmap: Personal Briefing Feed
|
|
|
|
**Date:** 2026-02-21
|
|
**Owner:** Product track (knowledge workers + consumers)
|
|
**Status:** Draft for execution
|
|
|
|
---
|
|
|
|
## Vision
|
|
|
|
Ship a daily briefing product that helps users identify what matters now, adapt the feed instantly with lightweight feedback, and trust the results enough to return habitually.
|
|
|
|
## Product Thesis
|
|
|
|
People do not need another infinite feed. They need a controllable, high-signal briefing that respects time, explains relevance, and improves immediately from feedback.
|
|
|
|
---
|
|
|
|
## Milestone Summary
|
|
|
|
| # | Name | Proves | Depends On |
|
|
|---|------|--------|------------|
|
|
| P0 | Beachhead Validation | Users care enough to return for a daily briefing | M0 + partial M1 |
|
|
| P1 | Concierge Alpha | Briefing usefulness and immediate adaptation in a narrow segment | M1 + partial M2 |
|
|
| PG1 | Personalization Core Done (Blocking Gate) | Core personalization loop is correct, immediate, and meaningfully better than baseline | P1 + M1/M2/M3 core slices |
|
|
| P2 | Productized Beta | Self-serve onboarding, trust UX, and repeatability without manual curation | M2 + partial M3 |
|
|
| P3 | Public Launch | Reliability, quality floor, and trust controls at public volume | M3 + M5 core + M6 partial |
|
|
| P4 | Scale + Revenue Fit | Sustainable growth and monetization without quality collapse | M6 + M7 |
|
|
|
|
---
|
|
|
|
## Current Status
|
|
|
|
| Phase | Status |
|
|
|-------|--------|
|
|
| p0: Beachhead Validation | NOT STARTED |
|
|
| p1: Concierge Alpha | NOT STARTED |
|
|
| pg1: Personalization Core Done gate | NOT STARTED |
|
|
| p2: Productized Beta | NOT STARTED |
|
|
| p3: Public Launch | NOT STARTED |
|
|
| p4: Scale + Revenue Fit | NOT STARTED |
|
|
|
|
**Current phase:** p0 (Beachhead Validation)
|
|
|
|
---
|
|
|
|
## Milestone P0: Beachhead Validation
|
|
|
|
### Milestone Thesis
|
|
|
|
Validate that a personal briefing feed solves a painful daily job for target users and creates early repeat usage.
|
|
|
|
### Done When
|
|
|
|
- 20-50 users recruited in target segment.
|
|
- Daily briefing prototype used for 2+ weeks.
|
|
- Median user gives at least one feedback action per session.
|
|
- Interview evidence confirms value over baseline feeds.
|
|
- D2 and D7 retention meet agreed threshold.
|
|
|
|
### Phase Plan
|
|
|
|
- Phase 1: Target Segment and Research Ops
|
|
- Phase 2: Concierge Briefing Loop
|
|
- Phase 3: Signal and Retention Evaluation
|
|
|
|
---
|
|
|
|
## Milestone P1: Concierge Alpha
|
|
|
|
### Milestone Thesis
|
|
|
|
Deliver a high-value daily `Today Brief` with transparent reasons and immediate feedback reflection for a narrow cohort.
|
|
|
|
### Done When
|
|
|
|
- Ranked briefing cards with source links and reason labels are live.
|
|
- `more/less/hide/mute/save` controls are available and used.
|
|
- Next refresh visibly reflects negative feedback.
|
|
- Time-budget mode (`5/10/20`) is used by pilot users.
|
|
- Weekly active usage indicates repeated utility.
|
|
|
|
### Phase Plan
|
|
|
|
- Phase 1: Briefing UX and Reason Labels
|
|
- Phase 2: Feedback Controls and Real-Time Adaptation
|
|
- Phase 3: Quality and Diversity Guardrails
|
|
|
|
---
|
|
|
|
## Milestone P2: Productized Beta
|
|
|
|
### Milestone Thesis
|
|
|
|
Turn concierge alpha into a self-serve product with stable onboarding and trust-preserving defaults.
|
|
|
|
### Done When
|
|
|
|
- Onboarding can be completed in under 3 minutes.
|
|
- Cohort layer (`trending for people like you`) is available.
|
|
- Explanations are clear and consistent per card.
|
|
- D7 retention and useful-item rate beat baseline.
|
|
- Manual curation is no longer required for normal operation.
|
|
|
|
### Blocking Prerequisite
|
|
|
|
P2 cannot start until **PG1 Personalization Core Done** passes.
|
|
|
|
### Phase Plan
|
|
|
|
- Phase 1: Self-Serve Onboarding and Profile Bootstrapping
|
|
- Phase 2: Cohort and Context Views
|
|
- Phase 3: Trust Controls and Preference Persistence
|
|
|
|
---
|
|
|
|
## Milestone P3: Public Launch
|
|
|
|
### Milestone Thesis
|
|
|
|
Launch publicly with reliability and trust controls suitable for broader consumer and knowledge-worker usage.
|
|
|
|
### Done When
|
|
|
|
- Reliability and latency SLOs for briefing generation are met.
|
|
- Freshness, duplicate suppression, and source quality floor are enforced.
|
|
- Notification cadence controls prevent fatigue.
|
|
- Product support and incident playbook are active.
|
|
|
|
### Phase Plan
|
|
|
|
- Phase 1: Reliability and SLO Enforcement
|
|
- Phase 2: Operational Quality Controls
|
|
- Phase 3: Launch Readiness and Support Ops
|
|
|
|
---
|
|
|
|
## Milestone P4: Scale + Revenue Fit
|
|
|
|
### Milestone Thesis
|
|
|
|
Scale the product and validate monetization while preserving user trust and briefing quality.
|
|
|
|
### Done When
|
|
|
|
- Monetization model validated.
|
|
- Revenue and quality metrics monitored together.
|
|
- Retention remains stable as volume increases.
|
|
- Next segment expansion is backed by product data.
|
|
|
|
### Phase Plan
|
|
|
|
- Phase 1: Monetization Experiments
|
|
- Phase 2: Quality-Protecting Growth
|
|
- Phase 3: Expansion Strategy
|
|
|
|
---
|
|
|
|
## Milestone PG1: Personalization Core Done (Blocking Gate)
|
|
|
|
### Milestone Thesis
|
|
|
|
Before expanding product breadth, prove the personalization loop is technically correct, immediately responsive, and materially useful to users.
|
|
|
|
### Must Pass (All Required)
|
|
|
|
- **Hard negatives are exact:** `hide/mute/block` items and creators never leak after write, restart, or replay.
|
|
- **Immediate adaptation is real:** `more/less/skip/save` actions change next-refresh ranking within target latency budget.
|
|
- **Replay correctness:** user personalization state (seen-state, preference shifts, relationship weights) rebuilds deterministically from checkpoint + WAL replay.
|
|
- **Quality uplift vs baseline:** useful-item rate and repeated-unwanted-item rate beat a non-personalized baseline feed.
|
|
- **Diversity with personalization:** relevance holds while source/topic domination stays within guardrails.
|
|
|
|
### Why This Gate Exists
|
|
|
|
Without this gate, roadmap execution drifts into breadth (more surfaces, more modes) before the core personalization promise is trustworthy.
|
|
|
|
---
|
|
|
|
## Product Metrics
|
|
|
|
### Activation
|
|
|
|
- First briefing completion rate
|
|
- Time to first useful item saved
|
|
- Feedback action rate in first session
|
|
|
|
### Retention
|
|
|
|
- D1/D7/D30 retention
|
|
- Sessions per active user per week
|
|
- Percentage of users with 4+ briefing days per week
|
|
|
|
### Quality and Trust
|
|
|
|
- Useful-item rate per briefing
|
|
- Repeated-unwanted-item rate after negative feedback
|
|
- Diversity score in top 10 items
|
|
- Explanation usefulness rating
|
|
|
|
---
|
|
|
|
## Dependencies on Engine Track
|
|
|
|
| Product Capability | Primary Engine Dependencies |
|
|
|--------------------|-----------------------------|
|
|
| Real-time adaptation from feedback | M1 Signal Engine, M3 Feedback Loop |
|
|
| Cohort briefing layer | M3 User model, M6 cohort surface support |
|
|
| Search-within-briefing | M5 Hybrid Search |
|
|
| Public reliability | M7 Production Hardening |
|
|
|
|
---
|
|
|
|
## Planning References
|
|
|
|
- Use case: `docs/personal-briefing-beachhead.md`
|
|
- Engine roadmap: `docs/planning/ROADMAP.md`
|
|
- Product milestone execution: `docs/planning/milestone-p/`
|