# NULLIUS verifiers, release 2026-10-27

Three clean-room verifiers. Each one is a single Python file with zero CAIN imports. It needs Python 3 and the
`cryptography` package. It exits 0 only when the evidence proves the claim against the public keys **you** pin.

| File | Checks | Sample evidence to try it on |
|---|---|---|
| `verify_mission_journal.py` | an Evolution 16 mission journal | `/evidence/evolution-16-durable-mission-runtime/sample/` |
| `verify_execution_truth.py` | Evolution 18 execution-truth receipts | `/proof/bundle/sovereign-reality-evolution18-2026-10-12/fixtures/` |
| `verify_launchpad.py` | an Evolution 14 Launchpad deployment export | `/evidence/evolution-14-sovereign-launchpad/sample_deployment_export/` |

Check the files against `SHA256SUMS` before you run them.

## What changed since the copies inside the 2026-10-12 bundles

The earlier copies are left unchanged inside their bundles and auditor-kit releases, because those releases record
their hashes. Use these files instead. A live audit on 2026-10-27 found the following.

* **execution truth: replay could not be checked from the command line.** The tool took one receipt, so the
  published `replayed` fixture, which must be FAILED, came back VERIFIED. It now takes several receipts and keeps
  one record of receipt and authorization ids across them:
  `python3 verify_execution_truth.py R1.json R2.json ANCHORS.json`.
* **execution truth: the enforcer could hide a sensor.** A failed sensor leaves no trace in a receipt, and the
  enforcer chooses which observations to include. An enforcer that dropped the one anchored sensor that saw an
  undeclared write got VERIFIED. Now, if any sensor you anchored did not report, the result is INCOMPLETE
  (`ANCHORED_SENSOR_DID_NOT_REPORT`).
* **launchpad: fields were shown but never checked.** Changing 410 of 1,168 single fields in the sample export
  still gave VERIFIED. Examples: a step's visible `action` (for instance to `delete_everything`), its `state` and
  `action_digest`, the gate's signed receipt, each record's `digest`, the dispatch decision id, the order of the
  history, the export schema and the deployment id. Every one of these is now checked against the signed records.
  The changes still accepted are only these: one witness statement out of four (three still meet the threshold of
  3), the producer's free-text note, an under-claimed quorum flag, a reordering of history sequence numbers that
  keeps them strictly increasing, and the producer's paging window, which the output now labels as unverified.
* **mission journal: a crash on malformed input.** A line that was valid JSON but not an object stopped the tool
  with a traceback. It now gives a clean FAILED. Nothing was ever accepted.

The mission-journal verifier passed every other attack: 132 single-digit edits, truncation against the witnessed
head, reordering, duplication, a swapped trust file, and the same attacks under `python -O`.

## What VERIFIED does not mean

These verifiers check the evidence against the keys you pin. They do not check the channel you got the keys from,
whether a signer told the truth, or anything that happened outside the recorded run. The verifiers were written by
the same project as the systems they check, and no third party has reproduced these results.