nx_gen_lora_verify.nx

nx_gen_lora_verify.nx -- prove the sovereign LoRA fold against an EXACT f64 reference. ★★★★★ WHY NOT GRADE AGAINST sd.cpp. We tried, and it cannot answer the question. sd.cpp applies this adapter at RUNTIME (`apply lora at runtime` -> forward_with_lora), so its weight tap yields the BASE weight and only its activations carry the adapter. Grading our fold against those activations measured a LoRA delta of 0.86% of the signal through an oracle whose own Q8_0 error is 0.6% median. A least-squares fit for the scale recovered 0.1725 against a true alpha/rank of 0.1667 -- consistent, but the confidence interval swallows the answer. ⇒ THE SAME REMEDY AS EVERY OTHER SCALE THIS SESSION: build the third, higher-precision reference. exact = h @ (W + (alpha/rank) * up @ down)^T in f64, from the SAME dequantized bytes. Now the only difference between us and the reference is OUR arithmetic, which is the thing under test. sd.cpp is no longer a judge here -- it is a second defendant. Usage: nx_gen_lora_verify <lora.safetensors> [multiplier_milli] [ref_fixture] ⚠THE REFERENCE IS AN ARGUMENT ON PURPOSE. A fold that ignored the multiplier entirely would pass the mult=1.0 case perfectly and look green forever. ★ A GATE THAT ONLY TESTS THE EASY SIDE OF A SWITCH DEFENDS NEITHER SIDE -- so the multiplier is graded against its OWN exact reference at 0.5 and at -1.0, and each must fail the others. license_tier: ORIGINAL