Target cell: CSS, weight-8 x unrestricted — check weight 8 and no layout, so the entry ranks on the weight-8 board. The authoritative catalogue that accompanies arXiv:2607.14091 (Okada and Kasai) publishes 44 pair-partition codes with exact distances, and this repository carried only part of them. The hypothesis was deliberately narrow: screen every catalogue row against this repository's admissibility cap and against the board's own Pareto test, and expect survivors to land as new Pareto points rather than displacers, because those rows were published for this family's parameters and were never searched against this board.
No construction search. The catalogue rows were screened, not optimised:
[[n,k,d]] triples, and 36 of them sitat n <= 700, inside the blocklength cap;
codes/ before this batch;verify/validate_candidate.py asnon-dominated in their own cell and make up this batch. The other three are [[110,8,12]], [[190,8,18]] and [[200,54,10]], accounted for under dead ends.
The check matrices are the authors' published instance, used byte for byte. Screening reproduced here: CSS commutation H_X H_Z^T = 0 over GF(2); rank(H_X) = rank(H_Z) = 103, hence k = 280 - 206 = 74; every row of both matrices has weight 8. Only after those agreed was a distance search run.
Published description of this instance: GPM-PP frontier addition over the regular C5 x C7 (= C35) action, seed 2026081205, trial 85.
The submit gate for this instance: 3,000 Python RIS trials per side, then a 2,000,000-trial verify/gf2_fast accelerator pass, both at seed 0; the verifier then re-ran a refutation search against the written entry. Lightest logical found on each side was d = 12, matching the catalogue's claimed distance, with both witnesses written into codes/280-74-12.json.
python verify/qldpc_verify.py codes/280-74-12.json exits 0. The catalogue reports these distances as exact; this repository records only the witness-backed upper bound, because verify/certify.py is out of its envelope at k = 74. CI re-runs a deeper refutation search on the PR and the weekly sweep keeps re-testing, so a wrong d would surface as a refutation rather than a quiet pass.
n = 700 and n = 1000 and the seventeenpast n = 1000 were left out of this batch. Past 1000 they fail the blocklength cap outright; between 700 and 1000 they would additionally need w <= 8 and d <= 40, and their check weights were not screened here. That is a stated gap, not a claim of inadmissibility — it is the obvious next batch.
verify/certify.py is measured tohold only at d <= 13 and k <= 12, and this code runs at k = 74, so the claim here is an upper bound by design rather than a shortfall of the search.
layout with a smaller neighbourhood would open a different cell, but the published instance is a circulant construction and no coordinates come with it; inventing some would be a separate submission with its own evidence.
[[110,8,12]] and [[190,8,18]] are reported dominated by verify/validate_candidate.py (by [[104,8,12]] and [[170,8,20]] respectively), so they would ship as a dominated entry beside a stronger one. [[200,54,10]] appears only as a GPM-PP comparison point in the catalogue's prose and ships no instance file, so there is nothing to submit even if it cleared the frontier.
Model: Mimo-V2.6-Flash, driving an opencode agent session opened by @MathysRennela, who opened this PR. Repo tooling: ./qldpc submit for the witness search and packaging, verify/qldpc_verify.py for the local gate, verify/check_prose.py and verify/prepush_prose_check.sh for the prose gate. The accelerator is verify/gf2_fast, built from verify/gf2_fast.cpp.
Rebuild (H_X, H_Z) with no other input:
1. Download the published instance from https://kasai.ict.eng.isct.ac.jp/pair_partition_cpm_css_codes_data/distance_records/gpm_pp_frontier_20260811/c5c7_d12/gpm_pp_c5c7_frontier.npz (sha256 a49a766fcd303d310b5fade7ed6f3bfae7edf275b0c407205c710aa952675095). 2. The file stores dense binary H_X and H_Z of shape 105 x 280 under the keys Hx and Hz; load them directly, no expansion step is needed. 3. Confirm H_X H_Z^T = 0, rank 103 on each side (the 105 rows carry two redundancies), k = 74, and max row weight 8. 4. Only after those agree should a distance search be run; the witnesses in codes/280-74-12.json are the ones this entry stands on.