Recommendation rollout: current candidate
The candidate is PR 188, based on production commit 04608342c95abcb35c4903467e36f1c9d30797d1. Deployment and reader-quality evidence are separate: a reliable feed does not establish better recommendations.
The public application's new discovery, measurement and personalization flags remain off during these tests. This document describes the candidate and rollout, not a claim that readers already receive the new experience.
Intended reader experience
Discover finds stories the reader has not saved or started. A save or start removes that story family from future discovery results, including its language variants; Library is the place to return to it. Optional interest choices can help the first session, and skipping them must leave a usable feed.
Recommendations should combine story content with observed reading preferences, then reserve room for varied and unfamiliar choices. A single click is weak evidence. Sustained reading, returning to a story and deliberate saves provide different signals; none establishes a fixed personality trait with certainty.
Scrolling must continue while eligible unseen stories remain, even when the initial related-story candidate pool is exhausted. A finite catalog cannot supply infinitely many unique stories. Exhaustion should be explicit; repeating cards or silently returning saved stories would violate this product contract.
Current evidence
| Area | Established | Still required |
|---|---|---|
| Feed correctness | Real traversal across 713 families, full-hour expiry, session-slot recovery, feature-switch redeployment and independent cleanup; saved-family exclusion in the earlier run | Production capacity and private-cohort validation |
| Integrated source | Hosted build/typecheck, focused server/client checks, Linux Redis/warehouse CI, and serialized open-source tests pass | Preserve exact source/evidence identities through rollout |
| ClickHouse connection | Both tables replicate; canonical consumer view repaired; scheduled two-event capture, pruning, erasure and 21 report publications passed; independent current-state reconciliation passed | Sustained capture, completeness and latency remain unproved; the interrupted deployment trial remains failed |
| Session capacity | Admission bounds and small isolated deployment behavior | Production workload, memory and database interference at each proposed rollout size |
| Rich content ranking | Offline evaluation implemented and run | Better results before promotion; the tested rich candidate remains disabled |
| Low-latency streaming capture | Design reviewed for native ClickHouse materialized views plus repair | Implementation, scoped permissions, failure/resync recovery and measured capacity |
The integrated runtime at 4c0888f27ccf8bf51606b3e7dfdb068b943c90e3 includes production release PR 190. Local hosted build (five tasks), typecheck (eight tasks), and the added release-compatibility test passed. Both complete CI workflows passed: discovery and warehouse verification and open-source export. The deployed worker trial used the earlier immutable runtime 91e27378; the merge changes only three game-control/NPC files and does not change discovery code.
The content-ranking comparison used 60 stories, evaluated across 32 query/language observations from eight intents. NDCG was 0.643 for the baseline, 0.539 for the rich candidate and 0.618 for the tested fusion. These results do not support replacing the baseline. The separate frozen holdout must remain untouched until a candidate and its evaluation procedure are fixed.
Existing services and next rollout steps
PostgreSQL keeps authoritative stories, library state and operational event records. Redis keeps short-lived feed sessions and coordinates workers. ClickHouse keeps durable activity history for analysis and training. Content representations describe narrative features; behavior supplies evidence about which features and combinations readers actually prefer. Ranking and controlled exploration turn those inputs into an ordered feed.
No additional subscription is needed for the current validation steps. The proposed streaming archive uses the existing ClickHouse service. A separate queue or other new service should follow a measured recovery/capacity need.
With session lifecycle/rollback evidence and the bounded capture/state checks complete, the next step is a capped private feed pilot. Measurement remains off in that first pilot; enabling activity capture is a separate step. Broader capture needs a validated ingestion envelope. Any ranking change needs an offline improvement followed by a reader experiment with discovery, reading satisfaction, variety and reliability guardrails.
The initial feed pilot uses the owner's confirmed vivi22 and official yumina accounts, zero-percent public rollout and the existing dedicated Redis service. It caps stored visits at 16, with two per account or guest, and caps each application process at four feed requests in flight, including at most two fresh visits. Session encoding remains raw. Experimental personalization, interest onboarding, measurement and analytics readiness remain off. These are the previously proposed private-test bounds, not measured production capacity. Existing feed logging and hub_serve telemetry continue; measurement off refers to canonical discovery-event capture. The account identities are resolved to their existing internal IDs. Activation remains pending deployment verification; no password or new subscription is required.
The streaming-capture plan is a proposal, not implemented functionality or verified capacity. Its larger volume gates apply to that implementation; they do not block the separate tiny synthetic worker trial.
Detailed evidence is recorded in the ClickPipe report, earlier controlled deployment, current lifecycle protocol, and scheduled worker trial.