erdos-problems 0.3.2 → 0.3.4

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

@@ -0,0 +1,58 @@
+# Problem 848 Lemma 2.2 Prime-Count Bound
+
+This note closes the outstanding blocker inside `N848.G1.A6`.
+
+Goal:
+- freeze the additive `2 pi(N) / N` term that remained unresolved in
+  `LEMMA22_EXPLICIT_BOUND.md`
+
+## Source surface
+
+Primary source:
+- Pierre Dusart, `Estimates of Some Functions Over Primes without R.H.`
+
+Publicly visible statement used here:
+- for `x > 60184`,
+  `pi(x) <= x / (log x - 1.1)`
+
+Reference surface:
+- the public full-text view mirrored from `arXiv:1002.0442v1`
+- see the theorem summary lines recorded in the local research notes
+
+## Candidate threshold scale
+
+The strongest public candidate threshold discussed in the forum workstream is
+
+- `N = exp(1420)`.
+
+Since `exp(1420) > 60184`, Dusart's bound applies. Therefore for every
+- `N >= exp(1420)`,
+
+we have
+
+`2 pi(N) / N <= 2 / (log N - 1.1) <= 2 / (1420 - 1.1)`.
+
+Numerically,
+
+- `2 / (1420 - 1.1) ~= 0.0014095427`.
+
+At the weaker public candidate
+- `N = exp(1958)`,
+
+the same bound improves to
+
+- `2 / (1958 - 1.1) ~= 0.0010220247`.
+
+So the prime-count term is now explicit, monotone, and numerically small enough to carry into
+the weakest-branch witness budget.
+
+## Honest route consequence
+
+This closes the last unfrozen line item inside the provisional `T = 250` branch budget.
+
+The next live question is no longer:
+- how to bound the Lemma 2.2 `+1` contribution
+
+It is:
+- how much `eta` and final bookkeeping room survives once that bound is inserted into the full
+  weakest-branch ledger?

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

@@ -4,9 +4,21 @@ routes:
   - route_id: finite_check_gap_closure
     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.
-    why_now: This is the honest live frontier after the public asymptotic result.
-    next_move: Spend the now-frozen weakest-branch slack on the first explicit Lemma 2.1 inequality.
+    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.
+  - route_id: external_threshold_tracking
+    title: External Threshold Tracking
+    status: support
+    summary: Track the best imported public `N0` claims so the finite remainder is sized honestly.
+    why_now: Public threshold improvements change the scale of the remaining bounded verification problem.
+    next_move: Keep the 2026-03-21 to 2026-03-23 imported timeline current without silently adopting it as canonical repo truth.
+  - route_id: bounded_finite_verification
+    title: Bounded Finite Verification
+    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.
   - route_id: formalization_coverage_audit
     title: Formalization Coverage Audit
     status: support
@@ -15,12 +27,12 @@ routes:
     next_move: Keep this as support context until the threshold ledger is frozen.
 tickets:
   - ticket_id: N848
-    title: Convert the frozen weakest-branch budget into explicit inequalities
+    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 weakest branch and its conservative slack budget are now frozen; the next job is to quantify the explicit analytic losses against that budget.
-    current_blocker: Lemma 2.1 still hides its tail and inclusion-exclusion remainder behind `<<` and `N^(o(1))`.
-    next_move: Close `N848.G1.A4`.
+    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
@@ -54,6 +66,125 @@ atoms:
     title: Make the Lemma 2.1 remainder terms explicit against the frozen weakest-branch budget
     route_id: finite_check_gap_closure
     ticket_id: N848
+    status: done
+    summary: Lemma 2.1 now has a one-sided explicit remainder ledger, and the large-prime tail has emerged as the live bottleneck.
+    next_move: Use the new ledger to decide whether the next move is a sharper prime-tail treatment or a different truncation parameter.
+  - atom_id: N848.G1.A5
+    title: Decide whether the next Lemma 2.1 move is a sharper prime-tail bound or a different truncation parameter
+    route_id: finite_check_gap_closure
+    ticket_id: N848
+    status: done
+    summary: The truncation scan shows that the one-sided route can raise `T` far beyond `sqrt(log N)` without waking the discrete remainder, so the next move is to enlarge `T` before chasing a deeper tail theorem.
+    next_move: Use a larger `T` in the full weakest-branch bookkeeping.
+  - atom_id: N848.G1.A6
+    title: Carry a larger truncation parameter through Lemma 2.2 and the full weakest-branch budget
+    route_id: finite_check_gap_closure
+    ticket_id: N848
+    status: done
+    summary: Lemma 2.2 is now explicit at the witness-budget level, including the prime-count term, and the `T = 250` witness retains about `3.66e-4` room for final `eta` and bookkeeping.
+    next_move: Turn that witness budget into a line-by-line explicit branch assembly.
+  - atom_id: N848.G1.A7
+    title: Turn the `T = 250` witness budget into a line-by-line explicit weakest-branch assembly
+    route_id: finite_check_gap_closure
+    ticket_id: N848
+    status: done
+    summary: The weakest branch now has a line-by-line witness ledger at `T = 250` with a working choice `eta = 10^-4` and about `2.66e-4` visible reserve.
+    next_move: Carry the same witness into the other public proof branches.
+  - atom_id: N848.G1.A8
+    title: Check whether the weakest-branch witness already closes the other public branches
+    route_id: finite_check_gap_closure
+    ticket_id: N848
+    status: done
+    summary: The shared witness also closes the branches `0.0358`, `0.0336`, and `0.0294` at the repo's current explicit level, so no new branch bottleneck has appeared.
+    next_move: Package the shared witness into a proposition-level explicit candidate note.
+  - atom_id: N848.G1.A9
+    title: Package the shared witness into a proposition-level explicit candidate
+    route_id: finite_check_gap_closure
+    ticket_id: N848
+    status: done
+    summary: The repo now has a proposition-level explicit witness candidate with claim-safe wording.
+    next_move: Separate proof obligations from exposition obligations before any stronger claim is made.
+  - atom_id: N848.G1.A10
+    title: Write the proof-obligation ledger for the proposition-level explicit candidate
+    route_id: finite_check_gap_closure
+    ticket_id: N848
+    status: done
+    summary: The remaining obligations are now split cleanly into mathematical hardening work versus presentation-quality work.
+    next_move: Harden the decimal inputs used by the current witness.
+  - atom_id: N848.G1.A11
+    title: Replace the displayed decimal inputs with certified numerical bounds
+    route_id: finite_check_gap_closure
+    ticket_id: N848
+    status: done
+    summary: The current shared witness now has a conservative machine-interval ledger for its main numerical inputs.
+    next_move: Assemble the hardened witness into a theorem-style note.
+  - atom_id: N848.G1.A12
+    title: Assemble the hardened witness into a theorem-style explicit proof note
+    route_id: finite_check_gap_closure
+    ticket_id: N848
+    status: done
+    summary: The route now has a theorem-shaped proof artifact built from the numerically hardened shared witness candidate.
+    next_move: Decide where to surface that artifact next.
+  - atom_id: N848.G1.A13
+    title: Decide how to surface the theorem-style repo candidate
+    route_id: finite_check_gap_closure
+    ticket_id: N848
+    status: done
+    summary: The theorem-style candidate now lives in both the paper bundle and a dossier-level public review artifact, with a short share-ready summary.
+    next_move: Decide whether to commit and open review on the surfaced package.
+  - atom_id: N848.G1.A14
+    title: Prepare the surfaced candidate package for commit and review
+    route_id: finite_check_gap_closure
+    ticket_id: N848
+    status: done
+    summary: The paper bundle now has drafted review-facing sections, the surfaced package has no remaining placeholder text, and the safety checks are green.
+    next_move: Turn the prepared package into a clean review unit.
+  - atom_id: N848.G1.A15
+    title: Commit or open review on the surfaced candidate package
+    route_id: finite_check_gap_closure
+    ticket_id: N848
+    status: done
+    summary: The review-ready 848 package is now committed and pushed on `main`, so this is no longer the live frontier.
+    next_move: Record the imported threshold timeline and restate the optimization target clearly.
+  - atom_id: N848.G1.A16
+    title: Record the imported threshold timeline and clarify the closure objective
+    route_id: finite_check_gap_closure
+    ticket_id: N848
+    status: done
+    summary: The dossier now distinguishes imported public thresholds from the repo's own audited candidate and states clearly that the real objective is finite-gap closure.
+    next_move: Choose the next closure lane under the best imported threshold currently tracked.
+  - atom_id: N848.G1.A17
+    title: Choose the next closure lane under the best imported threshold
+    route_id: finite_check_gap_closure
+    ticket_id: N848
+    status: done
+    summary: The repo has chosen bounded finite verification as the next closure lane under the best imported threshold currently tracked.
+    next_move: Freeze the bounded finite-verification program and the certificate spec.
+  - atom_id: N848.G1.A18
+    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 branch-level slack is now frozen; the next unresolved inequality is the Lemma 2.1 tail plus inclusion-exclusion remainder.
-    next_move: Write explicit upper bounds for the `N / T` tail and the small-prime inclusion-exclusion remainder with `T = floor(sqrt(log N))`.
+    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/PROOF_OBLIGATIONS.md

@@ -0,0 +1,101 @@
+# Problem 848 Proof-Obligation Ledger
+
+This note closes `N848.G1.A10`.
+
+Purpose:
+- separate the remaining obligations behind the current proposition-level repo candidate into
+  two buckets:
+  - obligations that could still change the mathematics
+  - obligations that are primarily presentation or publication quality
+
+## Current repo candidate
+
+The current candidate, from `PROPOSITION_EXPLICIT_CANDIDATE.md`, is:
+- `N >= exp(1420)`
+- `eta = 10^-4`
+- shared truncation witness `T = 250`
+
+with the conclusion that near-extremal sets are forced into the `7 mod 25` or `18 mod 25`
+classes.
+
+## Obligations that still affect the mathematics
+
+### 1. Certified replacement for displayed decimal approximations
+
+Why it matters:
+- several branch ledgers currently use displayed decimals such as `0.0376113079`,
+  `0.0005641453`, and `0.0014095427`
+- if one of those visible decimals is not backed by a certified upper interval, the current
+  witness could in principle be overstated
+
+What would discharge it:
+- a machine-checked interval or conservative rational upper bound for every decimal input used
+  in the proposition-level candidate
+
+### 2. Explicit domination of the discrete inclusion-exclusion terms
+
+Why it matters:
+- the discrete terms are obviously tiny at `N >= exp(1420)`, but the current notes still treat
+  them informally as “astronomically small”
+
+What would discharge it:
+- one explicit numerical line showing each discrete term is below a fixed reserve such as
+  `10^-10`, or far smaller, at `N = exp(1420)` and hence for all larger `N`
+
+### 3. One-sheet theorem-style assembly
+
+Why it matters:
+- the current candidate is spread across several notes
+- a theorem claim should have one place where every branch bound is assembled in the same
+  notation and every input is visibly consumed exactly once
+
+What would discharge it:
+- a single proposition-proof ledger using the current witness and citing the supporting notes
+  only as lemma justifications, not as extra floating context
+
+## Obligations that are mainly presentation-quality
+
+### 4. Citation polish
+
+Examples:
+- pin the exact Dusart theorem/section in a cleaner bibliographic form
+- standardize references to Sawhney's note and the forum discussion
+
+These matter for publication quality, but do not presently look like mathematical blockers.
+
+### 5. Reader-facing proof narration
+
+Examples:
+- convert the current route notes into a smoother proof narrative
+- reduce repeated explanations of why the repo is still claim-safe
+
+This matters for public readability, not for whether the witness currently works.
+
+### 6. Paper-writer integration
+
+Examples:
+- seed the explicit candidate into the paper bundle
+- turn the proposition candidate into a draft section with theorem/proof/corollary structure
+
+Again, useful, but downstream from the mathematical hardening steps above.
+
+## Honest prioritization
+
+The next mathematically meaningful hardening step is:
+- replace the displayed decimal inputs with certified intervals or conservative rational bounds
+
+That is the step most likely to change whether the current repo candidate survives intact.
+
+By contrast, the remaining citation and exposition work is important but does not currently
+look like the true blocker.
+
+## Route consequence
+
+The route no longer needs:
+- another branch hunt
+- another witness search
+- or another truncation scan
+
+It now needs:
+- one hardening pass on the numerical inputs
+- then a theorem-style explicit candidate writeup

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

@@ -0,0 +1,69 @@
+# Problem 848 Proposition-Level Explicit Candidate
+
+This note closes `N848.G1.A9`.
+
+Public context:
+- this note records the repo's audited explicit candidate package
+- it does not claim to be the best imported public threshold currently visible on the
+  Problem 848 forum thread
+
+## Candidate repo statement
+
+The current repo evidence supports the following **candidate**:
+
+For every
+- `N >= exp(1420)`
+
+if
+- `A subseteq [N]`
+- `ab + 1` is never squarefree for all `a, b in A`
+- `|A| >= (1/25 - 10^-4) * N`
+
+then
+- `A` is contained in either the `7 mod 25` class or the `18 mod 25` class.
+
+This is the repo's current explicit stability candidate for Sawhney's Proposition 1.1.
+
+## Why the repo can now say this
+
+The supporting chain is now explicit inside the repo:
+- `WEAKEST_CASE_BUDGET.md` freezes the weakest public branch main term.
+- `LEMMA21_EXPLICIT_BOUND.md` and `LEMMA21_TRUNCATION_SCAN.md` make Lemma 2.1 explicit and
+  justify the larger truncation witness `T = 250`.
+- `LEMMA22_EXPLICIT_BOUND.md` and `LEMMA22_PRIME_COUNT_BOUND.md` make Lemma 2.2 explicit at
+  the same witness scale.
+- `WEAKEST_BRANCH_T250_ASSEMBLY.md` freezes the weakest-branch line-by-line witness with
+  working `eta = 10^-4`.
+- `BRANCH_COMPARISON_LEDGER.md` shows that the same witness also controls the public branches
+  rounded as `0.0358`, `0.0336`, and `0.0294`.
+
+So at the repo's current explicit level, the public proof skeleton now has one shared witness
+instead of a collection of separate unresolved branches.
+
+## What the repo is **not** claiming yet
+
+This note does **not** yet promote the candidate into canonical solved truth.
+
+The repo is still **not** claiming:
+- that a publication-ready explicit proof has been written line by line with every rounding
+  and floor/ceiling detail frozen at journal quality
+- that `exp(1420)` is the optimal threshold
+- that the finite range below `exp(1420)` has been closed here
+- that the public theorem page should already be updated from `decidable` to `solved`
+
+So the right reading is:
+- explicit repo candidate: yes
+- finished publication proof artifact: not yet
+- full all-`N` closure inside this repo: not yet
+
+## Honest next move
+
+The next route task is not another branch estimate.
+
+It is:
+- write the proof-obligation ledger separating this repo candidate from a publishable explicit
+  theorem writeup
+- list exactly which remaining details are purely expository/bookkeeping and which would still
+  change the mathematics if they failed
+
+That is the remaining gap between the current research workspace and a public-truth update.

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

@@ -5,5 +5,22 @@
 - Second refinement: freeze the first threshold ledger separating existential, weakly explicit, and tentative public threshold claims.
 - Third refinement: isolate the `0.0377` branch as the weakest public case and freeze a source-backed branch-budget note for it.
 - Fourth refinement: freeze the weakest-branch main term numerically at about `0.0376113`, with conservative slack about `0.0023887` before analytic error absorption.
-- Current public pack posture: active route `finite_check_gap_closure`, with asymptotic theorem already in hand and the remaining gap centered on explicit remainder extraction, threshold budgeting, and bounded finite verification.
-- Next maturity threshold: replace the Lemma 2.1 `<<` and `N^(o(1))` steps with explicit inequalities against the frozen branch budget.
+- Fifth refinement: make Lemma 2.1 one-sided explicit and identify the large-prime tail, not the small-prime inclusion-exclusion remainder, as the live analytic bottleneck.
+- Sixth refinement: show that the one-sided route no longer needs `T = floor(sqrt(log N))`, and that raising `T` materially improves the live bottleneck while leaving the discrete term negligible.
+- Seventh refinement: make Lemma 2.2 explicit at the same one-sided level and freeze a provisional `T = 250` weakest-branch tail budget, with the remaining unfrozen blocker concentrated in the Lemma 2.2 prime-count term and final `eta` bookkeeping.
+- Eighth refinement: freeze the Lemma 2.2 prime-count term with an explicit Dusart bound, leaving about `3.66e-4` witness margin at `N >= exp(1420)` for `eta` and final bookkeeping.
+- Ninth refinement: freeze a weakest-branch working witness at `T = 250`, `N >= exp(1420)`, `eta = 10^-4`, leaving about `2.66e-4` visible reserve in that branch.
+- Tenth refinement: compare the same witness against the public branches `0.0358`, `0.0336`, and `0.0294`, and find that all three retain strictly larger visible reserve than the weakest branch.
+- Eleventh refinement: package the shared witness as a proposition-level repo candidate `N >= exp(1420)`, `eta = 10^-4`, while keeping the distinction between repo candidate and finished theorem writeup explicit.
+- Twelfth refinement: separate the remaining proof obligations into mathematical hardening work versus presentation-quality work, and identify certified numerical intervals as the next real blocker.
+- Thirteenth refinement: replace the visible decimal inputs with conservative machine intervals, leaving a certified visible reserve of about `2.66e-4` after the working `eta = 10^-4`.
+- Fourteenth refinement: assemble the hardened witness into a single theorem-style note suitable for paper-writer mode and future public review.
+- Fifteenth refinement: surface the current candidate in both the paper bundle and a dossier-level public review note, with a short share-ready summary.
+- Sixteenth refinement: draft the remaining paper-bundle sections, refresh the indexes, clear the last placeholder text, and verify the package with tests and a publish-surface check.
+- 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.
+- 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

@@ -1,13 +1,16 @@
 route_packet_id: nt848_finite_check_gap_closure_v1
 route_id: finite_check_gap_closure
-frontier_claim: Preserve the sufficiently-large-N theorem for Problem 848 while turning the remaining finite-check gap into an explicit threshold-plus-verification workspace.
+frontier_claim: Close the finite decidable gap for Problem 848 while keeping imported threshold progress separate from repo-owned audited claims.
 theorem_module: ""
 checkpoint_packet: CHECKPOINT_TEMPLATE.md
 report_packet: REPORT_TEMPLATE.md
 ready_prompts:
-  - Which case in the proof has the smallest slack to 1/25?
-  - How much of the roughly `0.002388` weakest-branch slack can be safely assigned to Lemma 2.1?
-  - Can the Lemma 2.1 tail and inclusion-exclusion remainder be made explicit without exhausting the branch budget?
+  - What is the best imported explicit `N0` currently visible on the public thread, and how trusted is it?
+  - What exact interval should the repo try to certify first in the bounded-verification lane?
+  - 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/THEOREM_STYLE_EXPLICIT_NOTE.md

@@ -0,0 +1,91 @@
+# Problem 848 Theorem-Style Explicit Note
+
+This note closes `N848.G1.A12`.
+
+## Statement
+
+**Repo explicit candidate.**
+
+Let
+- `N >= exp(1420)`,
+- `A subseteq [N]`,
+
+and suppose that
+- `ab + 1` is never squarefree for all `a, b in A`,
+- `|A| >= (1/25 - 10^-4) * N`.
+
+Then the current repo candidate says:
+- `A` is contained in either the `7 mod 25` class or the `18 mod 25` class.
+
+## Witness parameters
+
+The shared witness used throughout the current repo candidate is:
+- truncation value `T = 250`
+- threshold scale `N >= exp(1420)`
+- stability parameter `eta = 10^-4`
+
+## Proof skeleton
+
+### Step 1. Split into the public branches from Sawhney's proof
+
+The public proof breaks into the branches whose rounded bounds are:
+- `0.0377`
+- `0.0358`
+- `0.0336`
+- `0.0294`
+
+### Step 2. Use the shared explicit witness
+
+The repo now has explicit ledger support for the shared witness:
+- `LEMMA21_EXPLICIT_BOUND.md`
+- `LEMMA21_TRUNCATION_SCAN.md`
+- `LEMMA22_EXPLICIT_BOUND.md`
+- `LEMMA22_PRIME_COUNT_BOUND.md`
+- `CERTIFIED_NUMERICAL_LEDGER.md`
+
+These notes provide the explicit replacements for the original `o(1)` and `<<` steps at the
+chosen witness scale.
+
+### Step 3. Close the tightest branch
+
+`WEAKEST_BRANCH_T250_ASSEMBLY.md` shows that the tightest public branch retains a certified
+visible reserve of about
+- `2.66e-4`
+
+after all currently frozen lemma-level costs and the working choice
+- `eta = 10^-4`.
+
+### Step 4. Check the remaining public branches
+
+`BRANCH_COMPARISON_LEDGER.md` shows that the branches `0.0358`, `0.0336`, and `0.0294` all
+retain strictly larger visible reserve than the weakest branch under the same witness.
+
+So no new branch obstruction appears at the current explicit level.
+
+### Step 5. Conclude the repo candidate
+
+Since every public branch in the proof skeleton is controlled by the same witness, the repo
+arrives at the proposition-level candidate stated above.
+
+## What this note is and is not
+
+This note **is**:
+- a theorem-shaped packaging of the current repo candidate
+- a bridge artifact for paper-writer mode
+- a clean summary of the current explicit witness
+
+This note is **not yet**:
+- a final publication-ready proof
+- a formal proof-assistant certificate
+- a declaration that Problem 848 is fully solved in the repo
+
+## Remaining gap
+
+The remaining work is no longer “find the right witness.”
+
+It is:
+- decide whether the current repo candidate is strong enough to publish internally as a public
+  review artifact
+- port it into the paper bundle
+- and, if desired, replace the current repo-level interval reasoning with stronger formal or
+  machine-checked certification

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

@@ -0,0 +1,60 @@
+# Problem 848 Verification Certificate Spec
+
+Any bounded-verification claim for Problem `848` should attach a certificate with these fields.
+
+## Required fields
+
+- `interval`
+  - exact range covered, for example `N = 1..7306`
+- `method_class`
+  - one of:
+    - `exact_small_n`
+    - `structured_breakpoints`
+    - `imported_external_computation`
+    - `hybrid`
+- `claim_level`
+  - one of:
+    - `exact`
+    - `verified`
+    - `external_only`
+- `artifacts`
+  - concrete files, repos, scripts, or notes used for the claim
+- `reproduction`
+  - how a maintainer can rerun or recheck the claim
+- `failure_mode`
+  - what would invalidate the interval claim
+- `audit_status`
+  - one of:
+    - `repo_audited`
+    - `partially_audited`
+    - `external_unreviewed`
+    - `blocked`
+
+## Strongly preferred fields
+
+- `breakpoint_definition`
+  - if the method uses breakpoint sufficiency, define exactly what the breakpoints are
+- `monotonicity_justification`
+  - if interval coverage is inferred between checkpoints, explain why
+- `independent_check`
+  - a second script, proof note, or reviewer confirmation
+- `cost_profile`
+  - rough runtime or proof complexity
+
+## Rejection triggers
+
+Do not count a range as canonically covered if any of the following is true:
+
+- the claim silently uses the wrong asymptotic handoff threshold
+- the method covers only sample points but is presented as interval coverage
+- a breakpoint argument is used without a monotonicity justification
+- the computation is public but explicitly criticized as unverified or likely incorrect and no
+  repo audit has answered that criticism
+- the result cannot be rerun or inspected by a future maintainer
+
+## Why this matters here
+
+The public thread already contains one verification attempt that was later corrected and
+criticized as difficult to verify. That does not make bounded verification hopeless. It does
+mean this repo should demand interval certificates rather than encouraging "I think this
+covers everything up to X" style claims.