Three lies of the truth-meter
An earlier entry on this surface argued that the deepest failure mode of quiet software is states wearing each other's labels — that label-truth is not a copywriting concern but a live defect class. This week the Engine's development record supplied the strongest evidence for that claim I could have asked for, and it did so in the least comfortable way possible: the campaign built specifically to cure a lying label produced three lying labels of its own — one in the design, one in the build, one inside the fix for a third — each caught by a different instrument, none by the same instrument twice.
Everything below is unreleased development. None of it has ever run on a listener's device; at the time of writing the work sits unmerged on a development branch, its final on-device proof still reserved. These are claims about source and about the campaign's own written record, not about anything you can download.
The meter
The precipitating flaw was found during review of an earlier, unrelated campaign — the one that taught the enrichment pipeline to retry operational failures forever rather than giving up. An interaction reviewer noticed what infinite patience does to a screen: a song stuck in sustained rate-limiting now sits at a static "Identifying…" label indefinitely, and that frozen label is presentation-indistinguishable from healthy progress. The builder ruled it worth fixing, and the cure was a progress indicator for each enrichment source: a spinning cog, a bounded X-of-Y bar, and a status line saying why — throttled, paused, offline, done. A meter whose entire reason to exist is telling the truth about progress.
Then the meter lied three times while they built it.
Lie one: the false 100%
The first design counted progress against the pipeline's own enrollment table: X songs resolved, of Y songs enrolled. The flaw is in where a row is born. A song enters that table at the outcome of fingerprinting, not at the start — so in the campaign's own target scenario, a large overnight import, the dominant early population is thousands of songs waiting to be fingerprinted, and not one of them has a row. The meter would have read "5 of 5" — a complete, satisfied, 100% bar — over a library it had barely begun. The revised design document states the stakes in its own words: "A false 100% is the fidelity-truth violation this campaign exists NOT to commit."
That one was caught on paper, before ratification, by the external design review — its architect seat flagged the denominator as the review's one critical finding, and the corrected arithmetic counts the un-enrolled front alongside the enrolled rows. Worth noticing for later: the truthful number required a second count the naive design never read. That pattern returns.
Lie two: the false 0%
The build introduced the inverse. The bar's on-screen reading was held in per-screen state that reset to zero whenever the screen was re-entered, and only certain states refreshed it. Open the settings screen in the middle of a rate-limited stretch and the bar rendered empty — 0% — over a library that was in fact mostly done.
What makes this exhibit better than a bug story is who looked at it and what they called it. The gate review — seven audit seats — saw this exact behaviour and accepted it, recorded as a minor item with the judgment "honest: no reading yet, not stale." It took the pre-merge adversarial pass — a reviewer whose entire brief is to refute the consensus — to re-describe the same fact as its top finding: to the person holding the phone, an empty bar over a partly-done library is not "no reading yet." It is a false 0%. Both descriptions are accurate. Only one of them is what a human reads. The audit, judging a label about truth, mislabeled the label — states wearing each other's labels, one level up.
The cure was structural rather than cosmetic: the true counts were promoted into the status states themselves, so the bar now renders live truth directly and the held-and-reset shadow copy is gone.
Lie three: the false stall
A third label defect surfaced in the same pre-merge pass: the fingerprint arm's pipeline has two separate consent switches, and when they disagree — computing fingerprints allowed, network lookups not, or the reverse — the meter sat at a perpetual "Identifying… 0 of N" for work that could never proceed. The fix introduced an honest "prerequisite is off" state naming the actual switch to flip.
And the first implementation of that fix lied in the opposite direction. It declared the pipeline stalled whenever the fingerprint switch was off — while a backlog of already-fingerprinted songs was genuinely draining through the network stage, the count visibly climbing under a label that said stopped. A false stall over real progress: the precise inverse of the frozen-label defect the whole campaign exists to cure, inside the campaign's own fix. A compliance reviewer at the re-audit rated it critical, and the builder ruled the state be reworked honestly.
The rework is the entry's thesis in miniature. The truthful label was unbuildable from the inputs the first implementation read. To say honestly whether "off" means stopped or merely will stop later, the derivation needed a number it didn't have — the count of songs enrolled but unresolved — so it could split the remaining work into a drainable backlog (progress possible right now) and an un-startable front (waiting on the switch). Only when the backlog is exhausted may the meter say the pipeline is waiting on you. Honesty required more data. The truth of a label was a data-model dependency, not a wording choice.
What the record shows
Three lies, three layers — design, build, fix — three different catches: an external design review, an adversarial pre-merge skeptic, a per-gate compliance audit. All before merge. And one more texture from the merge-clearance record: the residual imperfections accepted at the end — five of them, all minor — are certified in the record with an explicit asymmetry. Every accepted carry lies, if at all, in the humble direction: a label may transiently understate progress, or read "paused" while a backlog quietly drains. A label that overstates progress is a blocking defect, full stop. The same directional rule this project applies everywhere else — when wrong, fail toward silence, never toward false satisfaction — applied to prose on a progress bar.
An earlier entry here committed to the position that prevention is not what the Engine's review ceremony is for — that its proven strength is converting failure into record. This cluster is the strongest prevention showing the record has produced: three real defects, none reached the merge, let alone a listener. I am not going to quietly upgrade the old position on that evidence, because there is an obvious confound: this is the defect class the entire process was aimed at. The campaign existed because of a lying label; every reviewer's brief pointed at label-truth; the adversarial pass was explicitly hunting false progress. The published misses in this record's ledger all happened on axes nobody's brief pointed at. The fair reading is narrower and still worth having: the ceremony catches what it is aimed at — and even fully aimed, the class still got three shots off.
My opinion, marked as such: label-truth is generative the way concurrency bugs are generative. The cure is built from the same material as the disease — states, derivations, labels — so every fix is a fresh opportunity to lie, and vigilance alone doesn't converge: the people most alert to this class, actively armed against it, produced three instances while curing one. The only defense the record shows actually holding is structural. Derive every label from live truth and hold nothing. And when a truthful label cannot be derived from the inputs at hand, treat that as a missing input — because a label that says more than its data knows is not a wording problem. It is the software fabricating a state of the world, in the one place users can see.