jordan/tidaldb
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
192c473f55
tidaldb/docs/planning/PRODUCT_ROADMAP.md
jordan 4f076c927d feat: M0p1 runtime skeleton, M0p2 tooling & diagnostics, m1p4 signal ledger 
## 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>
2026-02-20 20:32:00 -07:00

6.6 KiB
Raw Blame History

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/