docs: ASAP primitive schema and summary coverage (definition + selection)

[zzylol]

Why

ASAP primitives (summary states such as KLL, Count-Min or exact accumulators) flow along DAG edges next to raw values. A Schema says what kind of state an edge carries, but not which data the state summarizes. So two states with identical schemas can still be wrong to merge or reuse: a KLL over latency and one over size, overlapping time windows, or the same population counted twice. The design for this was spread across several docs; this PR collects it into one design document.

What

New: docs/design_docs/proposals/asap-primitive-schema.md

Section	Content
§1 Goal	links to the LogicalDAG (#509) and operator (#511) docs; every summary operator and its status
§2 Terminology	relation, column, schema, aggregate state, materialized view, physical layout, and how ASAPPlanner uses each
§3 Schema	the schema as the DAG edge; a summary type's levels (family, category, algorithm, parameters); which aggregation intents each type answers
§4 Coverage	§4.1 Goldstein & Larson view matching (SIGMOD 2001) with a worked example. §4.2 Summary Coverage = Summary definition + selection: why there are two parts (§4.2.1), how the planner derives the definition and then the selection from the sub-DAG (§4.2.2), and what derivation costs (§4.2.3: linear in the few operators directly under the SummaryAgg, not in the sub-DAG). §4.3 what is left to the downstream deployment runtime
§5 Operators	one example per summary operator, drawn as a DAG with the schema on each edge, and a table per operator: what comes out, when it is rejected, its coverage, state or value. SummaryMerge adds allowed and rejected merges, per-family overlap rules, slice and reuse
§6 Code interfaces	ordered from the DAG node inward: OperatorNode, ASAPOp, schema and field types, summary-family parameters, update input and readouts, SummaryCoverage. Every field and function is commented, and a diagram shows how they connect

The SDS definition is left as a TODO for a separate doc.

Moved here, leaving a summary and a link behind: operator-sharing.md §2.1, pre-asap-ir.md (fields and column references), asap-aware-mapping-contracts.md (sketch family identity), physical-planning-and-deployment.md (input vs summary semantics).

Link only: decoupling_op_and_expr.md, concepts/post-asap-ir.md, univmon-frequency-summary.md and the proposals index. Links into this doc point at its current sections.

Before / after

• Before: schema and state-type design is spread over four docs, and none of them says what a summary state covers.
• After: one design doc defines it end to end, and the other docs point to it.

Related code

PR	Status	What it implements from this doc
#560	merged	SummaryMerge over children with identical schemas
#646	open	coverage derived as definition + selection; merges require equal definitions and non-overlapping selections (§4.2, §6.1, §6.6)
#592	open	per-family overlap rules (family_merges, merge_relation) (§5.6)
#601 / #604 / #628	open	window-composition panes derive their time from TimeRange + TimeShift instead of declaring it

Where the doc describes code that is not on main yet, it says which PR adds it. This PR is documentation only and based on main.

🤖 Generated with Claude Code

https://claude.ai/code/session_01W7qG9aFyPij5uWsyAJCxDW