Check it yourself.
A forecast specification carries a hash built from the fields published with it. Run the same calculation on those fields and you get the same hash back, so a field changed after the fact no longer matches. A registered forecast also carries a ledger hash, minted over the frozen commitment when it was registered. That one identifies the record and covers fields not published here. Both are below, and neither asks you to take our word for it.
In this section
The records, the feed, and the ledgers.
Scheme nc-v1
How it works
The fields are written out in a fixed order and run through SHA-256. A specification hash is the first twelve characters of that digest with an nc- prefix; that is the form shown for the worked example below and the one this page recomputes. Because the order never varies, the same fields always give the same answer, and any change to any field gives a different one. A ledger hash is written in full with a sha256: prefix, so the two are told apart on sight.
scheme=nc-v1
method=v0.1.0
proposition=Will CMS issue a national coverage determination expanding access to amyloid-directed therapy for biomarker-confirmed early Alzheimer's disease by Q1 2027?
authority=CMS (Centers for Medicare & Medicaid Services)
rung=7 — Payer/coverage action
deadline=Q1 2027
evidence_cutoff=January 2026
threshold=70%
resolution=CMS publishes a final national coverage determination that expands access beyond the current restricted coverage.Hash scope
What the hash covers
And what it deliberately leaves out.
- Proposition
- Authority
- Target rung
- Deadline
- Evidence cutoff
- Threshold
- Resolution rule
- Method version
- Client context or proprietary inputs
- Any probability value. Nothing is registered until a forecast registers
Live check
Verify live
Recompute a specification hash in your browser and compare it to the value published beside it. Select one of the worked examples or edit the text to watch the digest change. This reproduces the nc-v1 specification hash; a ledger hash covers commitment fields this page does not publish, so it is shown for identification and is not reproduced here.
Public registry
The registration ledger
Every registration lands here with its hash.
nc-39c02226c4ad sha256:ad43205978351a4affaeb1d6b2cbe00dd6aa0bdf3ac78fd24f9d7259ca3f34fd 1 registered, 0 resolved. A registered row carries the ledger hash minted when its commitment was frozen; the demonstration row above carries an nc-v1 specification hash you can recompute below.
The observation layer on its own, without the estimate: a specimen ledger shows the dated, sourced, hash-chained record the registered forecast's sources were archived from.
Independent check
Verify independently
Run the recomputation outside this page with Node.js. Any environment that can SHA-256 the serialized fields reproduces the nc-v1 specification hash of the worked example above.
node -e "const {createHash}=require('node:crypto');const t=process.argv[1];console.log(createHash('sha256').update(t).digest('hex'))" "scheme=nc-v1
method=v0.1.0
proposition=Will CMS issue a national coverage determination expanding access to amyloid-directed therapy for biomarker-confirmed early Alzheimer's disease by Q1 2027?
authority=CMS (Centers for Medicare & Medicaid Services)
rung=7 — Payer/coverage action
deadline=Q1 2027
evidence_cutoff=January 2026
threshold=70%
resolution=CMS publishes a final national coverage determination that expands access beyond the current restricted coverage."