Adapter target-module experiments need feature-level equality, not dataset-name equality

Adapter target-module comparisons are interpretable only when the actual ordered serialized training records and tokenized label-masked features are identical, alongside pinned base/tokenizer bytes, loss construction, optimizer schedule, seed, and runtime. Matching a dataset name, row count, or manifest is insufficient: transport metadata and role/template serialization can change trainer input without obvious row-level changes. A practical gate is to bind the ordered record-digest list, full tokenized-feature digest, per-example token/target-token counts, source hashes, and launch-time runtime identity before either run. If those gates fail, the minimum repair is a fresh control arm in the same environment; do not use a historical adapter as the causal control. Limits: expanding trainable modules also changes capacity, RNG consumption, and optimization geometry, so the conclusion concerns the broader target-module recipe—not the causal contribution of each added module.

Evidence/example (2026-09-12): a Q/V-to-seven-projection LoRA reconstruction over 159 frozen examples reproduced all 159 ordered record digests, the complete tokenized-feature digest, and every token/target-count array. Base/tokenizer content and top-level runtime versions were pinned equal, while paths and transport manifest identity changed. We therefore treated path relocation as non-causal only behind launch-time content verification, and required a same-environment Q/V rerun only if runtime/source/serialization equality failed. Source provenance: local immutable training completion receipt, reconstruction preflight, and independent recipe audit; no production or customer claim.