Exact TopK (accuracy: Exact) has no warm-tier materialization -- always falls to archive #432

Context

One of the five "D1-D5" query-shape gaps originally tracked in the (now-retired) analyzer-parity-matrix.md, and explicitly scoped in control_plane/docs/design-backend-plan-wire-format.md/migration-plan-backend-plan.md (#389/#390, Phase 3) as something capability_for() should close. Confirmed still open today:

// control_plane/src/sketch_algebra/capability.rs
#[test]
fn capability_for_topk_exact_returns_none() {
 // Exact top-k must use HashAgg+Heap; no ASAP-tier sketch.
 let intent = AggIntent::TopK {
 k: 10,
 accuracy: AccuracyTarget::Exact,
 };
 assert_eq!(capability_for(&intent), None);
}

topk(k, metric) (or any composed shape reducing to AggIntent::TopK { accuracy: Exact, .. }) always capability-misses to archive today — there is no warm-tier path, approximate or exact.

Root cause (two layers)

1. Upstream (ASAPController): capability_for() delegates directly to asap_plan::boundary::implementation_for(intent) for everything except the local Frequency extension. For TopK { accuracy: Exact }, implementation_for's exact_realization returns Implementation::PassThrough unconditionally — no accumulator form for TopK exists in asap-plan at all, and (per implementation_for_with's design) the decision to even try isn't reachable via a CostModel hook. This is already tracked as ASAPController#151 — filed before this repo's git-dep migration, still open.
2. Local (this repo): even if feat(asap_types): make aggregationId optional; backend derives from content #151 is resolved upstream (e.g. TopK at Exact starts offering a candidate list to CostModel instead of hard-PassThrough), data_plane has no concept of an exact, warm-tier top-k materialization to realize it as. AggregationType (ExactAgg's family enum) only has Sum/MinMax/Increase — no TopK variant — and there's no accumulator in precompute_engine/operators/ implementing "exact heap-based top-k" (the HashAgg+Heap the test comment names). capability_for's exact-accumulator branch (implementation_to_capability) has nowhere to map a hypothetical SummaryKind::TopK-exact even if upstream started producing one.

So this needs work on both sides, not just a local fix once #151 lands.

What closing this would take

• Upstream: feat(asap_types): make aggregationId optional; backend derives from content #151 's resolution (offer TopK-at-Exact as a real candidate to CostModel, or an equivalent mechanism).
• Local:
  • A new AggregationType variant (or equivalent) representing exact top-k, plus a real accumulator (a bounded min-heap over exact per-key counts — the "HashAgg+Heap" the existing test comment already names as the target shape).
  • capability_for's implementation_to_capability extended to map it.
  • Wire-format support: today's AggregationConfig/StreamingConfig schema would need a materialization shape for it (same underlying gap design-backend-plan-wire-format.md's still-unimplemented MaterializationPayload::ExactAggregate was meant to cover generally — this is one concrete instance of that broader, still-unstarted BackendPlan work, not a reason to block on it specifically).

Scope note

Not urgent on its own — topk(...) at approximate accuracy already works via FrequencyTopk/CMS-with-heap; this only affects the accuracy: Exact request explicitly asking for no approximation, which today correctly (if unhelpfully) falls over to archive rather than silently returning an approximate answer. Filing to keep it visible alongside the other D1-D5 items now that analyzer-parity-matrix.md (which used to track it) is retired.

References

• control_plane/src/sketch_algebra/capability.rs — capability_for/implementation_to_capability, capability_for_topk_exact_returns_none
• ASAPController#151 — the upstream half of this gap
• control_plane/docs/design-backend-plan-wire-format.md §7 ("Closing D1-D5") / migration-plan-backend-plan.md Phase 3 — original scoping of this exact gap, from before analyzer-parity-matrix.md was retired