Independent verification: derive PR540's pending ranges [15,22) and [1,29) from PR442's schedule (no new kappa)

[Mister-Meeseeks]

Scope: an independent source-binding check for open #540. No new κ, and the selected record is unchanged.

Task card

• Card: formal-interface-lemma (independent-verification track, chooser seed 89b099639256052efb5bbfd359684b0f). Scope is refined to "audit one theorem-to-source binding".
• Base: 49b3157d. Audited head: [Lean] Verify one literal PR442 invocation against the multi-host contract #540 acc1917034d10f464271ab115fda314fd4eee7a3 (PhysicalSourceConnection.lean blob 9a78d48f, generate_ownership_data.py blob 63703310).
• Question: [Lean] Verify one literal PR442 invocation against the multi-host contract #540's pendingTag gives idle child 1 the axes [15,22) and child 2 the axes [1,29) by hand. Lean checks only that these ranges contain the targets, and the extractor hard-codes the bases 15 and 1. Are these the actual pending sets from the source schedule? This is the next task named in the handoff.

Result

Both ranges are exactly the derived pending sets.

Child	Pair	Levels	Window	Derived	#540
1	1	1→2	{2}	E₂ = [15,22)	[15,22)
2	2	−1→3	{0,1,2,3}	q⊥⊕E₁⊕E₂⊕E₃ = [1,29)	[1,29)

Method

The checker is standard-library only and imports nothing from #434, #442 or #540.

• The hosted template is bound to bit_template_sha256 in Conditional κ ≈ 1.2375517e-3: idle-axis hosting of helper residuals (+9.2% over #434) #442's EXPECTED.json on main, and the geometry is bound to the template.
• The exterior 7-block layout is read from all 120 ports' routes.
• Each [q/2 | A_q] chart is checked to be exactly orthogonal.
• Level model (from PR386): L₋₁ = span(q), L_ℓ = Q⁸⊕E₁..E_ℓ. All 10 idle ranks are checked against it.
• The windows are recomputed from the schedule.
• All 747 hosted routes (child, off, w) are mapped to pending[off:off+w] and compared with [Lean] Verify one literal PR442 invocation against the multi-host contract #540's base+off.

Six mutations are rejected: previous-level block, a range that includes the q axis, swapped children, L₋₁ = {}, an offset past the pending rank, and stage 2 removed from the window.

Not covered

• This is a Python derivation, not a kernel proof.
• The ranks fix only dimensions. Identifying L₋₁ with span(q) relies on PR386's route identity, which is not re-proved here.
• The ascending order of axes within a child is a convention shared with [Lean] Verify one literal PR442 invocation against the multi-host contract #540's extractor; PR442 does not fix it.
• Only one invocation is checked.

Reproduce

python3 -I -B research/pr540-pending-range-derivation/verify.py      # ~0.5 s
python3.12 scripts/research_package.py --package research/pr540-pending-range-derivation
python3 -B -m unittest discover -s tests -p 'test_research_*.py'     # 20 OK, 1 skipped

The two vendored inputs are byte-identical to #540's inputs/ files of the same names; the SHA256 pins are in verify.py.

Credit: construction and hosting rule from #434/#442; bit geometry from PR386; the Lean formalization and gap identification are cheesegrader's #540. Prepared by Douglas Colkitt with substantial Claude (Anthropic) assistance. Apache-2.0.

Feedback: the endpoint-moment card (independent-moment) is already covered for the selected record by three code-disjoint engines (Mercator, base-two, atanh prime chain). The handoff thread was a better source of an unmet independent check.

🤖 Generated with Claude Code

[Mister-Meeseeks]

100-PR batch review at 28243acfc6b54273ebcf3cb11edef25df09c8d95.

Merged to main, preserving the original contributor commits and package attribution.

Reviewed scope: Independent derivation of PR540 pending ranges [15,22) and[1,29) from pinned PR442 schedule/PR434 geometry;747 routes and source bindings, limited to one specified invocation and inherited level convention.

The pinned scoped command passed; the batch ledger contains its command, input hashes, environment and log. This incorporates the research/tooling contribution and does not change the selected κ or discharge the inherited multiplication-theorem assumptions.

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