P104 cut enlargements (#6064) cannot fund separately paid coordinate delivery

research/dyadic-cut-delivery-budget/PREDECESSOR.json

@@ -0,0 +1,10 @@
+{
+  "source_pr": "https://github.com/CrocSwap/integer-mult-bounds/pull/6064",
+  "head": "5fd1fdedddf32307db31416958a1f03a8a67aa16",
+  "path": "research/dyadic-cut-enlargement/README.md",
+  "retained_path": "predecessor/PR6064-README.md",
+  "sha256": "0cb8510368768ba3428d41ed5133e03a29901d065f1b0da9000c032e610a0ad5",
+  "author": "https://github.com/zxv",
+  "license": "Apache-2.0",
+  "usage": "Unmodified pending predecessor proof and statement; retained bytes, no foreign Git history required."
+}

research/dyadic-cut-delivery-budget/PROOF.md

@@ -0,0 +1,128 @@
+# A one-cut delivery price screen for the PR6064 opportunity
+
+This is a scoped invoice obstruction, not a universal bound on helper changes.
+It uses the exact selected PR6030 bill and answers a particular application of
+[PR6064](https://github.com/CrocSwap/integer-mult-bounds/pull/6064).
+
+## Contract
+
+Keep the existing complete targets and paid jobs. At one fixed cut per LOCAL,
+add d eligible coordinates. Suppose the native realization satisfies PR6064's
+fixed-prefix/full-module hypotheses and makes at most 2d **additional binary
+helper splits** available per LOCAL. Each split replaces a rank-h helper by
+independent rank-a and rank-(h-a) targets, with 1 <= a < h <= 9. Existing paid
+jobs and all other target credits stay unchanged. Charge at least d new paid
+jobs of positive integer rank in the **entire** assembly, not d per LOCAL.
+
+These conditions are explicit. In particular, a bound on a module's capacity
+increase is not automatically a bound on every changed supplier's productive
+targets. The old realized channels must be retained, one additional unit must
+produce at most one binary split, and old unused or previously incompatible
+channels must not be relabelled as a new capacity increase. A different prefix,
+changed boundary, multi-cut reuse, additional carrier targets, or joint delivery
+of several coordinates by one paid job requires a new bill.
+
+PR6064 proves that adjoining d coordinates increases the full dyadic pairing
+capacity by at most 2d. Its proof and attaining matrix are retained verbatim in
+predecessor/PR6064-README.md with the exact source head/hash in PREDECESSOR.json.
+The implication above is the declared realization contract, not an admission
+of that scalar example as a native P104 supplier.
+
+## Whole-interval price
+
+Write k for the proposed saving, p=1-k, and M(k) for the old complete raw
+target moment minus the old complete paid moment. We examine the whole interval
+
+    781451/250000000 <= k <= 17/5000.
+
+The lower endpoint is selected kappa .003125804. The upper endpoint is the
+unchanged admitted BIT saving .0034. The exact source contains 18 LOCALs and
+no helper rank above 9. By concavity,
+
+    a^p + (h-a)^p - h^p <= h^p (2^k - 1)
+                              <= 9 (2^k - 1).
+
+Since log(2)<7/10 and exp(x)<=1/(1-x) for 0<=x<1,
+
+    total extra target credit <= 2 d * 18 * 9 * (7k/10)/(1-7k/10)
+                              <= d * 12852/16627
+                               < .773 d.
+
+Each positive-rank paid job costs at least 1 at p>0. Therefore the changed
+moment is at most M(k) - d*(3775/16627). This grants free scalar basis changes,
+normalization, routing, restoration and every other unchanged obligation. Any
+additional fees can only hurt this comparison.
+
+It remains to check the small slack between the selected rounded claim and
+the raw crossing. The verifier independently reconstructs the complete signed
+profile from PR6030's source-bound RESULT.json. Exact rational logarithm and
+Taylor bounds give
+
+    M(.003125804) < 13/200,
+    M'(k) < -234000                 for every 0 <= k <= .0034.
+
+Consequently, for every integer d>=1 and every k in the stated interval,
+
+    changed moment < 13/200 - d*(3775/16627)
+                   <= -538849/3325400
+                    < -.162.
+
+Thus this route cannot even retain the selected saving. It cannot increase
+kappa under the unchanged BIT and declared one-cut delivery contract. This is
+a necessary raw-budget failure; compiler, tail and outer checks cannot rescue
+a negative raw moment.
+
+## Rational certificates without a sampling grid
+
+For q in [1,2], z=(q-1)/(q+1) belongs to [0,1/3]. The first 32 terms of
+2 sum z^(2j+1)/(2j+1) give a lower bound for log(q); the remaining tail is at
+most 2 z^65/(65(1-z^2)). Range reduction gives bounds L_r<=log(r)<=U_r.
+
+For x>=0, P3(x)<=exp(-x)<=P2(x), where
+
+    P2(x)=1-x+x^2/2,   P3(x)=P2(x)-x^3/6.
+
+Both polynomials decrease on the certified x interval [0,1/50]. At the lower
+kappa endpoint, sum T_r r P2(k L_r) - sum P_r r P3(k U_r) bounds M from above.
+For the derivative, r^(1-k)<=r and r^(1-k)>=r(1-k log r) give the uniform upper
+bound
+
+    sum P_r r U_r - sum T_r r L_r (1-(17/5000) U_r).
+
+All arithmetic is rational. No finite grid is substituted for an interval
+claim, addressing the failure mode in PR6049.
+
+## Existing eligible coordinates on the selected word
+
+Separately, the unmodified full-subspace census of
+[Matarener](https://github.com/Matarener)'s
+[PR5994](https://github.com/CrocSwap/integer-mult-bounds/pull/5994) is applied
+to the selected PR6030 word. It considers **every role already at the cut
+chart**, not only helpers in the boundary group. At 8,734 evaluations across
+69 groups and 562 helpers, it finds no pure helper split: six two-sided group
+classes have zero cut pairing. The more permissive boundary-support screen
+also finds none (1,590 zero cut pairings and 11 zero boundary pairings).
+
+An enlargement by coordinates already in these complete chart banks is a
+restriction of a tested domain and therefore cannot bypass that exclusion.
+This last statement concerns PR5599's pure-prefix/pure-suffix split contract;
+it does not exclude PR5718 corrections or changed scalar programs. It is not
+used to silently identify a rational census with PR6064's dyadic capacity.
+
+The census implementation and its criterion belong to PR5994. The contribution
+here is the current-word receipt and its applicability to the proposed free
+eligibility route, alongside the new whole-interval delivery budget.
+
+## Limits
+
+This does not price a productive carrier, multi-coordinate paid transport,
+different recursive boundary, multi-cut lifetime, changed paid trajectory,
+new BIT cap or other helper architecture. It is not a complete multiplier,
+native admission, global P104 ceiling, independent human review or formal proof
+kernel check. The five selected framework assumptions remain.
+
+Prepared by [zxv](https://github.com/zxv), with substantial OpenAI Codex assistance.
+Credit [Ali Romman](https://github.com/aliromman)'s cut and P104 lineage,
+[DreamingOfClouds](https://github.com/DreamingOfClouds)'s PR6030 word/bill,
+[Matarener](https://github.com/Matarener)'s full-subspace census, and the retained
+source authors. Apache-2.0.

research/dyadic-cut-delivery-budget/README.md

@@ -0,0 +1,30 @@
+# P104 single-cut enlargements cannot fund one paid delivery per added coordinate
+
+Applying [PR6064](https://github.com/CrocSwap/integer-mult-bounds/pull/6064)'s two-channels-per-added-coordinate opportunity to the selected P104 invoice requires a cheaper delivery contract. Under the explicit single-cut realization contract in [PROOF.md](PROOF.md), all additional binary helper splits earn less than **.773 per added coordinate**, even granting 18 LOCAL invocations and charging only one new rank-one call in the entire assembly. That call costs at least one. The route cannot retain selected kappa .003125804, throughout the unchanged BIT range up to .0034. No new kappa is claimed.
+
+The theorem assumes at most two additional binary helper splits per added coordinate per LOCAL, ranks at most nine, unchanged other targets/paid jobs, and at least one new paid job per added coordinate globally. PR6064's capacity theorem alone does not establish that every supplier realization satisfies this target-count contract. Productive carriers, shared multi-coordinate transport, multi-cut reuse and changed prefixes/boundaries remain outside this exclusion.
+
+The free-delivery alternative was also checked on the actual selected PR6030 word. The unmodified full-subspace census from [Matarener](https://github.com/Matarener)'s [PR5994](https://github.com/CrocSwap/integer-mult-bounds/pull/5994) already grants every role present at a chart. Both exact group and relaxed boundary supports have zero pure helper splits at all 8,734 evaluated cuts. An added eligible role already in one of those full banks cannot help within that pure split contract. This is an application of the predecessor's algorithm, with its credit retained.
+
+## Significance for researchers
+
+The sharp algebraic two-for-one gain in PR6064 is not enough to fund individually paid coordinate delivery in the current assembly. A useful successor should change the delivery/credit contract before growing the scalar fixture. Exact rational bounds cover the entire kappa interval; they do not use a grid that could miss the crossing behavior identified in [PR6049](https://github.com/CrocSwap/integer-mult-bounds/pull/6049).
+
+## Reproduce
+
+```sh
+python3.12 -B scripts/research_package.py --package research/dyadic-cut-delivery-budget
+python3.12 -B scripts/check_research_commit.py --package research/dyadic-cut-delivery-budget
+```
+
+Normal and optimized commands use the standard library. They authenticate the selected result/word and frozen census, prove rational margin/derivative bounds, recompute both complete cut screens, and check positive, orthogonality and changed-contract controls. RESULT.json is compared with the full recomputation. The current-word census reuses the original engine and is not an independent engine audit or full selected/native/outer replay.
+
+## Open next questions
+
+Can one paid transport deliver at least two newly eligible coordinates, or can an existing paid trajectory provide a coordinate at no extra recursive cost? Start with one exact native chart/time/lifetime and the complete signed bill. The one-call-per-coordinate hypothesis would change; this certificate does not rule out that case.
+
+Can a newly productive carrier or a changed multi-cut continuation earn enough additional credit? First give the independent target, unchanged dirty endpoints and all native/restoration fees. Those credits cannot be inferred from capacity.
+
+## Credit and limitations
+
+Prepared by [zxv](https://github.com/zxv), with substantial OpenAI Codex assistance. Credit [Ali Romman](https://github.com/aliromman)'s dyadic cut/P104 work, [Matarener](https://github.com/Matarener)'s source census, [DreamingOfClouds](https://github.com/DreamingOfClouds)'s selected PR6030 word and invoice, [Nick Petalas](https://github.com/petalas)'s related carrier-price [PR6033](https://github.com/CrocSwap/integer-mult-bounds/pull/6033), and their retained predecessors. The pending PR6064 statement is preserved byte-for-byte with its source head and SHA256; no unavailable foreign commit is required. Apache-2.0. No new native construction, supplier admission, global P104 barrier, selected change, independent human review, proof assistant or full multiplier is claimed. The five framework assumptions remain.

research/dyadic-cut-delivery-budget/RESULT.json

@@ -0,0 +1,60 @@
+{
+  "admitted_bit": "17/5000",
+  "charged_margin_upper_at_d_one": "-538849/3325400",
+  "controls": {
+    "binary_splits": 36,
+    "free_delivery_outside_exclusion": true,
+    "rejected_contracts": [
+      "extra_paid_job",
+      "new_rank_ten_target",
+      "changed_local_multiplicity",
+      "changed_bit_cap"
+    ],
+    "shared_delivery_outside_exclusion": true,
+    "sharp_two_channel_border": true
+  },
+  "credit_upper_per_added_coordinate": "12852/16627",
+  "current_kappa": "781451/250000000",
+  "derivative_upper": "-234000",
+  "interval": [
+    "781451/250000000",
+    "17/5000"
+  ],
+  "local_calls": 18,
+  "max_helper_rank": 9,
+  "old_margin_upper": "13/200",
+  "selected_full_chart_census": {
+    "boundary": {
+      "classes": 1601,
+      "classes_sha256": "f3462dcbe8ca4a7ac8a07d55faa5c05073a35c8cc9eb653fcba741fda2180b78",
+      "counts": {
+        "evaluations": 8734,
+        "groups": 69,
+        "helpers": 562,
+        "kind_F1zero": 1590,
+        "kind_F2zero": 11,
+        "no_pure_prefix": 5382,
+        "no_pure_suffix": 1751,
+        "witnesses": 0
+      }
+    },
+    "group": {
+      "classes": 6,
+      "classes_sha256": "22b3f7d4140204e627174e7111fa8752108a012e6f8dd9603f0f4c991fb0815a",
+      "counts": {
+        "evaluations": 8734,
+        "groups": 69,
+        "helpers": 562,
+        "kind_F1zero": 6,
+        "no_pure_prefix": 7280,
+        "no_pure_suffix": 1448,
+        "witnesses": 0
+      }
+    }
+  },
+  "source_counts": [
+    13444,
+    66834
+  ],
+  "status": "PASS_DYADIC_CUT_DELIVERY_BUDGET"
+}

research/dyadic-cut-delivery-budget/SOURCES.json

@@ -0,0 +1,42 @@
+{
+  "schema_version": 1,
+  "base_commit": "721c03822c421b7f7fcbb2598993b947c4d88419",
+  "files": [
+    {
+      "path": "certificates/selected-result.json",
+      "usage": "provenance",
+      "git_blob": "d59b5035e7b4cbaa9d688a1d32dd0d6eb79c466a",
+      "sha256": "9b8d0eea95b3bf0dfcb7938a732a6439b87a2685dec2a5ab9e525b3b34debbfa"
+    },
+    {
+      "path": "docs/research/agent-task-catalog.json",
+      "usage": "provenance",
+      "git_blob": "3404fbdd5e7529a0674eef26114b5071e4586cec",
+      "sha256": "ead6cdc9d0af6d58e8a49744d8ec8c7c15e13d2ba93c276c434bcf9b51b93a81"
+    },
+    {
+      "path": "research/dyadic-helper-channel-capacity/PROOF.md",
+      "usage": "input",
+      "git_blob": "c97a6edce3070414c81f0ef6e6c099ebb17f3a90",
+      "sha256": "b258a217f2cd0fc48461285fe8ae24de26b0c5963668d9d8f0955fc6e759e929"
+    },
+    {
+      "path": "research/p104-helper-split-exhaustion/splitcensus.py",
+      "usage": "input",
+      "git_blob": "74727424f75adf75bd9061a7473e6cce2f520097",
+      "sha256": "c3bc8cfc14ab8fdbe600f06401119c7a7b6c5fe8dc460b6b1933cda7ef4bf1dd"
+    },
+    {
+      "path": "research/p104-helper470-twin-rung-removal/RESULT.json",
+      "usage": "input",
+      "git_blob": "e4a03118d585fb80c9ac932281b528ac394ccc5f",
+      "sha256": "84fcbe2a0b64307b5703c363408042bdd91555b0419509aa50daa43b3b1924ad"
+    },
+    {
+      "path": "research/p104-helper470-twin-rung-removal/WORD.json.gz",
+      "usage": "input",
+      "git_blob": "22f9ab02d1b73ea0aa4b07ce445a14cc2602c760",
+      "sha256": "7834725d9e34ee846a9ccc615221ea81e0201613938afa185d2eda0c9a6c232f"
+    }
+  ]
+}