docs: clarify precomputation terminology and remove stale review notes

Author: zzylol

docs/01-getting-started/architecture.md

@@ -113,5 +113,5 @@ Planner/ERP inputs through shared SDS descriptors, PrecomputePlan, physical
 instances and QueryPlan. Remote-write queue admission is not durable raw-data
 commit. Finite drain and typed producer-watermark completion are different
 protocols; the sample stream does not supply an authoritative watermark.
-See [maintenance replay](../developer_docs/maintenance-replay.md) for the
+See [maintenance replay](../developer_docs/precomputation-replay.md) for the
 current durable and continuous boundaries.

docs/design_docs/README.md

@@ -9,7 +9,7 @@ integration.
   by the following three designs.
 - [Binding Planner Physical DAGs to deployment plans](asapplanner-integration.md)
   defines how backend source/state bindings and operational policy instantiate
-  Planner-provided maintenance and query computation.
+  Planner-provided precomputation and query computation.
 - [Summary definitions table and SDS](summary-catalog-sds-architecture.md) owns definition
   and instance identity, version-scoped state references, read eligibility and
   committed-state metadata.

docs/design_docs/physical-operators.md

@@ -14,7 +14,7 @@ be changed and tested together in Planner.
 The query and precompute integration PRs both use the independent ASAP DAG runtime. Deployment code binds input
 sources, storage, ingestion windows, publication and protocol outputs. Execution
 phase belongs to the physical node's data state, not the operator payload.
-Computation has the same semantics at ingestion time and query time.
+Computation has the same semantics during precomputation and query execution.
 
 Candidate pruning uses a general semi-join with explicit matching keys, followed
 by grouped Sort and grouped Limit. The completeness certificate belongs to the
@@ -39,7 +39,7 @@ the backend can execute arbitrary raw-only installed plans.
 
 Planner PR #462 owns the library and depends on Planner #461, including its
 composed candidate-pruning API. Backend #774 consumes the pinned library;
-#763 integrates ingestion DAG execution and #765 integrates query DAG execution.
+#763 integrates precomputation DAG execution and #765 integrates query DAG execution.
 The remaining backend stack builds on those integrations. #728 checks candidate
 structure, #742 checks selection with synthetic costs, and #775 checks installed
 plans against data-plane results. Production evidence and performance validation
@@ -61,7 +61,8 @@ The backend `DeploymentPlanCompiler` binds declared historical query delay to
 retention; it does not change a logical selector's lookback. Current-series
 populations retain bounded versions only when the deployment requests historical
 coverage. Their current and retained versions share the population memory budget.
-Late revisions invalidate old coverage; missing or evicted state fails explicitly.
+Changed inputs require a new output revision; an older common snapshot remains
+eligible while it satisfies freshness. Missing or evicted state fails explicitly.
 Candidate costing includes version residency, copying and retirement.
 
 Every installed range evaluation uses the shared DAG execution path and reports
@@ -78,6 +79,7 @@ its labels from the candidate side. The native join performs the comparison.
 
 Physical execution errors retain their original cause. Memory exhaustion and
 cancellation terminate both instant and range requests; routing does not try a
-second engine or exact fallback. Physical fragments in one query evaluation share
-one run context. This does not yet account for every protocol-buffer allocation
-or provide an HTTP-disconnect cancellation mechanism.
+second engine or exact fallback. All range steps and nested physical executions share one request budget and
+cancellation signal, while retaining separate execution state. Tracked inputs,
+workspace and results count against that budget; estimates are not a hard RSS
+limit. See [query execution contracts](query-dag-execution.md#request-consistency-and-resource-contracts).

docs/design_docs/query-dag-execution.md

@@ -1,9 +1,9 @@
-# Shared physical DAG execution
+# Query DAG execution
 
 ## Decision and ownership
 
 ASAPPlanner owns `asap-physical-operators`, its independent DAG runtime and the
-post-ASAP IR that defines its computation contract. Precompute engine and query
+post-ASAP IR that defines its computation contract. The precomputation engine and query
 engine consume the same library. Changes to an IR operation and its execution
 implementation can be reviewed in one Planner PR.
 
@@ -22,14 +22,14 @@ custom summary state formats. Those states need not fit Arrow RecordBatch.
 A plan is a DAG of typed operations. A producer can have multiple consumers and
 executes once per run. Each consumer sees its output independently. The runtime
 owns dependency scheduling, bounded buffering, cancellation and request-local
-caching of intermediate results. Separate query evaluation times and ingestion
+caching of intermediate results. Separate query evaluation times and precomputation
 windows have separate execution state.
 
-Every computation operation can execute at ingestion time or query time.
-The phase belongs to the plan, not the operator kind. Ingestion time includes
-background work triggered by incoming data. Sources and publication remain
-engine responsibilities; phase assignment alone does not provide a missing
-source or implementation.
+Ingestion means accepting input data. Precomputation means executing a selected
+Physical DAG before a query request, including work triggered by ingestion or
+scheduled window processing. Query execution evaluates the selected request-time
+DAG. Build, merge and readout are reusable operators; their placement belongs to
+the selected plan, not the operator kind.
 
 ```mermaid
 flowchart LR
@@ -107,42 +107,10 @@ Relation binding checks the same native implementations at installation and
 execution. Unsupported operations must be rejected explicitly. Declaring an
 external source is a separate deployment choice, not evidence of local support.
 
-This table lists each operation once. Shared computation can be used in either
-phase; the backend column identifies the available deployment bindings.
-
-| Physical operation | Purpose | Shared library implementation | Backend integration | Missing coverage |
-| --- | --- | --- | --- | --- |
-| Raw Scan | Read raw input rows | Engines can supply typed batch sources | Local raw Scan is rejected | Local raw source is explicitly deferred |
-| Read materialization | Load previously computed state | Shared decoding and delta reconstruction | Catalog/store references, population and window checks | Missing or incompatible state is a runtime error |
-| Maintain current-series state | Update values and timestamps of maintained time series | No general table update operation | Remote-write storage path | General row updates; this is not a raw-table executor |
-| Read current-series state | Read maintained current values | Typed source interface | Installed identity/capacity and time scope | Arbitrary raw-table reading |
-| Scalar | Produce a scalar | Typed source, including nullable values | Query scalar source | General ingestion literal binding |
-| Binary | Combine or compare values | Planner numeric/comparison kinds, typed expressions and checked-division domains | Query native Project; ingestion uses shared arithmetic kernels | Arbitrary vector matching and unsupported domains |
-| Unary negate | Negate a value | Int64/Float64 expression, null propagation and checked integer overflow | Query native Project | General ingestion expression binding |
-| Vector to scalar | Convert an instant vector to a scalar | Native Float64 operator; zero or multiple rows yield NaN | Query native batch binding | General ingestion value binding |
-| Exact aggregate | Compute Count/Sum/Avg/Min/Max, including ReduceSum | Native grouped aggregation; checked Int64 Sum, Float64 Sum/Avg, Int64 Count, ordered Min/Max and nullable inputs | Query vector and SQL relation bindings use shared computation | Other aggregate intents, unresolved grouping-without and per-entity relation lowering; no spill |
-| Finalize exact accumulator / ExactReadout | Obtain an exact result from state | Shared state merge/finalization and typed batch readout | Ingestion finalization and stored-query readout use shared kernels | Arbitrary state conversion and unsupported exact families |
-| Project | Select or compute output columns | Planner scalar expressions and native projection | SQL native DAG; vector expression binding | Unsupported expression functions/types |
-| Filter | Keep rows satisfying a predicate | Planner predicates, three-valued boolean logic and native filtering | SQL native DAG | Unsupported predicates/coercions |
-| Relational join, including semi-join | Match rows; semi-join retains matching left rows | Inner/left/right/full/cross/semi/anti joins; typed predicates and nullable outer outputs | SQL native DAG; candidate vectors use general semi-join with explicit keys | General ingestion source binding; SQL candidate-pruning source binding |
-| Sort | Order rows or values | Stable grouped sort with null placement | Query vector and SQL native Sort | Sort expressions must be projected first; unsupported key types; no spill |
-| Limit | Keep a bounded slice per group | Grouped offset/limit across batches | Planner grouped Limit; query vector and SQL native binding | Limit does not rank or match candidate keys |
-| Union | Combine compatible input streams | Fair polling of native input streams | Multi-input summary merge | General installed batch-source binding |
-| SummaryAgg | Construct summary state | Native builders for exact Sum/Count/Min/Max/Rate/Increase, KLL, DDSketch and HLL; other admitted families have shared update kernels | Ingestion DAG and per-window update paths | General query builder binding; native Int64/keyed updates and other batch families |
-| SummaryMerge | Combine compatible summary states | Native grouped merge and shared stored-state merge kernels | Ingestion native DAG; query selects panes and invokes shared state kernels | Cross-family conversion is not a merge; not every stored encoding has a native batch binding |
-| SummaryEstimate | Read an approximate result | Shared Planner SketchQuery dispatch; native KLL/DDSketch/HLL batch readout | Stored-state query readout uses shared kernels | Unsupported family/readout combinations; accuracy evidence remains required |
-| SummaryJoin | Combine summaries using summary join semantics | No registered implementation | Rejected | Concrete semantics and implementation |
-| SummarySubtract | Subtract summary state | No registered implementation | Rejected | Concrete semantics and implementation |
-| SummaryDelete | Remove state contributions | No registered implementation | Rejected | Concrete semantics and implementation |
-| Temporal computation | Compute Rate/Increase/Sum/Avg/Min/Max/Count over a window | Native window operator using Planner intents; reset-aware rates, Int64 Count | Query range vectors bind to native batches | Other temporal intents; general ingestion window binding |
-| Histogram quantile | Interpolate a quantile from histogram buckets | Native window operator using Planner HistogramQuantile intent | Query bucket input binds to native batches | General ingestion histogram source binding |
-| Subquery | Evaluate an expression over a time grid | Shared DAG execution and request-local caching of intermediate results | Backend binds a bounded grid of operation/evaluation-time nodes | General ingestion time-grid binding |
-| Extension | Execute an additional operation | No universal executor | Unsupported extensions are rejected | A registered implementation for each admitted extension |
-
-Stored-state codecs and readout kernels are library capabilities; they do not
-imply that every family has a native batch builder. Parameter, schema, population
-and window compatibility remain mandatory. Availability of an approximate
-kernel does not prove its accuracy guarantee.
+Operator support belongs to the [Planner library contract](physical-operators.md),
+not a second backend operator matrix. Deployment acceptance additionally requires
+compatible typed inputs, stored-state formats, grouping, windows, and accuracy
+evidence. A library kernel alone does not establish deployment feasibility.
 
 ## Candidate pruning and grouped ranking
 
@@ -189,13 +157,13 @@ through fallback routing or by tests supplied with already decoded raw batches.
 ## Planner compilation and deployment binding
 
 The backend `DeploymentPlanCompiler` establishes state identities, window contracts
-and query/precompute bindings. ASAPPlanner #462 owns `physical_planner`, native
+and query and precomputation bindings. ASAPPlanner #462 owns `physical_planner`, native
 operators and DAG execution. Its compiler accepts typed input contracts without
 live readers and produces `CompiledPhysicalDag`; instantiation binds inputs and
 checks their properties without repeating operator lowering.
 
 The SQL relation adapter composes Planner-compiled operators into that reusable
 physical representation before reading storage, then resolves typed inputs and
-instantiates the selected graph. PromQL vector and maintenance adapters continue
+instantiates the selected graph. PromQL vector and precomputation adapters continue
 to supply protocol/window inputs to the same native library. Source coverage,
 revision admission, publication and serving remain deployment responsibilities.

docs/developer_docs/control-plane/physical-compiler.md

@@ -42,7 +42,7 @@ for every target collector. Legacy
 they are not a second semantic planner.
 
 ASAPPlanner owns semantics and physical candidate construction, including summary
-families, maintenance lifecycles and physical boundaries. Backend evaluates
+families, precomputation update lifecycles and physical boundaries. Backend evaluates
 candidate feasibility and complete workload-scoped costs, then selects and binds
 the deployment without changing its computation.
 Missing or stale implementation evidence makes the candidate unavailable; the
@@ -117,7 +117,7 @@ Why this interface exists: it prevents adapters, protocols, and physical
 planning from each implementing their own query-to-summary mapping.
 
 Snapshot and HTTP adapters provide the same `WindowCostModel`. After logical
-selection, one generator enumerates layouts allowed by each state's maintenance
+selection, one generator enumerates layouts allowed by each state's precomputation
 requirements and deployment target, then derives or matches layout-specific costs.
 See [repeated window planning](../planning/repeated-dashboard-panes.md) for inputs,
 migration and cadence examples.
@@ -228,8 +228,9 @@ Graph traversal is separate from node definitions and store semantics.
 Activation validates roots, edges, bindings, reachability, and cycles.
 The shared physical DAG runtime creates one producer per reachable node and
 shares its outputs with bounded buffering within the request,
-so a shared node in a diamond DAG performs one store/operator execution. A
-typed node failure follows the entry's explicit fallback route.
+so a shared node in a diamond DAG performs one store/operator execution. Only an
+eligible availability failure follows the entry's explicit fallback route.
+Resource exhaustion and cancellation terminate execution without fallback.
 
 ### What the compiler puts in CollectorPlan