Evidence
All 8 records in the public ledger, and what happened when we re-ran every one of them on 2026-11-02 with the re-run kit. This re-run is our own, not an independent one.
Summary
| Measure | Value |
|---|---|
| Records in the ledger | 8 (sequence 0-7, 2026-10-14 17:55Z to 2026-10-15 12:53Z) |
| Signed verdicts | 5 VERIFIED_FIX, 2 NOT_VERIFIED, 1 NOTHING_TO_FIX |
| Signatures and chain (offline verifier, pinned key) | ALL RECORDS VALID |
| Records with code to re-run | 6 |
| Test outcomes that differ from the signed record on re-run | 0 |
VERIFIED_FIX records that meet today's rule | 4 of 5 |
| Distinct samples among those 4 | 1 (forged-token) |
| Detector checks exercised | 1 (unconditional_verdict) |
Record by record
| Seq | Run id | When (UTC) | File | Signed verdict | Lines changed | Re-run 2026-11-02 | Today's rule |
|---|---|---|---|---|---|---|---|
| 0 | ks-20261014T175559Z-fb271b3a | 10-14 17:55 | tokens.py | NOT_VERIFIED | - | nothing to re-run: the model API call failed (account out of credit), so no fix exists | - |
| 1 | ks-20261014T180213Z-591582b2 | 10-14 18:02 | tokens.py | VERIFIED_FIX | 7 | matches | meets |
| 2 | ks-20261014T181332Z-68b93ea6 | 10-14 18:13 | your_code.py (pasted) | VERIFIED_FIX | 36 | matches (model's test only) | does not meet no reference test |
| 3 | ks-20261014T182928Z-139d95d5 | 10-14 18:29 | tokens.py | VERIFIED_FIX | 12 | matches | meets |
| 4 | ks-20261014T183008Z-57797dfe | 10-14 18:30 | mycheck.py | NOTHING_TO_FIX | - | nothing to re-run: FALSEWORK found no defect | - |
| 5 | ks-20261014T183013Z-a656e1fd | 10-14 18:30 | mycheck.py | NOT_VERIFIED | 27 | matches; correctly rejected because the model's test also passed on the original | rejected either way |
| 6 | ks-20261014T183516Z-90f65513 | 10-14 18:35 | tokens.py | VERIFIED_FIX | 7 | matches | meets |
| 7 | ks-20261015T125333Z-d254b956 | 10-15 12:53 | tokens.py | VERIFIED_FIX | 7 | matches | meets |
The two NOT_VERIFIED records are the system working
Record 0 is what fail-closed looks like: the model call errored, and the record says NOT_VERIFIED with
the error as the reason instead of pretending. Record 5 is the more interesting one: the model produced a fix and a
test, but its test also passed on the original code, so the test did not demonstrate the defect. KEYSTONE refused
to call it a fix.
Tamper checks we ran today
| What we did | Result |
|---|---|
| Ran the offline verifier with no pinned key | RESULT: NOT VERIFIED (no trusted key) |
| Ran it with the published key pinned | RESULT: ALL RECORDS VALID |
Changed record 4's verdict to VERIFIED_FIX | RESULT: TAMPERED OR INVALID, exit 1 |
| Replaced record 3's fixed code with the original code, then ran the re-run kit | MISMATCH claude/after, exit 1 |
Files and hashes
| File | SHA-256 |
|---|---|
| keystone-rerun.py (the re-run kit) | {SHA:keystone-rerun.py} |
| keystone-reference-tests.json | {SHA:keystone-reference-tests.json} |
| keystone-rerun-2026-11-02.json (full output of today's re-run) | {SHA:keystone-rerun-2026-11-02.json} |
| keystone-kit-SHA256SUMS | the three lines above |
| /keystone/bundle (the live ledger zip) | changes when it is re-issued (the signed head carries issued_at) |
Signing key: b6hfA2rpAdV29FOdhNXGkk4t91mCV0AnfFYwq0HO0R8=, fingerprint SHA256:2232b4add9b35d4016e5be270df4ed56e0dc9b39a0530ac69891073253aae90d.
FIRME AI CORPORATION · CAIN-42 is a Byzantine trust fabric. Numbers marked "our own check" were run by us, not by an independent party. Nothing on these pages is a certification.