[petalas]

Result

Finite certificate in a necessary-condition model. No new κ. I took the binary normalized paired-stage controller of #5631 (research/paired-stage-chronology-cut) at m = 4 (n = 6 fields, L = 8 calls) and imposed the earlier rank and pairing conditions plus #5631's mixed chronology coefficient (*). Under these conditions, every query system, chronological order, stage pairing and compatible projector choice has

D = 4m - sum_c rank E_c >= 10,

and 10 is attained. The previous bound at this size was D >= 2. This answers #5631's open question (can a constant-loss family satisfy chronology?) at the first open size. It does not settle the all-size question.

	Gram systems
all, L = 8, every order	35,008
no assignment satisfies the conditions	23,564
minimum D = 10 / 12 / 14 / 16	2,400 / 4,760 / 3,084 / 1,200

Evidence

The census enumerates three things. It covers every Gram matrix K = (v_i u_j); systems with equal K are GL(6, F2)-conjugate. It covers every compatible rank-two projector u b + a v, with duplicates removed. It covers all 105 pairings, with every pairwise-commuting choice of targets. A reversal-transpose symmetry halves the work, and the histogram is reweighted by orbit size. PROOF.md gives the lemmas. Controls:

• m = 3 attains D = 0.
• An optimal m = 4 word passes Strengthen paired-stage bounds and add a mixed chronology cut #5631's unchanged chronology.mixed.
• Exchanging that word's first two calls makes the routine report a defect.
• Reversing the call order preserves (*), as the reversal lemma predicts.

Local evidence that is not registered: a separate NumPy implementation without orbit reduction reproduced the full histogram. With (*) removed, a 12-system sample reached minimum D = 4 to 6.

Reproduce from the repository root (Python 3.12, standard library):

~/git/integer-mult-bounds/.venv/bin/python3.12 -B scripts/research_package.py --package research/paired-stage-chronology-m4
~/git/integer-mult-bounds/.venv/bin/python3.12 -B scripts/check_research_commit.py --package research/paired-stage-chronology-m4 --check-source-history
python3.12 -B research/paired-stage-chronology-m4/verify.py                         # witness and controls
python3.12 -O -B research/paired-stage-chronology-m4/verify.py --shard K --shards 7  # K = 0..6

Local results: all 8 registered commands passed (PASS_REGISTERED_RESEARCH_PACKAGE). The full package took 89 s wall time on 18 cores. One shard takes about 130 CPU s, or 35 s wall time with 4 processes. check_research_commit --check-source-history passed.

Limitations

These are necessary conditions only. Passing them does not make a caller: other word coefficients, native realization, restoration and price are unchecked. The model has no thin calls, no idle maps, separate ports and characteristic two. No price exclusion moves, because #5631 already rejects m <= 47 using D >= 2. No m = 5 census or all-size lemma is claimed. Independent human and proof-kernel review have not been done.

Open next questions

1. Does D grow with m? If it grows linearly, Strengthen paired-stage bounds and add a mixed chronology cut #5631's price argument excludes every paired-stage size at κ >= 0.003. The first step is an m = 5 census or a paired analogue of the minimum-query private-projector lemma. The blocker is size: n = 8 gives 2^13 projectors per call.
2. Why is sum r_c <= 6 at m = 4? Classifying the 2,400 optimal systems could give a proof that generalizes. The witness has stage ranks 0, 0, 2 and 4.

Related open work

No open PR studies the paired-stage loss D. Predecessors are #5631 and #5617 (both merged), credited in the package. This account's PRs opened since the CLAIM (#6037, #6038, #6039, #6040) study other objects: chain multiplicities, conjugate-pair calls, Q8 shear identities and P104 helper splits.

CI notes

At head d459d800043bfd3d9f44df7594c2b85774761f58, both hosted checks passed: plan and replay (research/paired-stage-chronology-m4), which includes all seven exhaustive shards and the witness check. Run: https://github.com/CrocSwap/integer-mult-bounds/actions/runs/40612234179 (replay job 11m57s).