ORB5X is a refactoring of a mature physics code, so validation has two distinct questions: whether an algorithm is internally correct in C++, and whether its observable behavior agrees with the Fortran reference for the intended model.

Validation ladder

1. Unit tests exercise coordinate transforms, selectors, spline/matrix routines, loading, random/collision helpers, and small solver operations.
2. Integration tests check initialization, MPI communication, HDF5, and complete timestep paths.
3. Fresh C++/Fortran regressions compare the same input, rank count, and output observables for ITG, ITPA-TAE, and chirping cases.
4. Scientific benchmarks compare growth rates, frequencies, field histories, conservation diagnostics, and phase-space structure—not only raw bytes.
5. Performance studies report backend, compiler, dependency versions, rank/GPU mapping, and problem size alongside timing.

Floating-point interpretation

Kokkos backends, MPI reduction order, FFT/LAPACK implementations, and particle sorting can change rounding order. Bitwise identity is therefore not the general acceptance criterion. Tolerances must be tied to the observable and integration interval, with unexplained coherent drift treated differently from bounded roundoff-scale noise.

Reproducibility record

Archive the Git revision, complete input, equilibrium/profile files, build cache, compiler and dependency versions, MPI launch command, device model, rank/device mapping, and output-comparison script. Random-number configuration must also be recorded for collision-enabled runs.

Known scope rule

Documentation of an available selector means that the path exists; it does not assert that every cross-product of selectors is supported. The benchmark suite and current project issue/validation record define demonstrated configurations.