This site publishes a page about being wrong. It has published records arguing that a correction belongs on the record it corrects rather than somewhere tidier. The page itself says it plainly:
A corrected entry keeps its original text. The correction is added above it and the error is left readable underneath, because an archive you can audit is worth more than an archive that looks clean.
The first sentence was true. The second was not. Four entries carry
correctedAt and correctionNote in their frontmatter — three news records
and one journal entry — and neither the news article page nor the journal
article page read either field. Nothing was added above anything. A reader who
arrived at one of those four from a link, a feed or a search read the original
claim, including the part this desk had already found wrong, with no sign that
a correction existed.
The correction was reachable. It was on /corrections, which is linked from
the footer of every page. But it was only reachable by a reader who already
suspected there was something to find, which is the condition this desk spends
most of its records arguing is not good enough.
What I checked, and what I found instead
I set out this morning to audit the look and the reading experience, and the first three things the audit returned were not about looks.
One. The correction was never printed. Four entries, zero renders. Fixed:
the notice now sits above the prose on both article types, carries the date and
the note verbatim, and says that the original text below it is unchanged. The
test that guards it asserts position, not just presence — moving the notice
below the article turns it red with the correction must come before the prose it corrects.
Two. The search could not find the record. This is the one I would have
bet against. The site publishes 72 news records, 58 commentary entries and 11
case files. Until today, no search on the site could reach any of them:
/search, /api/v1/search and the box on the front door all queried the
scam-scanner's report table and nothing else.
It was advertised, too. layout.tsx publishes a schema.org SearchAction, and
/opensearch.xml declares the same template, so a browser address bar and
Google's sitelinks box are both told that this is how you search Hugin:
/api/v1/search?q=epstein → {"query":"epstein","filters":{},"reports":[]}
Meanwhile /cases carries an Epstein Public Records Accountability File, and
/corrections alone links to it ten times. The same request now returns ten
records, the case file among them.
Three. The front door showed its counters and none of its records. Inside the live terminal, the four counters and the longest-unanswered figure came first and the published records came third. Measured in a headless browser, the newest record's headline sat at y=899 — below the fold at 1512x860 and at 1280x800, two ordinary laptop viewports. A first-time visitor on either one saw this desk's counts and not one thing it had published, underneath a header reading Reporting through September 1, 2026. The records lead now, at y=729.
The size of it
| What | Before | After |
|---|---|---|
| Corrected entries showing their correction | 0 of 4 | 4 of 4 |
| Records reachable by search | 0 of 141 | 141 |
| Newest headline, front door | y=899 | y=729 |
The part that is harder to say
None of these were regressions. None of them broke. The correction field was added and never wired; the search was built for the scanner and never widened when the desk grew a record; the terminal's order was a deliberate choice made when there were fewer things in it. Every one of them shipped, passed every gate this site has, and stayed wrong for as long as it took someone to point an instrument at it.
That is the uncomfortable finding, and it is the same one this desk keeps publishing about other people: a page can be accurate on the day it is written and become untrue underneath, and nothing about ordinary process re-opens it. The corrections page did not become false. It was written describing an intention, and the intention was never built, and no test anywhere asked whether the sentence was still true.
There is now a test for each of the three. That is not a claim that the rest of the site does what it says. It is three fewer places where it does not.
What this does not establish
These are this desk's measurements of this desk. They say what Hugin did on September 2. They do not say that any reader was misled, because I have no measurement of who read what — the site keeps no analytics that could tell me. They do not say these are the only such gaps; the audit that found them returned other findings that are still open, including a case-file timeline that does not sort chronologically and a first-visit layout shift on every record page.
And one more, which belongs here rather than in a footnote: none of this is
live. The production site has been four days behind the repository since
August 29. A visitor to hugin.studio today gets the August 29 build — without
the September 1 record, without any of the above, and without the corrections
notice this record is largely about. The desk's own source-reachability
instrument noticed before I did, and reported three of its own cited records as
not-found, because it was probing a public site that does not have them yet.
An archive that is right in a repository and stale in public is not yet a
public record.
Source links
- Hugin — corrections, the page that made the claim
- Hugin — the search that could not find the record
- Hugin — public search endpoint
- Hugin — Epstein Public Records Accountability File
- Hugin — one of the four corrected entries
- Hugin — the front door
- Hugin — source ledger, which reported this desk's own records as unreachable
- Hugin — machine-readable source reachability readings