Audit the class-C 4-flat covering-config census of #2954: the cheapest config is useless for the hard rows, 3 of 5 are redundant (no kappa claim)

[muatfannajm-dot]

Summary

An exact, table-only audit of the class-C 4-flat covering-config census in the Discussion #2954 help package. It answers one narrow, decision-changing question: which of the advertised four-flat configs actually have to be run?

Adds research/k2-class-c-config-audit. Catalogue card census-pruning-audit, scope_status: refined (the handoff-first rule selected the live unclaimed #2954 request instead of the card's #2973 parity census; the card's own discipline -- never treat a prunable enumeration as a disproved bound -- is honoured, and no residue is excluded here).

No E8/P112 geometry is re-derived. The kill criterion (Lemma B) and relative root counting are not verified. No kappa, decoder floor, residue exclusion, supplier or frontier claim.

Two findings

1. The advertised cheapest campaign is provably useless for the hard rows. #2954 prices five configs and singles out 6543 = (6,5,4,3) as cheapest -- 2.6e7 pairs vs 1.1e8-3.3e8, ETA ~4e4 CPU-h vs ~3e5. It is the only plausibly affordable route-B target, and it is where the existing acceleration work (tekuuu PR2975, PR3000) was pointed.

6543 appears only on rows that relative root counting already kills, and covers zero of the 17 rows in rows17.csv. The complete set of configs seen only on RRC-killed rows is 5444, 5543, 5553, 6443, 6533, 6543, 6553. Spending 4e4 CPU-h there cannot advance the hard problem.

2. Three of the advertised configs are provably redundant. The exact minimum set covering the 16 config-coverable rows of the 17 is

{5544, 5555, 6554}

5554, 6444 and 6544 are redundant. The same three configs also cover all 64 config-coverable rows of the whole 70-row census, so the reduction is not specific to the 17. On the README's own pair counts, dropping redundant 5554 (3.3e8) and 6544 (1.1e8) removes 4.4e8 enumerated pairs before any closure runs. 6444's count is unpublished, so 4.4e8 is a lower bound.

Supporting checks -- all pass

• every listed config satisfies sum g <= 52, and 6554 = (6,5,5,4) saturates it exactly at 52, making it the unique largest admissible 4-flat budget in the table;
• rows17.csv is exactly rows70.csv minus the 53 RRC-killed rows (symmetric difference empty), kill count 53 as published;
• every shared row's d, s, weights, e and config list agree between the two tables;
• the 6 rows with no config are 3, 12, 24, 37, 54, 61, confirming Help wanted: the "class C" cells of the one-sided K2 residue (excess pays for corrections, d >= 4) -- 17 hard rows, a 4-flat span question #2954's "6 rows have no 4-flat candidate". Row 37 is the only one of the 17.

What is deliberately not established

• Completeness of the config list is not checked. Each listed config is verified admissible (sum g <= 52); that the packing predicate admits no further config is not, because that predicate is only sketched in Help wanted: the "class C" cells of the one-sided K2 residue (excess pays for corrections, d >= 4) -- 17 hard rows, a 4-flat span question #2954. The redundancy result is a statement about the published list. Recorded in TASK.json open_questions[0] and the README.
• Kill criterion, span H <= d-1, and RRC are untouched.
• Pair counts / ETAs are reused verbatim from the help README, not re-measured.
• No row is excluded. A redundant config is not a disproved row.

Evidence and reproduction

python3 -B research/k2-class-c-config-audit/verify.py
# expect PASS_K2_CLASS_C_CONFIG_AUDIT, exit 0
python3 scripts/research_package.py --package research/k2-class-c-config-audit --check-only
# expect PASS_PACKAGE_METADATA_AND_PINS
python3 scripts/check_research_commit.py --package research/k2-class-c-config-audit
# expect PASS_RESEARCH_COMMIT_BYTES

Python 3.12, standard library only, <1 s. The verifier asserts both input sha256 values, runs the 8 structural checks, then runs 4 rejecting mutants, each caught:

mutant	rejected by
inject inadmissible 6555 (sum g = 56)	admissibility + cross-table agreement
drop row 62 from rows17.csv	row count + rows17/rows70 identity
flip one RRC status (53 -> 52)	rows17 identity + kill count
edit row 35 configs in rows17.csv only	cross-table agreement

RESULT.json records every derived quantity. Author-checked; not independently reviewed.

Sources

Audited help package: DreamingOfClouds/integer-mult-bounds, branch research/k2-class-c-help, help-package source commit 1b25759bff5486293a9083ebbe0097b5f6642e08. The g-table, the sum g <= 52 bound and the pair counts are quoted from #2954 and its README and restated in verify.py. The two CSVs are not Git objects in this repository, so they carry no git_blob row; they are vendored under inputs/, declared as live inputs in VERIFY.json, and their sha256 is re-checked on every run as the byte-equality receipt.

Base canonical main 463113d675af7410ac91d53a4fed51ec6494eb9a, priority revision 6.

Overlap tooling limitation, stated plainly

python3 scripts/find_overlap.py --refresh could not refresh its remote corpus: its remote refresh shells out to gh, which is not installed in my environment, so it reported open_prs: null, discussions: null and fell back to local notes only. I substituted authenticated API reads of #2954, #1166 and #3156 and API searches over open and closed PR bodies. This is not an arbitrary-diff or unpublished-work census, and a null result would not by itself have proved novelty. scripts/find_overlap.py should not hard-depend on gh for its refresh path -- flagging that as workflow feedback.

Distinctness

• tekuuu PR2975 (33x requirement enumeration) and PR3000 (9.31x maximal-mask filtering) accelerate work inside a config; this removes whole configs from the campaign, and composes with both.
• petalas' current claims (C(P112) >= 64: what is left (for the swarm) #3156) are E8 capacity/shortening predicates with different hypotheses.
• The RRC residue chain is PR2985 / PR3049; both remain open and retain all credit. This PR audits one census table inside that lineage and neither confirms nor disputes their mathematics.

Predecessor credit

DreamingOfClouds -- the class-C help package, the s4z/s3z engines, data88.txt, the g-table, the sum g <= 52 bound, and both CSV tables that are the entire object of this audit. Their results are retained in full; nothing here disputes them. tekuuu -- PR2975, PR3000. Nick Petalas and the retained #2816 / #2826 / #2862 E8/P112 lineage; the PR2985 / PR3049 residue chain. Douglas Colkitt and the retained source lineage.

Prepared by muatfannajm-dot, with substantial OpenCode (Space Bunny Free) assistance. Apache-2.0. The audited help package remains DreamingOfClouds' work under the repository's Apache-2.0 licence.

Open next questions

1. Is the admissible config list complete? Obtain the exact weight-multiset -> config packing predicate, regenerate configs independently, diff against inputs/rows70.csv. Blocked by: the predicate is unpublished; s4z.c encodes it only implicitly.
2. Rows 37, 3, 12, 24, 54, 61 admit no 4-flat config, so no amount of 4-flat closure closes them. Test whether a 5-flat or explicit two-free-piece cover exists within sum g <= 52 for row 37, or prove none does. Blocked by: needs the E8/P112 flat geometry and the unpublished RRC scenario list.
3. Do the 3 redundant configs matter for the 116 open residues of PR2985/PR3049? Run this audit unchanged against their tables after pinning heads. Blocked by: those tables are not vendored here.

[muatfannajm-dot]

Correction: the cover relation is dominance closure, not literal incidence

@krzysztofwojt was right and my headline claim #2 was wrong. Your point about rows 13/62 listing 5544 while omitting 6554 is exactly the tell. I checked it properly and pushed a fix in 240e7f6.

I had read the cover relation as literal CSV incidence (a config serves exactly the rows that list it). That is wrong. Your published per-config totals pin the real relation down:

config	literal incidence	dominance closure	published in #2954
6554	39	62	62
5555	21	27	27
6544	36	40	40
5554	22	23	23
6543	16	16	16

Dominance closure reproduces all five totals exactly; literal incidence reproduces none of them correctly. 6554 = (6,5,5,4) dominates 5544, 6444, 6544 and 6543 coordinatewise, so its true reach is 62 rows, not the 39 the CSV lists. The CSV appears to list only the minimal generator of each cover rather than every config that can serve it.

Corrected results

• Minimum cover is {5555, 6554}, not {5544, 5555, 6554}. 5544, 5554, 6444, 6544 are all dominated by 6554. For the full 70-row census, 11 of the 13 table configs are redundant -- only 5555 and 6554 survive. 5555 survives because 6554 does not dominate it: (5,5,5,5) is narrower than (6,5,5,4) in its largest dimension.
• Finding Refine paired parameters and derive the fixed-exponent supremum #1 survives and gets stronger. 6543 is dominated by 6554, so it is redundant by dominance regardless of the cover relation -- on top of appearing only on RRC-killed rows and covering none of the 17.
• Pair saving on the README's own counts: 4.4e8 for the hard-row campaign, 4.66e8 including 6543 for the full census. Both lower bounds, since 5544 and 6444 have no published counts.

What I added

dominance_checks() in verify.py asserts the five published totals are reproduced by closure and not by literal incidence, plus 6554 dominates {5544, 6444, 6544, 6543}. Check count 8 -> 11, controls 4 -> 5; the new control adds 6554 to row 3 so the closed total moves off 62 and must be rejected. PASS_K2_CLASS_C_CONFIG_AUDIT, registered replay, metadata check and check_research_commit.py all pass at 240e7f6; 11/11 checks and 5/5 controls.

The limit I am now stating explicitly, and it is your question

The whole two-config conclusion rests on one premise this table audit cannot prove: that 6554 may substitute for a dominated config at the same target T, i.e. that the dimension-dominance implication preserves the span threshold. That is exactly the source-semantic lemma in your claim. So please read {5555, 6554} as the planning conclusion pending your lemma, not as a certified campaign. I have added it as open_questions[0] in TASK.json and the README, framed as: fix one (V1..V4) instance and one T, and check the dominated and dominating config against the real span computation.

Also unchanged: no completeness claim about the config list (the packing predicate is still unpublished), no span/RRC/E8 geometry claim, no row excluded. Credit to Krzysztof Wojt for the dominance observation and to DreamingOfClouds for the audited tables. Apologies for the wasted round-trip on a claim I should have checked against your own published totals the first time.