docs: match the DAG API docs to the implemented collection boundaries

Describe the two plain candidate collections, the view-based compile, the
caller-typed physical candidate errors, lifecycle_guarantee, and
PhysicalExecution as an execution handle. Remove APIs the docs said were
removed but never existed (compile_timed_candidates, PhysicalDAGCandidate),
the agent instructions in the alignment proposal's baseline, and the
ingestion-time Binary exception from design docs, where it is an
implementation detail (the developer migration guide keeps it).

Restore #485's statement that candidates do not choose placement and #508's
CandidatePostASAPDAGs<Id> names in input-output-workflow.md, rejoin the
split test table in physical-planning-and-deployment.md, and take
planner-backend-layering.md verbatim from #509.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Author: zzylol

docs/design_docs/architecture/input-output-workflow.md

@@ -30,7 +30,7 @@ fields and [frontend dependencies](#frontend-specific-dependencies).
 
 | Output | Fields or contents | Meaning |
 |---|---|---|
-| `CandidatePostASAPDAGs` | All legal logical candidates for the workload, represented compactly as canonical roots, one candidate set per target sub-DAG, and cross-target composition information | The candidate space: nothing is selected yet |
+| `CandidatePostASAPDAGs<Id>` | All legal logical candidates for the workload, represented compactly as canonical roots, one candidate set per target sub-DAG, and cross-target composition information | The candidate space: nothing is selected yet |
 | `PlanOutput` | One selected PostASAPDAG root (`Rc<PostASAPNode>`) per workload entry, optionally with summary-maintenance lifecycle decisions | One optimization pass's selection, returned by `e2e_plan` and `optimize` |
 
 `PlanOutput` is selected from the candidate space, not a second output beside
@@ -41,7 +41,9 @@ it. [Output layers](#output-layers) places both in the `PreASAPDAG` →
 DAG assembly](#selection-and-dag-assembly), and
 [summary-maintenance lifecycle](#summary-maintenance-lifecycle-aware-helper) APIs operate on this candidate collection.
 These are different uses of the candidate space, not mandatory sequential
-stages. The logical candidates have no selected summary-maintenance lifecycle.
+stages. `CandidatePostASAPDAGs` itself has no selected summary-maintenance lifecycle, and
+its candidates do not choose precompute versus query-time placement: a chosen
+lifecycle assignment sets each node's execution timing.
 
 These candidates are logical `PostASAPDAG`s. Planner also compiles
 physical candidates. Downstream systems price lifecycle assignments, bind
@@ -325,7 +327,7 @@ Additional inputs for a Planner-owned maintenance decision are listed with the
 
 ## Output
 
-### CandidatePostASAPDAGs
+### `CandidatePostASAPDAGs<Id>`
 
 The logical layer outputs `CandidatePostASAPDAGs`. The current
 Rust API represents this collection compactly as `CandidatePostASAPDAGs<Id>`; this is an
@@ -390,8 +392,8 @@ timing assignments, physical candidate generation and explicit transport exports
 |---|---|---|
 | 0. Frontends | `CandidatePreASAPDAGs` | Parse and lower PromQL, SQL, or MetricsQL; reject unsupported semantics such as PromQL `fill`. |
 | 1. Logical Post-ASAP | `CandidatePostASAPDAGs` | What to compute: summary families, rewrites, and exact candidates. No placement. `PlanOutput` is an optional library-selected logical result; deployments can enumerate candidates themselves. |
-| 2. Summary maintenance lifecycle | Lifecycle choices per unique summary state and maintained population → `CandidatePostASAPDAGs` with timing | `Ephemeral`, `Prepared`, `Shared`, or `ContinuouslyMaintained`. Each admissible assignment produces a candidate with node timing, window framework, and retention; this layer is the only source of timing. |
-| 3. Physical compilation | `CandidatePhysicalDAGs` | Compile operators and kernels once, then cut by timing into precompute and query DAGs with typed `InputContracts`. Ingestion-time Binary lowering requires matching compile-time timing. |
+| 2. Summary maintenance lifecycle | Lifecycle choices per unique summary state and maintained population → `CandidatePostASAPDAGs` with timing (`CandidatePostASAPDAGsWithTiming`) | `Ephemeral`, `Prepared`, `Shared`, or `ContinuouslyMaintained`. Each admissible assignment produces a candidate with node timing, window framework, and retention; this layer is the only source of timing. |
+| 3. Physical compilation | `CandidatePhysicalDAGs` | Compile operators and kernels once, then cut by timing into precompute and query DAGs with typed `InputContracts`. |
 | 4–5. Deployment | Deployment-owned | Prices lifecycle assignments with its own costs, including summary store cost; selects, binds, and executes. |
 
 Each layer preserves all legal candidates under the supplied constraints;

docs/design_docs/physical-planning-and-deployment.md

@@ -434,15 +434,14 @@ The lifecycle layer decides timing; physical compilation reads it. Lowering a
 node does not depend on the frontier, so each query DAG is lowered once and
 different lifecycle assignments are different cuts of that lowering.
 `compile(dag, inputs, roots)` yields the complete `PhysicalDAG`.
-`frontier_from_timing(&timed_dag)` reads an assignment's timed DAG (from
-`export_timed_dag`) and returns its frontier: ingestion-time nodes read by
+`frontier_from_timing` reads an assignment's timing (a lifecycle assignment's
+view, or a DAG from `export_timed_dag`) and returns its frontier: ingestion-time nodes read by
 query-time nodes, or an ingestion-time root; a query-time node feeding an
 ingestion-time node is rejected. `cut_candidate(&compiled, &frontier)` then
 partitions the lowered operators: the frontier's ancestors form the precompute
 DAG and the rest form the query DAG. Helper operators are numbered by their
 Planner node (`u64::MAX - (node_id << 16) - index`), so a cut is byte-identical to
-`compile_candidate` for that frontier. One exception: an ingestion-time
-`Binary` lowers differently, so its timing must match at compile time.
+`compile_candidate` for that frontier.
 `compile_candidate(s)` and `enumerate_frontiers` wrap the same path. Temporal
 pane candidates remain a separate lowering.
 
@@ -572,7 +571,6 @@ operator/runtime fixtures:
 | `summary_maintenance_lifecycle_e2e::continuous_lifecycle_compiles_and_executes_spatial_kll` | PromQL workload → selected continuous lifecycle → logical DAG → compiled precompute/query candidate → results in independent revisions; an unbounded candidate fails before pricing, and a bounded request candidate summarizes the same input samples |
 | `summary_maintenance_lifecycle_e2e::chosen_lifecycle_timing_decides_precompute_contents` | PromQL workload → enumerated lifecycles → explicit choice → timed DAG → compiled candidate; ContinuouslyMaintained stores the state in precompute, Ephemeral leaves precompute empty and reads the raw source at query time; both return the same p99 |
 | `summary_maintenance_lifecycle_e2e::lifecycle_timing_cuts_one_compilation` | KLL quantile and grouped Rate→Sum: one compilation cut by the ContinuouslyMaintained and Ephemeral timed DAGs equals `compile_candidate` for each; the frontier is the retained state or empty |
-
 | `summary_maintenance_lifecycle_e2e::chosen_population_lifecycle_decides_precompute_contents` | PromQL `topk by(job)` over a maintained population → explicit choice → timed DAG → compiled candidate; ContinuouslyMaintained stores the population in precompute, Ephemeral rebuilds it from raw samples at query time; both rank alike |
 | `summary_maintenance_lifecycle_e2e::planner_lifecycle_selection_reproduces_strategy_timing` | For PromQL summary fixtures, the timed DAG from Planner's retained selection equals the DAG realization strategies produce |
 | `kll_pane_execution::five_panes_roundtrip_and_shared_merge_runs_once` | Explicit one-minute precompute DAGs → real MessagePack state bytes → five required query inputs → shared native merge → p50/p99; counts every sample once, checks adjacent aligned windows and instruments one merge start per run |

docs/design_docs/proposals/dag-api-alignment.md

@@ -25,11 +25,8 @@ lifecycle assignments; generation does not implicitly select a winner.
 
 ## Baseline
 
-The complete implementation depends on the physical compilation and lifecycle
-integration underlying #508. Main and the original #480 documentation branch
-do not yet contain those implementations. Apply the complete refactor on that
-integration, preserving #480's documentation changes; do not merge main as part
-of this task.
+The implementation builds on the physical compilation and lifecycle APIs of the
+stack under #508; main does not contain them yet.
 
 ## Changes
 
@@ -61,8 +58,8 @@ of this task.
    identifying their timing cuts, contracts and lifecycle metadata. Reuse the
    existing cut and validation implementation. Materialize precompute/query
    execution graphs on demand, including after deployment selection. Preserve
-   separate compilations when timing changes operator lowering, notably an
-   ingestion-time Binary. Keep failures attributable to their candidates.
+   separate compilations when timing changes operator lowering. Keep failures
+   attributable to their candidates.
 6. **Update the public boundary and documentation.** Route collection APIs
    through the existing lowering, search, lifecycle and compilation algorithms.
    Preserve explicit opt-in selection helpers. Update the DAG naming table to
@@ -77,8 +74,8 @@ of this task.
 - Shared logical subgraphs retain identity through enumeration and compilation.
 - Lifecycle alternatives reuse the logical graph and assign all required node
   timing, window and retention information. Illegal timing edges are rejected.
-- Equivalent timing cuts share one compilation. Timing-dependent Binary
-  lowering remains correct and cannot reuse an incompatible realization.
+- Equivalent timing cuts share one compilation; a realization is never reused
+  for timing that lowers differently.
 - Candidate generation preserves valid alternatives and visible rejection
   reasons; candidate inspection never silently invokes winner selection.
 - Selected physical execution graphs preserve their typed producer/reader
@@ -96,49 +93,52 @@ rather than treating a rename as completion of the structural work.
 
 - Named the existing node types and shared root aliases; added frontend
   `lower_pre_asap_dag_candidates` and the ID-preserving `CandidatePreASAPDAGs` collection.
-- Added `PostASAPDAGIndex`, retaining shared node references and edge metadata.
-  Physical compilation accepts the root, index or timing assignment through a
-  borrowed projection. Transport import and direct compilation share validation
-  and operator lowering; no second rewrite implementation was introduced.
-- Added a lazy, budget-checked timed stage of `CandidatePostASAPDAGs`. Unpriced legal choices
-  retain unknown cost, and rejected combinations retain their choices and errors.
-  `execution_assignment` attaches timing to the shared index. Window and
-  retention metadata stay on the accompanying lifecycle plan; unresolved window
-  evidence remains explicit and must be supplied before deployment installation.
-- Added `compile_physical_dag_candidates` and `CandidatePhysicalDAGs<Id>`. Compatible
-  assignments share `Arc<PhysicalDAG>`; Binary timing changes produce a separate
-  compilation. Cuts materialize on demand through the existing implementation.
+- Added `PostASAPDAGIndex`, retaining shared node references and projecting
+  node and edge records once. Physical compilation takes a borrowed
+  `PostASAPDAGView` of a transport document, an index, or a lifecycle
+  assignment; an assignment's view overlays its timing on the index's records
+  instead of copying them. Transport import and direct compilation share
+  validation and operator lowering; no second rewrite implementation was introduced.
+- Added the lazy, budget-checked timed collection `CandidatePostASAPDAGsWithTiming`.
+  Unpriced legal choices retain unknown cost, and rejected combinations retain
+  their choices and errors. `execution_assignment` attaches timing to the shared
+  index. Window and retention metadata stay on the accompanying lifecycle plan;
+  unresolved window evidence remains explicit and must be supplied before
+  deployment installation.
+- Added `compile_physical_dag_candidates` and `CandidatePhysicalDAGs`. Compatible
+  assignments share `Arc<PhysicalDAG>`; timing that changes lowering produces a
+  separate compilation. Cuts materialize on demand through the existing implementation.
 - Kept explicit eager cut and winner-selection helpers for callers requesting
   them. These helpers are not the candidate-preserving generation pipeline.
 - Added regression coverage for workload entry IDs, shared logical identity,
-  assignment budgets and unknown costs, physical compilation sharing,
-  timing-dependent Binary separation, transport equivalence and rejected timing.
+  assignment budgets and unknown costs, physical compilation sharing, agreement
+  with independent compilation of each assignment's transport, and rejected timing.
 
 The Rust API migration is documented in
 [dag-api-migration.md](../../develop_docs/dag-api-migration.md). Downstream
 consumers must adopt the breaking names before repinning to this branch.
 
 ## Collection boundary completion
 
-The logical collection now has a timed stage,
-`CandidatePostASAPDAGs<Id, WithTiming<'a, Id>>`, which encapsulates the existing
-lifecycle enumerator. `with_timing_for_root` handles logical realization,
-index sharing, assignment budgets and lazy generation. Single already-assembled
-graphs use `from_post_asap_dag`. The old lifecycle enumerator is crate-private.
-
-`compile_physical_dag_candidates` consumes this timed collection directly and
-returns `CandidatePhysicalDAGs<Id>`. The physical collection owns shared graphs
-and cut descriptors; the old public `PhysicalDAGCandidate` wrapper is removed.
-The physical crate depends on the mapping crate to consume this typed boundary;
-logical search does not depend on physical compilation. Both transitions retain
-IDs, lifecycle metadata and errors. Reuse also checks contracts and requested
-roots, preventing one candidate's input boundary from contaminating another.
+The logical collection `CandidatePostASAPDAGs<Id>` and the timed collection
+`CandidatePostASAPDAGsWithTiming<'a, Id>` are separate plain types. The timed
+collection encapsulates the existing lifecycle enumerator: `with_timing_for_root`
+handles logical realization, index sharing, assignment budgets and lazy
+generation, and single already-assembled graphs use `from_post_asap_dag`. It
+also answers `lifecycle_guarantee`, so a deployment can price an alternative
+before binding it. A state without lifecycle alternatives yields a diagnostic
+entry rather than disappearing.
+
+`compile_physical_dag_candidates` consumes the timed collection's entries and
+returns `CandidatePhysicalDAGs<M, E>`, which owns shared graphs and cut
+descriptors. The metadata type `M` and the timing error type `E` belong to the
+caller, so the physical crate does not depend on lifecycle planning; a timing
+failure stays typed as `PhysicalCandidateError::Timing`, separate from
+`PhysicalCandidateError::Compile`. Both transitions retain IDs, lifecycle
+metadata and errors. Reuse also checks contracts and requested roots,
+preventing one candidate's input boundary from contaminating another.
 
 Existing explicit lifecycle selection and cut APIs delegate to the same
 implementation. No second lifecycle enumeration or operator compiler was added.
-
-Validation: `cargo test --workspace` passed 1509 tests across 91 test groups.
-`cargo clippy --workspace --all-targets -- -D warnings`, formatting and diff
-checks passed. Integration coverage exercises the two named collection
-transitions, lazy assignment generation, total budgets, retained IDs and errors,
-graph sharing, and compilation reuse across contract/root changes.
+Binding runtime sources is an execution step: `PhysicalDAG::instantiate`
+returns a `PhysicalExecution` handle for one run, not another DAG.