The source ledger has one job. It says which of the pages this desk cites can still be read, so a reader knows which claims can be re-checked and which rest on a single reading taken the day they were anchored.
Until this evening it said 49 sources decline this desk's automated reads. That number was on the public page. It was wrong by more than double. The real figure is 19.
Twenty-nine sources were readable the entire time.
What the instrument was actually measuring
Two bugs, independent of each other, both producing refusals that were not refusals.
The first: a HEAD request could end the probe. The prober asks for HEAD first because it is cheap. If HEAD came back 403 the probe classified the source as declining us and returned — without ever trying GET. Plenty of hosts refuse HEAD and serve GET perfectly well. Those sources were recorded as refusing this desk on the strength of a request they were never really asked.
The second is the one worth keeping. A decline was recorded from a single HTTP client. Paired test, one machine, inside one minute, against a page this desk had marked blocked:
curl + this desk's user-agent 200, 152,100 bytes
curl + curl's default agent 403
node fetch + this desk's user-agent 403
node fetch + same agent, accept headers 403
The same identity is served to one client and refused to another. So the filter is not keying on who the request says it is — it is keying on the client stack underneath the name: TLS fingerprint, header order, the shape of the request below the part this desk controls. Adding accept headers to the losing client does not close the gap.
This desk's verification calendar has carried a note since August 12 saying identity could not explain these refusals, written after a page accepted and refused the same identifying client inside one session. This narrows it to something specific and testable. A 403 can be a fact about your HTTP library.
A refusal is now only recorded after a second, independent client has also been refused. Eight sources are readable solely through that fallback.
What was behind the twenty-nine
This is the part that matters, and it is not the arithmetic.
Among the sources this desk had written off: the New Mexico Department of Justice's Epstein litigation documents — press releases, the tips page, and a 507 KB filed complaint. Primary court records. Marked unreachable, and therefore never re-checked from the day they were anchored to this evening.
A source marked unreadable does not just lose a status field. It leaves the loop. The claim verifier skips it, the drift detector cannot compare it, and the citation quietly becomes permanent — true as of one reading, unfalsifiable after. Twenty-nine citations sat in that state because of a HEAD request and a single choice of HTTP client.
So the obvious next question: did any of them stop saying what they are cited for?
The honest answer is that eight became checkable and nothing broke.
Re-running the claim-fingerprint verifier against the corrected ledger:
anchors skipped as blocked ....... 21 -> 13
facts checked .................... 247 -> 255
facts newly checkable .............. 8
of those, present ............... 1
of those, still unverifiable .... 7
previously verified readings that moved ... 0
Seven of the eight are still unverifiable, and that is the finding worth sitting with. Recovering a source means the page can be fetched. It does not mean the specific token this desk cites can be located in it — a filed PDF may not yield its text to the same extraction, a page may render its substance client-side, a fact may live in a table the fingerprinter cannot read as prose.
Fixing the reader is not the same as reading. The ledger is now honest about what it can fetch. It is not yet honest about what it can confirm, and those are different columns. The what a source can settle section published earlier today already separates them; this is the first time the difference has cost something visible.
Nothing that was already verified moved. Two hundred and eight readings stayed present, eleven partial, eight absent — identical. The corpus held.
What this desk got wrong, stated plainly
A published figure on a public page overstated, by 2.6 times, how much of this site's evidence base could not be re-checked. It was not a rounding error or a stale artifact. The instrument was reporting a property of its own HTTP client as a property of the sources, and it did that for as long as the ledger has existed.
There is a pattern in it this desk has now written down three times today. A metric that scored its own caption as the subject of a photograph. A count that rested on an API's silent 10,000-row cap. And this: a reachability instrument measuring its own reachability. An instrument that cannot distinguish itself from the thing it measures will report itself, confidently, with a number attached.
The defence is not better instruments. It is the second client, the control request, the impossible value chased instead of shrugged at — and publishing the correction where the wrong number was published.
Source links
- Hugin: the source ledger — now reading 313 of 335 sources
- Hugin: what a source can settle — fetchable and confirmable are different columns
- Hugin: "August 27 — the check came due" — where the client-fingerprint finding first surfaced
- Hugin: rulemaking that went quiet — today's other instrument, and its own three bugs
