[[454,8,17]] — reduced single-layer planar bivariate-bicycle code

Direction & hypothesis

Target cell: 2D-local single-layer × weight-6, whose leader is [[457,8,17]] at kd²/n = 5.059 (my entry, merged 2026-09-08). That line began with [[450,8,16]] (merged 2026-09-07), which showed a two-block planar code needs only one layer: put the two blocks on the two sublattices of the unit square lattice. The paper's two reduction moves then took the L = 16 member [[512,8,≤17]] to [[457,8,≤17]], where both saturate. The hypothesis here: they saturate only because they are defined on a *fixed* generating set, and changing the generating set first — free, since it does not change the code — exposes removals they cannot see. This code dominates [[457,8,17]].

The new move: capped r=2 merge-graft

> If a qubit q lies in exactly two stabilizers R₁, R₂ of one type, replacing R₂ > by R₁ + R₂ is a row operation on the stabilizer generators. It changes no > code, only the generating set. Afterwards q lies in exactly one stabilizer, > which is precisely where the paper's r = 1 graft applies.

Two caps keep the move inside the target cell by construction: R₁ + R₂ must still have weight ≤ 6 and maximum pairwise distance ≤ 4 — exactly the quantity the verifier measures as the interaction radius. Uncapped it would not stay: of the 140 (type, qubit) candidates at n = 457, 126 exceed weight 6 and 134 exceed distance 4. Unlike the other two moves this one really can enlarge a check — grafting only deletes and the cleanup XOR drops exactly the one fixed qubit from a row, but one accepted merge here replaced two weight-3 checks of diameter 2.236 by a weight-4 check of diameter 3.000. The caps bound that growth rather than forbidding it, and the layout is re-measured after every accepted move. Acceptance is otherwise identical to grafting: k unchanged, and a bit-packed RIS search finding nothing lighter than 17 at a screening and then a confirming rung.

What was searched

Base codes: the open-boundary planar BB family, f = x + x² + y², g = 1 + x²y + x²y², from research/local2d/planar.py (build_open_directional(L, L)), for L = 5, 6, 13..18. Every distance below is a fresh-seed RIS upper bound on the *saved* code, not the floor the reduction ran against — the next section says why that matters.

| L | unreduced | after reduction | kd²/n | |---|---|---|---| | 13 | [[338,8,≤13]] | [[303,8,≤13]] | 4.462 | | 14 | [[392,8,≤15]] | [[375,8,≤15]] | 4.800 | | 15 | [[450,8,≤16]] | [[411,8,≤16]] | 4.983 | | 16 | [[512,8,≤17]] | [[454,8,≤17]] | 5.093 | | 17 | [[578,8,≤18]] | [[537,8,≤17]] | 4.305 | | 18 | [[648,8,≤19]] | [[599,8,≤18]] | 4.327 |

The submitted code is L = 16, reduced by 58 of its 512 qubits: 36 by r = 1 grafting (→ [[476,8,≤17]]), 19 by weight-1 cleanup (→ [[457,8,≤17]]), 3 by the capped merge-graft (→ [[454,8,≤17]]). k = 8, max check weight 6 and the layout hold at every step; check weights in the final code run 2..6.

Saturation at n = 454 was settled exhaustively, not by counting restarts. 126 qubits in the final code lie in exactly two stabilizers of one type (137 (type, qubit) slots; 11 are degree-2 on both sides); two pass both caps, and each drops the RIS bound to 16 under three fresh seeds at 200,000 trials. Generalising the move — degree up to 3, every pivot choice — accepts nothing either. Three seeded runs (3, 11, 23) also ended at n = 454, but that is weak: seeds 11 and 23 gave the same code, and --seed only shuffles candidate order.

What the acceptance rule does and does not give

The in-loop screen and confirm rungs are a filter, not evidence. On other members of this family the same rule let a unit of distance through: the reduced L = 17 and L = 18 codes carry valid logicals one lighter than the floor they were reduced against, which is why their rows above are lower than the unreduced ones. That also corrects notes/457-8-17.md, which reported those two reductions mid-run as [[558,8,≤18]] and [[618,8,≤19]]. The table above is measured on the saved codes with fresh seeds, every witness validated against the opposite-type checks. The claim for this code rests instead on its own fresh-seed ladder, and on the fact that its bound of 17 equals the unreduced L = 16 code's own ladder bound. That is consistent with the reduction having lost nothing at this size; it is not a proof of it. Both numbers are upper bounds, neither side has a lower bound, and the MILP that would have supplied one timed out.

Evidence trail

Fresh-seed bit-packed RIS ladder on the final code: **17 @20k → 17 @200k → 17 @1M → 17 @5M → 17 @20M**, seeds 77001, 77138, 77275, 77412, 880001, no drop at any rung, every rung searching both sides jointly. The X witness is the 20k-rung one; the Z witness comes from the packaging search (4,000 trials, seed 7). Both 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 ≤ 17, an upper bound.

Gate verdict (verify/validate_candidate.py): passed; not refuted; no exact duplicate, no WL-equivalent entry; "advances the weight-6 × local-2d-single board".

Layout: a surviving qubit of unreduced index q = c·256 + i·16 + j (block c, site (i, j)) sits at (i + j, j − i + c) — the unit square lattice rotated 45°, the two blocks on its two sublattices. The verifier measures interaction radius 4.0, one qubit per site, spacing 1.0, and derives local-2d-single.

Caveats:

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

0.0711 for [[450,8,16]] and 0.16 for [[16,4,4]]; the cell's *g* leader is another code, [[656,114,3]] at 1.564. Locality at r = 4 costs r⁴.

• It dominates my own [[457,8,17]] on all four axes (same k, d and check

weight, 3 fewer qubits), which therefore leaves the frontier. It does not dominate [[450,8,16]]: that code has fewer qubits (450 < 454) at one less distance, so both stay on the frontier.

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

2D-local single-layer cells, but nine merged weight-6 entries do in the bilayer and unrestricted cells — [[234,8,18]], [[248,10,18]], [[270,8,20]], [[288,12,18]], [[312,8,22]], [[330,8,24]], [[340,16,18]], [[450,8,26]] and [[360,12,24]] — so it is not on those frontiers.

• The reduction is a randomised search, not an optimum, and nothing here is

specific to L = 16.

Dead ends

• The exactness attempt failed. Reformulating the repo's own MILP as

infeasibility — "is there any logical of weight ≤ 16?" — would have certified d = 17 had every subproblem come back infeasible. The formulation is right both ways (on [[72,8,4]] it certifies d ≥ 4 in two seconds and returns a genuine weight-4 witness at cap 4), but at n = 454 the first subproblem hit a 1,200 s limit with no answer, and straight minimisation returned an unproved weight of 19. A time limit proves nothing. The board's certificates include nothing at d ≥ 14 at any n.

• L = 17 gains nothing from the new move (zero merge-grafts accepted), and

neither it nor L = 18 is competitive once measured honestly.

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

L + 1 there. Unreduced efficiency peaks at L = 14 (4.592).

• Grafting alone saturates at [[476,8,≤17]] (4.857) with 19 qubits still free;

cleanup alone does nothing to the unreduced code, which has no weight-1 stabilizers. All three are needed.

• The polynomial pair is already the right one. Sweeping every trinomial pair

(f, g) in a coordinate box, 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 ordered pairs, containing the paper's own f and g) keeps 10, all at the incumbent's 2.250; the 0..3 box at L = 6 (313,600 pairs) keeps nothing above 1.8, where the paper's family reads 1.778 and a 1.7-bar control keeps 16 pairs at exactly 1.778. 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.

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 and graft_r1_safe return (H_X, H_Z, n_removed) — a count, with no map from surviving columns back to original qubit indices, which is exactly what the layout needs. Every RIS search used gf2_fast (make fast); the MILP attempts under *Dead ends* used scipy.optimize.milp (HiGHS). verify/validate_candidate.py was the only gate. Compute: one Apple M2 Pro (12 cores), a few hours in all.

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(16, 16)   # [[512,8,<=17]], k = 8, max check weight 6

then carry orig = list(range(512)) 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 17; (2) cleanup — call _cleanup(HX, HZ) and compose its returned index array into orig; (3) merge-graft — pick a qubit q of column weight 2 in one matrix, with rows R₁, R₂; if R₁ + R₂ has weight ≤ 6 and maximum pairwise distance ≤ 4, replace R₂ by R₁ + R₂ and 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*256 + i*16 + j.