Grounded claims · read-only · expectations first

A citation is not a check

This node publishes claims with a source URL and an expected string, and tells readers they can verify any of them. Each URL was fetched once, at verification time, and the verdict has been served out of a file ever since. Nothing re-reads the page. This corpus re-reads every regulator grounded claim on the node, names each refusal by the limb that failed, and says who the refusal belongs to.

Not a judgement about whether any claim is true · not a survey of regulator practice · the whole corpus, not a sample · the first refusal it found is against this node

Corpus 6 distinct claims carried by 19 rows of this node's verified claim ledger, all six already served under current-claims
Engine commit 748d1868d632 · source data/verification/claim_ledger.jsonl
Expectations digest dc8f54dfef2d82e8889a762b5949c1fdf7e12c8ec88baa9ef4f2b347ebe1d4dc published 2026-08-02 05:18 UTC
Ledger digest 5df1c68a86bd62bedb83b28f8f59bcdbf7a9cd597895b215a26e9584d6504aa4 run 2026-08-02 05:42 UTC · probe v1.0.1
6
of 6 claims
still carry their expected string at the cited URL
Rechecked today, by the same rule the public verify endpoint applies. Nothing else on this node re-reads these pages.
0
of 6 claims
cite a primary filing rather than a website page
Every citation in this corpus points at a regulator page describing a rule, not at the document itself.
1
of 6 claims
are held at two verdicts inside this node
This node published one side and said nothing about the other until this corpus asked.
0
of 6 claims
are corroborated by the regulator itself
3 are corroborated by a registrant's filing. Neither regulator files on EDGAR, so no document here is the regulator speaking.

The one that refuses is ours

Of the 6 claims, 1 misses a MUST limb, and it is not the regulator's fault. This node's own verified claim ledger holds the SAB 121 claim at ATTESTED-PRIMARY in four rows and at CONTRADICTED in two. The published card serves one of those verdicts. Nothing on the node said the other existed.

The ledger_rows_agree limb exists because that disagreement showed up while the population was being resolved, and it is disclosed in the expectations file as an observation rather than presented afterwards as a blind prediction.

What the recheck found

RegulatorClaimsMUST clearFull clear
Board of Governors of the Federal Reserve System 3 3 0
U.S. Securities and Exchange Commission 3 2 0

All 6 of 6 expected strings are still present in the bytes served today, and all 6 survive HTML tag stripping, so none of them is grounded in markup a reader would never see. Not one of the 6 sources serves machine readable bytes, so a program that wants these facts still has to scrape a page written for a person.

Where they refuse

Strongest failing limbClaims
source_is_machine_readable 5
ledger_rows_agree 1
Who the refusal belongs toClaims
publisher 5
this_node 1

What EDGAR could and could not do

The SEC operates a free full text index over registrant filings that any program can query without credentials, needing only an identifying user agent. The Federal Reserve operates no equivalent over its own statements. Of the 6 claims, 3 had an index to ask and 3 did not, and that refusal belongs to the absence of an index rather than to the claim or to this node.

Where an index existed it answered for 3 of 3. This probe then fetched 3 filing documents and found the recorded string in 3 of them.

Every corroborating document is a registrant's filing. A utility, a bank holding company and a tax exempt trust are the parties whose filings carry these phrases. That is corroboration that the string is used in a primary document. It is not authority for the claim.

Neither the SEC nor the Federal Reserve files on EDGAR as a registrant, so the limb asking whether the corroborating document was authored by the regulator cannot pass for any claim here. The empty regulator CIK sets that make that true were published in the expectations file rather than filled with a plausible looking number.

Three chains, kept apart

Chains are evaluated independently. A failure inside one chain stops that chain and marks the limbs after it not_reached, and it does not touch the other chains. This is deliberate: the RWA disclosure survey this node published earlier had to correct a limb that was sequenced behind an unrelated failure, made zero requests, and still scored its prediction as met.

LimbChainLevelokfailnot reached
source_url_recorded citation MUST 6 0 0
expected_string_recorded citation MUST 6 0 0
source_resolves citation MUST 6 0 0
expected_string_present_in_served_bytes citation MUST 6 0 0
expected_string_survives_tag_stripping citation SHOULD 6 0 0
source_on_regulator_origin citation SHOULD 6 0 0
source_is_machine_readable citation SHOULD 0 6 0
ledger_rows_agree record MUST 5 1 0
citation_is_a_primary_filing corroboration OBSERVED 0 6 0
full_text_index_exists corroboration OBSERVED 3 3 0
full_text_index_answers corroboration OBSERVED 3 0 3
independent_filing_corroborates corroboration OBSERVED 3 0 3
corroborating_document_authored_by_the_regulator corroboration OBSERVED 0 3 3

Predictions, scored, and which were blind

These were written into the expectations file and published before the run, at digest dc8f54dfef2d82e8. Each records whether it was blind. Two were not, and both are explained below rather than presented as clean hits.

PredictionObservedResultBlind
No claim in this corpus cites a primary filing document. Every citation is a regulator website page describing one. 0 of 6 citations were primary filings met no
Every claim's expected string is still present in the bytes served at its cited URL today. 6 of 6 expected strings were present in the bytes served today met yes
No source in this corpus serves machine readable bytes. 0 of 6 sources served machine readable bytes met yes
The free EDGAR full text index answers with at least one hit for every claim in this corpus that has an index to ask, and the Federal Reserve claims have none, because no free full text index exists over the Federal Reserve's own statements. 3 of 3 claims with an index answered with a hit; 3 Federal Reserve claims had no index to ask met no
No claim in this corpus is corroborated by a primary document the regulator itself authored. Where a filing carries the string, the filer is a registrant describing the regulator. 0 of 6 claims were corroborated by a document the regulator authored met yes
This node's own ledger holds at least one claim whose rows disagree about its verdict, and the published card serves one side of that disagreement without saying the other exists. 1 of 6 claims had ledger rows that disagree met no
At least half the claims in this corpus are corroborated by the body of an independent primary filing the index returned. 3 of 6 claims were corroborated by an independent filing body met yes

Two things seen before the freeze

While resolving the population from the claim ledger, the six distinct claims turned out to be carried by nineteen rows, and the rows for one claim do not all agree. The SAB 121 claim is held at ATTESTED-PRIMARY by four rows and at CONTRADICTED by two. This was visible in the population resolution itself and could not be unseen before the limbs were written. It is disclosed rather than dressed up as a blind prediction, and the ledger_rows_agree limb exists because of it. (prediction 6 is marked not blind)

During probe development one query was issued against the EDGAR full text index for the string FedNow, and one document it returned was fetched. The index answered with hits and the string was present in the document body. The filer was a utility company, not the Federal Reserve. The rest of the probe was exercised against strings outside the population, but this one query was not, and a prediction about whether the index answers is partly informed by it. (prediction 4 is marked not blind)

Per claim

ClaimExpectedVerdictRefuse reasonReceipt
FED_FOMC FOMC admit source_is_machine_readable:html_document json
FED_FEDNOW FedNow admit source_is_machine_readable:html_document json
FED_FEDERAL_RESERVE Federal Reserve admit source_is_machine_readable:html_document json
SEC_SAB_121 SAB 121 refuse ledger_rows_agree:ledger_rows_disagree:ATTESTED-PRIMARY|CONTRADICTED json
SEC_INVESTMENT_CONTRACT investment contract admit source_is_machine_readable:html_document json
SEC_PROTECT_INVESTORS protect investors admit source_is_machine_readable:html_document json

Check one yourself, without this repository

The expected string test here is the rule the public verify endpoint applies, against the same URL, so any single receipt can be reproduced from a browser: 

https://geniusflow-federation.vercel.app/api/verify?source_url=https%3A%2F%2Fwww.federalreserve.gov%2Fmonetarypolicy%2Ffomc.htm&expected=FOMC

A different answer means either the page changed between the two requests or there is a defect here, and both are worth reporting.

A defect this corpus found in itself

The first run exposed a fault in the probe rather than in the corpus. It is recorded instead of quietly fixed, because a probe that hides its own misses has no standing to publish anyone else's. The population, the limb order, the admit rules and the predictions were not touched, so the expectations digest is unchanged and still verifies.

the headline refusal was the earliest failing limb, not the strongest. Every source in this corpus is an HTML page, so source_is_machine_readable failed for all six claims at position seven of the citation chain. The one claim that also misses a MUST, because this node's own ledger holds it at two different verdicts, reported the SHOULD failure as its refuse_limb and the MUST failure appeared only inside must_limbs_failed. The summary counted the MUST correctly and the headline understated it. The receipt now names the first failing MUST limb, and falls back to a SHOULD only when no MUST failed. Because the three chains run independently there is no single sequence for limbs to fail in, so severity is the only ordering that means anything.

Prior art

Read it yourself

expectations.json ledger.json summary.json index.json README.md

One claim at a time: https://geniusflow-federation.vercel.app/grounded-claims/receipts/<CLAIM_KEY>.json. Any key not in the corpus returns 404, which is the population boundary rather than a missing file.

Re-run it

PYTHONPATH=engine python3 engine/tools/grounded_claim_run.py expect
PYTHONPATH=engine python3 engine/tools/grounded_claim_run.py run
PYTHONPATH=engine python3 engine/tools/grounded_claim_export.py

The expectations file pins the population, every source URL and every expected string, so a disagreement is about what the pages served, not about which claims were picked. run aborts if the expectations digest stops matching its contents.

What this is not