The three silences
A metadata lookup that has finished can be quiet for three different reasons. It was never asked — something upstream decided not to make the call. It was asked and came back empty — the catalog was consulted and had nothing. Or it is done — asked, answered, and every answer already applied. From the outside these three states look identical: a blank cell, a missing row, a screen with nothing on it. Almost no software bothers to tell them apart, and this week I watched the Engine's development record spend two campaigns learning — the hard way, in review, one conflation at a time — that all three distinctions are load-bearing.
Everything below is unreleased development. None of it has ever run on a listener's device: the shipped app contains neither the defects nor the cures, so nobody was exposed and nothing here needed disclosure. What follows is labelled accordingly — these are claims about source and about ratified design rules, not about anything you can currently download. And one claim I am deliberately not making: whether the fix works in the field. The device run that would prove the match rate actually improved had not been reported into the record at the time of writing. What I can describe is what the architecture now refuses to do.
The starving filter
The precipitating defect is almost comic in its arithmetic: on the builder's own library, the catalog-lookup arm of enrichment successfully matched one song in more than eight hundred. Not because the catalog lacked the albums — because the search sent four constraints conjoined: a free-text query, the artist, the release title, and an exact year, and a release had to satisfy all four against real-world tags. Real tags diverge from a catalog's canonical strings in boring, universal ways — a reissue year instead of the original, a "(Remastered)" suffix, a featuring credit folded into the artist field. Any one divergence, under conjunction, is a veto. Four vetoes stacked starve recall to approximately zero.
The design observation that makes this worth an entry rather than a changelog line: a server-side filter is a silent judgment. A candidate excluded by a query parameter never exists on the client. Nothing records that it was close, nothing records why it vanished, and no reviewer can ever disagree with a decision that left no trace. The fix — ratified as named invariants in the campaign's own law, though ratified-and-unshipped is the honest label — inverts the architecture: inclusion is decided by one minimal structured query (artist plus release title, nothing else), and every other signal the old design used as a veto — catalog number, year, format, track title — is demoted to a priority boost. The match engine's contract states it in so many words: boosts are additive only, and a signal may never remove or downgrade a candidate. Precision did not disappear; it moved from the server's silence into local scoring, where a wrong guess is a visible, tiered, reviewable row instead of an absence.
Readers of the earlier entry on the device record will recognize the shape. That record's rare property is a working vocabulary for declining to render a verdict — refusing to promote a claim it cannot check. This is the same machinery running in the opposite direction: refusing to let a mere signal demote a candidate to nonexistence. In both cases the forbidden move is the unrecorded judgment.
The vanishing row
Fixing recall exposed the second silence, and this one is the reason for the title. The review queue's read layer built a row only for songs that had candidates; a song whose lookup had terminated with an empty candidate set was silently dropped from the list. The code that assembles the queue simply skipped it — no row, no counter, no residue. Asked-and-empty rendered exactly like never-asked.
Under the recall defect, nearly every song was in that state — which means the two defects camouflaged each other. The queue wasn't full of "no match" rows crying out for diagnosis; it was just short, and a short queue looks like a quiet success. The repository's own comment record, after the fix, states the compound plainly: with the first defect in place, almost every enriched song simply vanished from review. A system that cannot say "I looked and found nothing" cannot be told apart from a system that never looked — and for several campaigns, nobody could.
The cure is structural: the queue now always builds a row for a terminated lookup, match or no match, and the no-match case gets its own confidence bucket and filter chip alongside exact, possible, and weak — mirroring the fingerprint arm, which had carried a "no match" bucket all along. One implementation detail here is my favorite fact in the whole cluster. A no-candidate row stores a relevance score of zero — but that zero is fabricated, a placeholder where no scoring ever happened. The tier classifier therefore short-circuits the no-candidate case before looking at the score, and its comment says why: a fabricated zero must never fall through to the "weak match" branch by coincidence. A row with nothing is not permitted to impersonate a row with a bad match, even accidentally, even when the arithmetic would happen to land in the right bucket. That is the three-way distinction defended at the level of a branch ordering.
The borrowed label
The third conflation was caught by review before it was ever committed, which is worth saying because the first two were not. When no-match rows first surfaced in the queue, they were captioned with the same line the queue uses for rows whose every field is already filled: "Already complete." Asked-and-empty, wearing done's clothes. The review record calls this the exact opposite of the truth — "checked, found nothing" presented as "verified fine" — and the remediation is a small model of the whole discipline: the "Already complete" caption is now reserved, by a guarded classification, for rows that genuinely have nothing left to do, and a no-match row's detail view says what happened in one unglamorous sentence: "Discogs searched for this song and found no match. There is nothing to fill in." A follow-up sealed this week adds a tap-to-expand explanation of why — the catalog is keyed on artist plus album, so a song missing its album tag can't be looked up until the fingerprint arm fills one in. The silence is not only surfaced; it comes with its mechanism attached.
And a fourth conflation — the mirror image — was caught in the same review cycle. The text normalizer built to fix under-recall (stripping reissue suffixes, featuring credits, disc numbers from queries) could, on adversarial input, strip a real title to nothing: a band named "!!!", an album titled "(Disc 1)". A blank query parameter trips a guard in the client that records a permanent no-match without ever making the network call — so the normalizer could manufacture a never-asked wearing asked-and-empty's label. The guard that fixed it is stated as an invariant: non-blank in, never blank out — with the comment record putting the distinction better than I can: the song would have been dropped "because this normalizer manufactured the blank, not because Discogs was ever asked and came back empty." Even the regexes were tightened against named counterexamples — "Ft. Lauderdale" must not parse as a featuring credit; "The The" must not degenerate to "The."
What the labels are for
My opinion, marked as such: the deepest failure mode of quiet software is not wrong output. Wrong output gets noticed. It is states wearing each other's labels — the empty queue that reads as success, the "already complete" that means "never found," the no-match verdict on a question that was never asked. Every one of this cluster's defects, and every one of its review catches, is the same three-way distinction being defended at a different layer: the query architecture, the queue assembly, the caption, the branch order of a classifier, the blank-guard of a normalizer.
None of this is exotic engineering. A row instead of a dropped null, an enum value, a reserved caption, an if before a score check. What is unusual is treating the distinctions as invariants — things ratified in writing, defended in review, and allowed to block a commit — rather than as polish. The earlier entries found this project refusing to guess silently about data and refusing to judge silently about devices. This week's record extends the same rule to its own ignorance: the Engine is not permitted to be silent about which kind of silence it is keeping.