I read this as a read-only cryptographic release-provenance audit of the exact v17 candidate - I’ll locate the bundle, ledger, verification procedures, and then independently recompute and exercise every requested identity and deployment path without modifying tracked sources.


The exact v17 and postfreeze directories are located. I’m now authenticating their declared schema and verifier behavior before execution, with special attention to whether the “runtime removal” reruns are genuinely bare and whether any claimed equalities are projection-only rather than raw-byte equalities.


message: WebSocket error

stop_reason: error


The design is internally coherent: the stdlib-only bootstrap authenticates the frozen bundle, creates a fresh isolated venv, installs only the 107 sealed dependency wheels plus the two sealed product wheels offline, recomputes installed provenance, checks source/installed parity and authority, and scrubs the venv in `finally`. I’m executing that real path now, then independently recomputing all canonical digests, seals, chains, Ty binding, wheel RECORDs, and cleanup state.


The live rehydration passed with the original runtime already absent and left no temporary runtime. One non-blocking reproducibility discrepancy surfaced in the historical Ty receipt’s explicitly out-of-scope diagnostics: the capability surface still has zero findings, but the unsealed surrounding analysis context now yields 809 rather than 493 outside-surface findings. I’m treating that separately from candidate integrity and running the focused provenance/final-state tests once against the still byte-identical candidate source.


The 112 focused tests passed, but their fixture froze files beneath the disposable `--basetemp`, so the initial shell cleanup could not remove that temporary directory. This is not bundle drift; I’m restoring owner permissions solely on that disposable `/tmp` tree, removing it, and performing the final no-residue/no-drift check.


I read this as the final read-only provenance decision for v17 - I authenticated the bundle, ledger line 162, reran rehydration, and checked cleanup/drift.

# CRYPTOGRAPHIC PASS

Pass applies **within the bundle’s declared trust boundary**. It does not itself authorize release: ledger line 162 still states `release_authorized:false`, `task26_complete:false`, and “pending multi-lane review.”

## Recomputed identities

- Candidate/product: `448252965faa5b936855225eb2a638f65e4f24291c68206fa7de587e8d65aa7f`
- Product binding: `ed67bace5e141bdf371a0fb22fd761b6fc2bcad1f81b3300578dd53d4482321f`
- Source tree, 137 bound files: `b34b2a12fd0ad3d4c95a58c847a2411e81272a646f5a4f5ec568d0d3640a3747`
- Hermes wheel: `9189d87ec649f123e9a44ee45d7f800f6b938c8207e5f399c71e54758a023a3e`
- Profile wheel: `62c508d3548ed5f5fe28c1a137bbc1b6af286d48419dc9e66fa4c7c8422b4121`
- Portable runtime file/runtime identity:
  - `3a943f91983cdec5978ad058ed0dbed77f885db0a161b7b03268e55d11408ef9`
  - `84b48b3780d8999835f0e8f0bcee80537571506ffa497d2045e34e11a2b715f0`
- Capability receipt recomputed in source and installed modes:
  `f810b15aad4d0194bcb940dcd1661679249536ec8c068efbc77b595b76a36f93`
- Source/installed deployment receipt, byte-identical:
  `05948267ef7d5e86bf3e4f29e04c488ec736c432e793078f5d529e52922ddfb7`

## Wheels and installed RECORD

- Hermes: 991 members/991 RECORD rows; RECORD SHA-256
  `8442962a4fa5283a32abccdc8cc6cbdef47909ebbb5ef2a316ebb8288d32cecf`
- Profile: 58 members/58 RECORD rows; RECORD SHA-256
  `45545433260cd10d3354999f3f4c18013886bf17419e14ea6274a4d1517aee95`
- Every member hash, size, path, self-row, and installed row verified.
- Exactly 18 relocated Hermes data rows verified: 16 locale YAML files plus the Linear and n8n optional-MCP manifests.

Portable projections matched original and fresh rehydration:

- Hermes: `4719d451dfa07436213f87f6a94cd5c7b85101dde675125d5aafd3282e7273b4`
- Profile: `547a20d224fe90ef0282ea844c05912d1a10cb0995982ff86c3f22d088d3b958`

Raw RECORD hashes were kept separate. No equality was claimed. Fresh Hermes raw RECORD was `a6f2f369...`, differing from original `3d814a14...` as expected from path-dependent launchers.

## Seals, authority, chains

- Bundle seal: `699ca175e7985ebd91dae2ca721280ccf424a492c0277e1c94bfef9001c6bfa7`
- Postfreeze seal: `1eeac8f2c3f6c2f12c67c07bfbf37e74b68da245bab3a2db8fd91799cace36d0`
- Candidate inventory: 366 entries; exact match. Total sealed files: 368.
- Authority registry/ledger: 25 rows, canonical hashes and predecessor chains valid.
- Current authority is exactly the v17 candidate.
- Source evidence chain: 7 receipts, head `8f4cee6c...`
- Installed evidence chain: 7 receipts, head `73450a61...`
- Both observer chains: 5 valid receipts; `dnotify_signalfd_v1`, one directory resource, zero inotify watches.

Ledger line 162 binds exactly to all recomputed bundle, candidate, wheel, authority, runtime, test-log, and postfreeze hashes. Line SHA-256 including newline:
`7d138f6265af7478e94e61df8b6a597740f19d2585c084580662dc190b600ad7`.

## Actual reruns

- Bare stdlib bootstrap: `TASK26_FROZEN_BOOTSTRAP_PASS`
- Fresh sealed-wheel rehydration: `ACTUAL_INSTALLED_GOLDEN_PATH_PASS`
- Original v17 runtime was absent before execution.
- Hostile `PYTHONPATH` was excluded by isolated execution.
- Fresh runtime was scrubbed afterward; no bootstrap/rehydration directories remain.
- Focused provenance/final-state suite: **112 passed in 4.28s**
- Sealed historical logs authenticate 8,373 gateway, 749 profile, 450 source, 450 installed, 202+202 parser, 129 related, and 25 provenance passes.

## Discrepancy and residual risk

- Ty capability surface rerun still passed with **zero capability diagnostics**, but outside-surface diagnostics changed from sealed `493` to `809`. The source file hash is unchanged. The historical Ty executable itself is referenced by absolute path but not cryptographically hashed; only the wrapper, source, receipt, and wheelhouse are bound. This does not invalidate the scoped capability result, but prevents claiming fully hermetic Ty reproducibility.
- The source tree remains intentionally heavily dirty. Its status digest is unchanged before/after and exactly matches the sealed snapshots: `2800d070...`.
- No signatures, external authenticity, non-repudiation, WORM storage, or compromised-operator resistance are claimed.
- Ledger line 162 is not independently signed or self-hashed; its referenced artifacts authenticate, but ledger append-only status remains an operator-account trust assumption.

No bundle/source edits occurred. No writable sealed files, symlinks, temporary runtimes, or test residue remain.