Algorithm Portfolio Router¶
Routing rule — instantiates Problem-Distribution Fit Selection
Keeps a registry of methods and, case by case, dispatches each instance to the member whose bias fits that instance's regime — turning 'pick one winner' into 'pick the right specialist for this case,' and re-routing as the regime shifts.
If no single method dominates across a heterogeneous problem stream, the answer need not be to choose one anyway. Algorithm Portfolio Router declines the choice. It keeps a live portfolio of methods and, for each incoming instance, dispatches it to the member predicted best for that instance's features — then re-routes, or retunes a member, when the mix of instances drifts into a new regime. What sets it apart from every sibling is that it is the one mechanism that does not select a single method: it operationalizes "different biases for different regimes" as a standing routing rule over a registry, so the portfolio as a whole can beat any of its members averaged over the real workload.
Example¶
A logistics company solves vehicle-routing problems all day, and the instances vary enormously — small dense urban clusters, huge sparse rural runs, tight delivery windows against loose ones. No single solver wins across that range. A greedy insertion heuristic returns good routes for small instances in milliseconds; an exact mixed-integer solver is best on small-but-tightly-constrained instances yet explodes combinatorially on large ones; a large-neighborhood-search metaheuristic dominates the big messy cases but is overkill on the small ones.
The router reads each instance's features — node count, geographic density, window tightness — and dispatches it to the predicted-best solver, falling back to the metaheuristic whenever a chosen solver blows its time budget. When holiday volume shifts the instance mix toward large sparse runs, the switching trigger promotes that metaheuristic to default. Measured over the real instance stream, the portfolio beats every individual solver run alone — the gain no single-winner choice could have captured.
How it works¶
The distinguishing element is per-instance dispatch over a registry, with regime-triggered switching, rather than a one-time selection. The router maintains a registry of methods each tagged with its bias and scope profile; it featurizes every incoming instance; a selector — hand-written rules or a learned meta-model mapping features to the best method — picks the member whose profile fits; it runs that member under a time budget with a robust fallback; and it watches the instance stream so that a switch-or-retune trigger fires when the regime drifts. Selection here is per-case, continuous, and reversible, which is precisely what a single benchmark winner is not.
Tuning parameters¶
- Routing granularity — whether dispatch happens per instance, per batch, or per broad regime. Finer routing extracts more performance but demands a good selector and cheap feature extraction.
- Selector model — hand rules versus a learned mapping from instance features to best method. A learned selector adapts to subtle regime structure but needs training data and can itself overfit the historical instance mix.
- Switch-trigger sensitivity — how much regime drift is required before re-routing or retuning. A twitchy trigger thrashes between members; a sluggish one keeps serving a stale specialist after the regime has moved.
- Portfolio breadth — how many methods are kept live. More members cover more regimes but multiply maintenance and selector complexity, and a member that is never the best is pure carrying cost.
- Fallback policy — what happens when the chosen method exceeds its budget or the instance is unrecognized. Defaulting to a robust generalist keeps the system safe on the cases the selector gets wrong.
When it helps, and when it misleads¶
Its strength is capturing performance no single method can reach when the workload genuinely contains distinguishable regimes, handling heterogeneous and multi-modal distributions gracefully, and degrading softly through its fallback when a route is misjudged.
Its failure modes track its assumptions. The router only helps if regimes are actually distinguishable from observable features — where they are not, the selector adds cost and misrouting error over simply committing to one robust default, and a learned selector can overfit the historical mix and confidently mis-route novel instances. Its classic misuse is portfolio bloat: adding members to look sophisticated when one robust method would serve, or routing on a feature that secretly leaks the answer. The discipline is to prove the router beats the single best method on held-out instances before shipping it, and to monitor per-regime routing accuracy so a decayed selector is caught.[1]
How it implements the components¶
method_portfolio_registry— the router maintains exactly this: the live registry of candidate methods, each annotated with the regime and bias profile that governs when it is selected.retuning_or_switching_trigger— the regime-drift trigger that promotes a new default, re-routes traffic, or retunes a member is this component, wired directly into the dispatch loop.
It does not itself detect the distribution shift it reacts to — that signal comes from the Out-of-Distribution Monitor — and it does not profile each member's bias; it consumes those profiles from the Method Bias Matrix to route.
Related¶
- Instantiates: Problem-Distribution Fit Selection — the runtime answer to no-free-lunch, matching a specialist to each case instead of anointing one winner.
- Consumes: Out-of-Distribution Monitor supplies the shift signal that fires the switching trigger; the Method Bias Matrix supplies the per-method fit profiles the registry holds.
- Sibling mechanisms: Out-of-Distribution Monitor · Method Bias Matrix · Problem Distribution Profile · Assumption Register · Regularization Path Review · Baseline Comparison Table · Challenge Case Red Team · Stratified Benchmark Suite · No-Universal-Winner Claim Review · Method Card or Model Card · Benchmark Refresh Audit
Editorial Notes¶
Form Classification¶
Form family: Control, Automation & Runtime
Rationale: Keeps a registry of methods and, case by case, dispatches each instance to the member whose bias fits that instance's regime — turning 'pick one winner' into 'pick the right specialist for this case,' and re-routing as the regime shifts, making its operative form a state-dependent executable control that senses, filters, routes, or actuates during operation.
Independent corroboration: The frozen evidence defines Algorithm Portfolio Router as 'Keeps a registry of methods and, case by case, dispatches each instance to the member whose bias fits that instance's regime — turning 'pick one winner' into 'pick the right specialist for this case,' and re-routing as the regime shifts', so its operative form is Control, Automation & Runtime.
Nearest alternative: Decision, Gate & Allocation — It dispatches every live instance and re-routes on regime shifts rather than making a single bounded assignment.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Algorithm portfolios and per-instance algorithm selection were formalized in artificial intelligence and constraint-solving research.
Related originating lineages:
- Data Science & Analytics — Meta-learning and predictive routing operationalize case-by-case method selection.
- Operations Research — Optimization supplies many portfolio members and instance-regime models.
Review resolution: Software algorithm selection is primary, while operations research and data science materially shape portfolio choice and performance routing. Combining those established practices makes the mechanism cross-disciplinary and multi-domain, without implying historical ambiguity.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
The router is the only mechanism here that keeps several methods live at once, so it inherits the full maintenance burden of every member in the portfolio — retraining, monitoring, and dependency upkeep for all of them. That carrying cost is real, and a portfolio is justified only when its gain over the best single method clearly exceeds it; otherwise the honest move is to retire members down to the one that pays its way.
References¶
[1] The algorithm selection problem, framed by John Rice in 1976, asks which algorithm from a set will perform best on a given problem instance given its features — the formal core of what a portfolio router operationalizes at runtime, and a direct constructive response to the absence of a single dominant method. withdrawn registry ↩