Module harness
Expand description
The sampler-driving engine, at the seam and nothing above it.
Both deliverables of the M2.3 gate reduce to the same loop: hand a
Sampler a growing history and ask it for
the next point. This module is that loop, expressed as three primitives —
suggest (one sampler decision), record (fold one observation into the
history), and optimize (the sequential oracle that composes them into a
best-value curve).
§Why drive the sampler seam directly, not the Study loop
atune_core’s Study is the full ask/tell
driver, but its TrialCtx borrows the study, so holding several open trials
across the kurobako adapter’s message boundary would need a self-referential
handle. Driving the Sampler seam against a
hand-maintained StudyView avoids that
entirely and is exactly the translation the gate is specified as — “ask →
sampler suggest, tell → observe” — while still using the real samplers, the
real transform layer, the real history/visibility model and the real
trial-number seed derivation. Nothing here re-implements a sampler.
§Determinism
optimize is a pure function of (sampler kind, problem, seed, budget):
the sampler’s per-trial RNG is keyed on the trial number and the study seed
(TrialMeta::derive), the problem
objectives are pure, and the history is folded in trial-number order. Run it
twice and the curve is byte-identical (a property the regression test
asserts). That identity is per platform (docs/design/03-architecture.md §6):
samplers such as Tpe use f64
transcendentals, so a committed curve is pinned with a tolerance rather than
bit-for-bit.