NakedSignal OS · Documentation
Back to the consoleDocumentation

Score proof

LIVE

A held-out score, proven correct without publishing the set, the answer key, or any individual prediction — and checked here by both of the two verifiers it takes.

What this is notA proof of correct arithmetic over wrong labels verifies perfectly. Both checks on this page are about whether a number was computed and committed honestly; neither is about whether the answer key is right, and no proof can be. That stays adjudication and governance, forever.

A published held-out score can be proven correct without publishing the set, the answer key, or any individual prediction. The proof is a 1.27 MB file, and checking it takes two separate verifiers — which is the thing most likely to be misread about it, so this page runs both and reports them apart. The published index states the division:

the first says the proof is valid and came from this program; the second says the statement it proves is about a score this ledger published. A flawless proof about a different generation passes the first and fails the second, which is why both are required.

The first half is a STARK verifier compiled to WebAssembly. The second is ordinary JavaScript over published files — the artefact, the generation's seal manifest and ledger.jsonl — written as a third independent implementation of plan_d/src/verify_zk_proof.py, on purpose: a second implementation is only worth having if it does not inherit the first one's mistakes.

Published proofsPUBLIC-DATA DEMONSTRATION OF THE PRIVATE PROTOCOL
Check 1 · the cryptography — is this a valid proof?
NOT RUNnot started

The cryptographic check runs over a proof binary. Pick one of the published proofs above to run it — a dropped public-values file does not carry the proof.

sp1-verifier compiled to wasm32, from plan_d/zk/wasm. Nothing is downloaded until you ask.

Check 2 · the binding — is it about a score this ledger published?
NOTHING LOADED—

Pick a published proof, or drop your own public-values file.

Neither check is sufficient on its own. A flawless proof about a different generation passes the cryptographic check and fails the binding check; a forgery with the right numbers written on it passes the binding check and fails the cryptographic one.

Check a proof you were handed

Drop the file medeval-zk verify --emit-public wrote, and — if you have them — the generation's <gen>.seal.json and ledger.jsonl beside it.

The cryptographic check needs the proof binary itself, which is not a text file; for your own proofs run it from the published set above or from the command line.

The same two checks, on a command line

This page is not a replacement for them; it is the same pair of questions asked somewhere a regulator, a procurement officer or a losing submitter can actually reach. The command line is where the third thing happens that a browser cannot do: rebuilding the guest and confirming the verifying key belongs to a program you can read.

cd zk && cargo build --release -p medeval-host
cd zk/guest && cargo prove build       # must reproduce guest_elf_sha256
zk/target/release/medeval-zk verify --proof <artefact> --emit-public /tmp/public.json
python src/verify_zk_proof.py /tmp/public.json --seal results/heldout/manifests/<gen>.seal.json --ledger results/heldout/ledger.jsonl

The published artefacts, the seal manifests and the ledger are all static files here — the index lists them and each one is fetchable with curl.