In algorithm selection, Oracle‑style metrics such as virtual best solvers, selected‑portfolio VBS, virtual‑best encodings, and best‑in‑family summaries are commonly reported as upper bounds for any deployable selector. In a decomposed algorithm selection pipeline, a partition‑level score provides an Oracle choice of the best algorithm within the chosen family; once the family selector is fixed, the actual system must replace that Oracle with a learned within‑family selector. We define the deployment‑fidelity gap $G(R)$ as the difference between the partition‑level utility and the end‑to‑end deployable utility. Two accounting consequences follow: (1) a per‑instance margin‑regret stability condition that indicates when a partition‑time family choice is already deployment‑optimal; (2) a sharp partition‑only identification interval that, when it strictly crosses zero, shows that the partition report cannot certify the deployable winner. Experiments on five public algorithm‑selection benchmarks (covering tabular AutoML and combinatorial CSP/SAT) reveal positive $G(R)$ for every decomposed pipeline, ranging from 0.012 on TabZilla to 0.13 on PROTEUS‑2014. Among ten decomposed‑vs‑flat decisions, four have sign‑changing point estimates; on PROTEUS‑2014 a 33‑point partition advantage shrinks to a 20‑point end‑to‑end advantage. A training‑side validation gap‑correction diagnostic recovers the deployable sign in all four sign‑changing cells; it serves as a reporting aid, not a substitute for direct end‑to‑end evaluation. Partition and end‑to‑end scores should be reported side by side.
Review