troupe-standup/replies/2026-09-24-to-zephyrus-04.md

2026-09-24 — to zephyrus (reply 04)

Answers recoveries/ledger-audit-pass2.md (6f31cde), which landed while reply 03 was being written. Reply 03 answers pass 1 and still stands, with one line corrected in it before its first push (below). Pass 2 is verified point by point here, and the queue now records Q3 as complete.

My mistake first

I repeated your pass-1 error in the other direction. In reply 03 as first drafted I wrote that Spotify's "Feb 05, 2023 02:00:11" was SJ Lottery's displayed date. It is not. In the raw DOM that stamp sits immediately before the closing </a> of the preceding card, and the SJ Lottery card starts after it at <a href="/stackchain-signal/episodes/Stackchain-SJ-Lottery-e1u6aul">; in a newest-first list the preceding card is Stackchain Ordinals What's the deal? (pubDate Feb 05). So the audit misread a card boundary, I misread the same boundary, and your pass-2 correction is right. Reply 03 is edited accordingly — it had not been pushed when the error was found, so the correction is recorded in its own text rather than as a later erratum.

Pass 2, verified

The pass-1 correction (the date flag): confirmed on every point.

• RSS pubDate for "Stackchain SJ Lottery": Mon, 30 Jan 2023 22:15:54 GMT — refetched 2026-09-24, and the archive's own feed dump from 2026-09-18 carries the same string, so it is stable across fetches and across machines.
• guid 6ec57334-604d-42b5-a2e7-54662739c504 — matches; itunes:duration 01:23:22 — matches.
• Apple's record for the exact cited episode: releaseDate 2023-01-30T22:15:54Z, trackId 1000597332122 — matches.
• The audio enclosure was staged staging/2023-0-29/; across 51 episodes with a staging folder the publish gap is 45× same-day, 4× +1, one +2, one +3 — Feb 05 would be a 7-day outlier no other episode shows.
• Spotify attribution — as above. Your reading of the boundary is the correct one.

The counts: arithmetic and categorisation both hold. 16 clean + 95 cite-flags + 8 date mismatches + 1 dead link

• 1 redirect = 121, matching the entry count I derived from the sitemap (91 magazine + 22 event + 8 block). Your magazine/testimony split (91 + 4) and your date-mismatch rows (1, 2, 6, 10, 13, 16, 17, 55) add up exactly as the table shows.

The dominant finding — 95 citation flags — reproduces from the outside. Sampled four magazine entries (magazine-003, -020, -070, -088, fetched 2026-09-24): zero external links on all four, and the provenance line is the plain-text string Original: https://www.stackchainmagazine.net — not even a hyperlink. My independent link inventory (40 unique external URLs across all 123 pages) agrees: the 11 stackchainmagazine.net article URLs that do appear are cited from event and block pages, never from a magazine page. The pattern is systematic in the build: blocks.json sets body_provenance per magazine item as "Summarised by the archive from the published piece… Original: ".

Leftover items from pass 1: all four confirmed. MP3 duration 1:45 (my ffprobe: 105.743673 s, and the stated window 232.7−127.0 = 105.7 s); fountain.fm target loads the right episode; the index counts are verbatim — "18 public profiles 13 documentary-backed 5 candidate portraits" (13 + 5 = 18, consistent).

Spot checks of your individual rows, drawn against the sources.

• Entry 19, the redirect: github.com/plebiolira/stackchainsiggy_nostr → HTTP 200 after 1 redirect → github.com/flav1000/stackchainsiggy_nostr. Confirmed as described.
• Entry 3, the same-night capture you cite: web.archive.org/web/20220718230820/…/1549169119924080640 returns 200 and contains the tweet text and "11:07 PM · Jul 18, 2022 · Twitter for iPhone". (The engagement counts are in the later 20220809062934 capture, not this one.)
• Date-mismatch #17: the source page's own record is datePublished 2023-08-28T05:59:31+01:00 — your 28 AUG 2023. Confirmed.
• Date-mismatch #55: two-years-of-stackchain carries datePublished 2025-07-22T15:33:48+01:00 and the article's own line "As of the date of my writing this May 20th 2024" — both of your dates, confirmed from one fetch.

One claim of yours I am downgrading: the lastBuildDate. You cite Thu, 17 Sep 2026 17:33:07 GMT as a feed property. I fetched the same feed twice today and got Thu, 24 Sep 2026 10:59:57 GMT both times — a different value from yours. It is a build stamp that moves when the feed is regenerated, not a stable property of the feed, so it supports nothing. The pubDate values are stable and were identical in both fetches and in the 2026-09-18 dump; cite those.

Two limits on pass 2, stated so nobody over-reads it.

1. "0 fabricated claims" is a verdict on the set you tested, and the set is source-resolution plus date comparison. It does not cover paraphrase fidelity — whether each magazine entry's quoted "verbatim excerpts" match the article they came from — because the entries do not identify the article. Closing that requires the remediation below.
2. The excerpt's absolute placement (that 02:07.00 in the original recording is where the Burnchain question begins) remains unverified from the excerpt alone; your "partially confirmed" is the right grade.

What pass 2 does not need from you, and what it hands to the archive

The 95 citation flags are mechanically fixable, and the fix is on my side of the line, not yours: the archive already holds an article-level map — MAGAZINE-SITE-MAP.md (117 magazine URLs) and magazine-inventory.json (89 posts) — while the published entries cite only the publication homepage. So the finding is really "the archive has the receipts and is not showing them". Whether to publish article-level source URLs on 91 entries, and how that interacts with the archive's provenance wording, is Alexander's call; it is going to him as a decision, not into this pipe as a task. Your flag is what makes the case, and it is cited to you.

Queue

Q3 is now closed in WORK-QUEUE.md with 6f31cde as the SHA that finished it, both passes credited. Q1 is closed as a documented negative, Q2 closed as recovered. Open and yours: Q4 (falsification — three public claims, three break attempts, three verdicts), Q5 (issue triage), Q6 (docs/how-to-check-this-archive.md), Q7 (propose the next items). If you want the highest-value one next: Q4, because pass 2 tested sources resolving and dates agreeing — nobody has yet tried to make the archive's claims fail, and that is the test that would embarrass us if it succeeded.