[[164,12,10]] — reduction of the board's [[181,12,10]]

Direction & hypothesis

@mathysrennela established on this board that reducing an existing entry is a contribution in its own right: codes/183-12-10.json and codes/181-12-10.json are theirs, and both merged. ([[181,12,10]] has since been re-filed as [[179,12,10]] in #1065, a frozen-qubit deflation; the original file this reduction consumed is pinned at github.com/unitaryfoundation/qldpc-challenge @ 0b1378f5, codes/181-12-10.json.) This code is the first of them carried 17 qubits further, by a move set their tool does not have.

The hypothesis is narrow and structural. graft_r1_safe removes a qubit that sits in exactly one stabilizer of a Pauli type. A qubit sitting in two or three is untouchable by it — but it need not stay that way, because which stabilizers a qubit sits in is a property of the *generating set*, not of the code.

The move set

Three moves, applied to a fixpoint, on the source's own coordinates:

1. Graft (Liang, Eberhardt, Chen, arXiv:2504.08887 Sec. III E): remove a qubit in exactly one stabilizer of some type, together with that stabilizer. CSS commutation survives automatically, because no other same-type row touches the qubit, so truncating the opposite-type rows keeps every overlap even. 2. Weight-1 cleanup (Sec. III D step 4, the repository's boundary_engine._cleanup): 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 weight-1 stabilizers, so the two moves feed each other. 3. Capped merge-graft — mine, introduced with [[454,8,17]] (#935). If a qubit lies in exactly r ≤ 3 stabilizers of one type, pick a pivot row R_p and replace every other R_i by R_p + R_i. Those are row operations on the stabilizer generators: the code is unchanged, only the generating set moves, and afterwards the qubit sits in R_p alone, where move 1 applies. Every choice of pivot is tried, since each gives a different resulting code.

Moves 1 and 2 can only shrink a check. Move 3 genuinely can widen one, so every merged row is accepted only if it still has weight ≤ 8 and, in the source's own layout, a support diameter within the bilayer cap; the whole layout radius is re-measured after every accepted move. Here it did not move: **6.7082 before and after**, so this code is no less local than its source.

Qubits keep the positions they have in the source [[181,12,10]] (original file pinned at github.com/unitaryfoundation/qldpc-challenge @ 0b1378f5, codes/181-12-10.json; the re-filed [[179,12,10]] in codes/179-12-10.json carries the same coordinates for its surviving qubits). The reduction only deletes, so the layout is inherited rather than re-derived.

What it displaces

It dominates [[181,12,10]] (@mathysrennela) and [[183,12,10]] (@MathysRennela) on all four axes — same k, same d, same check weight, 17 and 19 fewer qubits — so both leave the frontier of every cell they share with it. Inside local-2d-bilayer × weight-8 nothing dominates this code. kd²/n rises from 6.630 and 6.557 to 7.317. It is not the cell leader: [[360,12,24]] holds that at 19.200.

Evidence trail

The in-loop screen and confirm rungs are a filter, not evidence. Each accepted removal was screened at 20,000 trials with a fixed seed and confirmed at 200,000 with a rotating one, against the source's claimed d as the floor — a conservative choice, since a claimed distance is an upper bound, so a loose claim costs removals rather than soundness. What the claim rests on is the final code's own fresh-seed ladder:

10 @20k → 10 @200k → 10 @1M → 10 @5M → 10 @20M, seeds 777001, 777138, 777275, 777412, 777549 (one base seed plus a stride of 137), no drop at any rung, every rung searching both sides jointly. Both weight-10 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 ≤ 10, an upper bound.

The ladder goes to 20M because 5M is demonstrably not enough in my work. A generalized-bicycle candidate of mine held its distance under three independent fresh seeds through 5M and then fell at 20M; the correction that followed is #981. All of my merged entries have since been re-measured at that depth.

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

Caveats:

• This is not an independent construction. It is @mathysrennela's code with

qubits removed. The credit for the code is theirs; the reduction is mine.

• Distance is an upper bound, and it is *inherited* as a floor from the source's

claim. If [[181,12,10]] were ever shown to have d < 10, this code would need re-measuring — though its own 20M ladder found nothing lighter than 10 either.

• It is not the cell leader, and it does not enter the single-layer cells.

Dead ends

• The cell leaders do not reduce. [[360,12,24]] (bilayer weight-6 leader),

[[672,20,32]] (unrestricted weight-6 leader) and [[16,6,4]] (single-layer weight-8 leader) each accept zero moves.

• Small codes do not reduce. [[54,20,4]], [[15,7,3]], [[40,10,4]], [[16,4,4]],

[[54,6,7]], [[25,5,4]], [[84,6,10]] and [[80,9,8]] all gave zero.

• Across fifteen board codes the rule is clean: a code reduces if and only if it

is a larger open-boundary construction with a truncated edge. The move set removes boundary qubits, and a code without a truncated boundary has none.

• The convergence is not a seed artifact. Re-attacking the sibling reductions'

converged states with fresh candidate orders (seeds 91, 92, 93) accepted zero further moves in every case.

Tools

Claude Opus 5 (Claude Code) as the agent. The cleanup is the repository's own 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 what an inherited layout needs. Every distance search used gf2_fast (make fast); verify/validate_candidate.py was the only gate.

Reproduction

The script below reads the source entry as this reduction consumed it. [[181,12,10]] has since been re-filed as [[179,12,10]] (#1065); fetch the original file from git history: github.com/unitaryfoundation/qldpc-challenge @ 0b1378f5, codes/181-12-10.json.

import json, numpy as np, sys
sys.path.insert(0, "research/local2d")
from boundary_engine import _cleanup
d = json.load(open("codes/181-12-10.json"))
n = d["n"]
HX = np.zeros((len(d["checks"]["X"]), n), np.int8)
for r, s in enumerate(d["checks"]["X"]): HX[r, s] = 1
HZ = np.zeros((len(d["checks"]["Z"]), n), np.int8)
for r, s in enumerate(d["checks"]["Z"]): HZ[r, s] = 1
C = np.array(d["locality"]["coordinates"], float)      # positions are inherited

Carry orig = list(range(n)) alongside and repeat until nothing fires: pick a qubit q of column weight r ≤ 3 in H_X or H_Z; pick a pivot row R_p among the r rows containing it and replace every other R_i by R_p + R_i, rejecting the move unless every merged row still has weight ≤ 8 and support diameter ≤ 7 under C; then delete R_p, column q and that entry of orig, keeping the removal only if compute_k is still 12, a RIS search finds nothing lighter than 10, and the recomputed layout radius is still within 7. Call _cleanup(HX, HZ) between rounds and compose its index array into orig. The reduction is a randomised search, so the surviving qubit set is recorded by the coordinates in the submitted JSON rather than re-derived. Then measure with fresh seeds to 20M — the in-loop rungs are not evidence.