I read this as a read-only cryptographic provenance audit of candidate `2efe939a…3bd82` - I’ll inventory the sealed evidence, cross-check plan/ledger claims, independently recompute every available digest and origin/parity assertion, then issue one evidence-backed verdict.


The evidence set is compact enough for full independent recomputation. I’ve confirmed it contains both release artifacts, installed-runtime parity receipts, source/installed Golden bundles, candidate/product seals, pre/post dirty-tree captures, cleanup seal, and a final inventory; I’m now validating the sealing graph rather than trusting its bundled verifier outputs.


The core cryptographic graph recomputes cleanly, but one audit discrepancy is confirmed: the frozen Golden bundle cannot be rerun with its own verifier because sealing changed its root mode from the verifier-required `0700` to `0500`. I’m treating the three retained pre-freeze outputs as historical receipts and independently validating the now-frozen bytes, RECORDs, archive chain, and runtime instead of counting that failed rerun as fresh PASS evidence.


type: cancelled

previous_status: running

reason: Candidate invalidated by code-quality P1 finding