[Matarener]

Requested by Mark

Change and mathematical scope

New research package research/joint-supplier-average-ceiling (negative result, audit of a changed demand; no κ change, no new supplier).

Before: research/kappa01-outer-repair §2 leaves open that a self-contained native word serving both the bit address-interchange endpoint and the complex butterfly-layer endpoint would remove the separate bit endpoint, with scoped limit κ < s/(1+s) for its joint saving s. The hope behind such a word is that the credits of the two sides add while the common neutral work (idle stages, local small jobs) is paid once.

After: a side-by-side (rank, role) ledger of the #4470 complex invoice and the #4814 BIT invoice shows that on the p16 controller every joint ledger that respects the rank-mass identity has saving between the two side roots, at most 0.003232 (+7.0% over the selected 0.00302015), below the BIT gate 0.003475458 (+15.1%) that an ordinary complex-side improvement reaches. The literal "identical (rank, role) paid once" rule removes 74,499 units of paid mass with unchanged targets (identity violated; its 0.18 is not a ceiling); idle ranks 8(j+1) and 7(j+1) never coincide; aligned twins have negative surplus; the only larger variants are the known small-job merge lever, reproduced inside one side alone (0.004109).

What it does: verify.py (standard library, 40-digit Decimal) authenticates the four pinned inputs, reproduces both raw roots to 1e-13, checks the surplus identities 752/753, partitions both invoices into roles, computes six joint models, checks the averaging property, binds the quoted outer statements to their source bytes and runs six rejecting controls. Status negative-result; selected κ and BIT admission unchanged.

Task and overlap

Base ff3cc58e370d0f678e529246f8c73e8094e18fcf. Card joint-query-controller, scope changed (reason in TASK.json): the card asks about the installed QQ16 caller; this package prices a different changed demand, the joint bit+complex supplier. Inputs: research/joint-helper-lattice/RESULT.json (#4470), research/bit-finite-ordinary-bootstrap/RESULT.json (#4814), research/kappa01-outer-repair/README.md, research/coordinated-frames-and-entrance-banks/arithmetic/balanced_shared.py.

Nearest overlap: kappa01-outer-repair (one side paying for the other through Walsh adapters; the opposite direction of this package), productive-lever-reprice (#4602, the lever table whose merge lever E/F reproduces), admission-constant-derivation (#4697, the surplus identity used here). Added value: a source-bound ceiling that closes the "one supplier for both" door on the current controller with a seconds-long replay.

Validation

python3 scripts/research_package.py --package research/joint-supplier-average-ceiling --check-only
python3.12 scripts/research_package.py --package research/joint-supplier-average-ceiling

Both pass locally on Python 3.12 (Windows): PASS_PACKAGE_METADATA_AND_PINS, PASS_REGISTERED_RESEARCH_PACKAGE ... outcome=negative-result. Controls: broken surplus, wrong recorded BIT surplus, foreign idle rank, swapped targets/paid, literal model as ceiling, tampered source pin (all rejected). Not run: the 47-inequality outer engine with a = b = s; the outer admission is cited from kappa01-outer-repair §2, not replayed, since the invoice ceiling decides the question. This is a finite check of the moment model on two frozen invoices, not a theorem about every controller.

Credit

#4470 (zxv lineage), #4814 (ai-nanachi, on PR4760), kappa01-outer-repair and the balanced engine (Zhihao Chen, RaD/hipotures, icekylinx, eumemic), productive-lever-reprice. Prepared by Mark (Matarener) with substantial Claude (Anthropic) assistance; Apache-2.0.

Open next questions

Whether a changed controller can give a two-endpoint word more credits per port window than either side has alone (the ceiling rests on S_joint ≤ S_c + S_b on the same windows). First step and blockers in TASK.json and the README.

Workflow feedback (optional)

None.

🤖 Generated with Claude Code

[jwr404]

Independent review (James Reed, with Claude Code). Head 3eb6c26b7439ea5827fa647cdd1c0d2dd3deddb9.

Verdict: the numbers reproduce, but the headline ceiling is stated more broadly than the package shows. The models that actually stay below 0.003232 need a no-merge premise, and the summary should name it.

Reproduced independently

I wrote my own 40-digit Decimal code, reading the invoices straight from joint-helper-lattice/RESULT.json and bit-finite-ordinary-bootstrap/RESULT.json (raw_invoice):

• surpluses 752 and 753, matching the recorded rank_surplus;
• roots: complex 0.003020165977, BIT 0.003475458064, model A (sum of the two equations) 0.003232027078;
• a 101-point sign scan of each side equation on [0, 0.05] shows one crossing each.

The registered replay passes locally (PASS_JOINT_SUPPLIER_AVERAGE_CEILING_NEGATIVE).

Main issue: the headline over-states the ceiling

The summary and README say: "any joint ledger that respects the rank-mass identity has a saving between the two side roots, at most 0.003232". The package's own table contradicts this. Models E (0.009325) and F (0.007541) are marked "mass identity: kept" and lie far above both roots.

That is unavoidable in this moment model. Merging paid jobs r1, r2 into r1 + r2 keeps mass, while strict subadditivity of r^(1−C) lowers the paid moment, so the root rises. As an independent illustration: merging the complex invoice's own rank-1 paid jobs pairwise (mass unchanged) moves its root from 0.003020 to 0.003422.

So the mass identity alone does not cap the joint saving. What the package shows is narrower:

• if each side's paid jobs keep their individual ranks (models A and D), the joint root is the mass-weighted average, at most 0.003232;
• every larger value needs merging paid jobs.

The README then argues that merging is excluded by #4416's whole-job premise and the centre and thin-shear floors. I think the headline should be conditional on exactly that premise, e.g. "under the whole-job (no cross-job merge) premise…". Whether that premise binds a joint native word, where one child could legitimately serve jobs from both endpoints, is precisely what's open.

Smaller points

1. Monotonicity is checked on a 50-point grid (decreasing()), which is not a proof. Betweenness only needs a single crossing of f_c + f_b. Two cheap rigorous routes:
   • bracket the sum's sign with exact intervals at the two side roots, and bound |G'| ≤ Σ n·r·(ln r)² to make the grid argument rigorous between points;
   • note that f(C)·r_max^C has a sign pattern with one change in the ranks (Descartes' rule for exponential sums), if that holds for these histograms.
2. "S_joint ≤ S_c + S_b on the same windows" is argued in prose, not derived. A one-paragraph statement of the controller surplus identity it relies on (admission-constant-derivation) would make the scope self-contained.

The model A, C and D arithmetic and the reading of B as an identity violation look right to me. This review does not cover the outer κ < s/(1+s) reduction, which the package cites rather than replays.

[jwr404]

Follow-up to my review (James Reed, with Claude Code). On point 1 (grid-only monotonicity): #5341's weighted-tail lemma settles it rigorously for this package.

If every tail B_k = Σ_{r≥k} r(T_r − P_r) is nonnegative for k ≥ 2, at least one is positive, and the maximum rank is below e^5, then f is strictly increasing in t on [4/5, 1] (summation by parts). I computed the tails exactly:

invoice	max rank	min B_k (k ≥ 2)	mass
complex #4470	145	32480	752
BIT #4814 raw_invoice	127	26160	753
model A (sum)	145	32480	1505

All tails are positive, so each equation has a unique root with C ∈ (0, 1/5], and model A's root lies strictly between the two side roots with no grid argument needed. You could cite #5341 there or add the ten-line tail check. My main point, that the headline ceiling needs the no-merge premise, is unchanged.