@@ -12,7 +12,7 @@ publication, and protocol conversion. It does not maintain copies of the shared
 runtime or generic computation algorithms. JSON and Arrow conversion at the SQL
 boundary does not make Arrow the internal representation of every summary.
 
-The [shared library design](https://github.com/ProjectASAP/ASAPPlanner/blob/feat/shared-physical-operators/docs/design_docs/physical-operators.md)
+The [shared library design](https://github.com/ProjectASAP/ASAPPlanner/blob/feat/shared-physical-operators/docs/design_docs/physical-planning-and-deployment.md)
 contains the architecture and DataFusion comparison. DataFusion provides mature
 Arrow operators; ASAP's independent runtime directly owns shared producers and
 custom summary state formats. Those states need not fit Arrow RecordBatch.
@@ -135,3 +135,17 @@ results or declared approximation guarantees as appropriate.
 Local raw Scan and a universal implementation of every Planner aggregate or
 extension are not part of this migration. They must not be presented as complete
 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
+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
+to supply protocol/window inputs to the same native library. Source coverage,
+revision admission, publication and serving remain deployment responsibilities.