Selection per #509: latency bounds and reasons for losing candidates — after #511 #526

Goal

#509 "3. Plan selection" rejects candidates that miss an accuracy target, exceed a latency bound or need a missing capability, and every rejected candidate carries a reason. Two gaps remain on main @107ab28d.

Blocked on

Implementation of #511 (unified operator graph). Do not start before #511 is implemented.

1. Latency bounds are never enforced

• LatencyRequirement (types/src/workload.rs:76, carried as QueryRequirements.response_latency) is read only by workload validation.
• No cost model estimates latency. CostModel has abstract Cost / CostRate. Empirical and ERP evidence measure CPU time, not wall-clock latency.
• Proposed:
  • Add a defaulted hook CostModel::read_latency_ms(summary, lifecycle) -> Option<f64> { None }.
  • Carry the minimum bound over a summary's bound entries in SummaryMaintenanceWorkloadFacts.
  • In alternatives_for, reject an alternative that exceeds the bound with a new SummaryMaintenanceLifecycleRejection::ExceedsLatencyBound.
  • With no estimate, keep the alternative and add "latency bound unchecked: no estimate" to its assumptions.
  • About 40 lines.
• Tests:
  • The bound rejects ephemeral while continuous is selected.
  • With no estimate, the alternative is kept and marked unchecked.
  • When every summary alternative violates the bound, raw recompute is chosen.

2. Candidates that lose selection keep no reason

• RejectedCandidate (replacement.rs:579, error: AccuracyError) records only stage 1-2 accuracy pruning.
• TargetSubDAGSelection keeps only chosen, and MajorPass drops both the search and the selection.
• Lifecycle alternatives already record {total_cost, rejection, assumptions} in PlanOutput.
• Proposed:
  • Keep pruning and selection separate; don't reuse RejectedCandidate.
  • Add the per-candidate costs considered (Vec<(candidate, Option<Cost>)>) to TargetSubDAGSelection, filled where the choice is made. About 25 lines.
  • Surface them in PlanOutput in a follow-up.

Open questions (recommendations)

• Check latency per lifecycle or per logical candidate? Per lifecycle.
• With no estimate, keep the candidate or fail closed? Keep it and mark it unchecked.
• Latency hook for raw recompute? Defer until a deployment can supply one.
• With One workload-level PhysicalASAPDAG and PlanOutput deduplication — after #511 #521 (one workload DAG), should loss reasons be recorded per whole-workload candidate?