erdos-problems 0.3.3 → 0.3.4

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

@@ -46,3 +46,5 @@ Read next:
 - `VERIFICATION_REGIMES.md`
 - `VERIFICATION_CERTIFICATE_SPEC.md`
 - `EXTERNAL_VERIFICATION_LEDGER.md`
+- `INTERVAL_WORK_QUEUE.yaml`
+- `EXACT_SMALL_N_1_2000_CERTIFICATE.md`

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

@@ -0,0 +1,43 @@
+packet_id: nt848_interval_work_queue_v1
+operational_threshold:
+  value: "2.64 x 10^17"
+  source: forum_thread_2026_03_23
+  trust_status: external_public_claim
+  usage: sizing_only
+intervals:
+  - interval_id: N848.V1
+    label: exact_small_n_base_interval
+    range: "1..2000"
+    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.
+  - interval_id: N848.V2
+    label: exact_small_n_extension
+    range: "2001..?"
+    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.
+  - interval_id: N848.V3
+    label: imported_computation_audit
+    range: "public_claimed_interval"
+    status: support
+    method_class: imported_external_computation
+    claim_level: external_only
+    certificate: EXTERNAL_VERIFICATION_LEDGER.md
+    data_packet: ""
+    next_move: Audit public computational claims without silently promoting them to canonical coverage.
+  - interval_id: N848.VA
+    label: asymptotic_handoff
+    range: "[2.64 x 10^17, inf)"
+    status: support
+    method_class: asymptotic_handoff
+    claim_level: external_only
+    certificate: OPERATIONAL_THRESHOLD_POSTURE.md
+    data_packet: ""
+    next_move: Keep the imported handoff threshold visible and separate from repo-audited theorem language.

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

@@ -0,0 +1,38 @@
+# Problem 848 Operational Threshold Posture
+
+This note fixes how the bounded-verification lane uses explicit thresholds.
+
+## Repo-owned audited threshold
+
+- current repo-owned audited candidate:
+  - `N >= exp(1420)`
+  - status: repo-audited explicit candidate
+  - use: internal proof packaging and audit surface
+
+## Imported operational threshold
+
+- current imported public threshold:
+  - `N0 = 2.64 x 10^17`
+  - source date: 2026-03-23
+  - source: Problem 848 forum thread
+  - trust status: external public claim, not yet repo-audited line by line
+
+## How the verification lane uses this
+
+- The bounded-verification lane may use `2.64 x 10^17` to size the remaining finite gap.
+- It may not present that value as canonical repo theorem truth.
+- Any interval-coverage claim that relies on this handoff must explicitly say:
+  - the threshold value being used
+  - that it is an imported public claim unless and until the repo audits it
+  - what part of the interval claim is computational and what part is asymptotic handoff
+
+## Practical policy
+
+- For planning: use the imported `2.64 x 10^17` value.
+- For canonical theorem language: keep the stronger distinction
+  - imported threshold
+  - repo-audited threshold candidate
+  - fully closed all-`N` theorem
+
+This keeps the finite-verification program operationally useful without overstating what the
+repo has personally audited.

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

@@ -5,8 +5,8 @@ routes:
     title: Finite-Check Gap Closure
     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, and the repo has now chosen bounded finite verification as the next closure lane.
-    next_move: Freeze the bounded finite-verification program and its certificate surface.
+    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.
   - 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: Partition the finite remainder into regimes and define the certificate required before any interval counts as covered.
+    next_move: Build on the exact `1..2000` 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, while the imported forum timeline currently points to a stronger external threshold. The chosen next lane is bounded finite verification under the best trusted threshold.
-    current_blocker: The repo has not yet frozen the certificate surface needed for any bounded interval claim to count as canonical coverage.
-    next_move: Close `N848.G1.A18`.
+    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`.
   - ticket_id: N848F
     title: Audit public formalization coverage
     route_id: formalization_coverage_audit
@@ -164,6 +164,27 @@ atoms:
     title: Freeze the bounded finite-verification program and certificate surface
     route_id: finite_check_gap_closure
     ticket_id: N848
+    status: done
+    summary: The verification plan, regime split, certificate spec, and external audit ledger are now part of the live handoff surface.
+    next_move: Freeze the operational threshold posture and the first covered interval.
+  - atom_id: N848.G1.A19
+    title: Freeze the operational threshold posture for the bounded-verification lane
+    route_id: finite_check_gap_closure
+    ticket_id: N848
+    status: done
+    summary: The repo now distinguishes operational use of the imported `2.64 x 10^17` threshold from canonical repo-owned theorem language.
+    next_move: Build the first exact covered interval.
+  - atom_id: N848.G1.A20
+    title: Build the first exact covered interval for bounded verification
+    route_id: finite_check_gap_closure
+    ticket_id: N848
+    status: done
+    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`
+    route_id: finite_check_gap_closure
+    ticket_id: N848
     status: ready
-    summary: The next closure cycle should start by partitioning the finite remainder into regimes and defining what evidence is strong enough for a bounded interval claim to count.
-    next_move: Promote the bounded verification plan, regimes, certificate spec, and external ledger into the live handoff surface.
+    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.

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

@@ -20,5 +20,7 @@
 - Seventeenth refinement: commit and push the review-ready 848 package so the audited candidate is now a public repo artifact rather than only a local workspace bundle.
 - Eighteenth refinement: record the imported public-threshold timeline through 2026-03-23 and state explicitly that the optimization target is finite-gap closure, not threshold-lowering in isolation.
 - Nineteenth refinement: choose bounded finite verification as the next closure lane and freeze the first repo artifacts for regimes, certificates, and external verification audit.
-- 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 the remaining gap centered on building a trusted bounded-verification program under the best imported threshold currently tracked.
-- Next maturity threshold: turn the verification plan into the first concrete covered-interval program.
+- 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.

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

@@ -10,6 +10,7 @@ ready_prompts:
   - What certificate format is required before a claimed interval counts as canonically covered?
   - Which public verification attempts should be treated as audit inputs rather than accepted coverage?
   - How should the finite remainder be partitioned into regimes so that methods and trust levels stay visible?
+  - How far does the exact small-`N` clique scan now reach, and what should the next extension target be?
 verification_hook:
   - erdos number-theory status 848
   - erdos number-theory routes 848

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

@@ -76,12 +76,14 @@ Desired certificate:
 
 ## Current honest posture
 
-- Regime A: not frozen in this repo
+- Regime A: first exact interval `1..2000` is now frozen in the repo with a reproducible
+  maximum-clique certificate
 - 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
 - Regime D: public asymptotic theorem exists; imported explicit thresholds are tracked but not
   yet repo-audited
 
-So the next honest move is to freeze the certificate format before claiming any new verified
-interval.
+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
+switching method class.

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

@@ -0,0 +1,170 @@
+#!/usr/bin/env node
+
+import fs from 'node:fs';
+import path from 'node:path';
+
+function parseArgs(argv) {
+  const args = { min: 1, max: 100, jsonOutput: null };
+  for (let i = 0; i < argv.length; i += 1) {
+    const token = argv[i];
+    if (token === '--min') {
+      args.min = Number(argv[++i]);
+    } else if (token === '--max') {
+      args.max = Number(argv[++i]);
+    } else if (token === '--json-output') {
+      args.jsonOutput = argv[++i];
+    } else {
+      throw new Error(`Unknown argument: ${token}`);
+    }
+  }
+  if (!Number.isInteger(args.min) || args.min < 1) {
+    throw new Error('--min must be a positive integer');
+  }
+  if (!Number.isInteger(args.max) || args.max < args.min) {
+    throw new Error('--max must be an integer >= --min');
+  }
+  return args;
+}
+
+function isSquarefree(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;
+    while (x % p === 0) x /= p;
+  }
+  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 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 maximumClique(vertices, adjacency) {
+  let best = [];
+
+  function bronKerbosch(R, P, X) {
+    if (P.length === 0 && X.length === 0) {
+      if (R.length > best.length) best = [...R];
+      return;
+    }
+    if (R.length + P.length <= best.length) return;
+
+    let pivot = null;
+    let pivotNeighborsInP = -1;
+    for (const u of [...P, ...X]) {
+      let count = 0;
+      for (const v of P) {
+        if (adjacency[u].has(v)) count += 1;
+      }
+      if (count > pivotNeighborsInP) {
+        pivotNeighborsInP = count;
+        pivot = u;
+      }
+    }
+
+    const candidates = pivot === null
+      ? [...P]
+      : P.filter((v) => !adjacency[pivot].has(v));
+
+    for (const v of candidates) {
+      bronKerbosch(
+        [...R, v],
+        P.filter((u) => adjacency[v].has(u)),
+        X.filter((u) => adjacency[v].has(u)),
+      );
+      P = P.filter((u) => u !== v);
+      X = [...X, v];
+    }
+  }
+
+  bronKerbosch([], vertices.map((_, index) => index), []);
+  return best.map((index) => vertices[index]).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 maxSize = clique.length;
+    const residue7Size = residue7.length;
+    const residue18Size = residue18.length;
+    rows.push({
+      N,
+      maxCliqueSize: maxSize,
+      residue7Size,
+      residue18Size,
+      candidateAchievesMaximum: residue7Size === maxSize,
+      exampleMaximumClique: clique,
+      exampleMatchesResidue7: sameSortedSet(clique, residue7),
+      exampleMatchesResidue18: sameSortedSet(clique, residue18),
+    });
+  }
+  return rows;
+}
+
+function summarize(rows) {
+  return {
+    interval: `${rows[0].N}..${rows[rows.length - 1].N}`,
+    rows: rows.length,
+    allCandidateAchievesMaximum: rows.every((row) => row.candidateAchievesMaximum),
+    allExampleCliquesMatchCandidateClass: rows.every(
+      (row) => row.exampleMatchesResidue7 || row.exampleMatchesResidue18,
+    ),
+  };
+}
+
+const args = parseArgs(process.argv.slice(2));
+const rows = scanInterval(args.min, args.max);
+const payload = {
+  generatedAt: new Date().toISOString(),
+  method: 'exact_maximum_clique_scan',
+  problemId: '848',
+  parameters: {
+    min: args.min,
+    max: args.max,
+  },
+  summary: summarize(rows),
+  results: rows,
+};
+
+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/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.
+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`.
 frontier_label: finite_check_gap_closure
-frontier_detail: The repo has chosen bounded finite verification as the next closure lane under the best imported threshold currently tracked.
+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.
 checkpoint_focus: Preserve the distinction between existential N0, explicit N0, sample finite checks, and full closure.
-next_honest_move: Freeze the bounded finite-verification program and its certificate requirements before claiming any new covered interval.
+next_honest_move: Decide whether to extend the exact clique scan beyond `2000` or pivot to a different bounded-verification method.
 related_core_problems:
   - "844"
 literature_focus:
@@ -21,15 +21,18 @@ artifact_focus:
   - EVIDENCE.md
   - FORMALIZATION.md
   - THRESHOLD_LEDGER.md
+  - OPERATIONAL_THRESHOLD_POSTURE.md
   - BOUNDED_VERIFICATION_PLAN.md
   - VERIFICATION_REGIMES.md
   - VERIFICATION_CERTIFICATE_SPEC.md
   - EXTERNAL_VERIFICATION_LEDGER.md
+  - INTERVAL_WORK_QUEUE.yaml
+  - EXACT_SMALL_N_1_2000_CERTIFICATE.md
 question_ledger:
   open_questions:
-    - What exact interval should the repo try to cover first in a bounded-verification lane?
     - Which imported threshold value is trusted enough to size the finite remainder operationally?
     - What certificate format is strong enough to prevent repeat low-trust verification claims?
+    - How far can the exact clique scan be pushed before a different method class is needed?
     - Which public verification attempts are worth auditing rather than rebuilding from scratch?
   active_route_notes:
     - Keep the asymptotic theorem separate from the unresolved finite closure.
@@ -41,4 +44,5 @@ 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`.
   problem_solved: []

package/problems/848/EVIDENCE.md

@@ -70,6 +70,11 @@ Current public evidence captured locally:
 - The repo has now chosen bounded finite verification as the next closure lane and frozen
   first-pass notes for verification regimes, certificate requirements, and imported
   verification audit.
+- The repo now has an operational threshold posture note that allows imported `N0`
+  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.
 
 Claim-safe local posture:
 - Exact: the public status is `decidable`, not `open` and not fully `solved`.
@@ -109,4 +114,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
-- freeze the bounded finite-verification program before counting any interval as covered
+- decide whether exact verified coverage should be extended beyond `2000` or whether the
+  next gain now needs a different method class

package/problems/848/ROUTES.md

@@ -70,9 +70,12 @@
 - The imported public thread currently reports a better external threshold
   `N0 = 2.64 x 10^17` on 2026-03-23.
 - The repo has now chosen the bounded finite-verification lane for the next cycle.
-- The next concrete task is to freeze:
+- The repo now has:
   - 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`
+- 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.
 - 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,6 +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`
 
 What is not being claimed:
 - not full all-`N` closure in the repo