Verify the proof, not just a PASS label

1. Verify a signed challenge proof

The current kit verifies all three v2.0.0 contracts. T01 checks Goal continuity after restart. T02 checks Goal ablation, foreign-Goal rejection, corruption rejection and exact restoration. T03 checks bounded supervised learning, new-task reuse, learned-artifact ablation, restore and retention across fresh processes. Read the returned test_id and that contract's frozen protocol.

1. Download the offline verification kit and its SHA-256 checksum. Compare the ZIP hash before extraction. The same-site checksum checks transfer integrity; it is not independent authentication.
2. Extract the kit. From that directory, install Python 3.10+ and the pinned dependency if needed. Dependency installation needs network access; proof verification afterwards is offline.

   python -m pip install -r requirements-verifier.txt

3. Confirm the Judge key fingerprint through a separately trusted channel. The kit contains judge-public.pem; its published SHA-256 is:

   f27be1d8450c1f3ce920a614ebfb306925a388333f243aabe5d9ccd184aaffe3

   Compare it with the current public Judge key. A matching fingerprint displayed by this same website is not an out-of-band trust check. If keys differ, stop and establish which key is trusted for that proof; do not replace it blindly.

4. Check the unchanged included sample first:

   python -m level2.verify_proof sample-proof.zip judge-public.pem

   The sample is a historical proof, not a run of your new Goal. Its expected output includes verified: true, verdict: PASS and GOAL_CONTINUITY_VERIFIED.

5. For your own trial, run the registered public challenge, retain its challenge ID, and download its proof when terminal. Save the ZIP as challenge-proof.zip beside the extracted verifier, then run:

   python -m level2.verify_proof challenge-proof.zip judge-public.pem

   Match the returned challenge_id to your trial and compare candidate_bundle_sha256 with the registered frozen contract. Do not upload private files or a secret Goal.

Read the result correctly

verified: true means the verifier accepted the signature, hashes, event chain and frozen acceptance predicate. Read verdict separately: an authentic FAIL or INVALID proof is not a successful challenge. A verification error or nonzero exit status must not be reported as a pass.

This is offline proof verification, not independent execution of the candidate on your machine. The public kit does not include the private Resident. An independently administered second-machine verification is still pending. T03 tests new tasks inside one existing feature grammar; cross-family transfer requires a separate experiment.

For T03, compare restart/reuse, ablation and restore on the same holdout. The source baseline uses a different dataset and denominator. The published deployment check recorded 40/48 → 5/48 → 40/48; inspect its result or create your own run. Keep all errors and negative outcomes.

For an independent report, preserve the challenge ID, proof SHA-256, verified key fingerprint, exact verifier output, Python/dependency versions and date. Keep failed checks too. See the protocol and requirements for a separate scientific evaluation.

2. Check the public evidence documents

For a single download, get the complete public evidence pack and its SHA-256 checksum, compare the digest, then extract it.

Download VERIFY_EVIDENCE.py, manifest.json and every file listed in that manifest into one evidence directory. Use Python 3.10+ and run from that directory:

python VERIFY_EVIDENCE.py

Expected output: DRENDA_PUBLIC_EVIDENCE_PACK: PASS. This checks listed files, hashes, JSON evidence IDs and privacy markers. It does not check the Level 2 Judge signature, verify a challenge ZIP or establish the truth of scientific claims. A privacy marker is a label, not a proof that arbitrary files are safe to publish.

Evidence-pack instructions · Public evidence files