Module identity 

Per-phase identity for checkpoint match / mismatch decisions.

Per SRD-44 §“Phase identity”, every checkpoint entry is keyed by an identity tuple, not by display labels. The tuple is structural (yaml_path + coords) plus an optional phase-program hash for sufficiency.

This module owns the type definitions; the pre-map walker ([crate::executor::pre_map_recursive]) is what populates yaml_path per scene-tree node, and the program-canonical- emit logic lives in crate::checkpoint::storage alongside the JSON serialization.

Why per-phase, not workload-level

Workload-level identity gates (“did the YAML byte-hash match?”) are coarser than per-phase: a comment-only edit invalidates the entire run’s saved progress, even though every phase’s compiled program is identical. Per-phase hash lets the resume planner invalidate exactly the affected phases.

What the hash covers

Per SRD-44 §“Why hash the compiled program, not the YAML body”, the hash is over the canonical re-emission of the phase’s compiled PolydatProgram — incorporating substituted param values, transitively-referenced binding values, and all fold-able compile-time state. So a phase whose body references {dataset} correctly invalidates when the dataset param changes; one that doesn’t reference {dataset} correctly survives.

Structs

PhaseIdentity

Per-phase identity, used by the checkpoint writer to record “what phase is this” and by the resume planner to match a saved entry to a freshly-pre-mapped phase.

Enums

PathSegment

One step in a phase’s structural location within the workload YAML. The full path is built by walking the scenario tree from the workload root down to the phase declaration. Order matters; comparison is element-wise.