Validation
Use this hub to decide how strongly to describe a public rfx result.
Simple public rule
Section titled “Simple public rule”| Surface | Public wording |
|---|---|
| uniform Cartesian Yee RF/FDTD workflows | recommended default path |
| rectangular waveguide S-matrices | bounded rectangular-guide claim envelope |
| lumped, wire, microstrip-line, and coaxial-line workflows | use only with the matching calculator and support envelope |
| differentiable design loops | valid optimization workflows, but final physics claims still require the matching validation evidence |
| other repository code | not public documentation unless a guide and support entry cover it |
Current practical anchors
Section titled “Current practical anchors”examples/crossval/05_patch_antenna.py— practical patch antenna cross-checkexamples/crossval/11_waveguide_port_wr90.py— rectangular waveguide-port workflowexamples/inverse_design/multilayer_ar_coating.py— conservative inverse-design demo
Practical takeaway
Section titled “Practical takeaway”Lead with the recommended default lane. Mention port-family envelopes only with their current limits, and use the public guide pages as the source for user-facing examples.
Evidence, artifacts, and reports
Section titled “Evidence, artifacts, and reports”Plots, Touchstone files, HDF5 snapshots, CSV tables, and report bundles are useful review artifacts. They become validation evidence only when paired with a documented analytic oracle, dump replay, external-solver comparison, convergence study, or benchmark envelope.