Revisit cached-first burst + shared caption-availability if cross-user overlap grows (ADR-028/ADR-024) #14

Open
opened 2026-06-11 17:56:13 +00:00 by mathias · 0 comments
Owner

ADR-028 rejected cached-transcript-first burst selection on live pilot evidence: ~3% cross-user video overlap, 0 cached-and-unsummarized, a new user's newest-20 all uncached. Newest-first and cached-first are structurally anti-correlated (fresh uploads are exactly what nobody has fetched). Empty lever at pilot scale.

Two related future optimisations, both gated on user/subscription overlap actually growing (more pilot users with shared interests):

  • Cached-first blend: if overlap rises, blending a few instant zero-fetch cached summaries into the burst becomes worthwhile. The blend ratio (cached-instant vs relevant-fresh) was explicitly reserved for the maintainer — decide it against a fresh overlap number, not the 3%.
  • Promote channel_caption_state to a shared (non-RLS) table (ADR-024 notes this): per-channel caption-availability is a public channel property. Shared, it would let the burst predict has-captions for a channel another user already probed — the one pre-fetch quality signal that's currently unavailable. Per-user + RLS was kept only because pilot channel sets barely overlap.

Re-measure overlap before acting. Source: ADR-028 (rejected alternatives), ADR-024 ("Why per-user, not global").

ADR-028 **rejected** cached-transcript-first burst selection on live pilot evidence: ~3% cross-user video overlap, 0 cached-and-unsummarized, a new user's newest-20 all uncached. Newest-first and cached-first are structurally anti-correlated (fresh uploads are exactly what nobody has fetched). Empty lever at pilot scale. Two related future optimisations, both gated on **user/subscription overlap actually growing** (more pilot users with shared interests): - **Cached-first blend**: if overlap rises, blending a few instant zero-fetch cached summaries into the burst becomes worthwhile. The blend ratio (cached-instant vs relevant-fresh) was explicitly reserved for the maintainer — decide it against a fresh overlap number, not the 3%. - **Promote `channel_caption_state` to a shared (non-RLS) table** (ADR-024 notes this): per-channel caption-availability is a public channel property. Shared, it would let the burst *predict* has-captions for a channel another user already probed — the one pre-fetch quality signal that's currently unavailable. Per-user + RLS was kept only because pilot channel sets barely overlap. Re-measure overlap before acting. Source: ADR-028 (rejected alternatives), ADR-024 ("Why per-user, not global").
Sign in to join this conversation.
No labels
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: mathias/tapir#14