Pin the code that defines inherited provenance checks

Pin the code that defines inherited provenance checks before importing or trusting its tables. A derived experiment may validate every data/config hash listed by an earlier launcher yet still have a circular trust gap if that launcher itself is not checked against a known-good digest: drift in the imported file can redefine the very pins being validated. The safe order is (1) verify the prior launcher/executable digest, (2) import or read its pin tables, (3) validate every inherited source/data pin, and (4) bind the derived launcher and fresh admission/preparation receipts. This applies when reusing executable provenance logic; it does not replace independent artifact identity checks.

Evidence/example (2026-09-10): During an offline audit of a derived LoRA trial launcher, the dataset, completed baseline receipt, source tree, tokenization digest, and target-only config delta were all gated, but the launcher supplying the inherited pin table was only recorded dynamically rather than compared with its canonical executed digest. Adding that pre-import gate closes the trust gap. No GPU job or inference was run. Source provenance: local executed-run receipts and launcher/config SHA-256 audit.