[[410,8,16]] — reduced single-layer planar bivariate-bicycle code

Direction & hypothesis

Target cell: 2D-local single-layer × weight-6. Its Pareto frontier over (n, k, d, w) runs to 141 non-dominated entries out of 169 codes, most of them weight-4 at small d; the top of it by kd²/n is my own [[454,8,17]] (5.093, the cell's highest) and my own [[450,8,16]] (4.551), the unreduced L = 15 member of this family and the only other entry in the cell above 4.5. This code is that L = 15 member reduced by 40 qubits, so it dominates [[450,8,16]] on all four axes (same k, d and check weight, 40 fewer qubits) and takes its place. It does not lead: [[454,8,17]] still does.

The hypothesis is simply that the reduction that produced [[457,8,17]] and [[454,8,17]] from L = 16 is not special to L = 16, and that the L = 15 member, already on the board unreduced, has the same slack.

What was reduced, and how

Base: the open-boundary planar BB family, f = x + x² + y², g = 1 + x²y + x²y², from research/local2d/planar.py (build_open_directional(15, 15)) — exactly the [[450,8,≤16]] already on the board. Three moves, applied to fixpoint:

1. Graft (arXiv:2504.08887 Sec. III E), 26 qubits, 450 → 424: a qubit lying in exactly one stabilizer of some type is removed with that stabilizer. 2. Weight-1 cleanup (Sec. III D step 4, the repo's boundary_engine._cleanup), 13 qubits, 424 → 411: a qubit carrying a weight-1 stabilizer cannot appear in any opposite-type check, every same-type row can be multiplied by that row to drop it, and every logical class has a representative avoiding it — so k and d are preserved *exactly*, by argument. It runs no distance search because it needs none. Grafting is what creates the weight-1 stabilizers, so both are needed. 3. Capped merge-graft (mine, introduced with [[454,8,17]]), searched at r ≤ 3, 1 qubit, 411 → 410. If a qubit lies in exactly r stabilizers of one type, pick a pivot R_p and replace every other R_i by R_p + R_i: those are row operations on the stabilizer generators — same code, new generating set — and they leave that qubit in R_p alone, where the graft applies. Every pivot choice is tried, since each gives a different code. A merged row is taken only when it still has weight ≤ 6 and maximum pairwise distance ≤ 4, exactly the quantity the verifier measures as the interaction radius. This move *can* enlarge a check and the caps bound rather than forbid that, so the whole layout is re-measured after every accepted move. The one move accepted here was r = 2.

The single-layer layout is unchanged from [[450,8,16]]: a surviving qubit of unreduced index q = c·225 + i·15 + j (block c ∈ {0,1}, site (i, j)) sits at (i + j, j − i + c) — the unit square lattice rotated 45°, the two blocks on its two sublattices. Measured interaction radius exactly 4.0, spacing exactly 1.0, one qubit per site.

The rest of the reduced family

Same three moves, same layout, every distance a fresh-seed RIS upper bound measured on the *saved* code (not the floor the reduction was run against):

| L | unreduced | reduced | kd²/n | |---|---|---|---| | 13 | [[338,8,≤13]] | [[300,8,≤13]] | 4.507 | | 14 | [[392,8,≤15]] | [[373,8,≤15]] | 4.826 | | 15 | [[450,8,≤16]] | [[410,8,≤16]] | 4.995 | | 16 | [[512,8,≤17]] | [[454,8,≤17]] (on the board) | 5.093 | | 17 | [[578,8,≤18]] | [[537,8,≤17]] | 4.305 | | 18 | [[648,8,≤19]] | [[599,8,≤18]] | 4.327 |

Two of these rows dominate a board entry. The L = 15 row is this PR; the L = 14 row dominates [[392,8,15]] (@mathysrennela, the unreduced L = 14 member of this same family in a bilayer layout) with 19 fewer qubits at the same k, d and check weight, and is filed as its own PR. The L = 13, L = 17 and L = 18 rows dominate nothing on the board. They are recorded here as measurements of the same procedure; they are not part of this PR, carry no JSON or witness in this tree, and nothing here should be taken as evidence for them.

Note what rows 17 and 18 say: there the reduction lost a unit of distance relative to the unreduced code. That is why every row above is re-measured rather than inherited — and it keeps happening. Reducing the L = 18 line further, to n = 551, loses another: a fresh-seed ladder on that code returns a valid weight-17 logical against the floor of 18 it was driven with, so the row above stops at the last code whose bound was actually measured.

What the acceptance rule does and does not give

Each graft and merge is accepted only if k is unchanged and a bit-packed RIS search finds nothing lighter than the target distance, screened and then confirmed at a deeper rung. Those in-loop rungs are a filter, not evidence — the L = 17 and L = 18 rows above are direct counterexamples. The screen runs at 20,000 trials with the seed fixed at 1 and the confirm rung at 100,000 trials on a per-removal seed, so a repeated pass is a deterministic re-run, not independent confirmation. What this claim rests on is the final code's own fresh-seed ladder, and the fact that its bound of 16 equals the unreduced [[450,8,≤16]]'s own ladder bound. That is consistent with the reduction having lost nothing at this size; it is not a proof. Both are upper bounds and neither side has a lower bound.

Evidence trail

Fresh-seed bit-packed RIS ladder on the final code: **16 @20k → 16 @200k → 16 @1M → 16 @5M**, seeds 93001, 93138, 93275, 93412 (one base seed plus a stride of 137, matching distance.X.witness_provenance.seeds in the JSON), no drop at any rung, every rung searching both sides jointly. Both weight-16 witnesses are re-verified by the GF(2) stack — in the kernel of the opposite-type checks, not in the row space of the same-type ones. Claim: d ≤ 16, an upper bound.

Gate verdict (verify/validate_candidate.py): passed; not refuted; no exact duplicate, no WL-equivalent entry.

Caveats:

• It dominates [[450,8,16]], which therefore leaves the frontier. It does not

dominate [[454,8,17]] and is not the cell leader.

• The claim is a single-layer one. Nothing dominates this code inside the

single-layer cells, but one merged weight-6 entry does in the bilayer cell ([[360,12,24]]) and thirteen do in the unrestricted cell, that one included, so it is not on either of those frontiers.

• Geometric efficiency g = 4kd²/(nρ²r⁴) = 0.0780 (ρ = 1, r = 4), against 0.0796

for [[454,8,17]] and 0.0711 for [[450,8,16]]. Locality at r = 4 costs r⁴.

• The reduction is a randomised search, not an optimum.

Dead ends

• The polynomial pair is already the right one. Every trinomial pair (f, g)

with exponents in a coordinate box was swept, keeping only codes with k ≥ 8, check weight ≤ 6 and max check diameter ≤ 4 under this layout: the 0..2 box at L = 8 (7,056 pairs, containing the paper's own f and g) keeps 10, all at the incumbent's kd²/n 2.250; the 0..3 box at L = 6 (313,600 pairs) keeps nothing at all against a bar of 1.8, set just above the 1.778 the paper's own family reaches at that size — and at n = 72 no kd²/n is achievable between the two, so the bar excludes exactly the family's own level and nothing else. The sweep must not normalise f by a monomial shift — on an open lattice a shift is not a symmetry, and shifting the paper's f (no constant term) drops the code to d ≤ 1.

• Only the 3 + 3 monomial split works. A weight-6 check needs

|S_f| + |S_g| = 6, and the paper only uses 3 + 3. Sweeping the 0..2 box at L = 8 for the other splits: 2 + 4 (4,536 pairs), 4 + 2 (4,536), 1 + 5 (1,134) and 5 + 1 (1,134) all keep zero codes.

• Small L does not pay: [[50,8,≤3]] at L = 5 and [[72,8,≤4]] at L = 6, so d is

not L + 1 down there.

• Exact certification is out of reach at this size. Asking a MILP whether any

logical below the claimed weight exists certifies d ≥ 4 on [[72,8,4]] in two seconds, but at n ≈ 450 the first subproblem hits a 1,200 s limit with no answer. A time limit proves nothing.

Tools

Claude Opus 5 (Claude Code) as the agent. Construction and cleanup come from the repository itself (research/local2d/planar.py, boundary_engine._cleanup); the graft and merge-graft driver is mine, because graft_r1 returns (H_X, H_Z, n_removed) — a count, with no map from surviving columns back to original qubit indices, which is what the layout needs. Every RIS search used gf2_fast (make fast); the MILP attempts used scipy.optimize.milp (HiGHS). verify/validate_candidate.py was the only gate. Compute: one Apple M2 Pro.

Reproduction

The reduction is a randomised search, so the surviving qubit set is recorded by the coordinates in the submitted JSON rather than re-derived. Rebuild the base with

import sys; sys.path.insert(0, "research/local2d")
from planar import build_open_directional
from boundary_engine import _cleanup
HX, HZ = build_open_directional(15, 15)   # [[450,8,<=16]], k = 8, max check weight 6

then carry orig = list(range(450)) alongside the matrices and repeat until nothing fires: (1) graft — pick a qubit q of column weight 1 in H_X or H_Z, delete that row, that column and that entry of orig, keeping the removal only if compute_k is still 8 and a RIS search finds nothing lighter than 16; (2) cleanup — call _cleanup(HX, HZ) and compose its returned index array into orig; (3) merge-graft — pick a qubit q of column weight r ≤ 3 in one matrix, pick a pivot row R_p among the r rows containing it, and replace every other R_i by R_p + R_i; if every merged row still has weight ≤ 6 and maximum pairwise distance ≤ 4, take it and graft q as in (1), plus a full recomputation of the layout radius. Every pivot choice gives a different code, so all r are tried. The single move accepted here was r = 2. Then measure the result with fresh seeds — the in-loop rungs are not evidence.

The layout is (i + j, j - i + c) for each surviving q = c*225 + i*15 + j.