Context
While migrating ASAPQuery-backend's `control_plane` off its own locally-defined L4 IR (`PhysicalExpr`) onto `asap_sketch::{SummaryExpr, L4Node}` + `asap_plan::bind::implement_tree_in_with` (a "plan-shaped serving" migration), we hit a real coverage gap.
`control_plane` has a deployment-specific point-frequency query (`count(*) WHERE key = k`) expressed via `AggIntent::Extension { ext_kind: "frequency", .. }` — the generic escape hatch documented in `crates/ir`'s `AggIntent` for exactly this "core doesn't know this shape" case.
`crates/plan/src/boundary.rs`'s `implementation_for` maps every `Extension` to `Implementation::PassThrough` unconditionally:
```rust
// ── Extension (deployment-model-specific, issue #131) — core has no
// realization opinion for a shape it doesn't know. The owning
// deployment model is expected to bind it via its own L4 rules
// before this generic boundary pass ever sees it; if one reaches
// here unbound, pass it through rather than guessing.
AggIntent::Extension { .. } => Implementation::PassThrough,
```
This is by design (per the comment), and the doc is correct that core can't guess the realization for an opaque, deployment-tagged payload. But it means there's currently no extension point at all for a deployment to plug in its own `Extension`-shape realization when it wants to use `implement_tree_in_with`'s tree walk (schema derivation, `col`/`by` computation, DAG construction) rather than forking the whole L3→L4 binder just to handle one extra intent shape.
Request
Consider a pluggable hook for `Extension` realization — something in the shape of `CostModel` (issue-free extension point, no default implementation, deployment supplies its own): e.g. a trait method `fn realize_extension(&self, ext_kind: &str, payload: &serde_json::Value, accuracy: &AccuracyTarget) -> Implementation`, consulted by `implementation_for_with` only for the `Extension` arm, defaulting to `PassThrough` when unset (preserving today's behavior for every deployment that doesn't need it).
What we did instead (for now)
`control_plane` currently intercepts `Extension`-shaped `Aggregate` nodes before calling `implement_tree_in_with`, and simply drops the sketch-binding for that one contract-row demo metric (`endpoint_request_freq`) — a real, accepted coverage regression versus its previous locally-defined `Bind*` rule, tracked as a known gap pending this issue.
References
Context
While migrating ASAPQuery-backend's `control_plane` off its own locally-defined L4 IR (`PhysicalExpr`) onto `asap_sketch::{SummaryExpr, L4Node}` + `asap_plan::bind::implement_tree_in_with` (a "plan-shaped serving" migration), we hit a real coverage gap.
`control_plane` has a deployment-specific point-frequency query (`count(*) WHERE key = k`) expressed via `AggIntent::Extension { ext_kind: "frequency", .. }` — the generic escape hatch documented in `crates/ir`'s `AggIntent` for exactly this "core doesn't know this shape" case.
`crates/plan/src/boundary.rs`'s `implementation_for` maps every `Extension` to `Implementation::PassThrough` unconditionally:
```rust
// ── Extension (deployment-model-specific, issue #131) — core has no
// realization opinion for a shape it doesn't know. The owning
// deployment model is expected to bind it via its own L4 rules
// before this generic boundary pass ever sees it; if one reaches
// here unbound, pass it through rather than guessing.
AggIntent::Extension { .. } => Implementation::PassThrough,
```
This is by design (per the comment), and the doc is correct that core can't guess the realization for an opaque, deployment-tagged payload. But it means there's currently no extension point at all for a deployment to plug in its own `Extension`-shape realization when it wants to use `implement_tree_in_with`'s tree walk (schema derivation, `col`/`by` computation, DAG construction) rather than forking the whole L3→L4 binder just to handle one extra intent shape.
Request
Consider a pluggable hook for `Extension` realization — something in the shape of `CostModel` (issue-free extension point, no default implementation, deployment supplies its own): e.g. a trait method `fn realize_extension(&self, ext_kind: &str, payload: &serde_json::Value, accuracy: &AccuracyTarget) -> Implementation`, consulted by `implementation_for_with` only for the `Extension` arm, defaulting to `PassThrough` when unset (preserving today's behavior for every deployment that doesn't need it).
What we did instead (for now)
`control_plane` currently intercepts `Extension`-shaped `Aggregate` nodes before calling `implement_tree_in_with`, and simply drops the sketch-binding for that one contract-row demo metric (`endpoint_request_freq`) — a real, accepted coverage regression versus its previous locally-defined `Bind*` rule, tracked as a known gap pending this issue.
References