Verification and Validation Methodology

How we separate a code that runs correctly (verification) from a code that matches reality (validation), and why both matter for the gates.

Two different questions

Verification asks: does the code solve its equations correctly? Validation asks: do those equations match the real machine? A verified but unvalidated code can be confidently wrong — which is exactly the risk in the 166–830x regime, where no validating data exists yet.

How we apply it

• Verify solvers against analytic and benchmark cases
• Validate against every operated device we can
• Bound extrapolation distance explicitly (the regime multiplier)
• Attach uncertainty to every prediction, not just a point value

Why it underwrites the gates

The gates are only as honest as the codes behind them. Stating that the plug regime is un-post-dictable is itself a V&V statement: no validating data exists at that point. The test burner is the first machine that adds validating data near the design regime.

The distinction between verification and validation is not academic here; it is the difference between a code that is confidently right and one that is confidently wrong. In the 166–830x regime no validating data exists, so even a perfectly verified code can only extrapolate. Saying the plug regime is un-post-dictable is itself a validation statement, and it is why the test burner matters.

See code benchmarking and uncertainty.