docs: take node timing from lifecycle assignment in the flattening proposal

[zzylol]

Why

The owner-approved planner layering (#480, "Output layers") makes the summary maintenance lifecycle layer the only source of execution timing: logical Post-ASAP / PlanSpace decides what to compute, the lifecycle layer decides placement, physical compilation splits by timing, and the deployment prices lifecycle assignments. The flattening proposal merged in #469 instead derived timing from operator kinds with derive_timings.

What

Docs only, docs/design_docs/proposals/operator-sharing.md:

• derive_timings / derive_timings_at → apply_lifecycle_timings(root, &LifecycleAssignment, memo). The timing slot stays; Unset means no assignment applied, and export rejects it.

• Validity checks (e.g. ingestion work cannot depend on a query-time result) become validation of the applied assignment (§2.3, §4, §5).

• Notes that some logical candidates hard-code timing today (exact-composition placements, maintained populations, feat: expose physical-ready logical candidates in Planner selection #472's Rate→Sum pair); they become lifecycle choices.

• Stage table: stage 4 applies current timing as the initial assignment; stage 5 switches to lifecycle-applied timing; stage 6 removes the fallbacks. Tests and open questions updated.

• derive_guarantees is unchanged. decoupling_op_and_expr.md does not mention timing, so it is not changed.

• §6 export: replace "largest connected non-ASAP subtree as one Relational fragment (with DagInput leaves)" with one post-ASAP node per non-ASAP operator; children become edges. Physical compilation then corresponds node by node (a node may expand to helper operators numbered from it). Tests and consumer table updated accordingly.

• Wording: the timing source is "physical design (summary materialization)", matching docs: propose workload-wide planning, summary sharing, and materialization #509; the LifecycleAssignment open question now points to SummaryMaintenanceLifecyclePlan / execution_timed_dag() from feat: derive execution timing from a summary lifecycle plan #482.

Before this PR

derive_timings runs on each assembled root, sharing one memo, top-down: a root is query time, a set node keeps its value, a node of fixed kind takes that kind's time, and every other node takes its parent's.

Stage 4: … copying each node's guarantee and today's derived timing into the slots …

After this PR

The summary maintenance lifecycle layer chooses a lifecycle per unique summary state; a chosen assignment determines every node's timing … It is the only source of timing. apply_lifecycle_timings writes the assignment into the slots … Unset means no assignment has been applied; physical compilation and export reject it.

Stage 4: … copying each node's guarantee into its slot and applying each node's current timing as the initial lifecycle assignment …

Related

#469 (original proposal), #480 (output layers), #476

🤖 Generated with Claude Code

[zzylol]

On the open question about LifecycleAssignment: #482 answers it with the existing type. A chosen assignment is a SummaryMaintenanceLifecyclePlan (from #476's SummaryMaintenanceLifecycleCandidates::select), and SummaryMaintenanceLifecyclePlan::execution_timed_dag() turns the per-state choice into per-node timing. This proposal could name those instead of a new LifecycleAssignment type.

[Selvomega]

Please don't merge this PR. I will update my design doc based on this PR as well as recent updates in main

[zzylol]

@Selvomega given the new planner architecture design and #511, this PR can be closed.