Background
Deferred from PR #84's review (gh-review-pr:finding=nested-recursion-evaluator-init), 2026-08-15.
RecursionTrainer's nested-config construction currently overwrites an inner evaluator_init key outright rather than using .setdefault()-style merge semantics. The current overwrite behavior is the exact code path that generated the Interp/I_MPSAer results shipped in PR #84 (and the associated Nautilus campaigns), so changing it now would need those results re-validated, not just the training-pipeline code.
What needs deciding
- Should nested
evaluator_init keys be overwritten by the outer config (current behavior) or merged via .setdefault() (only fill in missing keys, preserve any inner ones already set)?
- Whichever choice is made, confirm it doesn't silently change results for existing committed campaigns (Interp/I_MPSAer especially, since that's the method currently exercising this path).
Where
qaoa_training_pipeline's RecursionTrainer (or wherever the nested trainer-config construction lives in this repo's IBM_QAOA pipeline code — trace from RESULT_TAGs using I_MPSAer/Interp methods).
Background
Deferred from PR #84's review (
gh-review-pr:finding=nested-recursion-evaluator-init), 2026-08-15.RecursionTrainer's nested-config construction currently overwrites an innerevaluator_initkey outright rather than using.setdefault()-style merge semantics. The current overwrite behavior is the exact code path that generated the Interp/I_MPSAer results shipped in PR #84 (and the associated Nautilus campaigns), so changing it now would need those results re-validated, not just the training-pipeline code.What needs deciding
evaluator_initkeys be overwritten by the outer config (current behavior) or merged via.setdefault()(only fill in missing keys, preserve any inner ones already set)?Where
qaoa_training_pipeline'sRecursionTrainer(or wherever the nested trainer-config construction lives in this repo's IBM_QAOA pipeline code — trace fromRESULT_TAGs usingI_MPSAer/Interp methods).