Conversation
Proposes replacing StreamingConfig's pattern-match-shaped schema with a typed BackendPlan (Materialization + RoutingEntry), a query-time RoutingIndex in data_plane, and merging ASAPController's L1-L3 into control_plane as the canonical IR. Closes the D1-D5 gap documented in analyzer-parity-matrix.md by making exact materializations first-class instead of a capability_for() rejection.
2 tasks
Frequency -> ASAPController's RankingMeasure::Frequency; irate/rate fold adopted; control_plane gains SQL support; CSE moves to L4. Also records the general tie-break rule: adopt ASAPController wherever the two diverge, unless something is control_plane-only with no ASAPController equivalent.
3 tasks
This doc and data_plane/docs/l4node-plan-executor-design.md (Step C, #409, itself following Step A/#407 and Step B/#408) were written four days apart and never cross-referenced each other. §6's RoutingIndex assumed a flat one-query-to-one-materialization model that predates L4Node's tree shape and doesn't account for SummaryExecutor::find_candidates (ASAPController#155, the serving-time counterpart to this section). As originally written, §6 would reintroduce the exact bug AccumulatorSpec (#401) was built to close: step 5's Capability::is_satisfied_by is family-level only and can't guarantee two candidates actually share (SketchKind, SketchParams), which SummaryMerge requires. Corrects three things: - Granularity: RoutingIndex's Tier-2 lookup must be invocable per L4Node leaf (find_candidates is called once per SummaryAgg, possibly several times for one nested query), not only once per whole query. - Match precision: find_candidates needs exact (SummaryKind, SummaryParams) matching via AccumulatorSpec, not family-level Capability -- required for anything that can feed a SummaryMerge. - Selection semantics: find_candidates must return every exact match for merge_states to fold, not rank-and-pick-one like the original whole-query mode. Both consumption modes can share the same columnar/interned Tier-2 structure (§6.1) -- only match precision and return shape differ by caller. No code changes; this is a design-doc correction so implementation (of either this or #409) doesn't have to be redone once the two are compared. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
zzylol
added a commit
that referenced
this pull request
Jul 24, 2026
Phase 1 wasn't done as scoped (#391 closed unmerged; #392 "Phase 1b" substituted a bigger structural fix -- direct git-dep on ASAPController's IR crates instead of an in-tree vocabulary copy-merge). Phase 3 is substantially done already (capability_for() routes Sum/Min/Max/Rate/ Increase to exact-agg on main) but not via this plan's sequencing, and its own documented blocker (missing analyzer_parity_tests corpus) is still unresolved. Phases 4-5 haven't started. Also flags an unplanned parallel thread (#407/#408 Step A/B, merged; #409 Step C, open) that adopts asap_plan::bind::implement_tree / asap_sketch::L4Node directly and overlaps with what Phases 4-5 were meant to deliver -- cross-referenced against the RoutingIndex reconciliation just landed on design-backend-plan-wire-format.md (#389) so Phases 4-5 get re-scoped against what that thread actually ships before anyone executes them as originally written. No process/plan changes here beyond recording status -- this is the same kind of staleness correction this doc already applied to ASAPController/docs/migration-plan.md. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This was referenced Jul 29, 2026
Contributor
Author
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Design draft for replacing
StreamingConfig/AggregationConfigwith atyped
BackendPlanwire contract betweencontrol_planeanddata_plane, plus the ASAPController L1-L3 merge that feeds it.control_planeas the canonical IR(base = ASAPController — a fresh diff of
agg_intent.rson both sidesshows it's now the richer side after issues fix(sketch-db): POST /api/v1/db/backfill uses create_checked (§10.5) #43-feat(metrics): wire §6.3 barrier counter into all OTLP ingest paths #51, superseding
intent-algebra-reconciliation.md's older "base = control_plane"recommendation).
StreamingConfig's pattern-match-shaped schema(
aggregation_type/aggregation_sub_type/untypedparameters: HashMap<String, Value>) with a typedBackendPlanproto that makesexact materializations (
MaterializationPayload::ExactAggregate)first-class alongside sketches — this is what closes the D1-D5 gap in
analyzer-parity-matrix.mdoncecapability_for()is fixed to planthem instead of rejecting them as
UnsupportedAggIntent.RoutingIndexindata_planethat shares control_plane'sIR/capability vocabulary directly, so the two sides can't structurally
diverge the way the current canonical analyzer and the legacy
ASAPQueryEngine::parse_and_match_promqlduplicate do today.Topology/CostModelstay pure interfaces in ASAPController core perprior scoping — all edge/gateway/OpAMP/stage-allocation code stays
exactly where it is.
Full reasoning, schema sketches, and open questions are in the doc.
Test plan
🤖 Generated with Claude Code