Solution 02
Separate content-safety screening from quality filtering
01 — Root cause addressed
Safety was folded into a general NSFW and quality filtering step, so no stage owned it and no criterion could fail the release on safety grounds alone.
02 — Implementation
Split the two concerns into distinct pipeline stages with distinct owners and distinct pass criteria. Quality filtering may keep working in scores and thresholds; content-safety screening should return a pass or a removal and nothing that can be traded against a quality metric, averaged into an aggregate, or tuned for recall against a yield target. Give the safety stage its own record of what it screened, with what list version, and over what fraction of candidates, so the question of whether it ran is answerable after the fact rather than inferred from the absence of complaints.
03 — Prevention
Keeping the stages separate means a safety result can never be diluted by a quality score, and the safety stage retains standing to block a release on its own.
04 — Trade-offs
Two stages mean more pipeline complexity and another gate that can block a release, which is genuine overhead for a small or volunteer team. It is also the wrong emphasis for a dataset built entirely from licensed first-party content, where a dedicated screening stage would have almost nothing to do and would mostly add ceremony.