Detect disconnected / direct-sum BB/PBB candidates in the evolutionary pipeline

Problem

A BB/PBB candidate's Tanner graph can be disconnected — i.e. the reported [[n,k,d]] code is really an m-fold direct sum of smaller, structurally independent sub-codes glued together, not one genuinely larger connected construction. Because FOM = k*d²/n is invariant under m-fold direct-sum replication (n -> mn, k -> mk, d unchanged), a disconnected candidate reports a numerically "correct" FOM while inflating the displayed n and k relative to the smallest code that actually achieves that FOM. Left unchecked, the evolutionary loop can spend budget mutating/reporting replicas that add no new structure.

This is not hypothetical for this project: tests/verify_decomposition_288_24_12.py (already on main) documents a real case where a discovered [[288,24,12]] code turned out, on inspection, to be exactly a direct sum of two copies of the known [[144,12,12]] gross code — caught only via an ad hoc one-off BFS script written after the fact, not by anything in the evaluation cascade.

Where this shows up

• evaluation/evaluator.py (evaluate_candidate, the 5-stage CSS cascade) and evolve/openevolve_evaluator.py (the live fitness function used during LLM-guided mutation) have no connectivity/decomposition check anywhere in the path from candidate -> score. Confirmed by grepping both files on main for connect/component — no hits relevant to Tanner-graph structure.
• evaluation/tanner_equivalence.py already builds the colored Tanner graph (CSS via canonical_hash, non-CSS via canonical_hash_noncss with the required X/Z "tying edge" per its module docstring) for BLISS-based permutation-equivalence checks, so the graph-construction machinery a connectivity check needs already exists and is validated.
• A generalization of the ad hoc verify_decomposition_288_24_12.py script into a reusable module already exists as unmerged work-in-progress (evaluation/connectivity.py + tests/test_connectivity.py, not yet upstreamed) built on top of tanner_equivalence. It provides, roughly:
  • bicycle_translation_component_count(ell, m, A, B, C=None, D=None) / bicycle_translation_is_connected(...) — a cheap, O(w²) (row-weight w), construction-free check via the Smith-normal-form index of the subgroup of Z_ell x Z_m generated by the support differences of A∪C and B∪D. Cheap enough to run as an early gate before the k/distance stages, independent of lattice area.
  • tanner_components(code) / stabilizer_components(code) — connected components of the actual Tanner graph and of the generator-basis-invariant stabilizer row space (the latter needed because row operations can hide a block structure that a connected presentation doesn't reveal).
  • decompose(code, d=None) — structural summary (component count/sizes, base (n0,k0,d0) when homogeneous).
  • components_isomorphic(code) — rigorous pairwise isomorphism via BLISS canonical hashing reused from tanner_equivalence; returns None (inconclusive) rather than a false negative when a canonical-hash mismatch on a non-canonical presentation can't prove non-isomorphism.
• Separately, an audit of the pinned qldpc-challenge comparator codes used in the weight-5 paper (scripts/audit_qldpc_challenge_connectivity.py, also unmerged) found this is not just a risk for our own outputs: of the pinned comparison codes it rebuilt and checked, 21 of 102 were disconnected. Disconnection in BB/PBB-style constructions is common enough in practice (ours and others') that it's worth gating on, not just auditing after the fact.

Ask

1. Integrate the cheap bicycle_translation_is_connected-style gate into the live candidate-generation/scoring path (evolve/openevolve_evaluator.py and/or evaluation/evaluator.py's early validate/build stage), so disconnected candidates are filtered or penalized before the evolutionary loop spends BP-OSD/MILP budget on them, and so the LLM mutator isn't rewarded for "discovering" replicas of smaller known codes.
2. Run the full decomposition check (decompose / components_isomorphic) over the existing published catalogs (results/*.jsonl, results/ilp_catalog.json) as a one-time curation pass, to flag and appropriately annotate/deduplicate any already-published entries that are direct sums of a smaller code, so the Pareto front reflects genuinely distinct discoveries.
3. Decide on the right place in the cascade for the (more expensive) full Tanner-graph check as a final pre-publication certification step, distinct from the cheap early gate in (1).

Notes for whoever picks this up

• Terms must be pre-reduced into the fundamental exponent ranges before calling the translation-gate check; repeated monomials cancel over GF(2) rather than merely coinciding, so a naive set-based dedup of terms would silently misrepresent the polynomial — see the reasoning already captured in CLAUDE.md's _poly_to_matrix gotcha for the analogous PBB pitfall.
• Keep reusing evaluation/tanner_equivalence.py's graph construction (including the non-CSS tying edge) rather than reimplementing it, for the same correctness reason documented in CLAUDE.md.

Start by reading evaluation/connectivity.py and tests/test_connectivity.py, then trace the scoring stages in evaluation/evaluator.py and evolve/openevolve_evaluator.py. Integrate the cheap connectivity gate, determine where the full Tanner-graph certification belongs, and run the decomposition checks over the named results catalogs. Done means evolutionary scoring filters or penalizes replicas and the published entries are appropriately flagged or deduplicated.