Expand description
Reproducible operation plans.
§Why a plan and not just options
ExecutionOptions says how to run one operation. It does not say what
was run, what it produced, or whether re-running it would produce the same
thing. A graph evaluated twice under the same options gave no guarantee of
the same result, and nothing recorded which inputs and budgets produced a
given output.
A Plan is that missing artifact: the options, plus the recorded
provenance of every step, plus the outcome. Re-executing a plan against the
same inputs must produce the same result, and the plan itself is the
evidence of what was run.
§Determinism is requested, not assumed
Determinism has always been declarable, but nothing read it: a caller
could ask for Determinism::Bitwise and receive best-effort output with
no indication the request was ignored. A plan closes that hole. Executing a
plan admits the requested level against what the executing provider
actually guarantees, and refuses when the request cannot be met.
Refusing is the point. Silently accepting a determinism request a provider cannot honour is exactly the class of quiet wrongness this kernel exists to avoid: the caller believes it can hash the result and compare it across machines, and it cannot.
§Scope
A plan is an in-process artifact. It is deliberately not serialised: a wire format is a compatibility promise, and freezing one before the public API stabilises would commit to a shape the kernel has not finished learning. Reproducibility is proved by re-executing the same plan, not by persisting it. Serialisation can be added without changing this contract.