Validate realized LoRA selector coverage, not just configuration intent
General lesson: adapter configuration records intent, not realized trainable coverage. A permissive selector API can accept a mixed list, adapt only names that exist in the concrete model, and leave zero-match selectors invisible unless the run audits the generated tensors. Before paid training, build a selector-to-realization matrix from the exact loaded checkpoint and fail closed on missing or unexpected matches when the experiment contract requires exact coverage.
A reusable preflight method:
- Enumerate the exact loaded model's named modules and named parameters; do not infer topology from a generic architecture family or library preset.
- Separate module selectors from direct-parameter selectors. Ordinary LoRA module targeting does not prove that standalone nn.Parameter objects were adapted.
- After injection, map every generated LoRA A/B tensor back to its requested selector and base target. Record counts and names per selector.
- Require the optimizer parameter-ID set to equal the audited adapter set, while independently proving the frozen-state fingerprint is unchanged.
- Exercise save/reload in a dry run and re-run the same realization audit on the reloaded adapter.
- Treat a declared selector with zero realized targets as a compatibility decision, not a warning to ignore. Either correct the targeting mechanism or obtain an explicit amendment to remove a nonexistent target.
Limits: some projects intentionally use a union of alternative selector names across model variants. Zero-match entries are only fatal when the experiment promises literal coverage; otherwise the receipt should state which alternatives matched. Parameter targeting is library- and shape-specific and must be verified against the pinned implementation rather than assumed.
Evidence/example — 2026-09-10
In E3's e3-solutions/theft COR-4116 RF-DETR Small preflight, a nine-name PEFT LoRA configuration passed schema, optimizer-scope, freeze, serialization, and 72 tests. The realized receipt nevertheless contained adapters only for query, key, and value. Exact checkpoint inspection showed four projection aliases and register_tokens were absent; cls_token existed as a standalone 3D parameter but had not been passed through PEFT's supported parameter-target path. The pilot was stopped before its first optimizer step. This is evidence for the method above, not a claim that every LoRA selector union should reject zero matches. Provenance: COR-4116 Linear prelaunch/blocker receipts and the pinned RF-DETR 1.9.3 / PEFT 0.20.0 runtime inspection.