bvandeusen
5faa57634b
The #1249 mechanism (stamp WHY a track is in the snapshot at build time, freeze it onto the play at ingestion, break it down in metrics) generalizes from a For You one-off to the standard for every system mix (#1270): - Migration 0039 widens both pick_kind CHECKs (drop + re-add in the same change) to taste/fresh + Discover's dormant/cross_user/random + tier1-3 for the rule-#131 eligibility ladders. - GetForYouPickKindForTrack becomes GetSystemPickKindForTrack (user, variant, track); ingestion stamps any systemPlaylistSources play from its own variant's live snapshot, live + offline paths. - Discover stamps its candidate bucket on discoverTrack before the interleave, making the 40/30/30 allocation measurable; dedup keeps the taking bucket's stamp. - Metrics replace the for_you special-case with one pick-kind vocabulary — any family with attributed plays gets a breakdown, future stamping mixes need no metrics change. - Web: breakdown sub-rows are now toggled per surface (collapsed by default) so eight stamping mixes don't swamp the card. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01TsF3cNoKrqCYsU78cXC8U6
42 lines
1.7 KiB
SQL
42 lines
1.7 KiB
SQL
-- Provenance as standard (milestone #127, Scribe #1270).
|
|
--
|
|
-- #1249 introduced pick_kind as a For You one-off ('taste'/'fresh').
|
|
-- The mechanism — stamp WHY a track is in the snapshot at build time,
|
|
-- freeze it onto the play at ingestion, break it down in metrics — is
|
|
-- now the standard for every system mix, so the CHECK vocabulary
|
|
-- widens to cover:
|
|
--
|
|
-- taste / fresh For You head vs freshness-injection tail
|
|
-- dormant / cross_user / random
|
|
-- Discover's three candidate buckets — makes
|
|
-- the 40/30/30 allocation measurable instead
|
|
-- of a guess
|
|
-- tier1 / tier2 / tier3 the tiered-eligibility ladder (project rule
|
|
-- #131): tier 1 pins the mix's exact desire,
|
|
-- each higher tier steps back a little. Tier
|
|
-- provenance is how we measure what the
|
|
-- step-back trades away.
|
|
--
|
|
-- Postgres CHECK whitelists can't be altered in place: DROP + re-ADD
|
|
-- with the expanded list, in the same migration.
|
|
|
|
ALTER TABLE playlist_tracks
|
|
DROP CONSTRAINT playlist_tracks_pick_kind_check;
|
|
ALTER TABLE playlist_tracks
|
|
ADD CONSTRAINT playlist_tracks_pick_kind_check
|
|
CHECK (pick_kind IN (
|
|
'taste', 'fresh',
|
|
'dormant', 'cross_user', 'random',
|
|
'tier1', 'tier2', 'tier3'
|
|
));
|
|
|
|
ALTER TABLE play_events
|
|
DROP CONSTRAINT play_events_pick_kind_check;
|
|
ALTER TABLE play_events
|
|
ADD CONSTRAINT play_events_pick_kind_check
|
|
CHECK (pick_kind IN (
|
|
'taste', 'fresh',
|
|
'dormant', 'cross_user', 'random',
|
|
'tier1', 'tier2', 'tier3'
|
|
));
|