erdos-problems 0.3.5 → 0.3.7

package/packs/number-theory/problems/848/FOUR_ANCHOR_LEMMA_CANDIDATE.md

@@ -0,0 +1,101 @@
+# Problem 848 Four-Anchor Lemma Candidate
+
+This note promotes the anchor recon into a theorem-shaped candidate.
+
+## Candidate lemma
+
+Let
+
+- `a1 = 7`
+- `a2 = 32`
+- `a3 = 57`
+- `a4 = 82`
+
+Then for every integer `n >= 30` with `n not equiv 7 (mod 25)`, at least one of
+
+- `7n + 1`
+- `32n + 1`
+- `57n + 1`
+- `82n + 1`
+
+is squarefree.
+
+Equivalently, every outsider `n >= 30` is incompatible with at least one of the
+four fixed anchors `{7, 32, 57, 82}`.
+
+## What is already verified
+
+- Exact clique packet through `N = 10000`:
+  - `EXACT_SMALL_N_1_10000_CERTIFICATE.md`
+  - `EXACT_SMALL_N_1_10000_RESULTS.json`
+- Direct anchor scan for the candidate set:
+  - `ANCHOR_OBSTRUCTION_7_32_57_82.json`
+- Small-anchor search ledger:
+  - `ANCHOR_MINIMALITY_LEDGER.md`
+  - `ANCHOR_SUBSET_SEARCH_PREFIX10_K3_K4.json`
+
+The direct anchor scan currently confirms:
+
+- no failures in `30..10000`
+- witness usage counts:
+  - `7`: `6187`
+  - `32`: `2941`
+  - `57`: `402`
+  - `82`: `42`
+
+So the obstruction is real, uneven, and highly structured.
+
+## Why this lemma matters
+
+If the four-anchor lemma is proved, then the exact packet is no longer only a
+large finite certificate. It becomes evidence for a more conceptual route:
+
+1. Every outsider is blocked by a fixed finite anchor set.
+2. That obstruction should force a breakpoint law for clique growth.
+3. The only remaining work should be a finite startup stub and an exchange or
+   monotonicity argument.
+
+That would be much closer to a real closure theorem than continuing exact
+verification indefinitely.
+
+## Proof obligations
+
+The current candidate is **not** proved. The main obligations are:
+
+1. Show the four-anchor obstruction for all `n >= 30`, not just `n <= 10000`.
+2. Convert anchor obstruction into a clique-size consequence.
+3. Explain why the full `7 mod 25` class remains optimal even though the
+   obstruction is expressed using only four anchor elements.
+4. Close the startup range `n < 30` explicitly.
+
+## Most plausible routes from here
+
+### Route A: modular obstruction proof
+
+Treat each condition `qn + 1` non-squarefree as a union of square-modulus
+congruence classes and prove that no `n >= 30`, `n not equiv 7 (mod 25)`,
+can lie in all four unions simultaneously.
+
+### Route B: exchange lemma first
+
+Prove that any maximal clique not equal to the `7 mod 25` class must contain
+enough of the anchor set that an outsider can be exchanged away without loss.
+
+### Route C: breakpoint law first
+
+Use the exact packet to conjecture and then prove directly that
+
+`alpha(G_N) = alpha(G_{N-1})` for `N not equiv 7 (mod 25)`
+
+and
+
+`alpha(G_N) = alpha(G_{N-1}) + 1` for `N equiv 7 (mod 25), N >= 7`.
+
+The four-anchor lemma would then become the local obstruction that explains the
+flat steps.
+
+## Current recommendation
+
+The next serious move should be a proof attempt for the four-anchor lemma,
+supported by modular residue analysis and square-divisibility ledgers, not just
+another raw exact interval extension.

package/packs/number-theory/problems/848/FRONTIER_NOTE.md

@@ -32,14 +32,16 @@ The current package is already internally reviewed enough for handoff:
 - tests and publish-surface checks are green
 
 Chosen next lane:
-- bounded finite verification under the best imported threshold currently tracked
+- prove the four-anchor obstruction and turn it into a breakpoint theorem candidate
 
 Why this lane wins the next cycle:
-- the real objective is to close the finite remainder, not just publish a smaller `N0`
-- imported threshold progress already exists, so the repo needs an interval-certification
-  surface to make use of it
-- the public thread already contains one verification attempt that was later corrected and
-  criticized as difficult to verify, so trust and reproducibility have to be first-class
+- the exact verifier now reaches `1..10000`, so the finite-check surface is no longer tiny
+- the exact packet already exhibits a rigid breakpoint law: clique size only jumps at
+  `N equiv 7 (mod 25)`
+- the new anchor recon suggests a fixed finite obstruction set `{7, 32, 57, 82}` beyond the
+  tiny startup range
+- that is the first route that looks like a real theorem rather than an endless extension of
+  raw exact search
 
 Read next:
 - `BOUNDED_VERIFICATION_PLAN.md`
@@ -47,4 +49,7 @@ Read next:
 - `VERIFICATION_CERTIFICATE_SPEC.md`
 - `EXTERNAL_VERIFICATION_LEDGER.md`
 - `INTERVAL_WORK_QUEUE.yaml`
-- `EXACT_SMALL_N_1_3000_CERTIFICATE.md`
+- `EXACT_SMALL_N_1_10000_CERTIFICATE.md`
+- `ANCHOR_OBSTRUCTION_RECON.md`
+- `ANCHOR_MINIMALITY_LEDGER.md`
+- `FOUR_ANCHOR_LEMMA_CANDIDATE.md`

package/packs/number-theory/problems/848/INTERVAL_WORK_QUEUE.yaml

@@ -7,22 +7,22 @@ operational_threshold:
 intervals:
   - interval_id: N848.V1
     label: exact_small_n_base_interval
-    range: "1..3000"
+    range: "1..10000"
     status: done
     method_class: exact_small_n
     claim_level: verified
-    certificate: EXACT_SMALL_N_1_3000_CERTIFICATE.md
-    data_packet: EXACT_SMALL_N_1_3000_RESULTS.json
+    certificate: EXACT_SMALL_N_1_10000_CERTIFICATE.md
+    data_packet: EXACT_SMALL_N_1_10000_RESULTS.json
     next_move: Use this as the current trusted base interval and decide whether the next extension is another exact interval or an imported-computation audit.
   - interval_id: N848.V2
     label: exact_small_n_extension
-    range: "3001..?"
+    range: "10001..?"
     status: ready
     method_class: exact_small_n
     claim_level: target
     certificate: ""
     data_packet: ""
-    next_move: Decide whether exact coverage should continue in smaller certified steps beyond `3000` or whether the next gain should come from a different method class.
+    next_move: Decide whether exact coverage should continue directly beyond `10000` or whether the next gain should come from a different method class.
   - interval_id: N848.V3
     label: imported_computation_audit
     range: "public_claimed_interval"

package/packs/number-theory/problems/848/OPS_DETAILS.yaml

@@ -6,7 +6,7 @@ routes:
     status: active
     summary: Convert the sufficiently-large-N theorem into a complete all-N resolution without overstating what is already closed or confusing imported thresholds with repo-owned claims.
     why_now: The share package is already committed, the bounded-verification lane is now frozen, and the repo has a first verified interval.
-    next_move: Decide whether to extend exact verified coverage beyond `3000` in smaller steps or switch method class.
+    next_move: Promote the four-anchor obstruction from recon to a proof-shaped lemma candidate.
   - route_id: external_threshold_tracking
     title: External Threshold Tracking
     status: support
@@ -18,7 +18,7 @@ routes:
     status: active_support
     summary: Reduce the finite remainder directly once a threshold is trusted enough to be operationally useful.
     why_now: Lowering `N0` matters because it reduces this lane, not because "smallest threshold" is the whole problem.
-    next_move: Build on the exact `1..3000` base interval and decide the next extension rule.
+    next_move: Build on the exact `1..10000` base interval by extracting a structural theorem rather than defaulting to another raw interval.
   - route_id: formalization_coverage_audit
     title: Formalization Coverage Audit
     status: support
@@ -30,9 +30,9 @@ tickets:
     title: Close the decidable gap without confusing imported threshold progress and repo-owned candidate work
     route_id: finite_check_gap_closure
     status: active
-    summary: The repo now has a committed review package for its audited `exp(1420)` candidate, a chosen bounded-verification lane, and an exact verified base interval `1..3000`. The live question is how to extend coverage from that foothold without pretending brute-force still scales cheaply.
-    current_blocker: The repo has not yet chosen whether the next interval extension should stay in the exact clique-scan regime in smaller certified steps or switch to a different verification method.
-    next_move: Close `N848.G1.A22`.
+    summary: The repo now has a committed review package for its audited `exp(1420)` candidate, a chosen bounded-verification lane, an exact verified base interval `1..10000`, and a four-anchor obstruction candidate. The live question is how to turn that structure into a proof.
+    current_blocker: The repo has not yet promoted the four-anchor obstruction from empirical recon into a proof-shaped lemma with clear obligations and a breakpoint consequence.
+    next_move: Close `N848.G1.A24`.
   - ticket_id: N848F
     title: Audit public formalization coverage
     route_id: formalization_coverage_audit
@@ -189,9 +189,26 @@ atoms:
     summary: The repo now has a second exact certificate extending the bounded-verification base interval from `1..2000` to `1..3000`, while also showing that a blind jump to `1..5000` is no longer cheap enough to count as the default next move.
     next_move: Choose the post-`3000` extension policy.
   - atom_id: N848.G1.A22
-    title: Choose the post-`3000` verified interval policy
+    title: Rebuild the exact verifier and remove the false post-`3000` policy wall
+    route_id: finite_check_gap_closure
+    ticket_id: N848
+    status: done
+    summary: The exact verifier now uses an incremental update rule, the compact certificate format keeps packets small, and the exact bounded-verification base interval now reaches `1..10000`.
+    next_move: Choose the post-`10000` interval policy.
+  - atom_id: N848.G1.A23
+    title: Choose the post-`10000` verified interval policy
+    route_id: finite_check_gap_closure
+    ticket_id: N848
+    status: done
+    summary: >-
+      The repo has chosen the structure-first route: use the `1..10000` exact
+      packet as evidence for a four-anchor obstruction and a breakpoint law,
+      rather than defaulting immediately to a larger raw interval.
+    next_move: Formalize the four-anchor lemma candidate.
+  - atom_id: N848.G1.A24
+    title: Formalize the four-anchor obstruction lemma candidate
     route_id: finite_check_gap_closure
     ticket_id: N848
     status: ready
-    summary: The bounded-verification lane now starts from a real certified base interval `1..3000`. The next choice is whether exact coverage should continue in smaller certified steps, or whether the next gain should come from breakpoint or audit methods.
-    next_move: Decide whether to extend exact verified coverage beyond `3000` in smaller steps or switch method class.
+    summary: The repo now has a four-anchor obstruction candidate with no failures in `30..10000`, plus a minimality ledger showing that `{7, 32, 57, 82}` is unusually strong among small anchor sets. The next move is to package that into a proof-shaped lemma with explicit obligations.
+    next_move: Write the theorem candidate and proof-obligation surface for the four-anchor obstruction.

package/packs/number-theory/problems/848/ROUTE_HISTORY.md

@@ -23,5 +23,7 @@
 - Twentieth refinement: freeze the operational threshold posture so imported `N0` claims can size the finite remainder without being silently promoted to canonical repo theorem truth.
 - Twenty-first refinement: certify the exact interval `1..2000` by a reproducible maximum-clique scan, giving the bounded-verification lane its first genuine covered interval.
 - Twenty-second refinement: extend the exact certificate to `1..3000`, and record that a direct jump to `1..5000` no longer looks cheap enough to treat as the obvious default next move.
-- Current public pack posture: active route `finite_check_gap_closure`, with asymptotic theorem already in hand, a committed audited candidate package in the repo, and a real exact base interval `1..3000` now covered in the bounded-verification lane.
-- Next maturity threshold: choose the post-`3000` extension policy in the most efficient trustworthy way.
+- Twenty-third refinement: rebuild the exact verifier incrementally, compact the witness packet format, and extend the exact certificate all the way to `1..10000`.
+- Twenty-fourth refinement: mine the exact packet for structure, isolate the four-anchor obstruction `{7, 32, 57, 82}` with no failures in `30..10000`, and record that this is the first route that looks theorem-shaped rather than purely computational.
+- Current public pack posture: active route `finite_check_gap_closure`, with asymptotic theorem already in hand, a committed audited candidate package in the repo, a real exact base interval `1..10000`, and a four-anchor theorem candidate now visible in the bounded-verification lane.
+- Next maturity threshold: formalize the four-anchor obstruction lemma and connect it to the breakpoint law suggested by the exact packet.

package/packs/number-theory/problems/848/VERIFICATION_CERTIFICATE_SPEC.md

@@ -40,6 +40,9 @@ Any bounded-verification claim for Problem `848` should attach a certificate wit
   - a second script, proof note, or reviewer confirmation
 - `cost_profile`
   - rough runtime or proof complexity
+- `witness_encoding`
+  - if the certificate omits raw witness lists because they are derivable, state that
+    encoding explicitly, for example "pure residue class mod 25 when possible"
 
 ## Rejection triggers
 

package/packs/number-theory/problems/848/VERIFICATION_REGIMES.md

@@ -76,10 +76,10 @@ Desired certificate:
 
 ## Current honest posture
 
-- Regime A: first exact interval `1..3000` is now frozen in the repo with a reproducible
+- Regime A: first exact interval `1..10000` is now frozen in the repo with a reproducible
   maximum-clique certificate
-- Regime A warning: a direct jump to `1..5000` did not finish cheaply enough to treat blind
-  brute-force extension as the only serious next move
+- Regime A note: an incremental verifier removed the earlier false cost wall caused by
+  rebuilding the graph and clique search from scratch for each `N`
 - Regime B: not frozen in this repo
 - Regime C: public attempts exist, but some were explicitly criticized on the forum as
   difficult to verify or likely incorrect
@@ -87,6 +87,6 @@ Desired certificate:
   yet repo-audited
 
 So the next honest move is to decide whether exact-small-`N` coverage should be extended
-directly beyond `3000` in smaller certified steps, or whether the next gain comes from
+directly beyond `10000`, or whether the next gain comes from
 auditing imported computation or
 switching method class.

package/packs/number-theory/problems/848/compute/problem848_anchor_obstruction_scan.mjs

@@ -0,0 +1,120 @@
+#!/usr/bin/env node
+
+import fs from 'node:fs';
+import path from 'node:path';
+
+function parseArgs(argv) {
+  const args = {
+    max: 10000,
+    threshold: 1,
+    anchors: [7, 32, 57, 82],
+    jsonOutput: null,
+  };
+  for (let i = 0; i < argv.length; i += 1) {
+    const token = argv[i];
+    if (token === '--max') {
+      args.max = Number(argv[++i]);
+    } else if (token === '--threshold') {
+      args.threshold = Number(argv[++i]);
+    } else if (token === '--anchors') {
+      args.anchors = argv[++i].split(',').map((value) => Number(value.trim())).filter(Boolean);
+    } else if (token === '--json-output') {
+      args.jsonOutput = argv[++i];
+    } else {
+      throw new Error(`Unknown argument: ${token}`);
+    }
+  }
+  if (!Number.isInteger(args.max) || args.max < 1) {
+    throw new Error('--max must be a positive integer');
+  }
+  if (!Number.isInteger(args.threshold) || args.threshold < 1 || args.threshold > args.max) {
+    throw new Error('--threshold must be an integer between 1 and --max');
+  }
+  if (!Array.isArray(args.anchors) || args.anchors.length === 0) {
+    throw new Error('--anchors must provide at least one positive integer');
+  }
+  return args;
+}
+
+const squarefreeCache = new Map();
+
+function isSquarefree(n) {
+  if (squarefreeCache.has(n)) return squarefreeCache.get(n);
+  let x = n;
+  for (let p = 2; p * p <= x; p += 1) {
+    if (x % p !== 0) continue;
+    x /= p;
+    if (x % p === 0) {
+      squarefreeCache.set(n, false);
+      return false;
+    }
+    while (x % p === 0) x /= p;
+  }
+  squarefreeCache.set(n, true);
+  return true;
+}
+
+function scanAnchors({ anchors, threshold, max }) {
+  const failures = [];
+  const witnessCounts = new Map();
+  const residueStats = new Map();
+
+  for (let residue = 0; residue < 25; residue += 1) {
+    if (residue === 7) continue;
+    residueStats.set(residue, {
+      residue,
+      witnessCounts: Object.fromEntries(anchors.map((anchor) => [anchor, 0])),
+      firstFailure: null,
+      failureCount: 0,
+    });
+  }
+
+  for (let n = threshold; n <= max; n += 1) {
+    if (n % 25 === 7) continue;
+    const usableAnchors = anchors.filter((anchor) => anchor <= n);
+    const witness = usableAnchors.find((anchor) => isSquarefree(anchor * n + 1)) ?? null;
+    if (witness === null) {
+      failures.push(n);
+      const residueRow = residueStats.get(n % 25);
+      residueRow.failureCount += 1;
+      if (residueRow.firstFailure === null) residueRow.firstFailure = n;
+      continue;
+    }
+    witnessCounts.set(witness, (witnessCounts.get(witness) ?? 0) + 1);
+    residueStats.get(n % 25).witnessCounts[witness] += 1;
+  }
+
+  return {
+    failures,
+    witnessCounts: Object.fromEntries(anchors.map((anchor) => [anchor, witnessCounts.get(anchor) ?? 0])),
+    residueStats: [...residueStats.values()],
+  };
+}
+
+const args = parseArgs(process.argv.slice(2));
+const result = scanAnchors(args);
+const payload = {
+  generatedAt: new Date().toISOString(),
+  method: 'anchor_obstruction_scan',
+  problemId: '848',
+  parameters: {
+    anchors: args.anchors,
+    threshold: args.threshold,
+    max: args.max,
+  },
+  summary: {
+    failureCount: result.failures.length,
+    tailStart: result.failures.length ? Math.max(...result.failures) + 1 : args.threshold,
+    allCoveredFromThreshold: result.failures.length === 0,
+    witnessCounts: result.witnessCounts,
+  },
+  failures: result.failures,
+  residueStats: result.residueStats,
+};
+
+if (args.jsonOutput) {
+  fs.mkdirSync(path.dirname(args.jsonOutput), { recursive: true });
+  fs.writeFileSync(args.jsonOutput, `${JSON.stringify(payload, null, 2)}\n`);
+}
+
+console.log(JSON.stringify(payload.summary, null, 2));

package/packs/number-theory/problems/848/compute/problem848_anchor_subset_search.mjs

@@ -0,0 +1,134 @@
+#!/usr/bin/env node
+
+import fs from 'node:fs';
+import path from 'node:path';
+
+function parseArgs(argv) {
+  const args = {
+    max: 10000,
+    top: 15,
+    candidateCount: 10,
+    setSizes: [3, 4],
+    jsonOutput: null,
+  };
+  for (let i = 0; i < argv.length; i += 1) {
+    const token = argv[i];
+    if (token === '--max') {
+      args.max = Number(argv[++i]);
+    } else if (token === '--top') {
+      args.top = Number(argv[++i]);
+    } else if (token === '--candidate-count') {
+      args.candidateCount = Number(argv[++i]);
+    } else if (token === '--set-sizes') {
+      args.setSizes = argv[++i].split(',').map((value) => Number(value.trim())).filter(Boolean);
+    } else if (token === '--json-output') {
+      args.jsonOutput = argv[++i];
+    } else {
+      throw new Error(`Unknown argument: ${token}`);
+    }
+  }
+  if (!Number.isInteger(args.max) || args.max < 1) {
+    throw new Error('--max must be a positive integer');
+  }
+  if (!Number.isInteger(args.top) || args.top < 1) {
+    throw new Error('--top must be a positive integer');
+  }
+  if (!Number.isInteger(args.candidateCount) || args.candidateCount < 1) {
+    throw new Error('--candidate-count must be a positive integer');
+  }
+  if (!Array.isArray(args.setSizes) || args.setSizes.length === 0) {
+    throw new Error('--set-sizes must provide at least one set size');
+  }
+  return args;
+}
+
+const squarefreeCache = new Map();
+
+function isSquarefree(n) {
+  if (squarefreeCache.has(n)) return squarefreeCache.get(n);
+  let x = n;
+  for (let p = 2; p * p <= x; p += 1) {
+    if (x % p !== 0) continue;
+    x /= p;
+    if (x % p === 0) {
+      squarefreeCache.set(n, false);
+      return false;
+    }
+    while (x % p === 0) x /= p;
+  }
+  squarefreeCache.set(n, true);
+  return true;
+}
+
+function choose(list, size, start = 0, prefix = [], out = []) {
+  if (prefix.length === size) {
+    out.push(prefix);
+    return out;
+  }
+  for (let i = start; i <= list.length - (size - prefix.length); i += 1) {
+    choose(list, size, i + 1, [...prefix, list[i]], out);
+  }
+  return out;
+}
+
+function failuresFor(set, max) {
+  const bad = [];
+  for (let n = 1; n <= max; n += 1) {
+    if (n % 25 === 7) continue;
+    let ok = false;
+    for (const q of set) {
+      if (q <= n && isSquarefree(n * q + 1)) {
+        ok = true;
+        break;
+      }
+    }
+    if (!ok) bad.push(n);
+  }
+  return bad;
+}
+
+const args = parseArgs(process.argv.slice(2));
+const candidates = Array.from({ length: args.candidateCount }, (_, index) => 7 + 25 * index);
+const bySize = {};
+
+for (const size of args.setSizes) {
+  bySize[size] = choose(candidates, size)
+    .map((set) => {
+      const failures = failuresFor(set, args.max);
+      return {
+        anchors: set,
+        failureCount: failures.length,
+        tailStart: failures.length ? Math.max(...failures) + 1 : 1,
+        worstFailures: failures.slice(-12),
+      };
+    })
+    .sort((left, right) => left.tailStart - right.tailStart || left.failureCount - right.failureCount)
+    .slice(0, args.top);
+}
+
+const payload = {
+  generatedAt: new Date().toISOString(),
+  method: 'anchor_subset_search',
+  problemId: '848',
+  parameters: {
+    max: args.max,
+    top: args.top,
+    candidateCount: args.candidateCount,
+    setSizes: args.setSizes,
+    candidates,
+  },
+  results: bySize,
+};
+
+if (args.jsonOutput) {
+  fs.mkdirSync(path.dirname(args.jsonOutput), { recursive: true });
+  fs.writeFileSync(args.jsonOutput, `${JSON.stringify(payload, null, 2)}\n`);
+}
+
+console.log(JSON.stringify(
+  Object.fromEntries(
+    Object.entries(bySize).map(([size, rows]) => [size, rows[0] ?? null]),
+  ),
+  null,
+  2,
+));