Research audit: X2 acceptance boundary for the selected owner map (no new kappa)

[navinor]

Adversarial audit of one selected supplier obligation; no new κ. Navinor, with help from opencode. Apache-2.0.

Task selection: adversarial-audit track via scripts/choose_research_task.py (OS-random nonce ca8debca8488dd850dd6c0afb7398632), card supplier-boundary-audit (scope key dcdb0fa8e49b08a958d0), refined to one named condition. Base commit bce54fb3f895cbe5cd4c0eb477c3afeed100190f; audited source head 0fc329d0bec93ca7cd288eaea1295172e8789810 (the selected owner map, #1094).

Question and answer

The card asks: does one selected supplier obligation follow from its actual source-bound checks?

Obligation X2: pending axes of distinct idle children of one physical family are disjoint, so a family's hosts on different children never share a cell (stated and checked in Josie Elliston's owner audit, #1091).

Answer: no. X2's acceptance does not follow from the selected record's reproduce command. It is enforced exactly once, at batch1099 review time, by research/community-batch1099-audit/check_frontier1094.py (pinned in the record's proof_supplements). Neither make frontier1094-verify (stages historical-source, baseline1042-cold/reuse, rare-pattern-exchanges) nor scripts/verify_selected_result.py (record and hash validation only, no subprocess execution) nor the community-batch1099.yml CI job (which runs research/t16-owner-audit-seed67/verify.py --fetch for its pinned claim list, #1022 through #1087, excluding the selected supplier) executes that composition. The frozen verifier chain the replay does run (upstream1087.tar.gz, Jeremy Kothe's PR 1087 chain with Hao Yan's (FanPUYen) PR 858 T16 edits) keys hosted cells per (owner, child, port) in t16/indep16.py and asserts only len(pending) == rank per child in code/audit_allcold.py; cross-child cell sharing is outside its rule set.

Minimal adversarial instance

One integer in the pinned DATA-PHASES.json pending axes: child 1's axis 131072 at port 0 replaced by 13, already pending for child 0 (children 0 and 1 are distinct idle children of the same physical family place). Exactly one differing integer; every rank, window, role count, width and profile aggregate is preserved.

• geometry() rejects it: X2: children [0, 1, 14] share axes at port 0.

• With only the X2 check suppressed, geometry() returns an identical geometry object and the complete R1–R7/X1 rule set accepts the fixture. The X2 rule is the only rule that reads pending axes.

• Concrete damage: roles at time 3 and time 6 (both helper 476, owner replica 0, family 224, port 0, offset 0, width 8) resolve the same pending axis 13 of family 224 — one physical cell written twice — while every role-level rule accepts both.

• A second mutation (one axis duplicated inside a single child's list) is rejected at X2 as well. Both are failure controls with single-locus, rank-preservation and null-mutation guards.

The existing rejection batteries contain no X2-directed mutant: the owner audit's 11 controls and the frozen chain's 6 independent-t16 controls. This PR supplies the first two, answering the card's method ("construct one semantically invalid but superficially well-formed fixture and test rejection").

Reproduce

python3 -B research/owner-x2-acceptance-boundary/verify.py

Expected: PASS_PR1094_X2_ACCEPTANCE_BOUNDARY_AUDIT. Fresh run on Python 3.13 (Windows) in this session returned that status with both mutants rejected at X2. Deterministic record and exact input pins in research/owner-x2-acceptance-boundary/RESULT.json. The repo suite python3 -B -m unittest discover -s tests -p 'test_research_*.py' (with PYTHONUTF8=1) runs 20 tests with 5 errors and 1 skip — identical with this change stashed. The 5 errors are pre-existing environmental failures in test_research_onboarding.PackageTests on this Windows checkout (core.autocrlf=true breaks the temp-fixture scaffold commit comparison); they do not involve this package.

Files changed (new package only; upstream/, frozen pins and selected record unchanged)

• research/owner-x2-acceptance-boundary/README.md — task card, trace table, evidence, open next questions.

• research/owner-x2-acceptance-boundary/verify.py — stdlib-only harness (positive control, M1/M2 mutants, cell-collision witness, blindness measurement, control inventory, enforcement trace).

• research/owner-x2-acceptance-boundary/RESULT.json — deterministic record with source pins.

• research/owner-x2-acceptance-boundary/TASK.json, VERIFY.json, SOURCES.json — scope metadata and replay manifest.

Remaining obligations (not claimed)

• The full make frontier1094-verify cold replay with the mutated phases was not run (needs the published frontier1042 baseline artifacts and cold replay time); frozen-chain acceptance of the mutant is code-trace evidence, not execution.

• No claim other than the selected inputs was re-audited; the historical owner-boundary-audit package was used as a method example only.

• This is a checker-coverage audit of one named obligation: not a construction, not a supplier change, not a κ claim, and not a proof of hosting soundness (X2 itself is enumerated on the pinned phases, not proved universally).

Credit and predecessor attribution

X2's rule wording and the independent owner audit are Josie Elliston's (#1091), reused unchanged as a library. The selected owner map is Rohan Arun's #1094 on Jeremy Kothe's T16 owner-map lineage (#1050 and successors); the frozen verifier chain is Jeremy Kothe's PR 1087 chain with Hao Yan's (FanPUYen) PR 858 T16 edits; the batch1099 composition and review are Douglas Colkitt's; independent endpoint pricing is Sagar Thakrar's #1069. Nearest concurrent findings: #1277 (the reuse replay discards its ancestry recheck) — same replay-coverage class, different obligation, credited for the direction; #1209 audits pending-axis independence of the selected data semantically, while this PR tests which checkers reject a corrupted fixture at all.

Audit by Navinor with help from opencode.

[Mister-Meeseeks]

100-PR batch review at bdeda4e8c71d947bbda0c339b19a66f765dedbe0.

This remains open after scoped triage. Next review step: X2 semantic counterexample and source trace replay pass after fixture hydration. Clarify that missing semantic recomputation differs from acceptance of mutated pinned inputs: source-hash checks can reject the mutation. Full mutated-chain acceptance was not executed; narrow the structural-blindness claim or demonstrate the exact source-bound acceptance path.

This is a specific continuation point, not a rejection or a request to redo already recorded checks. Completed local evidence is retained separately from outstanding whole-head obligations.

Batch review, attribution and evidence. Thank you for the contribution.

[navinor]

Follow-up to the batch review note (reviewer comment, batch review doc) on bdeda4e8: the structural-blindness claim is narrowed to exactly what is demonstrated, and the exact source-bound acceptance path for the mutated fixture is now executed and recorded (1948edd9).

Old claim wording (README answer paragraph, PR body, TASK.json evidence):

• "Every checker that the reproduce path does execute is structurally blind to X2."
• "…the complete R1–R7/X1 rule set accepts the fixture…"
• "Acceptance of M1 by the frozen chain is established by code trace, not by execution."

New claim wording (README.md answer paragraph, RESULT.json source_bound_acceptance.claim_scope, TASK.json evidence):

• "No checker that the reproduce path does execute recomputes X2 semantically. That is a missing-semantic-recomputation gap, not demonstrated end-to-end acceptance of a mutated pinned input: the source-hash layers reject the mutated fixture before the semantic rules ever run (executed evidence below), and full mutated-chain acceptance was not executed."
• "…the complete R1–R7/X1 rule set accepts the fixture — the semantic-layer measurement on in-memory mutated bytes: the source-bound entrypoints never deliver mutated pinned bytes to these rules."
• "…the frozen chain carries no cross-child pending-axis rule (code trace); its DATA-PHASES hash handling is an emit-time self-consistency binding (emit_allcold.py source_artifacts ↔ audit_allcold.py exact_data_phase_recipe_sha256), not an external pin. Full mutated-chain acceptance is not executed and not claimed."

Where hash/pin vs semantic rejection happens (new verify.py section 7, recorded in RESULT.json source_bound_acceptance):

Layer	Checker	M1-mutated pinned DATA-PHASES.json
record/manifest hashes	scripts/verify_selected_result.py (SELECTED-SOURCE.json package inventory, proof_supplements)	the top-level audit fixture is outside the manifest's package roots (not covered here); the three vendored DATA-PHASES.json copies are pinned at c5916ff3… and a mutation of those is rejected
source input pins, before any semantic rule	research/community-batch1099-audit/check_frontier1094.py line 19 (before geometry() line 21); research/t16-owner-audit-seed67/verify.py line 359 (before geometry() line 362)	rejected at the sha256 pin (SOURCES.json inputs.data_phases_sha256) — executed
semantic rules	R1–R7/X1, X2 (geometry()); frozen indep16/audit_allcold	R1–R7/X1 accept (executed, in-memory); X2 rejects (executed); frozen chain: no cross-child pending-axis rule (code trace)

Executed evidence, from one command (python3 -B research/owner-x2-acceptance-boundary/verify.py): the one-integer M1 edit (131072→13 at recipes[0].idle_children[1].orthogonal_axes[0], byte delta 4, parsing the edited bytes yields exactly the in-memory M1 fixture) is applied to a scratch copy of the pinned bytes (tracked files untouched, scratch tree deleted) and the real source-bound entrypoints are run against it:

• mutated pinned input: check_frontier1094.py stops at its DATA-PHASES hash require (traceback frames 12/19, geometry() at 21 never runs); the owner audit stops at FAIL input: DATA-PHASES hash (line 359, geometry() at 362 never runs).
• intact controls: both entrypoints pass the pins and reach later code — the composition stops only at the intentionally absent scratch dependency at line 22, and the owner audit reaches its claim loop and stops only on the absent git blob store.

So the demonstrated gap is semantic recomputation: no executed checker on make frontier1094-verify re-derives X2 from the admitted bytes. A mutated pinned input is rejected by the source-hash layer before the semantic rules run; end-to-end acceptance of the mutated chain was not executed.

Verification on the corrected tree

• python3 -B research/owner-x2-acceptance-boundary/verify.py (run under both Python 3.12 and 3.13, PYTHONUTF8=1): PASS_PR1094_X2_ACCEPTANCE_BOUNDARY_AUDIT, RESULT.json byte-identical across interpreters (61f39542…).
• python3 scripts/research_package.py --package research/owner-x2-acceptance-boundary --check-only: PASS_PACKAGE_METADATA_AND_PINS. Two metadata corrections were needed for that validator: TASK.json scope_status is now refined with a reason (the validator requires it when the scope wording differs from the card question), and VERIFY.json status is ready.

Remaining open obligations (substance unchanged, wording narrowed)

• The full make frontier1094-verify cold replay with mutated phases is still not executed (needs the published frontier1042 baseline artifacts and cold replay time); no end-to-end acceptance of a mutated pinned input is claimed anywhere in the package.
• Whether the frozen chain would accept a defect introduced at generation time and re-pinned self-consistently remains code-trace only; the mutation above is rejected before the frozen chain can see it.
• Whether scripts/verify_frontier1094.py should execute the pinned review-time composition (which is what checks X2 for Conditional kappa 0.001672660197076918: rare-pattern T16 exchanges #1094) needs maintainer authorization; this PR does not change the reproduction path.

Credit is unchanged: the X2 rule and the independent owner audit are Josie Elliston's (#1091), the audited owner map is Rohan Arun's #1094 on Jeremy Kothe's T16 lineage, and the batch1099 composition is Douglas Colkitt's.

Aaron Wang, with help from opencode.