Prove exponential invoice frontiers at fixed count and rank mass

research/concave-invoice-antichains/README.md

@@ -0,0 +1,162 @@
+# Exponentially large concave-invoice frontiers at fixed count and mass
+
+Safe increasing-concave pruning can retain exponentially many distinct integer
+invoices even when every candidate has the same paid call count, total rank and
+target. An explicit family embeds reverse subset inclusion into invoice order.
+Its middle layer has `binom(m, floor(m/2)) >= 2^m/(m+1)` mutually incomparable
+candidates, each with only `2m` paid calls of rank at most `2m+1`.
+
+For `m=10`, all 252 middle-layer invoices survive such pruning. For `m=11`,
+all 462 survive. The latter already exceeds PR #5778's 256-candidate input cap,
+with only 22 paid calls, paid rank mass 264, and a paid rank bound of 23.
+
+This is a scoped mathematical proof with exact finite corroboration. It is a
+new worst-case family for the declared invoice order, not a physical supplier,
+a power-curve crossing, a search failure, or a new multiplication exponent.
+
+## Contract and predecessors
+
+[Ali Romman's PR #5778](https://github.com/CrocSwap/integer-mult-bounds/pull/5778),
+head `86342a33c04c72a52ddecf70b8f4b1dcb8304cef`, retains every incomparable
+candidate in a declared pool. Its reducer is cited, not replayed or audited here.
+The same order and signed paid-minus-target convention appear in the pinned
+[invoice guide](../../docs/research/recursive-invoice-preflight.md) and comparator
+by zxv. Their classical concave-order framework is a predecessor, not new work
+claimed by this package. [SOURCES.json](SOURCES.json) pins that context on main;
+the standalone verifier imports no predecessor code and needs no pending commit.
+
+Write `H_r` for one paid rank-r call. For integer `m>=1` and subset
+`S` of `{1,...,m}`, define
+
+```text
+P_S = sum_{i not in S} 2 H_(2i)
+    + sum_{i in S} (H_(2i-1) + H_(2i+1)).
+M   = 2m(m+1).
+I_S = P_S minus the common productive target H_M.
+```
+
+Each block contributes two paid calls and rank mass `4i`, whether spread or
+unspread. Consequently every invoice has exactly `2m` paid calls, mass `M`,
+positive paid ranks at most `2m+1 < M`, and the same one-target debit. No fee
+or target changes between candidates. These are synthetic accounting objects;
+the common boundary text does not assert circuit compatibility or realizability.
+
+Let `I_S <=_c I_T` mean that `I_S` costs no more than `I_T` for every
+nondecreasing concave tariff `f` on nonnegative reals with `f(0)=0`.
+The theorem is the exact equivalence
+
+```text
+I_S <=_c I_T    if and only if    S contains T.
+```
+
+## Proof
+
+For a hinge tariff `h_k(r)=min(r,k)`, the change caused by spreading block i is
+
+```text
+delta_i(k) = min(2i-1,k) + min(2i+1,k) - 2 min(2i,k)
+           = -max(0, 1 - abs(k-2i)).
+```
+
+To check the identity, split `k` at `2i-1`, `2i`, and `2i+1`. The four linear
+pieces have values zero, `2i-1-k`, `k-(2i+1)`, and zero, respectively. The
+open intervals on which these tents are nonzero are disjoint for distinct i.
+In particular, `delta_i(2j)` is -1 when `i=j` and zero otherwise.
+
+If S contains T, pass from P_T to P_S by spreading exactly the blocks in
+`S minus T`. Concavity gives
+`f(2i-1)+f(2i+1) <= 2f(2i)` for each such block. Summing and subtracting
+the unchanged target proves `I_S <=_c I_T`.
+
+Conversely, if S does not contain T, choose `j in T minus S`. The cost
+difference `I_S(h_(2j))-I_T(h_(2j))` is exactly +1. Every other block and the
+common target cancel. This tariff disproves `I_S <=_c I_T`. If strictly
+increasing tariffs are required, use `h_(2j)(r)+epsilon*r` with any
+`epsilon>0`. Equal rank mass makes its extra linear contribution cancel.
+This proves both directions for every m, independently of the finite replay.
+
+Distinct sets of cardinality `floor(m/2)` contain neither one another, so their
+invoices are pairwise incomparable. There are exactly `binom(m,floor(m/2))`
+such sets. To obtain the exponential lower bound without an asymptotic estimate,
+the ratio of successive binomial coefficients is `(m-j)/(j+1)`, so a middle
+coefficient is largest. The sum of the `m+1` coefficients is `2^m`; hence
+that largest coefficient is at least `2^m/(m+1)`.
+
+For example, at `m=2`, the two single-spread paid profiles are
+`H1+H3+2H4` and `2H2+H3+H5`. Both have four calls, mass 12 and target H12.
+Their signed cost differences are -1 at cap 2 and +1 at cap 4.
+
+## What this changes
+
+Equal mass, equal call count and a modest rank range do not guarantee a smaller
+concave-order frontier. Within a middle-layer input pool, every safe replacement
+by another pool member fails an explicit hinge test. A reducer promising to
+retain every incomparable member must retain the whole pool.
+
+This does not prevent useful typical-case pruning or a faster implementation.
+It does not show that the whole cube is a frontier: its fully spread member
+dominates every other cube member and would remove them if supplied. No claim
+is made about representatives outside the supplied pool, approximate pruning,
+or the narrower family of power tariffs. In particular, incomparability under
+all concave tariffs does not establish a power-curve crossing.
+
+## Reproduce and evidence
+
+From the repository root, with CPython 3.12 and the standard library:
+
+```sh
+~/git/integer-mult-bounds/.venv/bin/python3.12 -W error -B research/concave-invoice-antichains/verify.py
+~/git/integer-mult-bounds/.venv/bin/python3.12 -W error -O -B research/concave-invoice-antichains/verify.py
+~/git/integer-mult-bounds/.venv/bin/python3.12 -B scripts/research_package.py --package research/concave-invoice-antichains
+~/git/integer-mult-bounds/.venv/bin/python3.12 -B scripts/check_research_commit.py --package research/concave-invoice-antichains --check-source-history
+```
+
+The read-only verifier constructs every cube member for `1<=m<=7`, checks
+count, mass, the target debit, all half-integral hinge pieces and every ordered
+pair against the subset relation. It separately enumerates all unordered pairs
+in the m=10 and m=11 middle layers, evaluates both counter-tariffs directly on
+the complete signed histograms, and requires the exact gap +1 in each direction.
+It streams a digest of those certificates and prints a generated JSON receipt
+bound to SHA256 hashes of all five package files. No receipt is handwritten.
+
+Negative controls reject invalid dimensions and subsets, false or nonpositive
+counter-tariffs, changed mass or targets, a changed consumer, omitted members,
+duplicate members, and a wrong-cardinality layer member. Checks use explicit
+exceptions and remain active under `-O`. The universal statement is the written
+proof; the finite code is corroboration, not formal proof-kernel verification.
+
+The verifier has no recursive calls. Its constructor enforces `m<=11`, each
+cube has at most 128 members, and the largest layer has 462 members. It streams
+pair certificates instead of retaining them. Python's managed allocation and
+the fixed callback in the rejection-control helper are power-of-ten deviations:
+live storage is bounded by the 462 finite invoices, at most 31 hinge values per
+cube member, and one pair certificate at a time. The callback targets are the
+four named local check/constructor functions in `check_controls`; they own no
+external resources. A larger replay must revise these bounds and checks first.
+Warning-strict normal and optimized execution are registered in VERIFY.json.
+
+## Open next questions
+
+Can a source-constrained family of legal constructions force a large surviving
+frontier? This matters because these synthetic invoices demonstrate an accounting
+limitation, not a physical search obstruction. Start with one source's permitted
+rank exchanges and prove independent realizability of two disjoint blocks, with
+the full target, restoration, native and compiler bill. No such construction is
+provided here.
+
+Can the power-only order safely remove more members of these specific layers?
+Start by certifying the comparison for the two displayed m=2 invoices over a
+named exponent interval, then seek a theorem for the family. Hinge witnesses
+alone cannot answer that question. No power comparison was run as this result.
+
+## Credit
+
+This contribution was produced by Nick Petalas. Independent human and formal
+proof-kernel review are unclaimed. Credit Ali Romman for PR #5778's frontier
+contract, zxv for complete signed invoice accounting, mightyOil and the retained
+predecessors for the moment-order context, and Dugongue for the existing
+higher-order-exchange examples that distinguish concave order from power order.
+Mean-preserving spreads, hinge tariffs and the elementary binomial identities
+are classical. The contribution is the explicit fixed-count, fixed-mass integer
+family, its exact order embedding and the resulting pruning obstruction.
+New work is Apache-2.0. No predecessor file or credit line is changed.

research/concave-invoice-antichains/SOURCES.json

@@ -0,0 +1,36 @@
+{
+  "schema_version": 1,
+  "base_commit": "de5ec2e7a6074068452f45b1a191b5c72832df4a",
+  "files": [
+    {
+      "path": "certificates/selected-result.json",
+      "usage": "provenance",
+      "git_blob": "581f8d87008354eb5b869f7ed9de1317ad837ce8",
+      "sha256": "2a0220e866417774606e0f991e41b9c1d26b1f43b97857238cf478dbc7d330b5"
+    },
+    {
+      "path": "docs/research/agent-task-catalog.json",
+      "usage": "provenance",
+      "git_blob": "3404fbdd5e7529a0674eef26114b5071e4586cec",
+      "sha256": "ead6cdc9d0af6d58e8a49744d8ec8c7c15e13d2ba93c276c434bcf9b51b93a81"
+    },
+    {
+      "path": "docs/research/recursive-invoice-preflight.md",
+      "usage": "provenance",
+      "git_blob": "b84d50f53d6d9ab008c7021515a9330fac89fe19",
+      "sha256": "faf546cf3693e063c00b049a463e4173fa89414b799184c71d0604ff5595ae2e"
+    },
+    {
+      "path": "scripts/compare_recursive_invoices.py",
+      "usage": "provenance",
+      "git_blob": "fda2a852e9937e42fe40df0707694465ca7c1b48",
+      "sha256": "3930c22c11da7bc6042cfeb6e459ecb06e4478430037bee3469d034353855fc6"
+    },
+    {
+      "path": "research/higher-order-rank-exchanges/README.md",
+      "usage": "provenance",
+      "git_blob": "4db8cdccf9d1b2071e1f32a1ecf8b5c7de646b39",
+      "sha256": "8c4185b42f37cfbce98f5f2ce6fb3d51559fbec48fdc77eeaff412a84ef607dc"
+    }
+  ]
+}

research/concave-invoice-antichains/TASK.json

@@ -0,0 +1,95 @@
+{
+  "schema_version": 1,
+  "task_id": "coverage-law-change",
+  "priority_revision": 8,
+  "base_commit": "de5ec2e7a6074068452f45b1a191b5c72832df4a",
+  "original_card": {
+    "id": "coverage-law-change",
+    "question": "Can a completed call earn more independent productive target credit without an offsetting paid bill?",
+    "starting_points": [
+      "docs/research/current-priorities.md",
+      "docs/research/research-family-status.md",
+      "certificates/selected-result.json",
+      "docs/research/pr-intake-evidence/pr5599-completion/PROOF-REVIEW.md"
+    ],
+    "methods": [
+      "Construct and independently check one source-bound instance of the stated first experiment.",
+      "Seek an exact counterexample or target-specific complete-budget obstruction to that same proposed change."
+    ],
+    "acceptance_gate": "A source-bound arbitrary-input identity and legal producer/consumer boundary with the complete paid and productive target invoice, including restoration, ownership, native alignment and extra charges. Price under the actual current model; historical ceiling.py assumptions must be established before use. A favorable optimistic relaxation keeps a route open but is not a completed supplier. A scoped local result remains useful; expansion requires the family-level budget gate.",
+    "first_step": {
+      "command": [
+        "python3",
+        "-B",
+        "scripts/research_selected_baseline.py"
+      ],
+      "expected": "PASS_RESEARCH_BASELINE_BINDINGS_ONLY",
+      "inspect": "Read revision 8, the selected review and live exact-source handoffs. Then follow this card's bounded first_experiment.",
+      "scope": "Source-bound orientation only, not a supplier replay or theorem proof."
+    },
+    "first_experiment": "Use #5599 as a completed positive control, then choose one uncovered cut/module beyond an applicable frozen exclusion. Derive independence, saturation and chronological availability rather than counting rational rank alone. Price target credits and all new jobs together, then check compiler and actual caller compatibility. Stop on a nonphysical credit or an unfavorable complete relaxation.",
+    "bottleneck_link": "Judge the actual current supplier contract and complete signed target/paid bill; frozen-profile ceilings require an applicability proof.",
+    "allowed_variations": [
+      "One exact source head, helper/cut region or quantified proposition and changed hypothesis; check live handoffs first. Different seeds are not different scopes."
+    ],
+    "scope_change_triggers": [
+      "Changing source head, helper/cut domain, operation alphabet or caller boundary without recording the new scope.",
+      "Treating an archived proposal or local numerical pass as complete supplier admission."
+    ],
+    "overlap_terms": [
+      "target credit",
+      "helper split",
+      "coverage law"
+    ],
+    "existing_checks": [
+      {
+        "scope": "Selected PR5599: complete helper-subspace construction and independent caller replay; five framework assumptions remain.",
+        "evidence": "docs/research/pr-intake-evidence/pr5599-completion/PROOF-REVIEW.md",
+        "remaining": "The next experiment must identify uncovered source-specific work. Successor archive intake does not transfer this admission.",
+        "status": "reviewed",
+        "source_commit": "09dd0965711ca7eeb169057a420abab1c9052137",
+        "selected_record_sha256": "2a0220e866417774606e0f991e41b9c1d26b1f43b97857238cf478dbc7d330b5"
+      }
+    ]
+  },
+  "scope_status": "changed",
+  "actual_scope": "Prove an explicit exponential antichain of synthetic complete signed invoices with fixed call count, rank mass and target, under increasing-concave order.",
+  "scope_change_reason": "The card asks for a legal productive-target gain. This is an accounting side result prompted by PR5778: characterize the worst-case size of its retained incomparable pool. No physical target gain is claimed.",
+  "bottleneck_link": "A scoped limitation of a screening step for complete recursive bills. Count and mass conservation alone cannot guarantee that concave-order pruning reduces a candidate pool.",
+  "budget_minutes": 60,
+  "stop_rule": "Stop on the first proved explicit antichain and package its proof and finite corroboration; do not extend to physical realizations or power-only comparisons.",
+  "outcome": "completed",
+  "evidence": "README.md proves I_S <=_c I_T iff S contains T for every m>=1. verify.py enumerates complete small cubes and every pair in the 252- and 462-member middle layers.",
+  "author": "Nick Petalas",
+  "ai_assistance": "Independent human and formal proof-kernel review are unclaimed.",
+  "open_questions": [
+    {
+      "question": "Can legal source-level constructions force a large incomparable frontier?",
+      "why_it_matters": "The theorem is about synthetic accounting objects, so physical search relevance requires realizability.",
+      "first_step": "Prove two independent adjacent-rank spreads in one exact source with complete fees and target/restoration costs.",
+      "blocked_by": "No physical implementation of this family is supplied."
+    },
+    {
+      "question": "Can certified power-only comparison prune these specific middle layers further?",
+      "why_it_matters": "Hinge incomparability is weaker than a power crossing.",
+      "first_step": "Certify the two displayed m=2 invoices on a declared exponent interval.",
+      "blocked_by": "No all-exponent comparison is supplied."
+    }
+  ],
+  "predecessors": [
+    {
+      "pr": 5778,
+      "author": "Ali Romman",
+      "head": "86342a33c04c72a52ddecf70b8f4b1dcb8304cef",
+      "use": "Cited frontier contract only; no pending code imported or replayed."
+    }
+  ],
+  "claim_url": "https://github.com/CrocSwap/integer-mult-bounds/discussions/1166#discussioncomment-19216145",
+  "local_environment": {
+    "python": "3.12.15",
+    "implementation": "CPython",
+    "platform": "macOS-27.0.1-arm64-arm-64bit",
+    "interpreter": "/Users/nick/git/integer-mult-bounds/.venv/bin/python3.12",
+    "dependencies": "standard library only"
+  }
+}

research/concave-invoice-antichains/VERIFY.json

@@ -0,0 +1,32 @@
+{
+  "schema_version": 1,
+  "status": "ready",
+  "python": "3.12",
+  "requirements": [],
+  "inputs": [],
+  "commands": [
+    {
+      "argv": [
+        "{python}",
+        "-W",
+        "error",
+        "-B",
+        "{package}/verify.py"
+      ],
+      "timeout_seconds": 120,
+      "checks": "Exact cube order, disjoint hinge identities, conserved invoice data, every middle-layer pair with two counter-tariffs, and 17 rejecting controls."
+    },
+    {
+      "argv": [
+        "{python}",
+        "-W",
+        "error",
+        "-O",
+        "-B",
+        "{package}/verify.py"
+      ],
+      "timeout_seconds": 120,
+      "checks": "Exact cube order, disjoint hinge identities, conserved invoice data, every middle-layer pair with two counter-tariffs, and 17 rejecting controls."
+    }
+  ]
+}