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>
6.6 KiB
6.6 KiB
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/savecontrols 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/blockitems and creators never leak after write, restart, or replay. - Immediate adaptation is real:
more/less/skip/saveactions 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/