[[128,14,12]] — bivariate bicycle code C(c,d) on Z_8 × Z_8 from arXiv:2407.03973 Table 1

Direction & hypothesis

The weight-8 × unrestricted cell. The hypothesis was narrow and structural rather than a parameter sweep: Table 1 of arXiv:2407.03973 lists ten bivariate bicycle codes whose generators are printed in full, so every row is a complete specification rather than something to be searched for. If the convention is right, all ten rows should reproduce their published [[n,k,d]] exactly — that agreement is the real test, and it is what pinned the convention below. Having pinned it, the question became which of the ten rows are off-board and undominated.

[[128,14,12]] was the target: k = 14 at n = 128 with w = 8 gives kd²/n = 14 · 144 / 128 = 15.75, and the board had nothing in the cell.

What was searched

No random search. One paper's Table 1, ten rows, all built and screened:

• Transcribed all ten rows of Table 1 into research/bb_table1.py as exponent

pairs (x order l, y order m).

• Built each with the BB rule H_X = [M(c)|M(d)], H_Z = [M(d)ᵀ|M(c)ᵀ],

M(p) the sum of monomial permutation matrices over GF(2).

• Screened every row at its constructed weight against the live board using

the verifier's own 4-axis Pareto rule, and checked on-board status by filename.

Trials for the submitted code: 200k (seed 20261006, screening pass), then a two-rung confirmation ladder on independent fresh seeds. See "Evidence trail".

Evidence trail

Convention pinning. research/bb_table1.py reproduces all ten of Table 1's [[n,k,d]] exactly, and independently reproduces the board's own baseline codes/144-12-12.json (n = 144, rank 66 per sector, k = 12). `build_from_table ("128-14-12") regenerates the submitted H_X and H_Z` bit-for-bit.

Two convention errors had to be eliminated first, both of which produce a *valid* CSS code rather than an error:

1. Transposed orders. With l and m swapped the code still commutes but has the wrong k — [[144,12,12]] came out at k = 8. Caught by comparing against codes/144-12-12.json. 2. Mis-transcribed exponents. Reading y³ as (3,0) instead of (0,3) across the whole table, and x + y³ + y⁴ as 1 + y³ + y⁴, gave k = 0 and k = 2 respectively. Caught because 9 of 10 rows disagreed with the paper.

Both are silent: the matrices are square, the ranks are plausible, and CSS commutation holds throughout.

Distance ladder for [[128,14,12]] (each rung an independent seed):

| rung | trials | seed | lightest logical found | |---|---|---|---| | 1 | 200,000 | 20261008 | 12 | | 2 | 1,000,000 | 20261009 | 12 |

Both sides carry a weight-12 witness: X on qubits {65, 67, 68, 80, 98, 100, 101, 102, 103, 112, 114, 118} and Z on {8, 28, 40, 60, 83, 85, 107, 111, 113, 119, 123, 127}.

The claim is an upper bound. d = 12 is witnessed, not certified; the distance could be larger. This matches the paper's own claim for the row.

Gate. verify/validate_candidate.py returns passed: true with board_advancing: true, advances_by: ["d", "k", "n"], dominated_by: [], cell weight-8 × unrestricted.

Dead ends

• [[162,24,6]] from the same table looked board-advancing on parameters

(kd²/n = 5.33, undominated at w = 6) and built to the paper's n = 162, k = 24. The gate rejected it: `failed_checks: ["tanner_connected", "stabilizer_group_connected"]`. Its Tanner graph is disconnected, so the d = 6 it exhibits is not a property of a single connected code. Not submittable; screening on parameters alone would have missed this.

• The other eight rows are genuinely dominated, at their own weights:

[[108,16,6]] by [[96,16,6]], [[162,4,16]] by [[154,6,16]], [[162,12,8]] by [[150,16,8]], [[270,8,18]] by [[270,8,20]], [[162,8,12]] by [[162,8,14]].

• [[90,8,10]] and [[144,12,12]] screen as advancing but are *already on

the board*; a board entry does not strictly dominate itself, so they must be excluded by filename before screening or they inflate the count. This bit a screening harness in this campaign twice.

• A sibling paper screened worse than it looked. arXiv:2608.09115

(divisor-driven bicycle search) was screened as a fresh lead, but the board already holds 10+ entries citing it, [[66,20,7]] among them; its codes are weight-19 to weight-38, not the weight-6 the metadata suggested.

Tools

Model: Space Bunny Alpha 1.0. Agent harness: OpenCode. Repo tooling: research/kit/bb.py (build_bb), research/kit/css.py (compute_k, verify_css, GF(2) rank via verify/gf2.py), research/kit/surrogate.py (distance_rand), research/kit/submit.py (make_submission, save_submission), research/kit/coordination.py (gate). Verification: verify/validate_candidate.py unmodified. Compute: the distance ladder is ~1.2M trials per side on n = 128; screening the ten rows is seconds.

Reproduction

import sys; sys.path.insert(0, "research")
from bb_table1 import build_from_table
HX, HZ = build_from_table("128-14-12")

Equivalently, the exact parameters:

import sys; sys.path.insert(0, "research/kit")
from bb import build_bb
HX, HZ = build_bb(8, 8,
                  [(2, 0), (0, 1), (0, 3), (0, 4)],   # c = x^2 + y + y^3 + y^4
                  [(0, 2), (1, 0), (3, 0), (4, 0)])   # d = y^2 + x + x^3 + x^4

with HX, HZ of shape (64, 128) over GF(2), giving n = 128, k = 14 and uniform check weight 8. Running python research/bb_table1.py prints the reproduction table for all ten rows.