[[373,8,15]] — reduced single-layer planar bivariate-bicycle code

Direction & hypothesis

This is @mathysrennela's [[392,8,15]] (codes/392-8-15.json, the unreduced L = 14 member of the open-boundary planar bivariate-bicycle family) with 19 of its qubits removed and its layout tightened from two layers to one. It dominates that entry on all four axes — same k, same d, same check weight, 19 fewer qubits — and it lands in the strictest locality class rather than the bilayer one.

Two separate ideas compose here, and neither is mine alone:

• The single-layer placement: a two-block planar code does not need two

layers. Put the two blocks on the two sublattices of the unit square lattice — qubit (site (i, j), block c) at (i + j, j − i + c) — and the interaction radius is exactly 4 with spacing exactly 1, which is local-2d-single rather than local-2d-bilayer. I introduced this with [[450,8,16]].

• The reduction: the same paper's two qubit-removal moves, plus a third of

mine, take out 19 qubits at unchanged k and d.

The hypothesis was simply that they compose — that the reduction cannot break a layout already sitting at radius 4, because two of the three moves only shrink check supports and the third is capped so that it cannot grow one past the cap.

What was reduced, and how

Base: research/local2d/planar.py build_open_directional(14, 14) with f = x + x² + y², g = 1 + x²y + x²y² — the same polynomials codes/392-8-15.json names. Three moves, to fixpoint:

1. Graft (arXiv:2504.08887 Sec. III E), 14 qubits, 392 → 378: a qubit lying in exactly one stabilizer of some type goes, with that stabilizer. 2. Weight-1 cleanup (Sec. III D step 4, the repo's boundary_engine._cleanup), 3 qubits, 378 → 375: 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, and it runs no distance search because it needs none. Grafting is what creates the weight-1 stabilizers, so both moves are needed. 3. Capped merge-graft (mine, introduced with [[454,8,17]]), searched at r ≤ 3, 2 qubits, 375 → 373. 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: row operations on the stabilizer generators, so the code is unchanged and only the generating set moves, and afterwards that qubit sits in R_p alone, where the graft applies. Every pivot choice is tried. A merged row is taken only if it still has weight ≤ 6 and maximum pairwise distance ≤ 4 — exactly the quantity the verifier measures as the interaction radius. Unlike the other two this move *can* enlarge a check; the caps bound that growth rather than forbidding it, so the whole layout is re-measured after every accepted move. Both moves accepted here were r = 2.

Measured on the result: interaction radius exactly 4.0, spacing exactly 1.0, one qubit per site, max check weight 6, k = 8.

The rest of the reduced family

Same three moves, same layout. Every distance is a fresh-seed RIS upper bound measured on the *saved* code, never the floor the reduction was driven with:

| 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 |

The L = 15 row dominates [[450,8,16]] 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, are not part of this PR, carry no JSON or witness in this tree, and nothing here should be taken as evidence for them.

Rows 17 and 18 are the ones worth reading. There the reduction **lost a unit of distance** relative to the unreduced code, and it keeps happening: pushing L = 18 below n = 599, 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.

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. That 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 — and rows 17 and 18 above show it can miss a unit outright. It is a filter, not evidence. What this claim rests on is the final code's own fresh-seed ladder, and the fact that its bound of 15 equals the unreduced [[392,8,15]]'s own board distance. 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: **15 @20k → 15 @200k → 15 @1M → 15 @5M**, seeds 92001, 92138, 92275, 92412 (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-15 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 ≤ 15, an upper bound.

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

Caveats:

• It dominates [[392,8,15]], which therefore leaves the frontier of every cell

the two share. It is not the cell leader by kd²/n: on current main it is fourth at 4.826, behind my [[454,8,17]] (5.093), my [[457,8,17]] (5.059, itself dominated by [[454,8,17]]) and my [[450,8,16]] (4.551); [[410,8,16]], filed separately, would come in above it at 4.995.

• 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.0754 (ρ = 1, r = 4). 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, just above the 1.778 the paper's family reaches there. 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. 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.
• 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; at n ≈ 450 the first subproblem hits a 1,200 s limit with no answer.

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); verify/validate_candidate.py was the only gate.

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(14, 14)   # [[392,8,<=15]], k = 8, max check weight 6

then carry orig = list(range(392)) 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 15; (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, replace every other R_i by R_p + R_i, and if every merged row still has weight ≤ 6 and maximum pairwise distance ≤ 4, graft q as in (1) plus a full recomputation of the layout radius. 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*196 + i*14 + j.