Candidate to Split Provenance Workflow#

This is a V0.29 recipe page over existing public APIs; it adds no runtime surface.

This recipe is the complete candidate-validation path for users who already have a generator candidate and plan to materialize orbit-derived data.

supplied candidate
-> configured validation
-> generator confidence
-> orbit batch provenance
-> split leakage provenance report

Minimal Recipe#

  1. Represent the candidate as a supported public object or payload.

  2. Run validate_symmetry_candidate(...) against the intended field and residual evaluator.

  3. Keep validation, closure, finite-transform, and residual evidence distinct.

  4. Summarize combined evidence with summarize_generator_confidence(...).

  5. If materializing translations, keep source and shift indices enabled.

  6. Pass user-supplied partition labels to summarize_split_leakage_provenance(...).

  7. Treat traceable overlap as a reportable risk, not an automatic benchmark policy.

Tutorial Page#

The rendered notebook 13_candidate_to_split_provenance_workflow.ipynb shows this path with a known translation generator, one intentionally weak candidate, orbit provenance, and a split-risk report.

Boundaries#

This workflow does not create splits, prevent leakage, train a detector, prove a symmetry, or add arbitrary finite-transform/group-action machinery.