[carlostoledo1891]

Stacked on #232: both edit adjacent README table rows (1a/1b and 1c/1d), so this branch carries #232's commit underneath; once #232 is merged only the second commit remains, and either order merges cleanly.

#216, #230 and #232 applied the CONTRIBUTING rule that the marker "is removed when that changes — when the paper is refereed and published, or when the argument is formalized or independently replayed." This PR offers the same replay for the two family-1 rows that carry it, decided from the bytes the rows cite, with no code shared with the claimants. Markdown only.

bound	bytes replayed	exact value
$C_{1c} \geq 0.4103287$ [R2026]	rozetyp/barnard-steinerberger-lower-bound @ 19f3971, certificate.json, sha256 62ac49ddbbfc… ($K = 6144$, 6148 integer weights)	21072342208353792/51354782902387969 = 0.41032871754918741449…
$C_{1d} \leq 1.4630715826075594$ [CERT2026]	construction.json from the #224 description (300 values; sha256 44f3f2b63b0d… with CRLF line endings and no trailing newline, the bytes the stated digest is of)	2039224160683882663565441886346340189798400/1393796574908163689489385839036226787118881 = 1.46307158260755932746…

Two corrections.

• $C_{1d}$: the certificate's exact value, 1.46307158260755932746…, is above the bound printed in the table and the README, 1.463071582607559 (by $3.3 \times 10^{-16}$). An upper bound has to round up, so the certificate shows $C_{1d} \leq 1.4630715826075594$, not the printed number. This PR prints 1.4630715826075594 in the row, the README cell and the Recent-progress line.
• $C_{1c}$: the page gives the fraction's decimal as 0.41030287175…; it is 0.41032871754…. The bound column (0.4103287) is right and unchanged.

How. For $C_{1c}$, the autocorrelation of an equal-step function is linear between multiples of $1/K$, so the minimum over $t \in [0,1]$ is $K \min_{0 \le k \le K} \sum_i w_i w_{i+k} / (\sum_i w_i)^2$. For $C_{1d}$, $ff$ is linear between multiples of the cell width, so $\max_t |ff| / (\int f)^2 = 2n \max_m |\sum_{i+j=m} v_i v_j| / (\sum_i v_i)^2$, with the values read as the doubles json.load gives (as the certificate's own verifier reads them). Two implementations compute these exactly, sharing no code with each other or with the certificates' verifiers (not run): Python summing every lag term by term (fractions, int), and JavaScript over BigInt with Kronecker products. Both give the claimants' stated fractions exactly. The earlier $K = 3072$ certificate in previous/ was checked too (0.41030211723…, the value its row states).

Red controls, which must come out wrong in both implementations: a $C_{1c}$ bound $2 \times 10^{-15}$ above the exact value and a $C_{1d}$ bound $10^{-15}$ below it are refuted; a negative weight, and a $C_{1d}$ function changed to integral zero, are refused.

Re-derive from https://github.com/carlostoledo1891/cert-machine at d9a3942b82f9b5dd174935584601065a4e660b68:

node tools/replay-autocorr.js --check   # the JavaScript decider against the record, a few seconds; the red controls must fire
node tools/replay-autocorr.js           # both implementations (~2 min; the Python direct sums dominate)

Write-up: https://carlostoledo.co/reports/optconst-queue.html#autocorr (§7).

What changes:

• The README cells for 1c and 1d drop the asterisk; the 1d cell reads 1.4630715826075594.
• The two "(unverified)" Recent-progress lines are updated, and one line is added in the form the earlier replays were recorded.
• The two page rows lose the asterisk and get a one-sentence replay note, a [T2026] reference (no [T2026] exists on these pages) and a contribution note; on 1d the asterisk bullet says it was removed.

AI-assisted: prepared with Claude (Anthropic) in a certified-arithmetic setting: the replay code, the records and this pull request. Every number above is read from the pinned record at the commit cited, and was re-checked against the upstream files before sending.

🤖 Generated with Claude Code

[chessing234]

all good

[teorth]

Holding this one, with a policy change behind it rather than any objection to the work.

The asterisk-removal requests have reached seven across two accounts (#216 and #230 merged; #232, #235, #242, #243, #249 open), covering C_1a, C_1b, C_1c, C_1d, C_3b, C_3c, C_31, C_49, C_71, C_82 and C_86. Each replay is carefully documented — certificate bytes by sha256, two implementations sharing no code, red controls that must fire — and I have no reason to doubt any of them individually. The problem is structural: a marker that one party can clear across the whole repository stops distinguishing anything, which defeats the purpose of having it.

So CONTRIBUTING now says:

Removing an asterisk takes a second party. Adding the marker is a reviewer's call, but taking it off is a claim that someone other than the submitter has checked the work, so it needs evidence from someone other than whoever is asking. Any one of these is enough: the paper is refereed and published; the argument is registered with a service that mechanically checks the proof against the stated theorem, such as Palomar; a maintainer signs off; or someone independent confirms the replay in the pull request or issue thread. A replay carried out by the person requesting the removal is not by itself sufficient, however carefully it is documented [...] Post the replay, and let a second party confirm it.

What this means here. The replay stands as posted; it just needs one of the four. The quickest routes are a Palomar registration of the construction, or someone unconnected confirming in this thread that they re-ran it and got the same enclosure. Your write-ups make that easy to do — the sha256 and the command line are already there.

I am leaving these open rather than closing them, so the confirmations can land on the existing threads.

One mechanical note: #232 is subsumed by #243, which covers the same two constants plus C_1c and C_1d. Whichever route you take, #243 alone is enough and #232 can be closed.

Thanks for the care in these; the issue is the shape of the rule, not the quality of the replays.

[carlostoledo1891]

A mechanical note: #232 and #243 show as merged at 03:53, a few minutes after the hold note above, and constants/1d.md now lists [CERT2026] twice: as $1.463071582607559$* and, further down, as $1.4630715826075594$ without the asterisk. If the merge was intended, the starred row can go. If the hold stands, the unstarred row should go, and the C_1a and C_1b replays wait for a second party too. Happy to open the PR either way.