Fence off the play_events rows that mean 0.5 by construction

[jeffcrouse]

Phase 1. Three decisions wait on ADR-0004's data — its own completion-ratio threshold, ADR-0005's RADIO weights, and #53 — and the data doesn't start where we assumed.

What the live database says

Until #57, the web client delivered a play the moment listening crossed min(duration / 2, 4 min) and sent completion_ratio as measured at that instant, never revising it. Verified again on 2026-08-02, by day and context:

	completions avg
every context before 2026-08-01 (incl. library)	0.42 – 0.50
library, 2026-08-01 → 02	0.972 / 1.000 (skips ≤ 0.1)

795 of 823 rows predate the fix. library is contaminated too because the web derives context from the queue source and sends library for a library queue — exactly as the native app does.

So the clock restarted on 2026-08-01, not 2026-07-27. A month of trustworthy data lands around 2026-09-01, and all three decisions inherit that date.

Why a date, and why not delete

FEEDBACK_TRUSTWORTHY_SINCE / trustworthy_feedback_only put the boundary one call away instead of leaving it to discipline.

A date, not a client filter: play_events records no client and context doesn't stand in for one, so the good native rows can't be separated from the bad web rows beside them. Selecting on the ratio would be circular — it's the variable being measured. The cutoff costs those native rows; nothing cheaper does.

Excluded, not deleted, for a reason the investigation turned up: the damage isn't limited to the ratio. A track abandoned at 55% was recorded as a completion at ~0.5 rather than as a skip, so outcome is unreliable before the cutoff and skips are under-counted. What survives is that skipped/rejected rows describe real abandonments — an incomplete census, not a wrong one.

The reassuring part

ambient._negative_signal counts exactly skipped and rejected, over a rolling 90-day window. The live recommender was never poisoned — it's been running on a slightly weak negative signal, which heals as the window passes the cutoff (~2026-10-30). Nothing reads completion_ratio anywhere yet, so the threshold work is entirely ahead of us.

Also

• ADR-0005 gains the Implementation: block it never had — which is why it looked unbuilt in a survey while RADIO had been shipping for weeks.
• Volume: 28 events / 26 distinct tracks over two clean days. A month ≈ 400 events — enough to place a threshold, thin for weight tuning.
• Two follow-ups recorded: a nullable client column (cheap now, worthless retroactively — the one thing that would have made this separable), and that whether the web still reports at all is unverified, since every post-cutoff row carries the context the native app hardcodes. Settle that by playing one track in the web app, not by reasoning about rows.

Verification

Seven unit tests on the boundary, including that it's inclusive and naive-UTC to match TIMESTAMP WITHOUT TIME ZONE. ruff clean. The DB-backed suite can't run here — no local postgres on 5432 — so CI covers it; the new module is pure and needs none.

🤖 Generated with Claude Code

https://claude.ai/code/session_014P9p2fvFnyiywBxGkv4gfW