[unpaidmoon]

Change and mathematical scope

No new κ. The selected conditional exponent stays 781451/250000000. This package does not edit certificates/selected-result.json.

On the pinned 20-generator kernel of the D6 6-frame incidence code, research/e7-intersection-counters/engine.py at batch size 16 returns the same 16 words as the literal span. The SHA256 of the 15 positive words, as a default JSON list, is 23a7b374a6bc62bc2aca47843d52a01fa8e791ed3a98085133829d816c5094e8.

The domain is the 1048576-word F2 span of the twenty generators pinned in research/d6-intersection-counter-support/verify.py. A binary-reflected Gray walk lists every codeword. At each index the free coordinates of the running word equal index XOR (index >> 1). Those coordinates are an identity basis, so the walk is bijective onto the span. The words of weight at most 2 are zero and 15 words of weight 2. No nonzero word in that subset is lighter.

Batch size 16 puts the first 16 generators in one lane block. The pinned engine walks every offset in the span of the remaining 4 generators: the loop bound 1 << (len(rows) - count) is 16 on this input. Those four generators each have weight 2 and lie outside the 65536-word span of the first 16, so each is a target word that a lane-only pass cannot emit. The observed stream is 16 distinct words and equals the weight-at-most-2 subset. Ten generators already have weight 2. Five positive words are proper sums.

This is an exhaustive finite census of one finite span, and a set comparison at one batch size. It is not a proof that the engine is correct for every generator matrix, and it is not a census of the other legal batch sizes. A failed search was not used. No timing is recorded, and the comparison is not a speedup claim.

Task and overlap

Base commit: 17469fff78c22941280f04d39dc5a1faee09c840 on canonical CrocSwap main.

Task card replay-runtime, priority revision 8, from autoresearch.md. Scope status: refined. The card asks for a measured speedup that keeps coverage. The revision-8 verification row says a faster replay is not the same coverage until the sets are compared. Merged #6959 binds the bit-lane enumerator on this D6 basis and leaves this engine unrun (open question 3). Merged #6960 answers the same kind of question for the E6 64-word hash ad4a1d101774e6c2da40cde3d097d39aa56ee5668dcdca858513c5fec3578215. Open #7034 records that the engine refuses the P112 36-generator basis. This package is the D6 16-word comparison those leave open.

The selected record is 781451/250000000. The priorities page on this base still prints the older PR #5599 decimal. This package uses the selected record.

Ordered overlap check on 2026-11-10 after fetching that main commit. Open-PR search for the support hash, and for a 20-generator intersection-counter comparison, found no D6 engine comparison. The last 25 top-level comments on discussion #1166, through 2026-11-09, do not mention this hash. A repository code search was rate-limited and was not used.

Validation

Python 3.12 and the standard library, from the repository root. Head a8d3fd99d171503c1c39cd969aaeba1c2d4e41cf.

python3 -B scripts/research_package.py --package research/d6-intersection-counter-support --check-only
python3 -I -B research/d6-intersection-counter-support/verify.py
python3 -I -O -B research/d6-intersection-counter-support/verify.py
python3 -B scripts/research_package.py --package research/d6-intersection-counter-support
python3 -B scripts/check_research_commit.py --package research/d6-intersection-counter-support --check-source-history

Expected marker:

PASS_D6_INTERSECTION_COUNTER_SUPPORT batch=16 words=16 supports=15 hash=23a7b374a6bc62bc2aca47843d52a01fa8e791ed3a98085133829d816c5094e8 equal=True e7_census=false bit_lane_census=false timed=false no_new_kappa=true

Also PASS_PACKAGE_METADATA_AND_PINS, PASS_REGISTERED_RESEARCH_PACKAGE, and PASS_RESEARCH_COMMIT_BYTES.

Failure controls in the verifier: dropping the least positive word changes the set and the hash; a repeated generator raises ValueError: dependent generators; batch size 3 raises ValueError: batch count exceeds 65536 before a word is yielded. That batch-size-3 check is one refusal control, not a survey of batch sizes 1 through 20. The bit-lane low_weight_words rejects the intersection-counter keywords with TypeError. The D6 bit-lane census is not replayed.

Not run: scripts/research_selected_baseline.py as a scientific replay, the E7 census, Lean, Docker, and any timing harness.

Credit

The D6 lines and the support hash are merged PR #6959, research/d6-punctured-frame-code. The intersection-counter engine is Nick Petalas's research/e7-intersection-counters/engine.py. The injected population and threshold routines are Ali Romman's PR #5729, research/e7-bitsliced-exhaustion/binary.py. The E6 comparison in merged PR #6960 is the pattern for this check and is a different code. Open PR #7034 is the P112 refusal and is not rerun here.

Prepared by unpaidmoon with substantial Cursor Grok assistance. Apache-2.0. No independent human review and no formal-kernel acceptance are claimed.

Open next questions

From research/d6-intersection-counter-support/README.md.

1. Does the same set equality hold at another legal batch size on this 20-generator basis, for example 8 or 20? Batch size changes the lane split, so batch size 16 does not decide it. First rerun this comparison with batch_bits 8, or 20, and the same twenty generators, weight bound 2, and support hash. Nothing mathematical blocks that rerun. This package stops after batch size 16. Batch size 3 is refused before any yield, so it is not a second comparison.

2. Can this opt-in engine be installed at a caller that consumes the D6 6-frame code, with regenerated source pins? Set equality on one code leaves that replacement untouched. The first step is the installation and source-bound compatibility check already stated by research/e7-intersection-counters. This comparison does not regenerate consumer pins. Other codes are outside that package's claim.

Workflow feedback (optional)

The predecessor package names the engine, the 20-generator basis, one batch size, and the support hash, so the comparison stayed inside that question. One suggested improvement is to keep that four-part pointer (engine, basis, batch, hash) on later coverage questions. Discussion: #1200