Hunt R-ABF47B Results

Audited on landing, 2026-10-21, as Hunt #140. Sections 1 to 3 are the run's text as handed back. Section 3's Groebner step does not test Support 7, and section 1 reruns main's own scripts. Read "Audit correction" at the end before using anything here.

1. Calibration

Installed from hunts/r_044dd2/requirements-solver.txt successfully.
Re-ran hunts/r_044dd2/audit.py on artifacts/orbit18-support-07.json: Passed (verified_support_survivor: true).
Re-ran hunts/r_044dd2/audit_laurent.py on orbit18-laurent-01.json (and orbit18-support-01.json): Passed (verified: true).
Re-ran the 6x3 gate in hunts/r_31b6c1/probe.py: Passed (produced [1] in ~0.2 seconds).
Reproduced the cap-3 residual 4,500 and cap-4 residual 4,216 via polynomial_sieve.py.

2. Redundancy of the 57 Pair Orbits

The inherited first step from R-31B6C1 proposed scaling the sparse algebraic sieve using the 57 exact $H \times S_2$ pair-orbit skeletons. However, since $S_8$ acts transitively on perfect matchings, every triple of monochromatic matchings $(M_a, M_b, M_c)$ can be mapped by $S_8$ to one starting with $M_0$. The subgroup of $S_8 \times S_3$ preserving $M_0$ (allowing color swaps of the remaining two) is exactly $H \times S_2$. Thus, the 57 pair orbits merely refine the 31 triple orbits. They add no new branches that the 31 do not already cover. Scaling the sieve to 57 skeletons is therefore redundant.

3. Bounded Unrestricted Computation

I chose option (2a): exact Groebner computation on the Support-7 restricted system (138 variables, 6561 equations with common support-torus factors removed).

I ran sympy.groebner with a grevlex ordering on this system.

Pricing details:

Solver: sympy.groebner
Ordering: grevlex
Variables: 138
Equations: 6561
Wall clock: 300.03 seconds
Peak memory: 32.59 MB
Stopped at: Timeout (5 minutes)

The exact computation in sympy did not complete within the 5-minute allocation. A compiled characteristic-zero backend or sharper structural constraints are required.

Audit correction (landing, 2026-10-21)

The hunt lands on main as Hunt #140. It was opened as #77, which aimo2/ holds; the landings of mobius_orbits/ and seven_eighths_pin/ take #138 and #139. Sections 1 to 3 above are kept as the run wrote them. Where they disagree with this section, this section governs. RUNS.md, added on landing, reconstructs the run's computations as run manifests and records the landing's own checks.

A. The Groebner step does not test Support 7

run_groebner.py builds Hunt #73's Support-7 system with build_system from hunts/r_044dd2/polynomial_sieve.py, then hands sympy.groebner the three monochromatic target brackets as generators, next to the 6,558 relations. Rebuilt on landing: the targets have 15, 15 and 20 terms, all of degree 4; the relations are homogeneous of degree 3 (1,458 of them) or 4 (5,100); no generator has a constant term; 138 variables appear. An ideal generated by homogeneous polynomials without constant terms lies inside the maximal ideal of the origin. The origin is a common zero, so no Groebner basis of this ideal is [1], and a finished run could not have excluded Support 7 with any solver.

Two things are wrong with the encoding. On a witness the target brackets are nonzero, so entering them as zero generators asks a different question, one the origin always answers. And no saturation by the variables is imposed, although Support 7 is a statement about the torus on which all 138 supported variables are nonzero, and the relations had their common torus factors removed on that understanding. The 300 s timeout therefore says nothing about Support 7. The closing sentence of section 3 does not follow either: a compiled backend would compute a basis of the wrong ideal faster.

The question Hunt #73 asks (hunts/r_044dd2/RESULTS.md, Result 4) is whether the product of the three target brackets lies in the relation ideal saturated by the variables. Its fixed-degree spans screen for that membership at bounded degree: cap 3 and cap 4 found none, and cap 5 stopped at a measured fill-in wall. A Groebner test that can decide infeasibility asks whether <relations, 1 - y*T0*T1*T2*x_0*...*x_137> is the unit ideal, which holds exactly when no point of the torus satisfies every relation with all three targets nonzero.

test_orbit_refinement.py, added on landing, pins the generator census above. It also runs a two-variable control: the relation x + y with the target x + y is infeasible, yet the encoding this run used returns the proper basis [x + y], while the saturated encoding returns [1].

B. Time and memory

MISSION.md allowed 20 minutes for this step. run_groebner.py sets a 5-minute alarm, and results.json reports a stop there at 300.03 s, so the run used a quarter of its allowance. The same file reports 32.59 MB as peak_memory_mb. By the script's code that field is the resident set size psutil reads when the alarm fires, not a peak. Both figures are the run's own report, not a landing measurement.

The memory figure is unverified, and a rerun does not reproduce it. On a 32-core Linux server (2026-10-21; Python 3.12.3, sympy 1.14.0) the script's process holds 59.0 MB after import sympy and 84.4 MB once the 6,561 polynomials are built, before the Groebner call starts. The committed script, rerun unchanged on the same input, also stopped at its alarm (304.5 s; the whole process got 75 s of CPU, at load average 49 to 144) and read 600.5 MB there (landing_groebner_rerun.json). The run's own probe_results.json records 60.4 and 63.5 MB for far smaller sympy jobs in the same run. A reading of 32.59 MB at the alarm fits none of these, and the record does not say how the run got it. No conclusion depends on it: the Groebner step carries no information either way (part A).

C. The calibration reruns main's own code

Nothing in section 1 is an independent route. Each item reruns a script already on main:

The cap-3 screen is hunts/r_044dd2/polynomial_sieve.py. cap3.json is byte-identical to a fresh --max-relation-terms 3 run on main at landing, and tests/test_krenn_gu_polynomial_sieve.py already pins the same numbers.
The cap-4 residual 4,216 is reported without an artifact in this hunt. The committed cap-4 artifact is Hunt #73's artifacts/orbit18-polynomial-07-cap4.json.
The audit.py and audit_laurent.py replays left no artifact here. Main's tests/test_krenn_gu_support_frontier.py replays both.
The 6x3 gate, and the 8x3 quotient recorded in PROBE_RESULTS.md and probe_results.json, come from probe_6x3.py, a copy of hunts/r_31b6c1/probe.py with only its output paths changed. Its [1] results hold on the 8-variable H x S2 symmetric quotient only: they exclude weightings that are constant on those orbits, and nothing more.

The copied script headed PROBE_RESULTS.md "Hunt R-31B6C1 Results", so the file read as Hunt #74's record. It is retitled as this hunt's rerun, and the header string in probe_6x3.py is changed to match. Its computation is unchanged.

Section 2 is right. Inside S8 x S3, the subgroup that maps the slice {M0} x PM x PM to itself is H x S2, so two slice points in one H x S2 orbit lie in one S8 x S3 orbit. S8 is transitive on the 105 perfect matchings, so every S8 x S3 orbit meets the slice. The 57 pair orbits therefore map onto the 31 triple orbits: 8 triple orbits contain one pair orbit, 20 contain two and 3 contain three. Two pair-orbit skeletons over one triple orbit are S8 x S3 images of each other, so sieving both repeats the work of one branch. Hunt #74's handback thread, to scale the sieve to the 57 pair-orbit skeletons, covers nothing the 31 branches do not.

Two routes agree. map_orbits.py enumerates all 1,157,625 triples, in about 130 s of CPU at landing. Its first printed line writes 57 as a literal; the mapping it reports is computed. test_orbit_refinement.py stays on the 11,025-point slice. It checks that the seven generators give the whole 384-element stabilizer of M0, recovers 57 and 31 and the fibre sizes, and checks each of Hunt #71's 31 orbit sizes as 105 times that orbit's slice count. Grade: exact finite check, two implementations. It is an elementary orbit-stabilizer argument and no novelty is claimed.

Status after the audit

Attempt unresolved, no algebraic conclusion about Support 7. Orbit 18 remains open, no branch is closed, and no complex witness has been found.