Case study

Networked Players

An evidence-first music-credit graph and browser game: four playable modes over a 217-album catalog, where every connection between two records names the credits that prove it.

GitHub repository Visit the site

The Connect Two Records screen on Networked Players, showing The Low End Theory and Blood On The Tracks selected and the beginning of a documented two-hop route between them — Pick any two records in the catalog and the app finds a path between them through people who are actually credited on both ends — then shows you the releases that prove each step.

What it is

Networked Players is a music-credit graph you can play. It maps the people who connect recorded music — performers, producers, engineers, arrangers, everyone who ends up in the small print — and turns those connections into four browser games over a 217-album catalog of 517 artists, 575 documented paths, and 639 credited contributors.

The premise is narrow on purpose. A credit proves that two people worked on the same recording. It does not prove influence, friendship, or a scene. So every connection the site shows you names the release it came from, and you can follow that back to Discogs yourself.

The four modes ask different questions. Connection Guesser puts two records on the counter and asks who is credited on both, with two attempts and a five-rung clue ladder that gives up years, then a role, then initials, then an actual liner-note excerpt with the name blacked out. Connection of the Day is one frozen round per calendar date. Record Routes asks you to guess how many hops apart two albums are before it shows you. Connect Two Records is the one without a game attached: pick any two albums and get the documented route, with an alternate route and a “Why this route?” disclosure explaining why it picked the one it did.

There are no points. A round resolves as clean, with clues, or revealed, and that is the whole scoring model.

Why I built it

I wanted to know who keeps turning up. Not the famous names on the cover — the session bass player who appears on a jazz record in 1971 and a hip-hop record in 1991 and is the reason those two things are two hops apart at all.

That question sounds like a database query and turns out to be a data-modeling problem, which is exactly the kind of thing I do at work with much less interesting subject matter. Discogs publishes monthly data dumps under CC0, so the raw material is genuinely open — 47.6 million credit rows in the snapshot I work from. Getting from there to a claim you would defend in public is the actual project.

The bug that redefined the project

For a while the pipeline produced nonsense. The curator confidently surfaced Pink Floyd next to Nas, Nirvana next to John Coltrane, Prince next to Black Sabbath. These were not near misses. They were absurd, and they scored well.

The forensic audit is the most useful thing I have written on this project. The identity model turned out to be clean: every one of those 47.6 million rows resolved consistently, and no name in the corpus mapped to two different artist IDs. The defect was in the edge definition. I had been treating appeared on the same release as a connection — so a forty-six track compilation became a forty-six artist clique, and shortest-path search, which is drawn to high-degree edges, walked straight into them. Compilation-shaped releases produced 26.3% of the graph’s edges and carried 91.7% of its paths. Measured across every hop the curator had produced, the false-positive rate was about 99%.

The tempting fix was to require two hops, so I tested it. Two-hop pairs were more compilation-borne than one-hop pairs, not less — forbidding one hop just routes you through two compilations. Path length is not the defect; the edge is.

So the edge got rewritten to mean contributed to the same recording: a star outward from a track’s performers rather than a clique across a release. A companion rule connects two performers of the same track to each other only when both are billed release artists, so a DJ sampler cannot marry the two unrelated acts it sampled through an uncredited guest. Later I narrowed it further, to documented musical performance. That change roughly halved the published graph and retired a game feature I had already shipped, because once producer-and-engineer-only edges were gone there was nothing left for that filter to filter. Both decisions are written down, including the part where the second one reverses the first.

A documented route between two albums broken into four steps, each naming the contributor, their credited role, and the specific Discogs release that evidences the connection — Every step names its evidence. Ron Carter plays bass on *The Low End Theory*; he and Astrud Gilberto are both credited on a 1971 release; she and Paul Griffin on a 1969 one; Griffin plays organ on *Blood On The Tracks*.

Screenshots

A Connection Guesser round showing two 1985 albums side by side and a tray of candidate contributors, each labelled with their instrument — **Connection Guesser**: two records, two attempts, five clues in reserve.

A radial credit neighbourhood graph centred on A Tribe Called Quest with spokes to two dozen connected contributors — **Explore**: click any contributor to recentre the neighbourhood on them.

The contributor directory listing the most connected people in the catalog with their documented connection counts — **Contributors**: 639 people, filterable by the kind of work they were credited for.

The Connect Two Records search interface with two albums chosen and route filters for rhythm section and guitar credits — **Connect Two Records**: filter a route down to drums and bass, or to guitar.

Technical shape

The pipeline is Python. A monthly Discogs dump is verified by size and SHA-256, then streamed straight out of gzip so the expanded XML never touches disk, normalized into Zstandard-compressed Parquet, and checked with DuckDB. DuckDB does the real analytical work throughout — the edge definition itself lives as one generated SQL statement, reused verbatim everywhere an edge is counted, so there is exactly one answer to what an edge is.

The site is the opposite of that: Astro, fully static, no UI framework at all. There is no API and no server — the catalog is a set of versioned JSON artifacts, each one carrying a content hash, each downstream artifact pinning the version it was built from, so a stale sidecar is a detectable mismatch instead of silent drift. The pathfinding graph is stored as parallel arrays rather than objects, which measured about fifteen times smaller gzipped, and it is parsed and integrity-checked in a Web Worker so the main thread stays free.

Two things about the build are worth calling out because they are habits rather than features. Every public artifact has a validator with no dependencies at all, so the same check can be shipped to a small fleet of Raspberry Pis and an x86 box for an independent second opinion — the artifact passes only if every node agrees. And the site build fails if any distractor in a game round is actually a correct answer, which is the kind of bug that would otherwise only show up as a player being told they are wrong when they are right.

It is also built with AI coding agents, which the repository says plainly on the front page. The guardrails above are mostly what that costs: if you are going to let an agent generate work at volume, the checks have to be executable, because review attention does not scale the same way.

What I learned

A wrong edge definition is much worse than a wrong result, because it is invisible in aggregate and confident in detail. Mine ranked its own false positives highest, which is the failure mode I now look for first.
“Test the obvious fix” is cheap and keeps you honest. Requiring two hops felt right, measured worse, and knowing that took an afternoon.
Constraints that live in documentation do not exist. The catalog selection policy sat in a JSON file the code never read, so four of six picks in the first expansion round had to be filtered by hand. Moving it into the build path made the round strictly better on every measure.
Writing down the decisions I rejected has been more useful than writing down the ones I kept — including the one where a later decision reversed an earlier one, stated as a reversal rather than left to look like drift.