On August 27 this desk corrected its source ledger after learning that a page can refuse one HTTP client and serve another, even when both give the same identifying user-agent. The correction recovered twenty-nine citations that had been mislabeled as refusing automated reads.

The ledger was fixed. The claim checker was not.

They sit one section apart on the same public page, read the same corpus, and were giving incompatible answers about eleven citations. The source ledger said each page was readable. The claim checker said http-403, called the fact unverifiable, and moved on.

Fixing that disagreement is what this record set out to do. Doing it exposed two more, both larger — and all three turn out to be the same failure wearing different clothes. This desk was publishing one word, readable, while using it to mean three incompatible things.

One: the same source, two answers

The reachability sweep asks a narrow question: can this desk retrieve the source? Its full run today examined 335 unique URLs.

The claim-fingerprint verifier asks the next question: does the retrieved document still contain the checkable value attached to the citation — a date, money amount, percentage, public-law number, or other normalized token?

Before today's change, that verifier used Node's fetch stack only. Joining its output to the source ledger exposed the contradiction: eleven facts were marked http-403 even though the ledger's independent sweep had just read the same eleven URLs.

This was not an abstract possibility. Hugin had already published the paired test two days ago: from one machine, inside one minute, with the same declared identity, curl received a full document while Node fetch received 403. The source ledger had learned from that test and required a second client before declaring a refusal. The claim checker had not inherited the rule.

When the first reader now receives 401, 403, or 429, the verifier asks a second independent client for the document. It keeps the same identifying user-agent. For PDFs, the second reader preserves the response as bytes before passing it to the text extractor; treating a PDF as a string would create a different silent failure and call it a fix.

The output records which reader succeeded. A recovered source does not get a free pass: its claim still has to survive the same token check as every other claim.

                          before    after
facts examined ......      258       258
confirmed ...........      209       217
verification debt ...       49        41

Two: the largest repair lane was filed under the wrong problem

The queue this record introduces groups every unresolved fact by the work that would clear it. Reading it back after the first fix, the biggest lane was extraction gap — sixteen facts whose documents had supposedly arrived as bytes that would not become usable text. The stated next action was to repair the page or PDF extraction.

Fifteen of those sixteen were the same failure, and it was not extraction.

justice.gov answers an automated request with HTTP 200 and a 2.4 KB document carrying a bm-verify bot-verification redirect and no prose at all. Both of this desk's readers receive it. It is a challenge rather than one client being refused, so the second reader added above does nothing for it. The verifier stripped the markup, found no words, and recorded body-too-short — a label that sent a reader off to repair the extraction of a document that had never arrived.

Those fifteen facts are now bot-challenge and sit in the access gap lane, whose instruction is the correct one: recheck later, and never convert a refusal into an assertion about the document. With them moved, the extraction lane is empty. It never had anything in it.

Hugin does not attempt to satisfy the challenge. Bot filtering is an ordinary thing for a publisher to run, and a record this desk cannot retrieve is recorded as unread rather than worked around. The nine affected press releases — the Maxwell and Epstein charging and sentencing statements, the Bankman-Fried and Celsius sentencings, the Boeing 737 MAX fraud charge, the Bitfinex laundering sentence — remain perfectly readable to any person who opens them.

Three: and that shell had been counted as readable

The same page had already fooled the instrument one level up.

The reachability ledger decided its read outcome from the status line alone. A 200 was a read. So thirteen justice.gov URLs, each returning a bot shell with zero words in it, were counted inside the figure this desk publishes as the number of sources it can actually retrieve.

That figure was wrong, and it was wrong on the public page:

                                    published    corrected
readable, including redirects ....     318          305
answered without a document ......       0           13
declined automated reads .........      14           14
not found ........................       2            2
did not answer ...................       1            1

A success status is not a document. The ledger now records no-readable-text as its own outcome — separate from a successful read, because nothing was read, and separate from a decline, because nothing was refused. The threshold is exactly zero words rather than a "too short" rule: a genuinely terse page, such as an API root of seventy-nine characters, has still been read, and guessing at a minimum length would quietly reclassify real records.

Where a challenge marker is present the ledger says so in a note. The outcome states only what was measured; the likely reason sits beside it rather than inside it.

What the queue says now

facts examined ....................... 258
confirmed ............................ 217
partly found .......................... 11
value not found ........................ 9
could not test ........................ 21
verification debt ..................... 41

The current queue holds 41 facts across 10 cases and 32 source URLs:

Citation review — 20. The document was read, but a cited token was not matched. Re-open the source and either repair the citation or record why the automated check is insufficient.
Access gap — 16. Both readers were refused, or a challenge was served in place of the document. Recheck later; do not convert a refusal into an assertion.
Source recovery — 3. The address no longer produces the document.
Document identity gap — 2. The page that answered cannot safely be matched to the source the claim names.
Extraction gap — 0, for the reason given above.

Nine documents were retrieved by the second client in the latest run. Ten further anchors are skipped because every reader is refused; they are counted separately, since folding them in would make a blocked document look like a tested claim.

One cross-instrument conflict remains — and it is not the one that was there this morning. The OpenAI page that the ledger could read and the verifier could not now agrees across both. In its place, a congress.gov bill page reads in the ledger and returns 403 to the verifier. The count held at one while the row underneath it changed completely, which is the ordinary condition of measuring a live web, and the reason this queue publishes rows instead of a score.

What moved, and what that means

Across the day's runs the consequential figure moved from 209 confirmed to 216 to 217, and the debt from 49 to 42 to 41. One row also moved from "could not test" to "value not found" between two runs that were otherwise identical.

That movement is not noise to conceal. Some of it is this desk repairing its instruments and some of it is the web changing underneath a fixed corpus, and the queue is built so a reader can tell which is which. A system that claims to monitor changing public sources should be able to show when the change is in its own measurement — including when that correction runs against it.

Limits of this record

The fingerprint verifier checks normalized tokens, not truth. A present reading means the cited value was found in the retrieved representation. It does not prove the surrounding proposition, the source's reliability, or the claim's interpretation.

An absent reading means the checkable token was not found. It does not prove the value is absent from every rendering of the document, and it does not prove the claim false. An unverifiable reading says the instrument could not complete the test. It must never be read as evidence in either direction.

no-readable-text is a statement about what this desk received, not about the publisher. It carries no implication that a page is withholding anything, and none about whether a person visiting it would see the record perfectly well. Where a challenge marker was found the ledger names it; where none was found, the outcome says only that no text came back.

None of the three corrections here changes a published claim about the world. They change what this desk says about its own reach — which is the part a reader has no independent way to audit, and therefore the part that has to be volunteered.

Source links

Hugin: verification-debt queue — every unresolved row, grouped by next action
Hugin: source ledger — reachability, claim fingerprints, calendar, and instrument timestamps
Hugin: civic reachability API — machine-readable source and verification-debt records
Hugin: "This desk published that 49 sources refused it" — the source-ledger correction that exposed today's unfinished join
Hugin: "The check came due" — the filed August 27 verification outcome