Evaluation gates

Validation should exercise the actual operator, architecture, dtype, and backend used by your application. Repository test results are evidence for their tested cases, not a universal identity claim across all backends or devices.

Numerical agreement

Compare against an independent expression or reference implementation. State absolute and relative tolerances, the input range, derivative order, and floating-point dtype. Unsupported paths and shape mismatches are contract issues; a small floating-point difference must be interpreted against the agreed tolerance and conditioning.

Training behavior

Check that the chosen spatial derivative path retains gradients with respect to every parameter that should learn. Include assertions for output shape and finite values. The high-order residual and deep Laplacian examples perform these checks.

Enclosures and formal results

For an enclosure, verify the assumptions and input representation as well as regression containment. Sampled containment can detect errors but does not prove the full bound. If claiming a supported formal result, retain the obligation, toolchain result, and diagnostics. Digest verification, replay, and formal checking answer separate questions.

Reproducible performance

Benchmark compilation and steady-state execution separately. Include the baseline, CPU or accelerator, dtype, shapes, repetitions, and derivative order. Measure complete training steps before making a training-speed claim. See benchmark methodology.

Release records

Keep exact dependency pins and commands with the result artifacts. A failing test, timeout, or unavailable optional tool should remain visible in the record. Consult the pinned source's CI configuration for its current project gates; this page describes application validation practice rather than claiming a fixed test count.