n
457
Target cell: 2D-local single-layer × weight-6, whose leader is [[450,8,16]] at kd²/n = 4.551 (my own entry, merged 2026-09-07). That entry showed a two-block planar code needs only one layer: put the two blocks on the two sublattices of the unit square lattice. The hypothesis here is that the reduction half of the same published construction composes with that layout for free. Both reduction moves only delete qubits or XOR a weight-1 row into others, and neither can enlarge a check support, so a layout already sitting at radius 4 cannot get worse — while every qubit removed at fixed k and d raises kd²/n directly.
Base codes: the open-boundary planar BB family, f = x + x² + y², g = 1 + x²y + x²y², built with research/local2d/planar.py (build_open_directional(L, L)), for L = 13, 14, 15, 16, and (still running at the time of writing) 17 and 18.
Two reduction moves, both from arXiv:2504.08887:
type, together with that stabilizer. Accepted only if k is unchanged and a bit-packed RIS search finds nothing lighter than the target distance, screened at 20,000 trials with a fixed seed and then confirmed at 100,000 trials with a per-removal seed; a qubit that fails the confirm rung is blacklisted.
boundary_engine._cleanup): removethe qubits carrying weight-1 stabilizers. Such a qubit cannot appear in any opposite-type check (CSS commutation forbids the odd overlap), every same-type row can be multiplied by the weight-1 row to drop it, and every logical class has a representative avoiding it — so k and d are preserved *exactly*, by argument rather than by measurement. The elimination cascades: at L = 16 the grafted code had 8 weight-1 X stabilizers and 9 weight-1 Z stabilizers, and removing those 17 qubits left 2 more with degree zero, for 19 in total.
Grafting is what creates the weight-1 stabilizers — the ungrafted L = 16 code has none — so both moves are needed, and the driver alternates them until neither fires. For L = 16 the order that actually ran was graft to convergence ([[476,8,17]], a further pass with a fresh seed removed nothing), then one cleanup pass to [[457,8,17]], after which another graft pass removed nothing.
Results per base size (k = 8 and max check weight 6 throughout, every one with the single-layer layout intact at radius exactly 4 and spacing exactly 1; all distances are RIS upper bounds):
| L | ungrafted | after reduction | kd²/n | |---|---|---|---| | 13 | [[338,8,≤13]] | [[316,8,≤13]] | 4.279 | | 14 | [[392,8,≤15]] | [[378,8,≤15]] (graft only) | 4.762 | | 15 | [[450,8,≤16]] | [[411,8,≤16]] | 4.983 | | 16 | [[512,8,≤17]] | [[457,8,≤17]] | 5.059 |
L = 17 and L = 18 were still reducing when this was written, and the two figures this note gave for them — [[558,8,≤18]] and [[618,8,≤19]], 4.65 and 4.67 — are wrong. Both were read off mid-run log lines rather than measured on a saved code. Re-measuring those runs' saved output with fresh RIS seeds, validating every witness against the opposite-type checks, gives [[537,8,≤17]] (4.305) and, after the cleanup, [[599,8,≤18]] (4.327): the reduction driver's in-loop screen and confirm rungs let a unit of distance through at both sizes. No code was ever saved at n = 558; those runs converged to n = 544 and n = 537. The L = 16 line is unaffected — its bound of 17 equals the unreduced [[512,8,≤17]]'s own ladder bound — and the measured table for the whole family is in the note attached to the [[454,8,17]] submission (PR #935). The L = 13, L = 14 and L = 15 rows above have had less deep verification than the submitted code.
Submitted code: L = 16, 55 of the 512 qubits removed — 36 by grafting, 19 by cleanup. The base [[512,8,≤17]] carries its own ladder in the board's notes/450-8-16.md ("17 at 20k, 200k, 1M and 5M"), so the graft's distance floor of 17 was measured, not assumed.
Distance of the final code, fresh-seed bit-packed RIS ladder (the graft's own per-step checks only ran to 100k trials, so the claim gets its own ladder): 17 @20k → 17 @200k → 17 @1M → 17 @5M. Four fresh seeds (61016, 61153, 61290, 61427 — one base seed plus a fixed stride), no drop at any rung; every rung searched both sides and returned its lightest logical on the X side. The X witness of weight 17 is the 20k-rung one, re-verified by the GF(2) stack; the Z witness of weight 17 came from the packaging search (4,000 trials, seed 7) and is verified the same way. Both sides record survived_samples 5,000,000. Claim: d ≤ 17, an upper bound, not exact.
Gate verdict (verify/validate_candidate.py): passed, not refuted, no exact and no WL-equivalent board entry, "advances the weight-6 x local-2d-single board".
Layout: a surviving qubit whose index in the unreduced code is q = c·256 + i·16 + j (block c, site (i, j)) sits at (i + j, j − i + c); the surviving 457 keep those positions. The verifier measures interaction radius 4.0, one qubit per site, minimum spacing 1.0, and derives local-2d-single. Check weights after reduction run 2..6.
Caveats:
geometric efficiency g = 4kd²/(n ρ² r⁴) = 0.079 here (ρ = 1, r = 4), 0.071 for [[450,8,16]], 0.16 for [[16,4,4]], 1.564 for the cell's best. Locality at r = 4 costs r⁴.
at one less distance, so both stay on the frontier.
may do better, and the reduction is not specific to L = 16.
stopped at [[476,8,17]] (4.857) and further passes removed nothing, yet 19 qubits were still free to go.
base sizes do not pay even after reduction.
original lattice to the surviving columns; that silently keeps rows grafting had removed and produced negative k. A resume has to replay the saved check supports.
Claude Opus 5 (Claude Code) as the agent. Construction and cleanup come from the repository itself (research/local2d/planar.py, boundary_engine._cleanup); the grafting driver is my own, 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 — it also differs in screening with the compiled gf2_fast backend, confirming each removal at a deeper rung with a rotating seed, and blacklisting a qubit that fails that rung. Every distance search used gf2_fast (make fast); verify/validate_candidate.py was the only gate. Compute: one Apple M2 Pro (12 cores), a few hours across all base sizes.
The reduction is a randomised search, so the surviving qubit set is recorded by the coordinates in the submitted JSON rather than re-derived. To rebuild the base code and re-run the method:
import sys; sys.path.insert(0, "research/local2d") from planar import build_open_directional from boundary_engine import _cleanup HX, HZ = build_open_directional(16, 16) # [[512,8,<=17]], k = 8, max check weight 6
Then, carrying a list orig = list(range(512)) alongside the matrices: repeatedly pick a qubit q whose column has weight 1 in H_X or H_Z, delete that row and that column (and the entry of orig), keep the removal only if compute_k is still 8 and a RIS search at 20,000 then 100,000 trials finds nothing lighter than 17; when no removal is left, call _cleanup(HX, HZ) and compose its returned index array into orig. Repeat until neither move fires. The layout is then (i + j, j - i + c) for each surviving q = c*256 + i*16 + j.