Algorithms

DispatchAtlas separates solver behavior from benchmark generation and campaign execution. Every solver lives in dispatchatlas.solve behind one registry, and solver metadata is the public contract for objectives, capabilities, encodings, dependencies, stochasticity, evidence-tier visibility, and optional backends. This page explains the solver families at a working level; the solver system registry page is the authoritative per-solver catalog.

🏗️ How Solvers Are Organized

default_solver_registry() returns the registry of stateless solver factories. Each entry declares capability tags, supported objectives, default stop criteria, deterministic or seeded-stochastic replay behavior, a solution encoding, optional-dependency requirements, evidence-tier visibility, and a canonical citation (or an explicit citation-not-applicable rationale). Citations fail closed: a family with a canonical seminal origin that omits its reference cannot be constructed.

🧰 Solver Families

📋 Constructive dispatching rules

The bundled deterministic baselines are constructive list-scheduling solvers: each controls task order, and the serial constructor honors every task's declared resource demands. The eight families — earliest-start, shortest-processing-time, longest-processing-time, earliest-deadline, earliest-finish-time, minimum-slack, greedy-completion, and apparent-tardiness-cost — each name their canonical seminal reference in metadata. They are the fastest path to a feasible schedule and anchor every comparison, as in the first tutorial.

🔀 Metaheuristic baselines

Five representative seeded metaheuristics — genetic algorithm, simulated annealing, ant colony, particle swarm, and differential evolution — share the same feasibility, repair, scoring, and local-search operators, so a comparison measures search strategy rather than incidental plumbing differences.

🔌 Encoded adapter solvers

Comprehensive-learning particle swarm (clpso, d-clpso) and success-history adaptive differential evolution (lshade, d-lshade) search a continuous real-valued vector with one component per task. Each core is generic over a continuous objective and is bound to scheduling through a named encoding adapter (random-key, spv, rounding, and the transfer-function decodes) that turns a vector into a precedence-feasible task order, with an explicit repair policy that records whether repair fired.

🥊 Diversified competitors and the many-objective lane

A curated set of recent published peers broadens the comparison beyond the representative baselines, each carrying its full-text reference, strengths, and caveats in metadata. A peer joins the public field only when it clears a source-grounded venue-strength bar; a broader pool of classical baselines stays registered for internal comparison. nsga3 is the named many-objective competitor: it evaluates each precedence-safe order on a multi-objective vector (makespan, lateness, load fairness) and selects survivors by reference-point niching.

🎯 Exact adapters

Optional-backend adapters (CP-SAT, MILP, branch-and-bound) declare an optional dependency and probe its import root at runtime; when the backend is absent they raise MissingOptionalDependencyError with the extra name and licensing note instead of importing a heavyweight dependency at package import. Native-bounded adapters (exhaustive-enumeration and decision-diagram-sequencing) carry no third-party dependency and solve small instances exactly, raising UnsupportedCapabilityError past the supported task count. The commercial Gurobi wrapper stays behind the exact-commercial extra and is never bundled; a broader pool of optional backends stays registered for internal use.

🐝 The NDSO Family

NDSO is the registry's native-encoding solver family: it searches directly over feasible schedules, so every schedule it produces is feasible by construction and the family never runs an encode/decode step or a repair pass. It composes a small set of named mechanisms:

• a Confidence Matrix of learned trust per (position, task) cell, reinforced by better schedules;
• Confidence-Weighted Voting, which synthesizes the elite schedule by voting across the population weighted by that matrix;
• Quantity-and-Quality schedules that set how much a candidate changes and which guidance source it learns from;
• three-source guidance — the synthesized elite (exploitation), a peer (diversity), or a vanished-knowledge source (radical exploration);
• a unified adaptive coefficient, one non-linear schedule that shifts the family from exploration to exploitation.

An ablation map enumerates one isolating configuration per named mechanism so downstream analysis can attribute each mechanism's contribution, and a staged export filter fails closed rather than exposing a later-tier mechanism under a lower report scope. The full mechanism, council, ablation, and diagnostics detail lives in solver system; no performance claim is made before the comparative campaigns run.

🎛️ Selection

SolverRegistry.select matches solvers by capability tags, declared constraints, supported objective, and evidence-tier visibility — the quick start's registry.select(objective="makespan", disclosure_label=DisclosureLabel.CORE) is the smallest example. Above the registry, the selection layer ranks solvers for a problem from characterization features and public metadata, labels each recommendation by its source and confidence, and never claims a universal best solver. The solver recommender presents those explanations, including why a solver was excluded.