[Docs] Physical DAG → deployment interface in the physical planning design doc #971

Example

A backend developer wants to run rate(http_requests_total{job="api"}[5m]) from an InstallablePlan, with 1-minute panes materialized at ingestion. They read docs/design_docs/physical-planning-and-deployment.md §4–§5 to find out what to implement.

What the doc says today:

• §4 has the "Deployment Plan Compiler" diagram, RawInputSlot<Latency> and InputSlot<KllState>[5 panes], but no executor interface.
• §3 tells a runtime to feed SQL windows through TableRowSelector and PromQL windows through RawDataSampleSelector, and to bind them at the TimeRange.
• §5 says "Compiled physical plans are Planner outputs and keep their own serialized form".

None of this says which trait the backend implements, how a materialized view is bound, or what the plan file holds.

What it should say: the layers and concepts of #968.

• InstallablePlan { dag, query_texts } and materialized_views().
• Input slots: a table slot at each Scan, bound by Source, and a view slot at each materialized view, bound by node id.
• compile(dag, views, roots) and CompiledPhysicalDAG, which is executor-internal and not persisted.
• TableProvider with ScanRequest, and Bindings.
• Operators own the window, predicate and PromQL semantics; providers only read.
• The rate-query walkthrough.

Audience

Developer and designer/architect: an ASAPQuery-backend developer implementing the executor integration, and Planner/executor developers changing this boundary.

Reader question or task

"What does my deployment implement and call to install and run an ASAPPlanner plan, and what does the executor do for me?"

Required inputs and outputs

• Inputs: an InstallablePlan, and the deployment's raw data and summary store.
• Outputs: query answers at each evaluation time, and refreshed materialized views.

Scope and non-goals

• In scope: §4 rewritten as the Physical DAG → Deployment interface (layers, concepts, decisions Q1–Q5, walkthrough). The §3 selector paragraphs and the §5 "serialized form" sentence are replaced. The doc states which parts the code does not implement yet.
• Non-goals: how ASAPQuery-backend implements providers and its summary store; Stage 1–3 internals.

Verification of commands, interfaces, and examples

Every interface in the doc is either the current code on main or a target that #968's sub-issues name, and the doc marks which is which. The walkthrough's numbers (5m window, 1-minute panes) match the rate example of #968.

Existing style or terminology to follow

• The doc's existing four layers (Logical → Materialization → Physical DAG → Deployment).
• Materialization names (MatAtIngestion, MatAtQueryKeptAcrossEvaluations).
• "Materialized view" as defined in [Tracking] Physical DAG → deployment boundary: InstallablePlan, input slots, TableProvider, BindingDataSources #968.
• Design docs carry no PR numbers.

Parent: #968 (PR 1 of 6).