We pointed an LLM at copyright moderation. It flagged 1,632 of 2,026 videos. One was real.

Videojam is an embed-only music video platform. We host nothing — every video on the site is a YouTube embed, played through the IFrame API, served from Google's infrastructure. That gives our copyright question an unusual shape. We aren't asking "are we hosting infringing content?" We're asking "should we be curating and surfacing this particular upload?"

It's a narrower question, and I assumed it would be an easier one. It wasn't. Over the past week I rebuilt our copyright triage from scratch, and every approach that seemed obvious failed in an instructive way. The one that worked was almost embarrassingly simple, and it wasn't the one anyone would reach for first.

Here's the sequence, in the order we got it wrong.

---

Attempt 1: ask a language model

The first version was the version everyone is building right now. Point a model at each video's metadata — title, description, uploader, tags — and ask it to judge whether the upload looks like it shouldn't be there.

Over a corpus of 2,026 videos, it flagged 1,632.

That's four out of five. When a classifier flags 80% of its input, it hasn't found a problem — it is the problem.

Its own reasoning gave the game away. 1,602 of the 1,632 flags — 98.2% — came back under two rationales so broad they would apply to very nearly any music video in existence. The model wasn't discriminating between rows. It was restating its own prior, 1,632 times, with high confidence.

When we rebuilt the detector from scratch, that same corpus of 2,026 yielded one row worth acting on.

The failure isn't that the model is bad at reasoning. It's that the model was reasoning about the wrong thing, and reasoning well about the wrong thing produces confident nonsense. Consider two rows:

• Nirvana – Smells Like Teen Spirit, uploaded by NirvanaVEVO
• Nirvana – Smells Like Teen Spirit, uploaded by a channel with 400 subscribers and a stock-photo banner

Semantically, in title space, these are the same video. The thing that distinguishes them — who put it there and whether they had the right to — is not in the content. It's in the provenance. An LLM reading the content will always be guessing, and it will guess in whichever direction its prompt leans. Ours leaned cautious, so it flagged everything.

Attempt 2: a heuristic

Fine — drop the model, write a rule. We have a Cinema vertical (short films, documentaries) alongside the music catalog, and the obvious risk there is a commercial film ripped and re-uploaded. So: long duration, plus the cinema section, plus a non-official uploader, equals probable rip.

That rule flagged 196 videos. Every one of them was a legitimate documentary. Zero were rips.

Which, in hindsight, is exactly what the rule was built to do. "Long film on a channel that isn't a studio" doesn't describe a rip. It describes an independent documentary — which is to say, it describes our entire Cinema vertical. The heuristic detected length. Length correlates with legitimate long-form content, not with infringement.

We deleted the detector.

Attempt 3: match rightsholder names

Third try, and now we're getting warmer. Freeze a list of roughly forty artists and estates known for aggressive enforcement — the ones where a re-upload reliably draws a claim. Match their names against video titles.

This one actually caught things. It also caught a Tomorrowland set, uploaded by Tomorrowland, licensed by Tomorrowland, because a headliner's name appeared in the title.

We patched it: exclude titles containing remix, live, set, b2b, mix. That fixed the DJ content and immediately failed on the next class — covers, tutorials, reactions, karaoke. A guitar cover of a Prince track flags. A piano lesson for a Beatles song flags. Every patch bought one class of false positive and revealed another, and the list of exclusion tokens started growing without any obvious end.

There's a deeper problem with name-matching, and it's the one that should have stopped us sooner: it's spoofable in the wrong direction. A denylist keyed on names tells a bad actor exactly how to pass — leave the name out of the title. We had built an evasion guide and called it a filter.

Attempt 4: look at who uploaded it

The catalog stored an artist field, but — a known gap in our data model — it was populated from the YouTube channel, not the performer. And for a large slice of the catalog, particularly older gap-fill entries, it was empty.

That emptiness was doing enormous damage, and we hadn't noticed. Our name-matcher was flagging rows where the artist name matched and provenance was unknown — and it was reading "unknown" as "not official." Thirty-three videos sat in the queue, and the reason they were there was not that we had bad evidence about them. It was that we had no evidence about them, and had quietly converted that into guilt.

So we backfilled one field. A single batched call to the YouTube API, pulling channelId for every candidate.

Thirty-three collapsed to two.

The thirty-one that dropped out were: Official Artist Channels, VEVO uploads, - Topic auto-generated channels, and the festival's own account. The Beatles material was on the Beatles' channel. The Rolling Stones material was on the Stones' channel. Every one of them was, in fact, the single most licensed and most embeddable class of row in the entire catalog — and our detector had been flagging them for removal.

The two that remained were genuine: commercial masters by aggressively-enforced estates, re-uploaded by channels with no claim to them. We hid both, logged both, and denied both channels catalog-wide.

Two rows, across a catalog of 6,013 — one of them inside the 2,026 the language model had already chewed through. Found not by reading a single frame of video, but by looking at who uploaded it.

One caveat, stated plainly, because otherwise a careless reader will supply the wrong one for me: "two" means two rows met a criterion we can defend — a commercial master by an aggressively-enforced estate, re-uploaded by a channel with no claim to it. It does not mean the catalog contains exactly two problems. Our detector knows about a frozen list of forty rightsholders and nothing else. It is a triage tool, not a census, and I'd distrust anyone — including me — who tried to compute a clean-catalog percentage from a number like this. Making claims a method cannot support is, more or less, the entire subject of this post.

---

The thesis

Copyright triage on a music catalog is a provenance problem wearing a content problem's clothes.

Every signal that read the content — the LLM, the duration heuristic, the title matcher — failed, and failed at a rate that made it operationally worthless. The only signal that resolved the question read the uploader. And that's not a quirk of our catalog; it follows from what copyright actually is. Licensing status is a fact about a relationship between two parties. It is not a property of the artifact. You cannot see it by looking harder at the artifact, no matter how good your model is.

This is, I think, the thing worth taking away from a small platform's week of getting it wrong, at a moment when a great many larger platforms are pointing language models at exactly this problem.

The two rules

Out of it fell two rules that we now enforce in code and in tests, and which I'd suggest generalize well past music:

1. No exemption may key on a mutable string.

Our first fix for the Tomorrowland problem was to exempt channels named "Tomorrowland," "Boiler Room," "Cercle." That is trivially defeated: anyone can name a channel "Tomorrowland." An exemption keyed on a human-readable name inverts a denylist into a bypass. Every allowlist we run is now keyed on channelId — an identifier the uploader cannot edit after the fact. There is a test that spoofs the name and asserts the video still flags.

2. A detector must never fire on the absence of a field.

This is the one that cost us the most, and it's the subtler of the two. Thirty-one of our thirty-three candidates were there because provenance was missing, and the code read missing as damning. A detector that fires on absence isn't detecting anything — it's reporting its own ignorance, wearing the costume of a finding.

If that sounds familiar, it should: it's the same failure as attempt one. A model with no evidence, answering confidently anyway.

---

What we built instead

The engine that shipped is deterministic and has no LLM in it. It's a precedence chain over a single channel registry, keyed throughout on channelId:

1. Takedown denylist — channels that have received a valid notice. Overrides everything.
2. Official artist channels and event/label channels — exempt.
3. Rightsholder name list — runs last, and only on rows where provenance is actually present.

Alongside it: a public copyright and takedown page with a named contact and a stated turnaround, and an internal takedown log that records what triggered every action — a received notice, a manual decision, or an engine flag. That last field, source, is one line of schema, and it's the difference between having a compliance process and being able to show you have one.

The engine now flags on the order of one or two videos a week, and I look at every one.

The coda

There's a footnote here that turned out to be the point.

The reason our provenance data was missing in the first place is that Videojam's data model conflates uploader with artist. Which means a DJ's catalog is scattered across the channels of every festival that ever filmed them — Charlotte de Witte's work lives under Awakenings, Cercle, Boiler Room, and her own channel, as four unrelated entities.

That's a discovery problem, and I'd had it filed as one for months. It turns out to be the same bug as the copyright problem, keyed on the same field. Fixing provenance to stop mis-flagging the Beatles is the identical fix as making a DJ's catalog cohere.

Which is, in its own way, the most useful thing this week produced. Not the engine. The realization that we'd been treating one missing field as two separate problems.

---

Videojam is a music video discovery platform. Notices and questions: videojam.live/copyright.