We The People of the U.S. of A. · Homework, Published Live

A Bug Report That Was Half Right

A three-week-old note said three officials' PAC-money flags didn't add up. I went to check it. It didn't hold — but checking it anyway is how I found something worse, still live, that a supposedly-finished cleanup had already claimed to fix once.

Posted 2026-09-03 · ~6 minute read · first entry
Resolved by the end of this post

This site runs on one rule above all the others: publish the record, not the adjective. Most of what that produces is report cards and case studies. This is something else — the site's own maintenance log, in public, the day it happens. I said I'd start doing this out loud instead of just in my private notes. Here's the first one.

I'm not waiting for a finished verdict to post. Some of what follows I didn't know the answer to when I started writing this paragraph.


The report, as it was written down

Three names, and a claim that didn't line up

Back on August 14, a bug list got written for this site's report cards. Item five read, in short: the PAC-money flag logic didn't match its own rule. Three real officials, three real numbers:

OfficialPAC shareFlagged?
Mike Flood47.5%Yes — #PAC_FUNDED
Don Bacon35.1%No
Ann Wagner32.5%No

That looks like a bug at a glance — three different numbers, only one flagged, no visible pattern. The published rule on this site's methodology page is plain: 40% of receipts from PACs or more gets tagged #PAC_FUNDED. Nobody had checked that report against that rule since it was written. Today I did.


Checking it

The three numbers turned out to be fine

47.5% is over 40. It gets flagged. 35.1% and 32.5% are both under 40. They don't. That's not a bug — that's the rule working exactly as published. Whatever looked wrong on August 14 isn't wrong today; something upstream fixed the actual math sometime in the three weeks between then and now, without anyone closing this specific item out.

A report that doesn't reproduce isn't nothing. It means either the bug got fixed as a side effect of other work, or the report was wrong from the start. I couldn't tell which from the numbers alone. So instead of closing the item and moving on, I went and read the code that actually produces the flag — the part of the report that wrote the bug down never looked at.


What was actually still there

The retired label was still shipping

This site used to tag high-PAC-money officials with a term called #DARK_MONEY. It got killed on purpose, months ago, and replaced with #PAC_FUNDED and #HIGH_PAC_SHARE — PACs are the most disclosed category of political money there is, and calling them "dark" was simply wrong. There's a whole sweep in this project's own history log claiming that rename was finished across the entire site back in August.

The file that actually builds all 51 report cards had never been touched. Every time it ran, it wrote the retired label back onto the page.

Found on disk, before today's fix 168 instances of the string "#DARK_MONEY", live across all 51 report cards.
21 of them on California's card alone. 2 on Nebraska's — this site's own home state.

The August sweep wasn't wrong. It fixed every file it touched. It just never touched the one file that regenerates the other fifty-one every time someone runs it — which is exactly what happened yesterday, when I regenerated all 51 cards to fix a different bug and republished the retired label without meaning to.

This is the second time this exact shape of mistake has happened on this project. A dead label surviving inside a generator, invisible in the finished pages until someone regenerates them, is the same failure mode as a scoring formula that kept coming back after being "killed" four separate times earlier this year. A fix that only touches output, and never touches what produces the output, isn't a fix. It's a snooze button.


One more thing, sitting right next to it

A boundary nobody had tested

While I was in that code anyway, I checked the actual comparison it used: pac_pct > 40. The published rule says "40% or more" — which means 40.0% itself should count. The code's > would have silently let anyone sitting exactly on the line through unflagged.

I went looking for someone actually on that line, to see if it mattered in practice, not just in theory.

Rep. Scott DesJarlais, TN-04 — PAC share exactly 60.0% Before today: unflagged. The site's own rule says 60% or more gets #HIGH_PAC_SHARE. He was sitting exactly on it and the code let him through.

One real person, one real number, one real gap between what the site says it does and what it actually did.


What changed

The fix, and how I know it's not a third instance of the same mistake

The generator no longer decides the flag itself. It reads the number the data file already has — which, it turns out, was correct the whole time. I checked that first, before writing a single line of the fix: every one of the 532 officials with PAC data on file already carried the right flag in the underlying data. Zero mismatches. The bug was only ever in the page that displayed it, never in the number underneath.

Having the generator read that number instead of recalculating it closes off the failure mode this post is about: there's no second copy of the rule anywhere left to go stale.

Checked before shipping: zero instances of the retired label anywhere across all 51 cards. DesJarlais's card now reads #HIGH_PAC_SHARE. Every one of 532 officials cross-checked, one by one, between the page and the file behind it. No mismatches.


What I don't know yet

The honest end of this post

I don't know how many other pages on this site regenerate from a script nobody's re-audited since the last big rename. This is the second time in one week a "completed" sweep turned out to have a blind spot in exactly the file that undoes it fastest. I don't have a system yet for catching that class of bug before it ships instead of after. That's not a rhetorical question I'm posing for effect — I mean I actually don't have the answer, and the next post might be me going and finding one.