Genre picks from providers without a model, and a palette steered from enrichment

[robert-dean]

Status (2026-10-10)

This discussion asked whether a genre tag should be the period's second exception: a structured
steer beside the brief that a station with no model can still honour. Half of that has been
answered by building it, twice, and both halves lean over records the station already owns:

• A genre steer (Never-play rules, and a genre lean #420). deadair.genre_steers (migration 0069_block_rules.sql) holds one lean
  per station: a list of genres and an ends_at. CatalogSetGenerator draws a second, loose sample
  of records tagged with something containing a steered genre, matches the draw precisely with
  genre.match.ts, and gives the records really in a steered genre STEER_LEAN (four) times their
  weight (director/genre.steer.ts). Nothing is ever removed. ModelSetGenerator is told about the
  steer too, as a lean. It is set on the Programme page's "Leans and rules" tab and through
  /rules/steer. This is close to the "setting rather than a per-broadcast field" shape below, and
  needed no model.
• A mood, per slot (Moods: the model judges each record, and a slot can lean toward one #413, 0066_slot_mood.sql), which became up to four stages through a slot
  (Mood arc: a slot's mood becomes up to four stages #528, 0084_slot_moods.sql). Its migration calls itself the period's second exception in as many
  words: once a model has judged each record's mood, "lean toward comfort" is a number the floor can
  multiply a draw by, with no model in the room.

So the first question this discussion said had to be settled ("is a second structured filter beside
the brief acceptable, or does migration 0017's argument still hold?") is settled: it is acceptable
when the floor can honour it alone, and only ever as a lean.

What is left is the part neither of those reaches: music the library does not hold. A steer
toward synthwave on a library with six synthwave records plays those six more often. Nothing
without a model can go and find a seventh. That is the remaining question, plus the model-emitted
version of the same path, plus a second idea folded in from
director-and-lineups: a palette steered automatically from enrichment
rather than set by an operator.

---

The gap that is left

Written: 2026-09-20, after #205 added Deezer and ListenBrainz as similarity sources. Every
endpoint claim below was checked against the live services on that date, and every claim about the
tree against the code rather than the docs. Rechecked against the tree on 2026-10-10.

SetGeneratorChain registers ModelSetGenerator, ChartSetGenerator, SimilarSetGenerator,
CatalogSetGenerator, in that order (director.module.ts:138-143). What each does with the brief
and with a steer:

Generator	Where its records come from	What reaches it
ModelSetGenerator	the library and the providers, through search_music	the brief, the period, the mood, the steer
ChartSetGenerator	a provider's chart	the brief, to CHOOSE a chart (chooseChart); never filters one
SimilarSetGenerator	similarity sources, seeded from this broadcast's own records	no words
CatalogSetGenerator	the library only (ignoresBrief = true)	the period, the mood, the steer, as leans

So the only path from a GENRE to a record the station does not own is a model. Even that path is
narrower than it looks: search_music tells the model in its own description
(modules/llm/music.search.tool.ts) that it "matches NAMES and styles in the library, but only NAMES
at the providers", and that "at the providers a style like 'rap' finds records with that word in the
title, not records of that style". A model filling a synthwave hour has to name synthwave artists
from memory and search for them one at a time.

What is available without a model, measured

GET /1/lb-radio/tags on ListenBrainz: recordings carrying a MusicBrainz tag, with AND/OR across
several tags and a popularity window. No token. Checked 2026-09-20:

GET api.listenbrainz.org/1/lb-radio/tags?tag=synthwave&operator=AND&count=6&pop_begin=80&pop_end=100

Six rows of { recording_mbid, percent, tag_count, source }. Titles need a second, also keyless,
POST /1/metadata/recording/, whose artist.artists[0] is the LEAD artist the pick path needs.
What came back for synthwave: Galatée, Mitch Murder, From Fiction, Shuriken Sun, Mental
Minority, Mlada Fronta. Tag-accurate, every one of them.

The ListenBrainz client already exists: plugins/musicbrainz/src/listenbrainz.client.ts calls
/1/lb-radio/artist/{mbid} for similarity. The tags endpoint is a sibling of one it already reads.

Two limits, both real:

1. It samples rather than ranks. At pop_begin=40 the same query answered a Deus Ex
   soundtrack cue and something called "Turbine Tunnel Bass Arp II 125BPM". The popularity window
   is a dial, not a fix. This is the same property that made the radio endpoint unusable for
   artistTopTracks in Two more similarity sources, and an order for them #205, where ranking by its own listen count still produced a Daft Punk
   medley and a mashup.
2. MusicBrainz tags are genre-shaped words. synthwave works. "Flamenco guitar with a bit of
   swing" is not a tag, and never will be. This can answer a genre steer and cannot answer a brief.

Deezer cannot do this job. Its genre list is about twenty broad buckets (Pop, Rock, Electro),
and /genre/106/artists answers Drake, Bad Bunny and Taylor Swift. Its free-text search matches
titles literally: q=synthwave returns songs CALLED Synthwave. Checked the same day. So the
keyless tag path is ListenBrainz's alone, which also means it inherits ListenBrainz's habit of
closing endpoints to anonymous callers: /1/metadata/lookup/ and
/1/popularity/top-recordings-for-artist/ already answer 401 with a sentence about scrapers.

The design question

A tag is the period's argument a second time. The period earned a column because
CandidatesRepository.sample can narrow on it, "so a station asked for a decade keeps playing one
with llm.setGenerator off entirely, which prose can never do". A genre tag buys exactly that,
for exactly that reason, and pays exactly the same price: it is weaker than the sentence an
operator would rather have written.

The difference worth arguing about is where the records come from. A period narrows the DRAW over
records the station already owns. A tag would have to reach a provider, because the whole point is
music the library does not hold, so it is a new generator rather than a column the floor reads.
The genre steer has since made this sharper: the input already exists (genre_steers.genres),
and what is missing is only the generator that takes it outside the library.

Shapes, revised now the steer exists

The three shapes this discussion first offered were a tags column beside the period, a
station-wide setting, and model-emitted tags. The first two have been overtaken: the steer IS the
station-wide input, and it is stored in a table with an expiry rather than as a setting. What
remains:

A TagSetGenerator that reads the steer. While a steer is in force, ask /1/lb-radio/tags for
its genres, resolve the rows to titles and lead artists, and hand them to PickResolver as named
picks, which ingests what it can find at a provider exactly as it does for the model's picks.
Registered between the chart and similarity bindings, so a station with no model and a steer in
force gets records it does not own, and a station with neither falls through unchanged. The steer
already says "lean, never only", so this generator should supply SOME of a refill and leave the rest
to the generators below it, the way similarMix does, rather than owning the batch.

Let the model emit tags. set.prompt.ts already tells the model to pass yearFrom/yearTo
rather than writing "80s" into a query. search_music could take tags the same way, answered at
the providers through the same lookup, so a model asked for synthwave gets synthwave rather than
songs called Synthwave. One path would then serve BOTH the model-less station (operator-set steer)
and the briefed one (model-chosen tags). This is still the most interesting version and the one
that makes the feature earn its place twice.

Per-broadcast genres (a tags column on schedule_slots and station_lineup) stay possible
and stay unasked-for: the slot's mood showed the column route works, and the steer showed a
station-wide lean is enough to start with.

Against building it at all

The station this was written on (radio.deanhome.app) runs llm.setGenerator on,
llm.alwaysSearchProviders on, briefOnly on and similarMix at 0.6. For a station configured
like that, guidance already works and this adds nothing beyond better provider matching for the
model: the model reads the brief, searches the provider on every call, and PickResolver ingests
what it names. The gap is real only for an operator who does not run a model, and the honest
question is whether that operator exists in numbers worth a generator.

The counterargument is cost rather than capability: a tag lookup is two cheap requests where a
briefed refill is a model conversation with tool steps, and a station that wants a genre hour is
paying for a language model to rediscover the word "synthwave" every time.

What would need deciding first

• Is a second structured filter beside the brief acceptable? Settled by Moods: the model judges each record, and a slot can lean toward one #413 and Never-play rules, and a genre lean #420; see the
  status above.
• Per-broadcast (a migration) or station-wide (a setting)? Station-wide first, through the steer
  that already exists.
• Where would the tag vocabulary come from? MusicBrainz tags are a folksonomy with no closed list,
  so a free-text field that silently matches nothing is the obvious failure. /1/lb-radio/tags
  answering empty for a tag nobody uses is the same shape as the advisory clean-only problem: the
  honest answer is "nothing to play", and it has to be SAID rather than looking like an outage. The
  steer's genres today are matched against the station's OWN tags (genre.match.ts), which are not
  promised to be MusicBrainz's spelling.
• Does the sampling behaviour disqualify it? Deep cuts are a feature for discovery and a bug for a
  station that asked for a genre and expected to recognise something.
• What happens when ListenBrainz closes this endpoint to anonymous callers too? The client should
  fail open into the generators below it, like every other source.

---

Palette steering: a lean the station works out for itself

Folded in from director-and-lineups on 2026-10-10, where it was the
last open entry. As it stood there:

Palette steering. Distilling genres and year bands from enrichment to bias selection. The
rotation rules land without it; it is a weighting refinement, not a correctness one.

And from from-v1, the previous station's version of it: durable play
history driving a repeat window and artist cooldown, per-artist caps, and a palette derived from
what actually aired rather than from the pool.

Why it lives here now: it is the same draw and the same kind of weight as the steer above, and
the difference is only who chooses the genres. The steer is an operator saying "synthwave until
ten". A palette is the station noticing that the last hour was mostly synthwave and late-80s, and
leaning the next refill that way (or away from it) without anybody saying so.

What exists on 2026-10-10, and what none of it does. CatalogSetGenerator multiplies in several
leans (catalog.set.generator.ts, the scored map): the mood (mood.lean.ts), the genre steer, an
artist coming back (#525), a deep cut (#525), and a skip (#527, skip.lean.ts), plus the smart
shuffle's freshness. Every one of them is either set by an operator or read from history about a
RECORD or an ARTIST. None distils a genre or a year band from what aired. The generator's own header
still says so: "There is no similarity graph, no palette, no sense of flow beyond keeping one artist
off its own heels."

The data it would read is now in the tree. CandidatesRepository.tagsFor answers each track's
genres from the enrichment arrays at the track and at its artist (never the promoted tracks.genre
scalar), and genre.match.ts already says when one tag refines another. A year is on every track.
play_history says what aired. So a palette is a query over the last hour's play_history through
tagsFor, a distribution of genres and decades, and a weight, which is the steer's own mechanism
with a computed input.

What would need deciding first:

• Toward or away? A palette that leans toward what just aired is coherence; one that leans away
  is variety. The rotation rules already push away from the same ARTIST and SONG; whether genre
  should be pushed the same way, or pulled, is the whole design.
• Against what baseline? A library that is half indie rock will "lean" toward indie rock on any
  measurement of what aired. A palette has to be relative to the library's own distribution, or it
  is the rotation pool's shape fed back to itself.
• How it stacks with an operator's steer. A steer is an instruction; a palette is a habit. The
  steer should win where they disagree, and the obvious place to say so is that a palette is not
  computed while a steer is in force.
• It is still a refinement, not a correctness fix, as The music director and lineups #12 said. It should cost a query per
  refill at most, and a failed read should cost the lean and never the batch, like every lean
  beside it.

---

Written 2026-09-20 against main after #205. Rewritten 2026-10-10 around what is still open after
#413, #420 and #528, with #12's palette steering folded in; the earlier text is in this discussion's
edit history.