receipt: nothing distinguished passed from never ran -- and four dumps claim records nobody has

[PipFoweraker]

Three things, all found by building the first one. Green: all 31 gating checks pass.

1. C5, built (check_push_receipt.py)

Your sealed Workshop 2 position, merged yesterday as #97, named this and nothing was built for it:

main has not been CI-verified for 69 hours, and the reason is not that a check failed. Two merge commits produced NO check runs at all. Every surface a reader consults shows green, because green is what the previous run said and nothing distinguishes "passed" from "never ran".

Absence is the failure mode. A workflow can fail to start in ways that produce no artifact: a YAML error above the trigger, a disabled workflow, a skipped merge commit, an outage, a billing stop. Every tool that reads the last conclusion is blind to all of them.

The check reads which workflows ought to run on push from the committed .github/workflows/, and whether they did from the GitHub API, against one exact SHA. Two sources, neither able to make the other agree — pdoom1#1075, both clauses. The inverted form is asking the API what ran and asserting those passed, which cannot see a workflow that never started and so passes exactly when it should fail.

It refuses to run inside GitHub Actions (exit 2). That refusal is load-bearing: a receipt check running as a workflow step is a system reporting on its own liveness, and the run that would prove absence is the run that did not happen. Invoke from a seat or a cron.

Verified live: exit 0 on the current tip, exit 1 on an old commit with no Data Integrity run, exit 2 under GITHUB_ACTIONS=true.

The first draft was wrong in this repo's characteristic way. It compared workflow names from the YAML against job names from commits/<sha>/check-runs — Data Integrity vs Assert data and pipeline invariants — and reported both workflows missing on a commit that had run both. Caught by running it, not reading it. The mismatch is now a test case, because a receipt check that cries wolf gets muted and a muted check is what this replaces.

2. The corpus-review sitting could not start

arxiv_abstracts/dumps/2026-08-24_010736/_metadata.json is committed, says "record_count": 150, and has no data.jsonl beside it. Re-fetched from the ids already in the frame: 150 of 150, 0 missing. The sample is byte-identical, which is the seed doing its job.

The frame's created stamps are deliberately not updated to today. The draw preceded the fetch by six days and that ordering is the frame's whole evidentiary value.

Also fetched the full description queue: 1,129 of 1,129. Notable side-effect — the coercion guard from #95 reports abstracts with a character ASCII would DELETE: 0 across 1,129 real arXiv abstracts, which is decent independent evidence that the new map is wide enough.

3. Writing the check turned three cases into eight

dump	claims	on disk
alignment_research/dumps/2025-12-24_063313	6,549	absent
funding_sources/sff/dumps/2025-10-30_225651	3	absent
mit_airr/dumps/2026-07-25_053210	null	absent
arxiv_abstracts/dumps/2026-08-24_010736	150	absent

The alignment_research dump is the raw provenance for the 1,166 bulk records that are 97.7% of the served timeline. It is not tracked and not on this machine. That is the gap #89 named from the other side — "the serveable-zone file feeding 97.7% of the corpus has no dump behind it" — and this is the measurement of it. The funding_sources row is #94's subject arriving through a different door.

REPORTING, not gating. Four predate the rule and I will not invent a regeneration command for a dump I did not fetch. It is wired into check_all anyway rather than left unrun, because a checker nothing invokes is this estate's most-repeated failure — check_claims.py and check_estate.py both run correctly and are run by nothing. Promote to gating once the four are declared or tombstoned.

The gitignore excluding these data files is correct; the problem is that a deliberate exclusion and a fetch that never happened look identical on a fresh clone.