Module plan 

Execution plan — per-realize compilation output, Phase 1.5 reshape of the picker-work arc.

The plan is a topological order plus a sparse NodeId -> AlternativeSet map. Each entry is the per-decision-point top-N candidates the optimizer ranker considered, filtered and ranked per the configured PlanOptions. The eventual executor reads alternatives per node, takes the winner (Picker 2 territory in the long-term shape; Phase 4 wires the executor to this surface), and dispatches the resolved kernel.

What changed in Phase 1.5

Pre-1.5 this module hosted NodeKernelBinding, TolerancePolicy, and resolve_kernel — the v1 picker that fell out of Phase 7.6 step 9b. Those types had zero callers (verified by the 2026-05-30 picker-alternatives audit), so Phase 1.5 retires them and ships the AlternativeSet-based plan in their place. The shape composes with everything Phase 1.1–1.4 already shipped: the enumerator builds candidates, the filter chain narrows them, the cost composer scores them, and the plan stores the top-N-after-filter-and-rank.

Phase 4 of the picker-work arc migrates the PipelinedExecutor to consume ExecutionPlan::alternatives instead of compile_node’s first-registered path. Until then this module ships the infrastructure with no production consumer.

Structs

ExecutionPlan

Per-realize execution plan. Built by compile_plan.

PlanOptions

Plan-time configuration the caller hands to compile_plan.

Functions

backend_for_device

The BackendId that owns a DeviceLocation’s storage substrate. Total — BackendId mirrors DeviceLocation 1:1 (AOCL/MKL are kernel_source siblings under Cpu, not distinct backends). Inverse of default_device_for modulo GPU ordinals.

compile_plan

Build an ExecutionPlan from a topologically-ordered node sequence + binding table + options.

default_device_for

Default DeviceLocation for a BackendId when the graph has no per-node placement set. Mirrors the convention in fuel-graph-router (CPU is the singleton Cpu; GPU backends default to ordinal 0).

node_needs_plan_entry

Does this op receive an AlternativeSet entry from compile_plan? The single source of truth for the plan-entry gate (used by build_node_draft and PlanOptions::reuse_plan incremental extension): true exactly when op_to_op_kind maps the op AND it is not a residency-determined transfer (Op::Copy / Op::Move, whose kernel backend the executor resolves from the bridge-maintained source-backend stamp).