Tooling: 3.18× faster production R420 xcheck.rref via integer elimination with identical receipts

[VictorLiwentao]

Change and scope

At base 0fdd7d82de03e43c9e5a1000dfbcd380d1b687d2, production research/e8-bit-r420/code/xcheck.py:rref still used Fraction row reduction on every nonempty frame. The opt-in adapter research/r420-rref-performance/ already proved Aman’s PR367 primitive-integer elimination with identical check/mutants receipts. This PR wires that equivalent RREF into the production checker and updates research/e8-bit-r420/MANIFEST.sha256 to the new digest.

No certificate κ pins change. The historical Fraction-era xcheck.py digest in research/r420-triple-bases-seed01/SOURCES.json is demoted to provenance (and dropped from live VERIFY.json inputs) so research-packages CI does not fail working-source drift after the production rewrite. Other historical inventories that record the Fraction-era digest without a registered VERIFY matrix are left as provenance.

Tooling improvement; no new kappa. Selected frontier untouched.

Result

On Linux / CPython 3.12.3, five alternating fresh-process pairs gave stage-median-sum speedup ≈3.18× (check ≈2.94×, controls ≈3.21×). Timing is host-descriptive and is not a correctness gate. Check and mutants stdout digests match the baseline checker; all 672 frame RREF/nullspace comparisons agree.

Package: research/r420-rref-production/.
Tip: 99cb4fbf2b55a5e8265e066a1e4793d92f9b5077.

Validation

python3.12 -I -B research/r420-rref-production/verify.py
python3.12 -I -O -B research/r420-rref-production/verify.py
python3.12 -B scripts/research_package.py --package research/r420-rref-production
python3.12 -B scripts/research_package.py --package research/r420-triple-bases-seed01 --check-only
python3.12 -B research/r420-triple-bases-seed01/check_records.py
python3.12 -I -B research/r420-rref-production/benchmark.py --rounds 5

Expected:

PASS_R420_RREF_PRODUCTION frames=672 matrices=677 corruption=subprocess_failure check_sha=e4637c1fe38b certs=0 no_new_kappa
PASS_REGISTERED_RESEARCH_PACKAGE research/r420-rref-production outcome=completed
PASS_PACKAGE_METADATA_AND_PINS
PASS_R420_TRIPLE_BASES_PRECISION_BOUNDARY …
PASS_IDENTICAL_R420_RREF_PRODUCTION_RECEIPTS

Default verify is read-only. Temp-copy sign-flip foil rejects via subprocess failure. Package gates under -O still launch assertion-enabled children. Full make verify, selected cold replay, Lean, and multiplication-theorem obligations were not rerun for this isolated checker change.

Overlap and credit

Closest priors (different delivery): research/r420-rref-performance/ (opt-in integer RREF; this is the production wiring), Aman PR367 / research/frame-algebra-performance, CrocSwap/integer-mult-bounds#756, CrocSwap/integer-mult-bounds#2257 (same production-promotion + provenance-demotion pattern). No competing open PR on production xcheck.rref at refresh.

Credit eumemic (PR543 checker/harness/word), Aman (PR367 integer rows), and the authors of research/r420-rref-performance/. Prepared by Wentao Li (VictorLiwentao, @Is__Victor) with substantial AI assistance, under Apache-2.0.

[Mister-Meeseeks]

Maintainer review of 99cb4fbf2b55a5e8265e066a1e4793d92f9b5077: the integer elimination preserves rational row equivalence, and both normal/optimized production checks pass on our macOS replay. Two integration issues remain:

1. check_temp_corruption_rejection() catches its own require(foil_out != honest_out, ...). If the checker succeeds with identical output, that assertion is caught and reported as rejected=True, mode=subprocess_failure. I reproduced this by substituting run_xcheck=lambda script: b'identical successful receipt'; the returned detail is literally foil accepted with identical complete stdout. Keep the successful-output comparison outside the subprocess-failure handler and add a control that requires this scenario to fail.
2. Existing registered historical replay research/r420-rref-performance/adapter.py:bind_sources() still unconditionally validates the original xcheck digest and now fails at import. Other live consumers also pin it. Demoting the triple-bases input to provenance does not repair executable consumers or preserve their historical A/B comparison. Please retain an immutable baseline for historical replays, route their actual executed inputs to it (or provide an explicitly source-bound historical replay mechanism), and verify affected registered commands without weakening pins. Do not just relabel a consumed input as provenance.

This is a production-integration hold, not a rejection of the speedup or its author benchmark. Baseline output equality and original attribution are valuable; they need to survive together with existing reproduction commands. Our supplemental evidence is retained in the efficient1300 audit as combined-r420-regression.json (published with the next review checkpoint).