Tightened slack constants on the conservative paired scratch-reuse candidate: conditional κ = 3.6210858481e-4

[geckods]

Change and mathematical scope

Extends PR #135's draft candidate (this branch's parent, same status) by one instantiation choice: the retained 47-constraint assembly is instantiated with beta = 10^-15 and backoff = 10^-17 instead of the legacy beta = 10^-6, backoff = 10^-14 that PR #135 inherits from the PR104-era lineage (#97 used beta = 1/4, the batched assembly 1/1000, #104 10^-6, machinery unchanged; the strict constraints involve beta only through positivity and leaf-ordering margins, checked at exact rationals; the complex side binds, so the assembly bit saving is exactly (1-beta)*ac - backoff).

Everything else is byte-identical to PR #135: the pinned PR131 physical word with 26,597 roles and 2,108 compensated birth-cut aliases, PR132's orthogonal first-stage lockstep pairing, the conservative data-wire moment penalty, the stopped bit supplier, the finite bridge, all routers, reserves and charges.

Result, under all of PR #135's retained hypotheses (shared-scratch execution theorem and inherited all-size analytic/tape contracts remain assumptions):

kappa = 362108584810/10^15 = 3.62108584810e-4,

361,856 grid points (denominator 10^15) above PR #135's 3.62108222954e-4, the furthest published value at submission. This is a finite arithmetic candidate exactly in PR #135's status; no new physical execution is claimed and no global optimality is claimed. This is an instantiation refinement in the genre of #61, #100 and #107.

Validation

research/tightened-slack/certificate-tight.py re-runs PR #135's own certificate chain end to end from its pinned inputs (SHA-256 pins in SOURCE.json) at the refined constants: stopped bit supplier reproduction, finite bridge with reflection-audit charge checks, paired histogram telescoping identity, exact rational log/exp moment penalty enclosures, kappa bracket with next-10^-15-grid-point rejection, the +3%-over-PR132 target check, and all 47 strict constraints and 7 margins. Result is printed as PASS with kappa = 36210858481/100000000000000 (exact fraction 362108584810/10^15); the next grid point is rejected by the chain's own check. All construction credit belongs to the inherited lineage as recorded in NOTICE/SOURCES: PR131's physical word, PR130's three-stage cover, PR132's lockstep pairing, and PR #135's combination (DanieleCorso).

---

Note: this branch is one commit carrying PR #135's draft tree plus the tightened instantiation, so the certificate is runnable from this branch alone. .github/ is left at base-main's state, so PR #135's auxiliary CI workflow file is not carried here; no CI changes are proposed.

[DanieleCorso]

great work! i will keep working for around an hour, then continue in a few! let's do this!

[Swapnil-jain]

Heads-up: this tightens constants on #135, which relies on #132's first-stage lockstep pairing. That pairing step appears not to restore its targets. Details and an exact small counterexample are here: #132 (comment)

In short, in lockstep each core's frame steps also transform the other core's live data on the shared stream. The slack tightening itself may well carry over to the unpaired cover, but κ = 3.6210858481e-4 depends on the pairing.

[geckods]

Thanks — to be explicit about the scope of this PR: the only change is the assembly instantiation slack (beta 1e-6 -> 1e-15, backoff 1e-14 -> 1e-17); everything else is #135's machinery re-run from its pinned inputs. So the claim tracks exactly whatever base survives review of the lockstep schedule. If #132's pairing is retracted in favor of a consecutive or unpaired variant, the same tightening applies to that variant with the same machinery re-run from pinned sources (e.g. #134's unpaired shrunk-frame chain pins the same legacy slack constants, as do #137's padded covers, where the same refinement has been posted as #138). No aspect of this refinement depends on lockstep specifically; it was applied to #135's tree only as the furthest published instance at the time. If the schedule is retracted I'll re-instantiate on the surviving base and update this PR.

[geckods]

Closing: #135's inherited #132 lockstep schedule has been retracted by its author, so this tree's value is moot. The slack-tightening technique itself is schedule-agnostic and lives on in #138, where it is instantiated on #137's sequential (consecutive) dirty-reuse schedule — the schedule the #132 retraction explicitly endorses — giving the current furthest value kappa = 4.13596646966e-4.