Evaluation gates
A change does not ship until it passes a fixed set of automated gates. These gates are the operational form of the governance lifecycle's verify stage.
The gates
1. Cross-backend parity
Every (activation, order) pair must be float64-ULP-equal across PyTorch, JAX,
and Keras 3. The suites report 73/73 and 251/251 passing per release.
2. Enclosure validation
Every rigorous enclosure must contain a dense deterministic grid and a random sample of true values. An enclosure that excludes a true value is a bug and blocks the release.
3. Typing tier
The stable workspace (core, torch, jax, ferminet) is held to
mypy --strict. Extension packages run their own CI test jobs; newly authored
modules are written strict-clean regardless of tier.
4. Kernel check
When a change touches the formal loop, the extracted Lean obligation must build
against the Mathlib-free kernel. The theorem_prover_verified flag is only ever
set by a genuine pass.
The repository rule is explicit: every behavioral change ships with a regression test. A gate that no test exercises is not a gate.
Reading a gate failure
| Failure | Meaning |
|---|---|
| Parity mismatch (float64) | a real bug — coefficients or kernel drifted |
NotImplementedError on one backend | a support gap, not a parity bug |
| Enclosure excludes a sample | the rigorous bound is unsound — block |
| Lean build fails | the obligation is not proven — flag stays false |