1 rollouts.candidate_support

rollouts.candidate_support

Candidate-support contracts, preflight evidence, and immutable bundle I/O.

Import from the owning leaf module so dependencies remain explicit.

1.1 Package guide

Candidate-support evidence uses these leaf owners:

  • contracts.py defines immutable evidence DTOs, canonical hashes, coordinate-frame transformations, and scientific support reducers.
  • preflight.py streams rollout rows into fail-closed candidate-family admission evidence and reads or writes Phase-A evidence.
  • comparison.py compares exact paired Phase-A candidate populations under two validity policies; its typed result preserves full state/candidate denominators, gains/losses, configured-family support and persisted root floors.
  • bundle_io.py serializes and validates content-addressed benchmark bundles.

Import from the owning leaf. The split preserves schema IDs, hash inputs, ordering, family floors, flat-gain aggregation, masks, and geometry math.

For paired Phase-A support, admit each persisted artifact with preflight.read_candidate_family_phase_a and independently declared contracts.CandidateFamilyPhaseAExpectation, then call comparison.compare_candidate_family_support(reference, challenger). Missing, duplicate or reordered states, candidate geometry/proposal lineage drift, unknown family applicability, incomplete canonical population coverage and different source/support policies are rejected. The target-aware floor applies only when a non-forward target-aware family is applicable; explicitly inapplicable states pass that conditional gate and remain in the full state denominator. Both artifact and writer-config identities accompany the result; writer validity policies may differ. These descriptive counts measure feasibility support only, without reward-quality, policy-utility or corpus-admission conclusions. The reducer reads no stores and launches no generation. No package-root re-export or new CLI is required.

Back to top