Three decisions behind a music-to-curator matching score

I build OTONAMI, a pitch platform that connects independent
artists with music curators — playlist editors, radio DJs, bloggers, label scouts.
At its core is a single number: how well does this track fit this curator?

The math behind that number is textbook. Cosine similarity, Jaccard, a weighted
sum — nothing you can't find in a first-year course. What actually took real,
messy music data to get right were three design decisions. Each one came from
a concrete failure, and each one is the difference between a matcher that looks
fine in a demo and one that ranks sensibly in production.

I extracted and generalized the engine into a small, typed, open-source library —
music-matching-patterns —
so the code below is real and runnable. Here are the three decisions.

The shape of the problem

A match is scored on three factors and combined with weights:

score = genreScore · w_genre  +  moodScore · w_mood  +  audioScore · w_audio

Each sub-score lands in [0, 1]. Genre tends to be the strongest predictor of
fit, mood is a secondary signal, and audio is a tie-breaker rather than a driver —
so a split that leans on genre (something like 0.55 / 0.25 / 0.20) is a reasonable
starting point. The interesting part isn't the weights. It's how each sub-score is
computed.

Decision 1 — Genre uses recall, not Jaccard

The obvious move is Jaccard similarity over the two genre sets: intersection over
union. It's symmetric and tidy. It's also wrong here.

Picture a curator who covers ten genres — a generous, broad-taste editor. A track
that hits exactly one of those ten is a perfect fit for that curator's lane. But
Jaccard would score it 1 / 10 = 0.1, because the union is huge. The broader and
more welcoming the curator, the harder Jaccard punishes them. That's exactly
backwards from what you want.

The question isn't symmetric. It's: does this track fit inside the curator's
lane? So genre is scored as recall over the track's genres — of the track's
genres, how many does the curator cover?

export function genreScore(track: Track, curator: Curator): number {
  if (curator.openToAllGenres) return 1;

  const trackGenres = normalizeLabels(track.genres);
  if (trackGenres.length === 0) return 0.5; // see Decision 3

  const curatorGenres = new Set(normalizeLabels(curator.genres));
  const covered = trackGenres.filter((g) => curatorGenres.has(g)).length;
  return covered / trackGenres.length;
}

A broad curator is no longer penalized for being broad. The asymmetry of the
real-world question is now baked into the metric.

Decision 2 — Tempo is deliberately excluded from the audio vector

Audio fit is cosine similarity over a feature vector: energy, danceability,
acousticness, instrumentalness, valence. The tempting sixth dimension is tempo.
I left it out on purpose.

Automatic BPM detection is unreliable in a way that's uniquely destructive to a
distance metric: it makes half-time and double-time errors. A slow 60 BPM
ballad routinely gets read as 120 BPM. When that doubled value lands in a vector
and you compute distance, it doesn't just add a little noise — it blows a hole in
the score. Two tracks that belong together suddenly look far apart on one axis.

In an early version, this produced a bug where about 22% of matches collapsed
toward a flat, meaningless score. Tracing it back, tempo was the culprit nearly
every time. Pulling tempo out of scoring removed an entire class of false
negatives at once.

for (const dimension of AUDIO_DIMENSIONS) {
  const x = a[dimension];
  const y = b[dimension];
  dot += x * y;
  magA += x * x;
  magB += y * y;
}

Tempo can still show up in display copy ("similar energy and tempo") — humans
read it fine. It just must never re-enter the score. Keep explanation and scoring
decoupled.

Decision 3 — Missing data is neutral, never a penalty

Independent music is full of gaps. Plenty of tracks have no reliable audio
analysis. Plenty of curators never filled in their mood tags. The naive thing is
to treat a missing signal as a zero — and the naive thing quietly buries every new
or under-analyzed artist at the bottom of every ranking.

So whenever either side lacks audio, or either side lacks moods, that factor
returns a neutral 0.5. It neither helps nor hurts.

export function audioScore(track: Track, curator: Curator): number {
  const a = track.audio;
  const b = curator.audio;
  if (!a || !b) return 0.5; // absence of a signal is not evidence of a bad fit
  // ...cosine similarity...
}

Absence of evidence is not evidence of a poor fit. Encoding that one line keeps the
newest artists — the ones a discovery platform exists to serve — from being
penalized for thin metadata.

Takeaway

None of these are clever algorithms. They're small, boring guards: recall instead
of Jaccard, one dimension removed, one neutral fallback. But each one came from
watching real rankings go wrong, and together they're most of what separates a
matcher that works from one that merely runs.

The full implementation is open source and typed end to end:
music-matching-patterns.
If you're wiring an LLM into a Next.js app, you might also like my earlier write-up
on production patterns for the Claude API in Next.js.