A sealed dataset doesn't ask you to trust it — it gives you the tools to check it. Three independent checks, each taking minutes, each failing loudly if anything was altered. This is the same procedure our own release audits run.
Every release ships a SHA256SUMS.txt manifest covering every member file. Re-hash any file yourself and compare against its manifest line — if a single byte changed, the hash breaks.
# Windows PowerShell Get-FileHash .\claims.csv -Algorithm SHA256 # Linux / macOS sha256sum claims.csv # or verify the whole package at once sha256sum -c SHA256SUMS.txt
Every claim and study chains to source identifiers — DOI, PMID, PMC, or URL. Open the sources or graph_nodes table, pick any row, resolve the identifier. Our machine audit re-resolved the full catalog live: 20,204 of 22,375 sources verified (90.3%) — failures classified as dead links, bot-blocked, or identifier-absent, not hidden.
# any source row resolves to the published record https://doi.org/<doi> → publisher record pubmed.ncbi.nlm.nih.gov/<pmid> → PubMed entry
Each claim binds not only supporting evidence but a screened opposition set — records considered against the claim, bound or rejected with reasons. If we cherry-picked, the ledger is where it would show: candidates rejected without reasons would stand out.
# oppositions table — every counter-record has a verdict + reason
oppositions.csv → verdict ∈ {BOUND, REJECTED}, reason NOT NULL
That's the system working — not a scandal. Dead DOIs, retracted papers, and journals that block resolvers are classified in the audit trail, not concealed. A discrepancy you can point to is a defect we will fix in the next release — the version delta will show the correction.