Deployment inputs: capabilities and raw-data retention

[zzylol]

Stack: Wave 3 chain: #605 → #607 → #608 → #609 → #610

Rebased on main d4869a7 (DF 54).

Why

#509 lists three deployment inputs (cost model, accuracy model, execution capabilities) and says Stage 3 rejects a candidate "that needs a capability the deployment lacks". Only the first two existed (#525). Q48 also left raw-data retention unpriced: a plan that rebuilds a window from raw samples at query time looked free of retention even when the deployment does not keep raw data.

What

• DeploymentCapabilities in asap-types, new module deployment (not workload: a workload is what is asked; this is what the executor offers, a separate docs: propose workload-wide planning, summary sharing, and materialization #509 input). Data only:
  summaries: Option<Vec<SummarySupport { family: Exact(kind) | Sketch(algorithm), layout: PerGroup | Hydra(kind), readouts }>>, ingestion_time, query_time_retention, memory_budget_bytes, raw_data_retained, raw_bytes_per_sample (16).
• It sits in PlanningModels (capabilities, with_capabilities) with the cost and accuracy models. Default: UNRESTRICTED, raw_data_retained = true, so no number changes.
• Executor set (C2): asap_executor::capabilities(), derived from capability.rs's validators (validate_native_family, validate_sketch_evaluation, the keyed top-k configuration). The stage crates still do not depend on the executor (Reorganize crates and modules by #509 stages and the #511 unified IR #572 guards). stage_pipeline and the integration tests plan with it.
• Stage 3 (C3): rejects with a reason (q1: deployment lacks a CountSketchWithHeap TopK readout, q1: deployment lacks a CmsWithHeap summary, deployment cannot maintain state at ingestion time, retains N bytes across evaluations, over the deployment's memory budget of M bytes). With raw_data_retained = false, each query-time scan pays w_mem · lookback · λ · raw_bytes_per_sample; ingestion-time scans pay nothing. Documented in stage3-cost-model.md ("Deployment inputs").
• Label fix (Stage 2 materialization: ingestion vs query time per summary #604): Stage 2's family_name (and Stage 3's) label a Hydra summary "HydraCms", not "Cms". There is a regression test, which fails without the fix.

How (Before / After)

	Before	After
Example 1 selection, default inputs	P82, 4.620/s	unchanged (the test checks every cost under the executor's set against the default)
Executor's set vs. its compiler	none	every Example 1 candidate compiles and none is rejected for a capability
Raw retention	not priced	priced only when raw_data_retained = false

Q49 evidence (Example 3B = Example 4 Pattern B: p99 over 5 min every minute, 1M series, λ = 66 667/s; built-in model, executor capabilities, constants not tuned):

	raw kept (default)	raw_data_retained = false
B1: Kll ×5 panes at ingestion time	768.58/s	768.58/s
B2: rebuilt at query time from raw	5.17/s (rejected: 310 ms > 200 ms bound)	45.17/s (+40.0/s for 320 MB of raw samples; still over the bound)
B2 ≥ B1?	no	no

The B1 cost is mostly memory: 6 panes of 1M per-series KLLs, 6.1 GB. So the #606 tests stage3_b_rebuilding_every_window_costs_most and stage3_b_prefers_ingestion_time_tumbling_windows stay ignored, and their reasons now give these numbers.

Gate: cargo fmt --check, clippy -D warnings, cargo test --workspace: 1,661 passed, 23 ignored (#608: 1,652 / 23; 9 new tests). Restacked onto #608: fix: integrate with #607 plans the filtered-aggregate integration test with the executor's set too. The executor's filtered builds (#607) are a row filter on any summary build, so the capability set is unchanged and no filtered candidate is rejected for a capability. Viewer: python3 -m unittest test_render: 29 tests OK. The Example 1 fixture regenerates byte-identical.

Links: #509, #525, #572, #594, #604.

🤖 Generated with Claude Code