I read this as an independent, read-only release-provenance audit of the exact v33 candidate - I’ll locate the release ledger and artifacts, recompute every bound digest, rerun the required clean/hermetic/bootstrap/rehydration checks, and return a cryptographic verdict with any unresolved evidence called out.


I found the authoritative release entry at `.omo/start-work/ledger.jsonl:167` and the matching v33 prefreeze/postfreeze roots. I’m now validating the seal construction and every ledger-bound artifact independently before running the packaged verifiers from disposable locations.


The static bindings are internally coherent so far: candidate = SHA-256(canonical derivation inputs), product binding and document self-hashes resolve, all three sealed wheels match, Ty is explicitly `--python-version 3.12`, and the authority chain ends with v33 qualified after 18 predecessor revocations. I’m starting fresh disposable executions now; these operate only on `/tmp` copies and leave the release evidence untouched.


The first disposable run exposed two environment-sensitive facts rather than candidate corruption: changing the copied bundle’s directory modes invalidates the sealed wheelhouse inventory, and the standalone verifier expects a generated `postfreeze-seal.json` that is not stored in the immutable prefreeze root. I’m rerunning with byte-and-mode-preserving copies and reconstructing only the documented postfreeze input in `/tmp`; I will treat that missing standalone input explicitly in the final verdict if it cannot be cryptographically derived from the retained postfreeze receipts.


The rerun failures were caused by interpreter drift, not sealed bytes: the active `python3.12` is 3.12.13, while v33’s qualification interpreter is the retained `/home/cube/miniconda3/bin/python3` 3.12.9; the installed provenance probe is intentionally exact and rejected the newer pip/venv output. I found the original hostile-environment commands and am repeating them with the sealed 3.12.9 interpreter and exact file target.


I read this as the final cryptographic release-provenance verdict - I completed the read-only audit and exact-environment reruns.

# Cryptographic verdict: PASS

Candidate `2a6bf1a844e1110e79bfbc59a92a1b8d7d9acc41f1614c1b2ad8f13906a92622` is internally consistent and is the sole current v33 candidate.

- Independently resolved **all line 167 digests**, including candidate, source tree, three wheels, both seals, product binding, lifecycle evidence, authority files, test logs, and postfreeze proofs.
- Candidate recomputation matched SHA-256 of canonical derivation inputs.
- Hermes/profile/Ty wheels matched their bound hashes; all 109 wheel `RECORD` files validated.
- All 17 qualification-tool hashes matched packaged or sealed tools.
- Prefreeze inventory: 391 entries; immutable modes and hashes matched.
- Postfreeze inventory: 55 files; seal, self-hash, sizes, modes, and artifact references matched.
- Authority: 37 registry events and 37 ledger rows validated end-to-end; 18 predecessors revoked; only v33 remains active.
- Source/installed socket transcript canonical hashes matched.
- Canonical `direct_url` projections matched sealed wheel provenance. Raw path-dependent records correctly differed and made no equality claim.
- Profile receipt and source-tree digest matched; retained result is `749 passed`.
- Test receipts resolved: parser 204+204, lifecycle 131, focused 268, expanded 76, gateway 8514/0, direct-url attacks 32, Ty attacks 14.
- Fresh exact-environment executions passed:
  - standalone independent verifier
  - bare frozen bootstrap
  - explicit rehydration/final-state
  - hermetic Ty
- Fresh Ty result:
  - interpreter `3.12.9`
  - target `--python-version 3.12`, exactly once
  - 810 diagnostics, zero capability diagnostics
  - raw SHA-256 `f4a2265141525dc8005430e8afdf61145ff88c24a7fc00aad2d7609b3f2ce86a`
  - semantic fingerprint `4b24118c95c05fa392f976a69034da7e7d24f63d098b32ef5c252537ab13da61`
- Disposable audit roots were removed; release evidence remained untouched.

The generated `postfreeze-seal.json` is not retained in the prefreeze directory, but was independently reconstructed from the sealed inventory algorithm and reproduced its recorded SHA-256 exactly: `de56718d4f59699354840915f2ec82aaa6fad2ae1a0ecf7cf8a1d237cb1cfdc4`.