Step 5: split AggregationType into AccumulatorSpec (SummaryKind + typed params + grouping)

[zzylol]

Summary

Step 5 of the sketch-identity unification (scratchpad/artifacts/enum-unification-plan.md, §6/§8) — the highest-risk step, landed as its own PR per the plan's sequencing.

data_plane's AggregationConfig represented "which accumulator to run, on what, with what parameters" as three loosely-typed things: a 16-variant AggregationType enum that conflates sketch identity with the keyed/unkeyed axis, a raw aggregation_sub_type: String consulted only for two "wrapper" variants (SingleSubpopulation/MultipleSubpopulation), and an untyped parameters: HashMap<String, Value> bag. The real dispatch (accumulator_factory.rs::create_accumulator_updater) was a 14-arm match with a second string-typed dispatch layer underneath it (~54 AggregationType references in that one file).

This adds asap_types::AccumulatorSpec { kind: SummaryKind, params: SummaryParams, grouping: Option<KeyByLabelNames> }, converging data_plane onto the same asap_sketch::SummaryKind/SummaryParams representation control_plane already uses (Stage 3, merged — same asap-sketch git pin, rev = 150ef7d...), extended with the keyed/unkeyed grouping axis AggregationType wrongly folded into identity. accumulator_factory.rs now dispatches on AccumulatorSpec.kind instead of the AggregationType + string combo; the wrapper string-matching arms collapse away now that grouping is a sibling field. Every one of the old 14 match arms' behavior is preserved exactly — including the CMS-heap-vs-bare distinction, the bare-CountSketch-shares-CmsAccumulatorUpdater quirk, and all three fallback/unknown-warning paths (same warning text, same default updater per path).

Two decisions flagged for review

1. Additive, not a full replacement. AggregationConfig keeps its aggregation_type/aggregation_sub_type/parameters fields untouched — AccumulatorSpec is computed on demand via AggregationConfig::accumulator_spec().

• PolicyFingerprint::from_config hashes those three fields directly, and its own module doc calls the byte layout it produces a stability contract ("Don't reorder fields... any such change invalidates every deployed fingerprint and forces a cold-start rebuild"). policy_fingerprint.rs is not touched at all by this PR.
• Separately: AggregationType turned out to be read by ~40 files across data_plane/asap_types (query-time capability matching in capability_matching.rs, persistence/sid_metadata.json round-trip, reconciliation, index maintenance) — well beyond accumulator_factory.rs. Full removal was judged too large to land and review safely in one PR; tracked as follow-up.

2. Three details don't fit asap_sketch's upstream types, documented in accumulator_spec.rs's module doc, and still read AggregationConfig/its parameters map directly from accumulator_factory.rs:

• Min/max direction — SummaryParams::MinMax carries no fields.
• HydraKLL's (row, col) tiling grid — SummaryParams::Kll carries only k.
• Top-k weight_mode — no upstream concept at all.

The wire format (aggregationType/aggregationSubType/parameters JSON and YAML keys) is unaffected — AggregationConfig::from_yaml/from_json still parse those key names generically off a serde_yaml::Value/serde_json::Value, unchanged.

Test plan

• cargo build --workspace — clean
• cargo test -p asap_types — 78 passed (18 new: every AggregationType variant's resolution, both wrapper sub_type alias lists, all three error paths, a PolicyFingerprint stability regression guard)
• cargo test -p data_plane --lib — 881 passed, 2 ignored, 0 failed — matches pre-existing baseline exactly, no regressions
• cargo clippy -p asap_types -p data_plane --lib — no new warnings
• cargo fmt on touched files only — verified via git status that no incidental reformatting of untouched files leaked into the diff

🤖 Generated with Claude Code