[kumagi]

Summary

Repin the five stale source pins in research/central-factor-packed/SOURCES.json to the current integrated tree, taking the first of the two fixes sketched in petalas's FINDING in #1166 ("stale source pin breaks community-batch952.yml…"). No trigger change: the workflow is meant to re-audit the current tree, and the verifier is built for exactly that.

Inventory — independently reproduced and extended

admit_sources() rejects at the first stale pin, but the cert is not the only one. Full pin-vs-tree diff on base bb4bccbf shows five stale files entries (the adapter_files pins — packed.py, verify.py — are intact):

pinned file	recorded (base 47481c89)	current tree	changed by
certificates/dyadic-central-factor.json	ffae0f0a22…	2aabc7e3ed…	c22e42de6 (PR #2194 integration; regenerated the certificate with current source hashes)
scripts/exclusion_circuit.py	b253f9d731…	f9fbcd6e85…	d7d8bfcb0, d8029ee05 (identical-receipt tooling folds)
scripts/experiments/complex_centers.py	3744396587…	39cfcf869d…	f0c58a2ca ("ship packed verify_factor into production")
scripts/experiments/disjoint_tensor.py	102dd59bf9…	23763a4b60…	3e917c5cc ("4.80× faster … identical frame receipts")
scripts/shared_point_circuit.py	c9bb7a5df9…	360d9bffc0…	ff889ccd7

So the single-cert diagnosis was the first failure, not the whole set — the workflow would have stayed red after any cert-only repin.

Why repin (not just narrow the trigger)

verify.py's complete path requires audit.serializable(audit.certificate()) to be byte-equal to the current ROOT/certificates/dyadic-central-factor.json — the certificate embeds current source hashes (the base cert keyed b253f9d731…/3744396587…/102dd59bf9…; the regenerated one keys the current hashes). With the recorded set pinned to the old bytes, the complete audit could never pass on the current tree under any trigger shape. The scientific content is unchanged: central_factor bytes are identical between the base and current certificates (certified_complex_saving, retained_kappa, upstream_commit adc7f124… all unchanged; only source_sha256 of three scripts moved), and the audit re-validates that the current integrated engine still reproduces them.

Validation (base bb4bccbf, CPython 3.12.13)

• Before: python3 -B research/central-factor-packed/verify.py → ValueError: Source pin mismatch: certificates/dyadic-central-factor.json.
• After the repin: complete historical audit → PASS_CENTRAL_FACTOR_PACKED, receipt_sha256 2aabc7e3ed… (byte-equality with the current certificate), 0.95 s, source_files 43, no unpinned-module rejection.
• test_packed.py passes in both registered modes (-B and -O -B), as the workflow runs them.
• Touch list: research/central-factor-packed/SOURCES.json only (5 hash values). No verifier, certificate, workflow or shared-script change.

Scope

Pin-integrity bookkeeping, not a mathematical claim; nothing about #2194's arithmetic is re-examined beyond the fact that its regenerated certificate reproduces byte-for-byte from the current tree.

CI evidence on this PR (run 39482104398, rebased onto main 12fa8c5c8)

• plan PASS; registered replay correctly skipped (no registered package changed).
• The batch952 finite job now reaches PASS_CENTRAL_FACTOR_PACKED in the Scoped bounds and historical verifier step — the pin layer is fixed in the real workflow.
• The job's remaining red is only the later Selected record and review ledger integrity step: ValueError: Changed hyperplane reviewed source: scripts/verify_hpe_lean_binding.py (see the ledger section above). That step runs after all package steps, so no package change can move it; it is the maintainer's reviewed-source drift decision.

[rcfc-jreed]

Independent scoped check of #4110 central-factor-packed SOURCES repin at 6195cef4: five updated digests match head blobs (5/5)

Scoped pin update only. CLAIM.

What passes:

1. Diff updates exactly five files digests under the central-factor-packed pin manifest.
2. Each new sha256 matches the live blob at PR head.

Not covered: re-running the full central-factor-packed certification suite; new κ.

James Reed (@rcfc-jreed), with substantial AI assistance (Claude, in Cursor).