Price one (N-P) tensor M consumer at 199680 unit additions.

research/p104-omitted-side-consumer/README.md

@@ -0,0 +1,119 @@
+# One straight-line consumer of `(N-P) ⊗ M`
+
+**Partial scalar bill. No new κ.** Selected κ stays `0.001672660197076918`.
+
+Discussion comment 19056819 asked for a price of one repeated consumer of
+`(N-P) ⊗ M` before the Gram addition saving is treated as paid. This package
+gives that price for one 104×104 bank, in the unit-addition model of PR #3996.
+It is not a minimum, a native rank bill, or a supplier.
+
+## Scope
+
+The card `p104-side-correction` asks for a chronological endpoint correction.
+Scope is **changed**. The object here is the omitted identity side named in
+PR #3996's proof, not a flag program and not a replay of its 763,392 events.
+
+On the canonical fixture
+`research/p104-native-channel/inputs/P104-FIXTURE.json`
+(SHA256 `516c06f6ec3cb84be588c546108de897650288576dd5fbf5fe44b9c5546ad8a4`),
+the ordered ports give an 8×96 matrix `B2` whose ASCII digest is
+`88e9a726e8c8aec055bfd7cd024883b5c8ecbda0cd6471e591a08c43a108a535`.
+Every entry is in `{0, ±1}`, there are 384 nonzeros, each row has weight 48,
+each column has weight 4, and `B2 B2^t = 48 I`. Write `B = B2/2`,
+`U = [I, B; 0, I]`, `A = U^t P U`, `M = U U^t`, and
+`N - P = U^{-t}(I - A)U^{-1}`. The checker re-derives `A^2 = 13A`.
+
+The index convention of PR #3996 sends `(N-P) ⊗ M` to the bank map
+`(N-P) X M`, because `M` is symmetric. One straight-line program computes it
+by the shears:
+
+- right-multiply by `M = U U^t` with two `B2` matvecs per row (768 additions);
+- left-multiply by `N-P` with three `B2` matvecs per column (1152 additions).
+
+The closed form used for the second step is
+
+```text
+(N-P)(v1, v2) = (-B v2, v2 - B^t v1 + B^t B v2).
+```
+
+`B v2` is stored once and reused. Each matvec applies every nonzero of `B2`
+once, as a `±1` multiple of one coordinate. The program is straight-line:
+every bank pays the same count,
+
+```text
+104 * (2 + 3) * 384 = 199680
+```
+
+unit additions. Dyadic divisions by 2 and 4 restore the scale. They are not
+included in this count, and the half/double column of PR #3996 is not
+re-derived. The same program matches the integer operators `4(N-P)` and `4M`
+on the all-ones bank, a single-spike bank, and one dense modular bank.
+Dropping `B^t B v2` breaks that identity. The zero bank is the zero bank and
+still executes 199680 additions.
+
+## Comparison with the published Gram gap
+
+PR #3996's unit-addition invoices are entry plus exit `319488`, one coded
+Gram pair `26240`, and one specified reference pair `241280`. For `k`
+uncorrected pairs the gap is
+
+```text
+241280 k - 319488 - 26240 k = 215040 k - 319488.
+```
+
+That is `-104448` at one pair and **`110592` at two pairs**. Paying this
+consumer once against the two-pair saving leaves
+
+```text
+110592 - 199680 = -89088.
+```
+
+At three pairs the same one-time payment leaves `+125952`. The other omitted
+side `M ⊗ (N-P)` has the same straight-line count by swapping axes. Charging
+both, once each, costs `399360` additions. One coded pair plus both sides is
+`425600` additions, which is already above one reference pair (`241280`),
+before the entry/exit cost.
+
+This does **not** prove that every program for `(N-P) ⊗ M` costs at least
+`199680`, and it does not price native children, owners, or frames. A cheaper
+program remains the first open question. Until one exists, the two-pair Gram
+gap is not a paid saving.
+
+## Reproduce
+
+Python 3.12, standard library, from the repository root:
+
+```sh
+python3.12 -B research/p104-omitted-side-consumer/verify.py
+python3.12 -B research/p104-omitted-side-consumer/test_verify.py
+python3.12 -B scripts/research_package.py --package research/p104-omitted-side-consumer
+```
+
+Expected marker:
+
+```text
+PASS_P104_OMITTED_SIDE_CONSUMER
+```
+
+with `adds_one_side` 199680, `k2_net_after_one_side` -89088, and
+`new_kappa` false.
+
+## Open next questions
+
+1. Is there a straight-line program for one bank of `(N-P) ⊗ M` with fewer
+   than 110592 unit additions in this `B2` model? The number above is one
+   program, not a lower bound.
+2. Can the two omitted sides share shears? Independent charging may
+   double-count, which matters for the comparison with one 241280-addition
+   reference pair.
+
+## Credit
+
+The omitted-side formulas, the index, and the 110592-addition gap are ToikY's
+PR #3996 audit of Chris R / Clear1nsight's PR #3979. The fixture and root
+normalization are the retained P104 native channel (Rohan Arun, Chafik
+Boukhalfa, Adam Gall, and the native/E8 lineage named there). The request to
+price the consumer is discussion comment 19056819.
+
+Prepared by unpaidmoon with substantial Cursor Grok assistance. Apache-2.0.
+No independent human review is claimed.

research/p104-omitted-side-consumer/SOURCES.json

@@ -0,0 +1,24 @@
+{
+  "schema_version": 1,
+  "base_commit": "bb4bccbf42844d2801487450727c2f63e10d1d0f",
+  "files": [
+    {
+      "path": "certificates/selected-result.json",
+      "usage": "provenance",
+      "git_blob": "b1fea0c94436b236cc2b7d41a7be032811b94c81",
+      "sha256": "bb2eaa58647b353f88d0aec2eafb9d30df1be53589231b23e12ceef3e4bad129"
+    },
+    {
+      "path": "docs/research/agent-task-catalog.json",
+      "usage": "provenance",
+      "git_blob": "67f085acd86acd7d4e03922d9cf4b26bca66fed5",
+      "sha256": "47b42433f5a85809a3aadd29c2c339da2c6ed728e4f7762df6b88bccb7874cf0"
+    },
+    {
+      "path": "research/p104-native-channel/inputs/P104-FIXTURE.json",
+      "usage": "input",
+      "git_blob": "2e16f99b295bb386fd13bd8fbd57b42ef54143a9",
+      "sha256": "516c06f6ec3cb84be588c546108de897650288576dd5fbf5fe44b9c5546ad8a4"
+    }
+  ]
+}

research/p104-omitted-side-consumer/TASK.json

@@ -0,0 +1,94 @@
+{
+  "schema_version": 1,
+  "task_id": "p104-side-correction",
+  "priority_revision": 6,
+  "base_commit": "bb4bccbf42844d2801487450727c2f63e10d1d0f",
+  "original_card": {
+    "id": "p104-side-correction",
+    "question": "Can the proposed P104 joint endpoint flags be realized by a chronological correction program with coefficients, dirty restoration and an affordable complete bill?",
+    "starting_points": [
+      "docs/research/research-family-status.md",
+      "research/p104-native-channel/README.md",
+      "research/p104-native-channel/PROOF.md",
+      "docs/research/community-efficient1000-review.md",
+      "research/p104-joint-unit-flags/README.md"
+    ],
+    "methods": [
+      "Construct one side-correction word at an explicit chronological cut with the needed frames still available.",
+      "Derive a lower bound on the side correction and hosting costs that decides whether this channel can beat the selected budget."
+    ],
+    "acceptance_gate": "An exact arbitrary-input identity, source/target frame availability and restoration at the chosen cut, plus the complete channel+correction+idle/hosting bill or an explicit favorable bound. The native channel alone is not a supplier. A scoped local result may be retained without a complete supplier. Expanding it into further construction rounds requires the family-level budget and obligation gate in research-family-status.md; an optimistic passing relaxation alone is not acceptance.",
+    "first_step": {
+      "command": [
+        "python3",
+        "-B",
+        "scripts/research_baseline.py"
+      ],
+      "expected": "PASS_RESEARCH_BASELINE_BINDINGS_ONLY",
+      "inspect": "Read the revision-6 family record and #2981 static joint flags, alongside the reviewed #1991 channel. #2981 is an author-checked source archive, not an independently validated executable correction or a refutation of program-level lifetime floors.",
+      "scope": "Source-bound orientation only. Read the named package and review before relying on its local evidence; this command is not its replay or supplier admission."
+    },
+    "first_experiment": "After checking live handoffs, pin one named collection from #2981 and attach acquisition/delivery times, source dependencies and coefficient requirements. Test legal access and arbitrary dirty restoration; price any completion against the full channel/endpoint/hosting allowance. Stop with the exact missing implication or a scoped counterexample rather than expanding the static cover census.",
+    "bottleneck_link": "Completing an already realized changed channel tests a concrete construction opportunity, instead of refining the incumbent packing. A positive local result still needs global and all-size admission.",
+    "allowed_variations": [
+      "One correction factorization, one chronological cut, or one explicit hosting obstruction.",
+      "A changed correction schedule with an updated full bill and native frame contract."
+    ],
+    "scope_change_triggers": [
+      "Recompiling the already certified low-rank channel without closing a new obligation.",
+      "Treating a pending ancestor, local histogram or unpriced side correction as an admitted global supplier.",
+      "Repeating a correction or physical conversion already supplied by a pending follow-up without adding independent coverage or a different unresolved obligation.",
+      "Repeating the 208-flag static matching or calling a static nested cover a chronological correction program. Independent audit of that certificate is distinct and remains useful."
+    ],
+    "overlap_terms": [
+      "P104",
+      "I-G/2",
+      "side correction",
+      "native channel",
+      "1972",
+      "1991",
+      "2586",
+      "endpoint transport",
+      "physical dual",
+      "relay composition",
+      "2981",
+      "joint unit flags",
+      "acquisition delivery",
+      "static nesting"
+    ],
+    "existing_checks": [
+      {
+        "scope": "PR #2981 reports static joint endpoint flags and a matching of 208 departure and arrival flags; archival intake is not independent verification.",
+        "evidence": "research/p104-joint-unit-flags/README.md",
+        "remaining": "Independent flag check and a chronological coefficient program with dirty restoration and a complete cost.",
+        "status": "author-checked",
+        "source_commit": "3d24b92d8ba057b57cb2d480170ec407520e6882",
+        "selected_record_sha256": "bb2eaa58647b353f88d0aec2eafb9d30df1be53589231b23e12ceef3e4bad129"
+      }
+    ]
+  },
+  "scope_status": "changed",
+  "actual_scope": "Price one straight-line consumer of (N-P) tensor M on one 104 by 104 bank, in the PR3996 unit-addition model, and compare that bill with the two-pair uncorrected Gram saving.",
+  "scope_change_reason": "The catalogue card asks for a chronological endpoint-flag correction with a complete channel bill. The open question left by discussion comment 19056819 is narrower: the two-pair Gram addition saving is not a paid saving until some consumer of the omitted side (N-P) tensor M is priced. This package prices that one side. It does not build the flag program.",
+  "bottleneck_link": "A repeated Gram saving changes the complex supplier only if the omitted identity side fits inside it. The straight-line bill shows that one application costs more unit additions than the two-pair saving, so that saving is not yet a paid profile improvement.",
+  "budget_minutes": 60,
+  "stop_rule": "Stop after the straight-line B2 program matches (N-P)XM on the pinned fixture and the addition comparison is checked. Do not replay the 763392 events or start a native supplier.",
+  "outcome": "partial",
+  "evidence": "PASS_P104_OMITTED_SIDE_CONSUMER: 199680 B2 additions for one side, two-pair Gram saving 110592, net -89088 at two pairs. Both sides together cost 399360 additions, above one uncoded reference pair.",
+  "author": "unpaidmoon",
+  "ai_assistance": "Cursor Grok 4.7 wrote the checker and the comparison. The geometry and the 110592 saving are from the credited predecessors.",
+  "open_questions": [
+    {
+      "question": "Is there a straight-line program for one bank of (N-P) tensor M that uses fewer than 110592 unit additions in this B2 coefficient model?",
+      "why_it_matters": "199680 is the cost of this factorization, not a proved minimum. A cheaper program could still fit inside the two-pair saving.",
+      "first_step": "Replace either the two M shears or the three N-P matvecs by a program whose addition count is below 110592 and check it on the same three banks.",
+      "blocked_by": "none"
+    },
+    {
+      "question": "Can the two omitted sides share shears so that charging 2 times 199680 double-counts work?",
+      "why_it_matters": "PR3996's identity needs both (N-P) tensor M and M tensor (N-P). Shared work would change the both-sides comparison with the 241280-addition reference pair.",
+      "first_step": "Write one program that emits both sides on the same bank and count additions that are used by both outputs.",
+      "blocked_by": "none"
+    }
+  ]
+}

research/p104-omitted-side-consumer/VERIFY.json

@@ -0,0 +1,29 @@
+{
+  "schema_version": 1,
+  "status": "ready",
+  "python": "3.12",
+  "requirements": [],
+  "inputs": [
+    "research/p104-native-channel/inputs/P104-FIXTURE.json"
+  ],
+  "commands": [
+    {
+      "argv": [
+        "{python}",
+        "-B",
+        "{package}/verify.py"
+      ],
+      "timeout_seconds": 120,
+      "checks": "B2 digest and weights, A^2=13A, three banks equal (N-P)XM, straight-line count 199680, two-pair net -89088, dropped B^t B term rejected."
+    },
+    {
+      "argv": [
+        "{python}",
+        "-B",
+        "{package}/test_verify.py"
+      ],
+      "timeout_seconds": 120,
+      "checks": "Zero bank still pays 199680, one flipped B2 entry fails the Gram identity, omitting B^t B breaks the product, and the two-pair saving stays negative after one side."
+    }
+  ]
+}

research/p104-omitted-side-consumer/test_verify.py

@@ -0,0 +1,53 @@
+#!/usr/bin/env python3
+"""Failure controls for the omitted-side addition bill."""
+from pathlib import Path
+import sys
+import unittest
+
+sys.path.insert(0, str(Path(__file__).resolve().parent))
+import verify
+
+
+class ConsumerBillTests(unittest.TestCase):
+    def setUp(self):
+        self.b2 = verify.load_b2()
+        verify.check_b2(self.b2)
+        self.side, self.moment = verify.scaled_operators(self.b2)
+
+    def test_three_banks_match_and_share_one_bill(self):
+        counts = []
+        for matrix in verify.banks():
+            output, adds = verify.consume_bank(self.b2, matrix)
+            self.assertEqual(output, verify.reference_bank(self.side, self.moment, matrix))
+            counts.append(adds)
+        self.assertEqual(counts, [199680, 199680, 199680])
+
+    def test_zero_bank_is_zero_and_still_pays_the_straight_line(self):
+        zero = [[0 for _ in range(verify.N)] for _ in range(verify.N)]
+        output, adds = verify.consume_bank(self.b2, zero)
+        self.assertEqual(output, verify.reference_bank(self.side, self.moment, zero))
+        self.assertTrue(all(entry == 0 for row in output for entry in row))
+        self.assertEqual(adds, 199680)
+
+    def test_omitting_btb_breaks_the_identity(self):
+        matrix = verify.banks()[0]
+        output, adds = verify.consume_bank(self.b2, matrix, omit_btb=True)
+        reference = verify.reference_bank(self.side, self.moment, matrix)
+        self.assertNotEqual(output[8][0], reference[8][0])
+        self.assertEqual(adds, 199680 - verify.N * 384)
+
+    def test_flipping_one_b2_entry_breaks_the_gram_identity(self):
+        mutated = [row[:] for row in self.b2]
+        mutated[0][0] = 0 if mutated[0][0] else 1
+        with self.assertRaises(SystemExit):
+            verify.check_b2(mutated)
+
+    def test_two_pair_saving_does_not_pay_for_one_side(self):
+        self.assertEqual(verify.gram_add_saving(2), 110592)
+        self.assertLess(verify.gram_add_saving(2) - 199680, 0)
+        self.assertGreater(verify.gram_add_saving(3) - 199680, 0)
+        self.assertGreater(verify.CODED_PAIR_ADDS + 2 * 199680, verify.REFERENCE_PAIR_ADDS)
+
+
+if __name__ == "__main__":
+    unittest.main()