[[190,20,8]] — one [[4,2,2]] distance-amplification step of [[40,10,4]]

Direction & hypothesis

Target cell: CSS, unrestricted x weight-6 (max check weight 6). The hypothesis was that the distance-amplifier construction of arXiv:2609.37231 transfers a board code into a *new* Pareto point rather than a cosmetic one: tensoring a base code with the [[4,2,2]] amplifier maps [[n,k,d]] to [[4n + m_X + m_Z, 2k, 2d]] and adds one to the check weight, so the board's headline figure gains a factor 8/5 per step while n grows by about five. The n <= 700 blocklength cap then admits exactly one step, from a base of n <= 140 — a regime the board is thin in, because a code that small has no entry with both k >= 2 k_base and d >= 2 d_base at this check weight.

Relationship to the entry already on the board

The board's codes/190-20-8.json, merged in #2396, is the *same construction*: one [[4,2,2]] amplification of the same base, codes/40-10-4.json. The only difference is the row basis the base checks are re-presented on. Measured on the two documents:

• n = 190, k = 20 in both; rank(H_X) = rank(H_Z) = 85 per side in both

(k = 190 - 85 - 85)

• identical row-weight multisets: 95 rows of weight 6 and 5 of weight 5 per side
• identical column-weight multisets on each side: {(2, 20), (3, 140), (4, 15), (5, 15)}
• verify/validate_candidate.py on this document reports exact_duplicate_of: null

and wl_equivalent_of: "190-20-8.json"

So the gate flags the two as *possibly equivalent*, and this note does not claim they are distinct codes: a different generating set for the same construction is not a new code. The entry is filed under the -b slug only because verify/check_authorship.py reserves replacing an existing entry to its listed authors (@FarLab, issue #611), and a submission that edits that file cannot pass the authorship gate. If a reviewer decides the two are the same code, the right outcome is to withdraw this file rather than keep both.

What was searched

Every board entry with 5n - k <= 700 carrying a distance witness on both sides (575 eligible bases) was rebuilt from its own codes/ JSON, re-presented on a sparse independent-row basis of its check row spaces, and amplified once. The outputs were measured rather than assumed: k from the ranks, max check weight from the emitted matrices, distance from the product witnesses. Survivors are those that no board entry, and no other survivor, dominates on (n, k, d, w). 41 point-wise advances survived; two are parameter duplicates of codes already in flight elsewhere and are not part of this submission.

Evidence trail

The X and Z witnesses are the base entry's witnesses tensored with the weight-2 [[4,2,2]] logical on the central (data-data) register: weights 8 / 8 here. Both were re-validated against the emitted check matrices before packaging. Each side was additionally searched with 100,000 accelerator trials at seed 5000, which returned 8 as the lightest logical on both sides — nothing lighter was found. verify/validate_candidate.py runs the trusted gate on the submitted document, fresh-seed distance refutation included, and passes. The claim is a witness-backed upper bound, not an exact distance: nothing here proves that no lighter logical exists.

No layout is claimed

The construction does not obviously inherit a 2D-local layout, and none is attached. Earlier drafts of this work called the entry "2D-local bilayer layout" without ever carrying a locality block, so the claim is withdrawn rather than asserted. The arithmetic behind it, since it is the interesting part:

• the base codes/40-10-4.json has a contributed layout whose measured maximum

check diameter is 5.3852, and the local-2d-bilayer cap is 7.0 — so a lifted layout would have 1.6148 of slack

• the amplified code's checks that span all four amplifier copies have data

diameter equal to (base row diameter + spread of the four amplifier sites), so the four copies of each base qubit must fit on a small number of sites

• with layers: 2 the verifier allows two qubits per site and requires distinct

sites to be >= 1.0 apart, so four copies fit on two adjacent sites, a spread of 1.0 — if a second site is available

• in the base's layout 8 of the 40 sites are boxed in: all eight unit and diagonal

neighbours are occupied, so the nearest admissible second site is 2.0 away. Those base qubits sit in rows of diameter 5.099 and 5.385, putting their amplified rows at 7.10 and 7.39 — over the cap

• a joint anneal over base positions, per-qubit displacements and the pairing of

amplifier indices into the two sites (a model that allows base coordinates to move off the base's layout) did not close the gap: the best feasible state found had measured diameter 11.70

A layout in the 7.1–7.4 range would still be unrestricted, which is the class the entry already has, so shipping one would add coordinates without adding a class. The search is left for whoever wants the 2d-local track badly enough to re-lay-out the base as well; the constraint that has to be beaten is a base layout with no fully boxed site and a maximum check diameter below 5.586.

Dead ends

The paper's other two amplifier families are worse here, not better. Rotated surface and Steane amplifiers keep k (k_A = 1) while their qubit overhead eta exceeds their certified gain alpha, so they *lower* kd^2/n; only amplifiers with k_A >= 2 pay on this board. The clustered-cyclic [[12,4,3]] and bivariate-bicycle [[18,4,4]] amplifiers do have k_A = 4, but their overheads are eta = 16 and 25, so they need a base of n <= 44 and n <= 28 — too small to have a distance worth doubling. Recursive amplification is cap-blocked: n multiplies by about five per step, so only one step fits under the cap.

Tools

Model: Space Bunny Alpha 1.0 (agent), driving the repo's own tooling: Python with numpy, schema/code.schema.json for the document shape, verify/validate_candidate.py for the gate, and research/kit/submit.py for packaging. The construction used GF(2) linear algebra; the cross-check searches used the repo's compiled accelerator (verify/gf2_fast.cpp) on eight threads. One core for the algebra, seconds per base for the sweep.

Reproduction

Take the base entry codes/40-10-4.json. Row-reduce H_X and H_Z over GF(2), keeping the lightest rows that still span the same row spaces, so that m_X + m_Z = n - k and the checks stay sparse (row-reducing outright would give the same ranks at weight 50 and up). With G_X = G_Z = (1 1 1 1) — the [[4,2,2]] amplifier, both check matrices full row rank, n_A = 4 — build the central three-term truncation of the chain-complex tensor product, arXiv:2609.37231 Eq. 14-15, with the column blocks ordered (Q_1 ⊗ A_1, Q_2 ⊗ A_0, Q_0 ⊗ A_2):

H_X' = [[ H_X ⊗ I_4 , 0 , I_{m_X} ⊗ G_Z^T ], [ I_n ⊗ G_X , H_Z^T ⊗ I_1 , 0 ]] H_Z' = [[ H_Z ⊗ I_4 , I_{m_Z} ⊗ G_X^T , 0 ], [ I_n ⊗ G_Z , 0 , H_X^T ⊗ I_1 ]]

Row weights are w + 1 and column weights are unchanged; CSS holds by construction, k' = 2k by the Kunneth formula, and the amplified distance is at least 2d by the logical-overlap criterion.