erdos-problems 0.3.4 → 0.3.6

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

@@ -47,4 +47,4 @@ Read next:
 - `VERIFICATION_CERTIFICATE_SPEC.md`
 - `EXTERNAL_VERIFICATION_LEDGER.md`
 - `INTERVAL_WORK_QUEUE.yaml`
-- `EXACT_SMALL_N_1_2000_CERTIFICATE.md`
+- `EXACT_SMALL_N_1_10000_CERTIFICATE.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..2000"
+    range: "1..10000"
     status: done
     method_class: exact_small_n
     claim_level: verified
-    certificate: EXACT_SMALL_N_1_2000_CERTIFICATE.md
-    data_packet: EXACT_SMALL_N_1_2000_RESULTS.json
-    next_move: Use this as the first trusted base interval and decide whether the next extension is another exact interval or an imported-computation audit.
+    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: "2001..?"
+    range: "10001..?"
     status: ready
     method_class: exact_small_n
     claim_level: target
     certificate: ""
     data_packet: ""
-    next_move: Decide how far the exact clique scan can be pushed before a different method class is needed.
+    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 `2000` or switch method class.
+    next_move: Decide whether to extend exact verified coverage beyond `10000` or switch method class.
   - 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..2000` base interval and decide the next extension rule.
+    next_move: Build on the exact `1..10000` base interval and decide the next extension rule.
   - 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..2000`. The live question is how to extend coverage from that foothold.
-    current_blocker: The repo has not yet chosen whether the next interval extension should stay in the exact clique-scan regime or switch to a different verification method.
-    next_move: Close `N848.G1.A21`.
+    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..10000`. The live question is how to extend coverage from that foothold while taking advantage of the new incremental verifier honestly.
+    current_blocker: The repo has not yet chosen whether the next interval extension should stay in the exact clique-scan regime or whether the right next gain is a breakpoint-style compression of the exact lane.
+    next_move: Close `N848.G1.A23`.
   - ticket_id: N848F
     title: Audit public formalization coverage
     route_id: formalization_coverage_audit
@@ -182,9 +182,23 @@ atoms:
     summary: The repo now has a reproducible exact certificate showing that the conjectured extremal size is correct for every `N` in `1..2000`.
     next_move: Decide whether to extend the exact clique scan beyond `2000` or change method class.
   - atom_id: N848.G1.A21
-    title: Choose the next verified interval extension beyond `2000`
+    title: Extend the exact verified base interval beyond `2000`
+    route_id: finite_check_gap_closure
+    ticket_id: N848
+    status: done
+    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: 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: ready
-    summary: The bounded-verification lane now starts from a real certified base interval `1..2000`. The next choice is whether the exact clique scan still has enough headroom to extend that base efficiently, or whether the next gain should come from breakpoint or audit methods.
-    next_move: Decide whether to extend exact verified coverage beyond `2000` or switch method class.
+    summary: The bounded-verification lane now starts from a real certified base interval `1..10000`. The next choice is whether exact coverage should continue directly beyond that range, or whether the new exact data should be compressed into a stronger breakpoint method.
+    next_move: Decide whether to extend exact verified coverage beyond `10000` or switch method class.

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

@@ -22,5 +22,7 @@
 - Nineteenth refinement: choose bounded finite verification as the next closure lane and freeze the first repo artifacts for regimes, certificates, and external verification audit.
 - 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.
-- 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..2000` now covered in the bounded-verification lane.
-- Next maturity threshold: extend verified interval coverage beyond `2000` in the most efficient trustworthy way.
+- 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.
+- Twenty-third refinement: rebuild the exact verifier incrementally, compact the witness packet format, and extend the exact certificate all the way to `1..10000`.
+- 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..10000` now covered in the bounded-verification lane.
+- Next maturity threshold: choose the post-`10000` extension policy in the most efficient trustworthy way.

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,8 +76,10 @@ Desired certificate:
 
 ## Current honest posture
 
-- Regime A: first exact interval `1..2000` 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 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
@@ -85,5 +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 `2000`, or whether the next gain comes from auditing imported computation or
+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_small_n_exact_scan.mjs

@@ -26,52 +26,34 @@ function parseArgs(argv) {
   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) return false;
+    if (x % p === 0) {
+      squarefreeCache.set(n, false);
+      return false;
+    }
     while (x % p === 0) x /= p;
   }
+  squarefreeCache.set(n, true);
   return true;
 }
 
-function residueClass(N, residue) {
-  const result = [];
-  for (let n = 1; n <= N; n += 1) {
-    if (n % 25 === residue) result.push(n);
-  }
-  return result;
-}
-
-function sameSortedSet(left, right) {
-  if (left.length !== right.length) return false;
-  const a = [...left].sort((x, y) => x - y);
-  const b = [...right].sort((x, y) => x - y);
-  return a.every((value, index) => value === b[index]);
+function residueClassSize(N, residue) {
+  if (N < residue) return 0;
+  return Math.floor((N - residue) / 25) + 1;
 }
 
-function buildGraph(N) {
-  const vertices = [];
-  for (let a = 1; a <= N; a += 1) {
-    if (!isSquarefree(a * a + 1)) vertices.push(a);
-  }
-  const adjacency = Array.from({ length: vertices.length }, () => new Set());
-  for (let i = 0; i < vertices.length; i += 1) {
-    for (let j = i + 1; j < vertices.length; j += 1) {
-      const a = vertices[i];
-      const b = vertices[j];
-      if (!isSquarefree(a * b + 1)) {
-        adjacency[i].add(j);
-        adjacency[j].add(i);
-      }
-    }
-  }
-  return { vertices, adjacency };
+function isPureResidueClass(clique, N, residue) {
+  return clique.length === residueClassSize(N, residue) && clique.every((value) => value % 25 === residue);
 }
 
-function maximumClique(vertices, adjacency) {
+function maximumCliqueIndices(adjacency, candidateIndices, lowerBound = 0) {
   let best = [];
 
   function bronKerbosch(R, P, X) {
@@ -79,7 +61,7 @@ function maximumClique(vertices, adjacency) {
       if (R.length > best.length) best = [...R];
       return;
     }
-    if (R.length + P.length <= best.length) return;
+    if (R.length + P.length <= Math.max(best.length, lowerBound)) return;
 
     let pivot = null;
     let pivotNeighborsInP = -1;
@@ -109,29 +91,63 @@ function maximumClique(vertices, adjacency) {
     }
   }
 
-  bronKerbosch([], vertices.map((_, index) => index), []);
-  return best.map((index) => vertices[index]).sort((a, b) => a - b);
+  bronKerbosch([], [...candidateIndices], []);
+  return best.sort((a, b) => a - b);
 }
 
 function scanInterval(minN, maxN) {
   const rows = [];
-  for (let N = minN; N <= maxN; N += 1) {
-    const residue7 = residueClass(N, 7);
-    const residue18 = residueClass(N, 18);
-    const { vertices, adjacency } = buildGraph(N);
-    const clique = maximumClique(vertices, adjacency);
+  const vertices = [];
+  const adjacency = [];
+  let bestCliqueIndices = [];
+
+  for (let N = 1; N <= maxN; N += 1) {
+    const residue7Size = residueClassSize(N, 7);
+    const residue18Size = residueClassSize(N, 18);
+
+    if (!isSquarefree(N * N + 1)) {
+      const newIndex = vertices.length;
+      const neighbors = [];
+      for (let i = 0; i < vertices.length; i += 1) {
+        if (!isSquarefree(vertices[i] * N + 1)) {
+          adjacency[i].add(newIndex);
+          neighbors.push(i);
+        }
+      }
+      adjacency.push(new Set(neighbors));
+      vertices.push(N);
+
+      if (neighbors.length + 1 > bestCliqueIndices.length) {
+        const neighborClique = maximumCliqueIndices(
+          adjacency,
+          neighbors,
+          Math.max(0, bestCliqueIndices.length - 1),
+        );
+        if (neighborClique.length + 1 > bestCliqueIndices.length) {
+          bestCliqueIndices = [...neighborClique, newIndex].sort((a, b) => a - b);
+        }
+      }
+    }
+
+    const clique = bestCliqueIndices.map((index) => vertices[index]);
     const maxSize = clique.length;
-    const residue7Size = residue7.length;
-    const residue18Size = residue18.length;
+    if (N < minN) continue;
+    const exampleResidueClass = isPureResidueClass(clique, N, 7)
+      ? 7
+      : isPureResidueClass(clique, N, 18)
+        ? 18
+        : null;
+
     rows.push({
       N,
       maxCliqueSize: maxSize,
       residue7Size,
       residue18Size,
       candidateAchievesMaximum: residue7Size === maxSize,
-      exampleMaximumClique: clique,
-      exampleMatchesResidue7: sameSortedSet(clique, residue7),
-      exampleMatchesResidue18: sameSortedSet(clique, residue18),
+      exampleResidueClass,
+      exampleMaximumClique: exampleResidueClass === null ? clique : undefined,
+      exampleMatchesResidue7: exampleResidueClass === 7,
+      exampleMatchesResidue18: exampleResidueClass === 18,
     });
   }
   return rows;
@@ -153,6 +169,7 @@ const rows = scanInterval(args.min, args.max);
 const payload = {
   generatedAt: new Date().toISOString(),
   method: 'exact_maximum_clique_scan',
+  resultEncoding: 'residue_class_when_possible',
   problemId: '848',
   parameters: {
     min: args.min,

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

@@ -3,11 +3,11 @@ family_role: finite_check_number_theory_workspace
 harness_profile: decidable_gap_workspace
 default_active_route: finite_check_gap_closure
 bootstrap_focus: Treat Problem 848 as a finite-gap closure problem and freeze the certificate surface before claiming bounded verification progress.
-route_story: Problem 848 is already asymptotically resolved in public, but not yet closed here for all N. The honest job is to shrink the finite remainder with audited threshold tracking and reproducible bounded verification, beginning from the verified base interval `1..2000`.
+route_story: Problem 848 is already asymptotically resolved in public, but not yet closed here for all N. The honest job is to shrink the finite remainder with audited threshold tracking and reproducible bounded verification, beginning from the verified base interval `1..10000`.
 frontier_label: finite_check_gap_closure
-frontier_detail: The repo now has a verified exact interval `1..2000`; the next question is whether to extend that exact scan further or change method class.
+frontier_detail: The repo now has a verified exact interval `1..10000`, and an incremental verifier has made larger exact tranches practical again. The next question is whether to keep extending that exact lane or compress it into a stronger breakpoint method.
 checkpoint_focus: Preserve the distinction between existential N0, explicit N0, sample finite checks, and full closure.
-next_honest_move: Decide whether to extend the exact clique scan beyond `2000` or pivot to a different bounded-verification method.
+next_honest_move: Decide whether to extend the exact clique scan beyond `10000` or pivot to a different bounded-verification method.
 related_core_problems:
   - "844"
 literature_focus:
@@ -27,7 +27,7 @@ artifact_focus:
   - VERIFICATION_CERTIFICATE_SPEC.md
   - EXTERNAL_VERIFICATION_LEDGER.md
   - INTERVAL_WORK_QUEUE.yaml
-  - EXACT_SMALL_N_1_2000_CERTIFICATE.md
+  - EXACT_SMALL_N_1_10000_CERTIFICATE.md
 question_ledger:
   open_questions:
     - Which imported threshold value is trusted enough to size the finite remainder operationally?
@@ -44,5 +44,6 @@ question_ledger:
     - The threshold ledger separating existential and explicit claims is now frozen.
     - The repo now has an audited explicit candidate package distinct from the imported public threshold timeline.
     - The repo has now chosen bounded finite verification as the next closure lane.
-    - The repo now has an exact verified base interval `1..2000`.
+    - The repo now has an exact verified base interval `1..10000`.
+    - The exact verifier now uses an incremental update rule rather than rebuilding every instance from scratch.
   problem_solved: []

package/problems/848/EVIDENCE.md

@@ -74,7 +74,9 @@ Current public evidence captured locally:
   values to size the finite remainder without being silently promoted to canonical theorem
   truth.
 - A reproducible exact maximum-clique scan now verifies the expected extremal size for every
-  `N` in `1..2000`, giving the bounded-verification lane its first trusted covered interval.
+  `N` in `1..10000`, giving the bounded-verification lane a much larger trusted covered interval.
+- The exact verifier has been rebuilt incrementally, so the old post-`3000` cost wall is now
+  understood to have been mostly a tooling artifact rather than a serious mathematical barrier.
 
 Claim-safe local posture:
 - Exact: the public status is `decidable`, not `open` and not fully `solved`.
@@ -114,5 +116,5 @@ Next maintainer step:
 - preserve the current claim-safe package as a clean review unit
 - treat imported threshold improvements as external progress markers unless they are
   re-audited inside the repo
-- decide whether exact verified coverage should be extended beyond `2000` or whether the
+- decide whether exact verified coverage should be extended beyond `10000` or whether the
   next gain now needs a different method class

package/problems/848/ROUTES.md

@@ -74,8 +74,9 @@
   - a regime split for the finite remainder
   - a certificate format for bounded interval claims
   - an audit ledger for imported verification work
-  - an exact verified base interval `1..2000`
+  - an exact verified base interval `1..10000`
+  - an incremental verifier that makes larger exact tranches practical
 - The next concrete task is to decide whether the exact clique scan should be extended
-  directly beyond `2000` or whether the next gain now needs a different method class.
+  directly beyond `10000` or whether the next gain now needs a different method class.
 - The right optimization target remains the size of the remaining finite gap, not the
   threshold race in isolation.

package/problems/848/SHARE_READY_SUMMARY.md

@@ -23,7 +23,7 @@ What is ready now:
 - supporting explicit ledgers for the branch bounds and numerical witness
 - a bounded finite-verification lane with regimes, certificate requirements, and external
   audit notes
-- an exact verified base interval `1..2000`
+- an exact verified base interval `1..10000`
 
 What is not being claimed:
 - not full all-`N` closure in the repo

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

@@ -1,55 +0,0 @@
-# Problem 848 Exact Small-`N` Certificate: `1..2000`
-
-This is the first exact bounded-verification certificate frozen in the repo for Problem `848`.
-
-## Claim
-
-For every `N` with `1 <= N <= 2000`, the maximum size of a set `A subseteq [N]` such that
-`ab + 1` is never squarefree for all `a, b in A` is equal to the size of the `7 mod 25`
-residue class in `[N]`.
-
-This certificate only covers the interval `1..2000`.
-
-## Method class
-
-- `exact_small_n`
-
-## Reproduction
-
-Command used:
-
-```bash
-node packs/number-theory/problems/848/compute/problem848_small_n_exact_scan.mjs \
-  --min 1 \
-  --max 2000 \
-  --json-output packs/number-theory/problems/848/EXACT_SMALL_N_1_2000_RESULTS.json
-```
-
-The script:
-- filters vertices by the loop condition `a^2 + 1` not squarefree
-- builds the compatibility graph where `a` and `b` are adjacent exactly when `ab + 1` is not
-  squarefree
-- computes an exact maximum clique for each `N`
-- compares that maximum clique size against the `7 mod 25` class size
-
-## Outcome
-
-- interval: `1..2000`
-- result: verified
-- every scanned `N` satisfied:
-  - `max_clique_size = |{n in [N] : n equiv 7 mod 25}|`
-
-The machine-readable result packet is:
-- `EXACT_SMALL_N_1_2000_RESULTS.json`
-
-## Scope warning
-
-This does **not** certify anything above `2000`.
-It is a base interval certificate only.
-
-## Why this interval matters
-
-- it creates a real in-repo covered interval, not just a verification plan
-- it is large enough to be a meaningful finite-check foothold
-- it does not rely on disputed public computation
-- it gives the bounded-verification lane a concrete certificate format and reproduction path