docs(control_plane): target architecture -- planning-time and serving-time - #425
Merged
Merged
Conversation
…-time Written independent of what's currently implemented, grounded entirely in ASAPController's own current interfaces -- specifically the `## Interface` sections added to docs/l1-query-language.md through l5-physical-plan.md in ASAPController#169 (every signature there verified against ASAPController main at cc18c98, 2026-07-28). Core claim: control_plane should be a thin planning-time shell around asap-ir/asap-l2/asap-plan/asap-sketch, contributing exactly two things ASAPController doesn't ship -- an L5 physical planner (ASAPController has no asap-physical crate; L5 is explicitly speculative there, real here) and deployment-specific L4 extension points (CostModel, Matcher). data_plane should be a thin serving-time shell implementing SummaryExecutor once. The gap table (S4) finds L2-L4 substantially already at this target (thin re-export shims, ControlPlaneCostModel, SummaryFamilyMatcher) -- the two genuinely open items are L1 (adopt asap-frontend-promql, retiring query_parser/ outright) and the serving-time cutover (SummaryExecutor is fully implemented but not yet the live path). L5 should NOT shrink -- it's this deployment's own permanent contribution, not legacy debt, precisely because no asap-physical crate exists upstream. S5 reconciles this with data_plane/docs/l4node-plan-executor-design.md (PR #409)'s open questions -- PR #169's Reduction::{Reduce(GroupKeys), PerEntity} type looks like it resolves the grouping-ambiguity question that doc flagged as blocking, via a real upstream IR signal rather than a per-deployment heuristic. Supersedes #409 with a version grounded in ASAPController's now-merged official interface docs rather than proposing/guessing at them. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
5 tasks
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
Written independent of what's currently implemented in
control_plane/data_plane, grounded entirely in ASAPController's own current interfaces — specifically the## Interfacesections added todocs/l1-query-language.mdthroughl5-physical-plan.mdin ASAPController#169 (every signature there verified against ASAPControllermainatcc18c98, 2026-07-28).Core claim:
control_planeshould be a thin planning-time shell aroundasap-ir/asap-l2/asap-plan/asap-sketch, contributing exactly two things ASAPController doesn't ship — an L5 physical planner (ASAPController has noasap-physicalcrate; L5 is explicitly speculative there, real here) and deployment-specific L4 extension points (CostModel,Matcher).data_planeshould be a thin serving-time shell implementingSummaryExecutoronce.The gap table (§4) finds L2-L4 substantially already at this target (thin re-export shims,
ControlPlaneCostModel,SummaryFamilyMatcher) — the two genuinely open items are L1 (adoptasap-frontend-promql, retiringquery_parser/outright) and the serving-time cutover (SummaryExecutoris fully implemented but not yet the live path). L5 should NOT shrink — it's this deployment's own permanent contribution, not legacy debt, precisely because noasap-physicalcrate exists upstream.§5 reconciles this with
data_plane/docs/l4node-plan-executor-design.md(#409)'s open questions — PR #169'sReduction::{Reduce(GroupKeys), PerEntity}type looks like it resolves the grouping-ambiguity question that doc flagged as blocking, via a real upstream IR signal rather than a per-deployment heuristic.Supersedes #409 with a version grounded in ASAPController's now-merged official interface docs rather than proposing/guessing at them.
Test plan
N/A — docs only, no code changes.
🤖 Generated with Claude Code