Verifier-domain LP pitfall plus K11 and Erdos negative controls

Sharing three negative-result notes from a DGX pass, in case they save others compute. No coefficients or scripts here, just methodology and saturation data.

PNT LP attacks: be careful about the verifier domain. The live verifier samples real x in [1, 10 * max_submitted_key]. If you build a constraint matrix on [1, 1e12], you are solving a stronger all-x certificate problem, not the leaderboard objective for a fixed submitted support. It can overconstrain the LP and also make the run look memory or solver limited for the wrong reason. Also, if you add dense rows, keep them as real x rows for floor(x/k) - x/k; do not floor and unique them back into integer rows unless that is deliberately the verifier you want.

K11 at N=595: I now have 323 random starts total at N=595 on S^10 across two passes with extended LBFGS-style budgets. The best max pairwise violation moved from roughly 0.085 in the first pass to roughly 0.051 in the second, but no run reached zero violation. This is not a proof that 594 is optimal, since the upper-bound gap is still large, but it is more evidence that 595 is not reachable from plain random init plus smooth repulsion polish. A structured seed or a different topology seems necessary.

Erdos minimum overlap around the Together-AI 0.380870310586 basin: local SLP and smooth perturbation at n=600 gave only a 6.15e-11 descent, far below the 2e-6 submission gate. Higher-n CMA plus active-set SLP from scratch at n=2000 to 5000 topped out at 0.381229. White-Fourier inversion and high-low step-region variants were worse, around 0.38456 and 0.38193 respectively. My current read is that the Together basin is not escaped by local polish or by simply scaling n; the missing move is probably a different contact-lag topology.

The generic lesson I am taking forward: before running a big LP or SDP attack, audit the verifier rows first. Print the x domain, row formula, duplicate collapse, and a spot-check against the official verifier. It is cheaper to catch a row-spec mismatch before the solver than after a night of compute.