Function build_family_pipeline 

pub fn build_family_pipeline(
    graph: &mut Graph,
    stripped: &Ast,
    params: &[Box<str>],
    bindings: Rc<BindingSet>,
    resolve: &impl Fn(&str) -> Option<(NodeId, SourceSchema)>,
) -> Result<FamilyPipeline, BuildError>

Lower a parameterized query family (design 310 §4) into graph: one pipeline over the family’s stripped template (rindle-wire’s FamilyTemplate::stripped — the number-canonicalized AST with its holed root-equality conjuncts removed) whose params columns are a partition dimension. Compared with build_pipeline over a concrete member, the compiled pipeline differs in exactly three places:

• the root connection’s predicate is the residual where AND-ed with a membership test — row’s params tuple ∈ bindings — evaluated through the shared BindingSet handle; membership is never lowered to SQL (§4.4), so every family-root fetch is constrained by construction;
• the root limit compiles to a Take partitioned by params (per-binding top-N) that keeps drained-to-empty partitions (impl plan D4);
• the parameter columns join the root connection’s split-edit keys, so an edit that moves a row across partitions arrives as Remove(old) + Add(new), each side membership-checked (§4.3).

Everything else — related / EXISTS subqueries, start, projection — builds from the stripped AST exactly as from a concrete one; no operator below the root learns about partitions (§4.2’s disjointness argument). Drive the result with Graph::bind_family_partition / unbind_family_partition / hydrate_family.

Refused with a BuildError: an aggregate template (aggregate / group_by / having; the extraction already excludes them), no parameters, or a column bound twice. Anything the concrete member’s build would refuse is refused here the same way.