MILP-Evo: Closed-Loop Fully Automatic Design of MILP Solvers

# MILP-Evo: Closed-Loop Fully Automatic Design of MILP Solvers
Source: [https://arxiv.org/html/2607.18252](https://arxiv.org/html/2607.18252)
Jinbiao Nie1,2Kewei Feng3,2Xiaoyuan Zhang2Shan Yin1Zizhuo Wang4Bin Dong2,5 1BUPT2BZA3BIT4CUHK\-Shenzhen5PKU

###### Abstract

Machine learning methods have shown that data\-driven policies can accelerate mixed\-integer linear programming \(MILP\) solvers, but many such approaches remain difficult to inspect, adapt, and deploy because the learned policy is represented as an external predictor or other opaque model\. By contrast, explicit solver logic is easier to understand and integrate, but is usually hand\-designed rather than learned from solver feedback\. We study whether the automatic design of MILP solver logic can instead be cast as LLM\-guided closed\-loop search over executable white\-box components evaluated directly by end\-to\-end solver behavior\. To this end, we propose a closed\-loop program evolution framework for MILP solver auto\-design, implemented through PySCIPOpt, and instantiate it on the joint design of a cut selector and a branching rule\. Candidate programs are iteratively generated, loaded into SCIP, and evaluated by direct execution on MILP instances, with the resulting feedback guiding performance\-based selection, targeted repair, diagnostic reflection, and diversity\-aware population maintenance\. The method outputs explicit solver components that can be inspected, modified, and deployed within standard solver workflows\. Across four benchmark families, we find that LLM\-guided program evolution can discover competitive domain\-specialized policies in several settings\.

## 1Introduction

Combinatorial optimization \(CO\) is a foundational and challenging area of mathematical optimization, with applications ranging from production planning and distribution scheduling to chip design\(Liuet al\.,[2008](https://arxiv.org/html/2607.18252#bib.bib7); Chen,[2010](https://arxiv.org/html/2607.18252#bib.bib8); Maet al\.,[2019](https://arxiv.org/html/2607.18252#bib.bib9)\)\. Many exact CO tasks are naturally modeled as mixed\-integer linear programs \(MILPs\), a standard language for industrial and benchmark optimization instances\(Bengioet al\.,[2021](https://arxiv.org/html/2607.18252#bib.bib2); Gleixneret al\.,[2021](https://arxiv.org/html/2607.18252#bib.bib3)\)\. Because broad classes of MILPs are NP\-hard, the practical value of exact optimization depends heavily on the efficiency of modern solvers\. Such solvers build on branch\-and\-bound \(B&B\) and branch\-and\-cut, combining tree search with cutting planes, presolve, primal heuristics, and other internal mechanisms to obtain certifiably optimal solutions\(Achterberg,[2009](https://arxiv.org/html/2607.18252#bib.bib1)\)\.

Modern MILP solvers have historically relied on human\-designed policies for these decisions\. Such policies are widely deployed because they are compact, efficient, reliable, and naturally integrated into solver workflows\. For example, branching and cut selection rules are often implemented as hard\-coded scoring functions or carefully engineered procedures that reflect decades of optimization expertise\. However, designing these policies requires substantial expert knowledge and manual tuning, and generic rules may miss distribution\-specific structure in recurring problem families\(Bengioet al\.,[2021](https://arxiv.org/html/2607.18252#bib.bib2); Lodi and Zarpellon,[2017](https://arxiv.org/html/2607.18252#bib.bib4); Kuanget al\.,[2024a](https://arxiv.org/html/2607.18252#bib.bib21)\)\. This tension has motivated a growing body of learning\-based work that replaces or augments individual solver decisions with data\-driven policies, especially for branching\(Gasseet al\.,[2019](https://arxiv.org/html/2607.18252#bib.bib6); Guptaet al\.,[2020](https://arxiv.org/html/2607.18252#bib.bib10); Linet al\.,[2024](https://arxiv.org/html/2607.18252#bib.bib18)\), cut management\(Huanget al\.,[2022](https://arxiv.org/html/2607.18252#bib.bib11); Pauluset al\.,[2022](https://arxiv.org/html/2607.18252#bib.bib12); Turneret al\.,[2023](https://arxiv.org/html/2607.18252#bib.bib23); Wanget al\.,[2023](https://arxiv.org/html/2607.18252#bib.bib13); Liet al\.,[2023](https://arxiv.org/html/2607.18252#bib.bib14); Puigdemontet al\.,[2024](https://arxiv.org/html/2607.18252#bib.bib15)\), and other modules such as diving heuristics and presolving\(Paulus and Krause,[2023](https://arxiv.org/html/2607.18252#bib.bib16); Liuet al\.,[2024a](https://arxiv.org/html/2607.18252#bib.bib17)\)\.

Although learned policies can improve solving efficiency on problem distributions with shared structure, many of them are implemented as external neural or graph\-neural predictors\. This introduces a different set of challenges: the learned decision logic can be difficult to interpret, may require nontrivial training and inference infrastructure, and is not always easy to deploy as a native part of a production solver\. Recent work has begun to address this issue by learning more explicit and interpretable solver policies\. In particular, symbolic\-policy methods such as Symb4CO and GS4CO learn compact branching rules that are lightweight, interpretable, and closer in spirit to traditional solver heuristics\(Kuanget al\.,[2024a](https://arxiv.org/html/2607.18252#bib.bib21),[b](https://arxiv.org/html/2607.18252#bib.bib22)\)\. These works suggest that automatic algorithm discovery can produce white\-box solver policies rather than only black\-box predictors\. However, existing interpretable approaches still primarily focus on a single solver module, most notably branching, and often optimize a policy through imitation or proxy objectives rather than through direct end\-to\-end solver execution\. Recent work has also begun to study coupled B&B decisions such as node and variable selection jointly\(Duet al\.,[2025](https://arxiv.org/html/2607.18252#bib.bib26)\), but the broader question remains: Can LLMs directly search over executable solver logic, using end\-to\-end solver feedback to optimize interacting MILP components rather than separate predictors or isolated learned rules?

This paper studies this question through LLM\-guided executable search over solver programs implemented via PySCIPOpt\. We focus on branching and cut selection as a practical testbed for this setting\. Beyond their individual importance, these two components interact naturally within B&B\-based MILP solving: branching shapes the evolving search tree and LP contexts in which cuts are generated and applied, while cut selection changes bound progress, LP relaxations, and the candidate states seen by later branching decisions\. Both are also accessible through direct PySCIPOpt implementation, making them suitable for studying end\-to\-end code\-level search under realistic solver constraints\. Our framework uses an LLM to propose, mutate, repair, and reflect on candidate solver programs, but uses SCIP execution rather than LLM self\-assessment to determine their quality\. Each candidate is loaded into SCIP through PySCIPOpt\(Maheret al\.,[2016](https://arxiv.org/html/2607.18252#bib.bib5); Achterberg,[2009](https://arxiv.org/html/2607.18252#bib.bib1)\), evaluated by end\-to\-end solving behavior, and constrained by solver\-interface validity\. The output is an explicit code artifact with concrete control logic, making the resulting solver behavior easier to inspect, debug, modify, and deploy as a native solver component\. We study this framework on four learn2branch problem families: set cover, combinatorial auctions, facility location, and independent set\.

Our contributions are: \(i\) we formulate MILP solver\-component auto\-design as LLM\-guided closed\-loop search over executable PySCIPOpt callback components evaluated by end\-to\-end SCIP execution; \(ii\) we instantiate this formulation for the joint design of cut selection and branching rules, two interacting decisions in branch\-and\-cut search; \(iii\) we introduce an execution\-guided evolutionary loop combining program proposal, targeted repair, diagnostic reflection, performance\-based selection, and diversity\-aware population maintenance under solver\-interface constraints; \(iv\) we evaluate the discovered components on four learn2branch benchmark families—set cover, combinatorial auctions, facility location, and independent set—and show competitive domain\-specialized performance in several settings\.

## 2Related Work

### 2\.1MILP Solver Learning

Learning\-augmented MILP solvers replace hand\-designed components of branch\-and\-cut with policies trained from solver data\. The most established line studies variable branching: GNN policies over the variable\-constraint bipartite graph made it possible to imitate strong branching on recurring MILP distributions\(Gasseet al\.,[2019](https://arxiv.org/html/2607.18252#bib.bib6)\), while later methods reduce deployment cost or improve sample efficiency and transfer through hybrid inference and contrastive augmentation\(Guptaet al\.,[2020](https://arxiv.org/html/2607.18252#bib.bib10); Linet al\.,[2024](https://arxiv.org/html/2607.18252#bib.bib18)\)\. A parallel line studies cutting\-plane decisions\. Early learned cut selectors rank local candidate cuts, often with imitation or lookahead signals\(Huanget al\.,[2022](https://arxiv.org/html/2607.18252#bib.bib11); Pauluset al\.,[2022](https://arxiv.org/html/2607.18252#bib.bib12)\); more recent work broadens the control surface to separator configuration, cut removal, hierarchical cut selection, and global cut selection across the branch\-and\-cut tree\(Turneret al\.,[2023](https://arxiv.org/html/2607.18252#bib.bib23); Wanget al\.,[2023](https://arxiv.org/html/2607.18252#bib.bib13); Liet al\.,[2023](https://arxiv.org/html/2607.18252#bib.bib14); Puigdemontet al\.,[2024](https://arxiv.org/html/2607.18252#bib.bib15); Zenget al\.,[2025](https://arxiv.org/html/2607.18252#bib.bib27)\)\. These methods show that solver decisions expose learnable structure, but the learned object is typically a predictor or policy attached to one decision interface\.

Recent work has also moved beyond isolated branching toward broader learned B&B control\. Symbolic\-policy methods such as Symb4CO and GS4CO learn compact branching rules that are closer to traditional solver heuristics than opaque neural predictors\(Kuanget al\.,[2024a](https://arxiv.org/html/2607.18252#bib.bib21),[b](https://arxiv.org/html/2607.18252#bib.bib22)\)\. Other approaches learn coupled decisions, such as node and variable selection\(Duet al\.,[2025](https://arxiv.org/html/2607.18252#bib.bib26)\), or represent the entire B&B tree to select search nodes with reinforcement learning\(Zhanget al\.,[2025](https://arxiv.org/html/2607.18252#bib.bib28)\)\. This progression is important for our setting because branching, node selection, and cut management interact through the solver trajectory rather than through independent one\-step decisions\. However, these works still primarily optimize learned decision models or symbolic formulas, whereas our goal is to search directly over executable callback code that jointly implements interacting solver modules\.

LLMs have recently entered MILP research through complementary routes\. MILP\-Evolve uses an LLM\-based evolutionary process to generate diverse MILP problem classes, enabling foundation\-model training for integrality\-gap prediction, learning to branch, and instance\-text alignment across problem families\(Liet al\.,[2024](https://arxiv.org/html/2607.18252#bib.bib29)\)\. LLM\-LNS instead uses a dual\-layer self\-evolutionary LLM agent to design neighborhood\-selection strategies for large\-neighborhood search on large\-scale MILPs\(Yeet al\.,[2025](https://arxiv.org/html/2607.18252#bib.bib30)\)\. These studies suggest that LLMs can help expose optimization structure and synthesize useful solver heuristics\. Our work differs in the target of the search: rather than generating training instances or controlling an LNS repair heuristic, we use LLM\-guided execution feedback to evolve native PySCIPOpt branch\-and\-cut callbacks that run inside SCIP\.

### 2\.2Automatic Design

Evaluator\-in\-the\-loop program search has emerged as a general mechanism for discovering executable heuristics and algorithms\. FunSearch demonstrates that an LLM can propose small programs whose quality is determined by external execution rather than self\-assessment\(Romera\-Paredeset al\.,[2024](https://arxiv.org/html/2607.18252#bib.bib19)\)\. Evolution of Heuristics and ReEvo adapt this idea to heuristic design by combining LLM mutation, selection, and reflective feedback over populations of candidate algorithms\(Liuet al\.,[2024b](https://arxiv.org/html/2607.18252#bib.bib24); Yeet al\.,[2024](https://arxiv.org/html/2607.18252#bib.bib25)\), while AlphaEvolve scales code evolution to scientific and algorithmic discovery tasks\(Novikovet al\.,[2025](https://arxiv.org/html/2607.18252#bib.bib20)\)\. The common pattern is to separate proposal from evaluation: the language model explores a program space, and an evaluator supplies the selection pressure\.

Our work is closest to this executable\-discovery line, but the solver setting makes the search substantially more constrained than standalone heuristic design\. A candidate program must be valid Python code, satisfy SCIP’s callback contracts, return legal solver objects and result codes, and remain stable under repeated invocation inside a branch\-and\-cut solve\. Moreover, the evaluated artifact is not a single scoring function for an external benchmark; it is a pair of interacting native solver modules whose effects are only visible through end\-to\-end SCIP execution\. The contribution is therefore not generic LLM program search alone, but executable automatic design specialized to coupled MILP solver callbacks inside a standard optimization workflow\.

## 3Method

### 3\.1LLM\-Guided MILP Solver Auto\-Design

We propose a framework for LLM\-guided MILP solver auto\-design: automatically constructing MILP solver logic by evolving native PySCIPOpt callback programs under end\-to\-end SCIP execution feedback\. The key idea is to make the evolvable artifact an executable solver component rather than an external learned predictor\. Candidate programs are proposed by an LLM, loaded into SCIP through the callback interface, evaluated by direct branch\-and\-cut execution, and selected according to measured solving behavior rather than LLM self\-assessment\.

This framing separates our setting from both learning\-augmented MILP policies and generic LLM program search\. Learned branching or cut\-selection methods typically train a predictor for one solver decision interface, while our framework searches directly over executable solver components that run inside the solver\. Generic evaluator\-guided program search optimizes standalone code fragments\(Romera\-Paredeset al\.,[2024](https://arxiv.org/html/2607.18252#bib.bib19); Liuet al\.,[2024b](https://arxiv.org/html/2607.18252#bib.bib24); Yeet al\.,[2024](https://arxiv.org/html/2607.18252#bib.bib25); Novikovet al\.,[2025](https://arxiv.org/html/2607.18252#bib.bib20)\); in contrast, our candidates must satisfy solver\-interface contracts and remain stable under repeated invocation during SCIP optimization\. Thus the central difficulty is not only to generate code, but to generate admissible, executable, and useful solver logic\.

Figure[1](https://arxiv.org/html/2607.18252#S3.F1)summarizes the closed loop and its main artifacts\. Starting from a MILP instance set, the SCIP/PySCIPOpt API, and callback contracts, the LLM proposes semantic edits to a joint callback program through mutation or crossover\. Candidate code is then passed through contract\-preserving repair and validation before it is admitted as a paired cut selector and branching rule\. The repaired artifact is registered in SCIP, evaluated by branch\-and\-cut execution, and converted into traces and a scalar fitnessF​\(p;𝒟\)F\(p;\\mathcal\{D\}\); these signals update the MAP\-Elites archive, island populations, and reflection summaries that condition later proposals\.

![Refer to caption](https://arxiv.org/html/2607.18252v1/figures/method-overview.png)Figure 1:Overview of the proposed framework\. We adapt evaluator\-guided code evolution to MILP solver auto\-design by treating native PySCIPOpt callbacks as the evolvable artifact\. The LLM proposes candidate source code, repair enforces callback contracts, the resulting joint artifactp=\(cp,bp\)p=\(c\_\{p\},b\_\{p\}\)implements both cut selection and branching, and SCIP\-grounded execution supplies traces and fitness for quality\-diversity selection, island migration, and reflection\.
### 3\.2Joint Native Callback Search Space

Each candidate is a joint native callback artifact: a user\-defined Python program registered with SCIP and invoked by the solver at predefined control points of the optimization process\. The callback artifact does not replace SCIP’s main branch\-and\-cut loop; SCIP retains control of the solve and calls user logic only when a specific internal decision must be made\.

In this work, each program is a joint artifact

p=\(cp,bp\),p=\\big\(c\_\{p\},b\_\{p\}\\big\),wherecpc\_\{p\}is a cut\-selection callback andbpb\_\{p\}is a branching callback:

- •The cut\-selection callback is invoked after candidate cuts have been generated\. It scores, orders, and selects cuts from the candidate pool before they are added to the LP relaxation\.
- •The branching callback is invoked when the solver needs to branch at an LP node\. It chooses a branching variable from the current fractional candidates\.

The two callbacks are evolved as one source\-code artifact and are loaded into the same SCIP model\. This joint representation is essential because cut selection and branching are coupled through the solver trajectory\. Cut selection changes the LP relaxation, bound progress, and candidate states later encountered by branching; branching changes the future nodes, LPs, and separation contexts in which cut selection is invoked\. Searching over the pair\(cp,bp\)\(c\_\{p\},b\_\{p\}\)therefore targets their combined effect on branch\-and\-bound rather than the isolated quality of either component\.

This representation also keeps the learned policy explicit\. The output of evolution is not a neural predictor wrapped around the solver, but readable solver logic implementing concrete decision rules\. The program may use signals exposed by SCIP, such as cut efficacy, cut sparsity, row parallelism, objective coefficients, lock counts, pseudo\-cost information, branching candidate statistics, and node\-depth\-dependent state\. Evolution searches over how these solver signals are composed into cut\-ranking, cut\-filtering, variable\-scoring, and depth\-dependent control logic, while the callback interface constrains the program to remain deployable as a native solver component\.

The search space is therefore not ordinary Python code\. A generated source string first belongs to the unconstrained space𝒫~\\widetilde\{\\mathcal\{P\}\}\. It enters the effective search space only if it compiles, defines the required callback classes, satisfies the PySCIPOpt calling conventions, returns legal SCIP objects and result codes, selects cuts only from the candidate pool, and performs a valid branch action when the solver requires one\. We define the feasible callback space operationally as

𝒫=\{p∈𝒫~:F​\(p;𝒟\)<\+∞\},\\mathcal\{P\}=\\\{p\\in\\widetilde\{\\mathcal\{P\}\}:F\(p;\\mathcal\{D\}\)<\+\\infty\\\},where infeasible programs are assigned infinite fitness and are excluded from elite selection\. This view is important for solver auto\-design: a candidate can express a useful algorithmic idea while still being inadmissible as a SCIP program because it violates a low\-level callback contract\. Invalid artifacts may fail through syntax errors, Python exceptions, malformed return dictionaries, illegal cut objects, degenerate branch behavior, or C\-layer solver assertions\.

The resulting optimization problem is

p⋆∈arg⁡minp∈𝒫⁡F​\(p;𝒟\),p^\{\\star\}\\in\\arg\\min\_\{p\\in\\mathcal\{P\}\}F\(p;\\mathcal\{D\}\),whereFFis induced by registeringppinside SCIP and running the resulting solver on MILP instances𝒟\\mathcal\{D\}\. Thus the language model supplies search proposals, while SCIP execution supplies both the feasibility test and the selection pressure\.

### 3\.3Contract\-Preserving Evolution Loop

Given a candidate program, the evaluator compiles the module, loads the callback artifact, checks that the required solver interfaces are present, and rejects programs that cannot be instantiated\. For each MILP instance, it constructs a fresh SCIP model, registers the callbacks through PySCIPOpt, reads the instance, and invokes SCIP’s optimization routine\. The resulting trajectory provides process time, solve status, objective value when available, node count, solved\-instance count, and structured error information\.

We distinguish program\-level callback validity from instance\-level solve success\. A program is callback\-valid only if it satisfies the SCIP interface: the cut\-selection callback must return cuts drawn from the original candidate pool, a legal selected\-cut count, and a valid SCIP result code; the branching callback must perform a legal branch when LP branching candidates are available\. Syntax errors, missing callback definitions, malformed return values, callback exceptions, invalid cut objects, and degenerate branching behavior are treated as program\-level failures and receive\+∞\+\\inftyfitness\. Among callback\-valid programs, an instance run is successful only when SCIP terminates with the required target status, which is optimality in our experiments\.

Let𝒟\\mathcal\{D\}denote the evaluation batch\. For a callback\-valid programppand instancexx, letT​\(p,x\)T\(p,x\)be the measured process time of the SCIP run\. The selection fitness is

F​\(p;𝒟\)=\{1\|𝒟\|​∑x∈𝒟T​\(p,x\),if​p​is callback\-valid and succeeds on all​x∈𝒟,\+∞,otherwise\.F\(p;\\mathcal\{D\}\)=\\begin\{cases\}\\frac\{1\}\{\|\\mathcal\{D\}\|\}\\sum\_\{x\\in\\mathcal\{D\}\}T\(p,x\),&\\text\{if \}p\\text\{ is callback\-valid and succeeds on all \}x\\in\\mathcal\{D\},\\\\ \+\\infty,&\\text\{otherwise\}\.\\end\{cases\}All other evaluation outcomes receive infinite fitness and cannot enter elite selection\. This objective makes the scalar selection signal depend on complete end\-to\-end solver behavior while keeping structured failure information available for repair and reflection\. The evaluator also records solved count, status, node count, objective values, and error traces as diagnostics, while the scalar score remains grounded in SCIP execution\.

The evolution loop separates proposing solver logic from making it executable\. In the semantic proposal stage, the LLM is asked to improve the joint callback artifact: it may generate a new artifact, mutate a parent’s scoring formulas and control schedules, or perform crossover by recombining useful motifs from two parents\. These edits are represented as source code, but the intended object of search is the algorithmic logic: how to trade off cut efficacy and sparsity, how aggressively to remove nearly parallel cuts, how branching scores combine fractionality, locks, objective coefficients, and pseudo\-costs, and how these decisions should change across the branch\-and\-cut tree\.

When a candidate fails through a recoverable interface violation, we apply*contract\-preserving repair*\. The repair operator receives the candidate code together with compiler errors, Python tracebacks, callback\-wrapper diagnostics, solver status, and the relevant PySCIPOpt interface constraints\. Its role is to project the proposed solver logic back into the feasible callback space, not to replace it with a new heuristic\. In practice this means repairing imports, class definitions, method signatures, return dictionaries, SCIP result codes, branch actions, and illegal API uses while preserving the candidate’s cut\-ranking and branching\-scoring logic as much as possible\. The repaired program is then re\-evaluated by the same SCIP\-grounded objective before it can enter the archive\.

Finally, the archive maintains both performance and diversity\. Each evaluated individual stores source code, fitness, parentage, solver diagnostics, error traces, reflection summaries, and two language\-model\-rated descriptors:*code quality*and*marginal utility*\. These descriptors affect the exploration geometry by assigning candidates to cells in a two\-dimensional MAP\-Elites grid; they do not decide which candidate is better inside a cell\. Within each cell, replacement is determined solely by SCIP\-grounded fitnessFF\.

Within each island, each cell retains only a small number of finite\-fitness elites\. This prevents the search from collapsing immediately onto one visually similar family of programs, while still using solve time as the selection criterion inside each cell\. Reflection converts solver feedback into strengths, weaknesses, and suggested evolving directions, which are fed back into later mutation and crossover prompts\. Multiple islands evolve in parallel with periodic migration of high\-quality individuals, providing a second source of diversity at the population level\.

The final output is an explicit joint solver artifact that can be inspected, modified, and deployed through the same PySCIPOpt pathway used during evolution\.

## 4Experiments

### 4\.1Experimental Setup

#### Baselines\.

We compare against a set of representative branch\-and\-cut baselines covering classical solver rules, learned branching policies, hybrid methods, and symbolic branching policies\. FSB is full strong branching, RPB is reliability pseudo\-cost branching, GNN is the supervised graph neural branching policy\(Gasseet al\.,[2019](https://arxiv.org/html/2607.18252#bib.bib6)\), Hybrid combines learned and solver\-side branching scores\(Guptaet al\.,[2020](https://arxiv.org/html/2607.18252#bib.bib10)\), and GS4CO is a white\-box symbolic branching baseline\(Kuanget al\.,[2024a](https://arxiv.org/html/2607.18252#bib.bib21),[b](https://arxiv.org/html/2607.18252#bib.bib22)\)\. We also include default SCIP as a solver\-default baseline\. MILP\-Evo is evaluated as the exported PySCIPOpt artifact produced by execution\-guided search, jointly implementing a cut selector and a branching rule\. The primary comparison set consists of FSB, RPB, GNN, Hybrid, GS4CO, SCIP, and MILP\-Evo; GNN\-GPU and COPT\(Geet al\.,[2023](https://arxiv.org/html/2607.18252#bib.bib31)\)are included only as external references and are excluded from optimal\-run win counts and boldface comparisons\.

#### Benchmarks\.

We evaluate on four learn2branch MILP families: set cover, combinatorial auctions, facility location, and independent set\(Gasseet al\.,[2019](https://arxiv.org/html/2607.18252#bib.bib6)\)\. Each family contains Easy, Medium, and Hard transfer scales\.

#### Training and evaluation\.

For each problem family, MILP\-Evo uses Gemini\-3\-flash\-preview as the language\-model backbone and performs 400 search iterations on Easy\-scale instances to obtain a domain\-specialized joint callback program\. The exported PySCIPOpt policy is then evaluated without further adaptation across the Easy, Medium, and Hard scales of the same family\. All methods are measured by mean process time with a36003600second time limit, with unsolved runs charged the full time limit\. We also report per\-scale win counts over the primary comparison set and mean branch\-and\-bound node counts\. MILP\-Evo was run on machines equipped with Intel Xeon Platinum 8362 processors, using CPU execution only and no GPU acceleration\. Its main software environment used Python 3\.11\.9, PySCIPOpt 6\.1\.0, SCIP 10\.0\.2, and SoPlex 8\.0\.2\. Baseline implementations were run with the Python and package environments required by their original implementations\.

### 4\.2Comparative Evaluation and Search Behavior

Table[1](https://arxiv.org/html/2607.18252#S4.T1)reports the main comparative results\. Following prior branching\-policy evaluations, each block gives mean process time, win count, and mean node count for one problem family across the three transfer scales\.

Table 1:Comparative evaluation on four learn2branch families\. Time is meanproctimein seconds; Wins and boldface are computed over primary comparison set only\. GNN\-GPU and COPT are external references\.Overall, MILP\-Evo is strongly competitive across the four benchmark families, with the clearest gains on independent set\. On the remaining families, it also frequently reaches the best or near\-best performance among the primary comparison methods\.

These results suggest that joint executable search can discover domain\-specific and effective cut\-selection and branching rules, rather than only generic solver heuristics\. At the same time, the gains are not uniform across all families and transfer scales, indicating that the effectiveness of the discovered rules remains somewhat uneven\.

#### Search convergence

Figure[4\.2](https://arxiv.org/html/2607.18252#S4.SS2.SSS0.Px2)summarizes both the optimization trace and the ancestry of the best independent\-set artifact\. The convergence curve is staircase\-shaped rather than smooth: search spends long periods on valid but non\-improving programs, then improves when a structural edit changes how cut filtering and branching interact\.

#### Lineage analysis

The lineage panel adds the mechanism behind this pattern\. The final artifact does not descend through a monotone sequence of better programs\. Exploratory recombination initially worsens immediate fitness while introducing reusable motifs such as sparsity\-aware cut scoring and value\-sensitive branching\. Later descendants preserve these motifs and refine them into structure\-aware branching, graph\-connectivity signals, and calibrated cut filtering\. The best program is therefore the result of non\-monotone evolutionary reuse rather than a single isolated improvement\.

![[Uncaptioned image]](https://arxiv.org/html/2607.18252v1/figures/search-convergence-indset.png)

\(a\) Best fitness versus cumulative LLM output tokens\. ![[Uncaptioned image]](https://arxiv.org/html/2607.18252v1/figures/lineage-analysis.png)

\(b\) Milestones along the best lineage\. Figure 2: Search dynamics on independent set; lower fitness is better\.

### 4\.3Ablation Study

We use independent set as a representative case for the ablation study\. The cut\-only and branch\-only variants isolate the two callback components\. The separate\-best variant combines the best independently found single\-component artifacts after search, without co\-evolving them as one program\. NoRepair disables the contract\-preserving repair step described in Section[3](https://arxiv.org/html/2607.18252#S3)\.

Table 2: Ablation on independent set\. Time is meanproctimein seconds\.

The ablation supports the importance of joint executable search\. MILP\-Evo outperforms both single\-component variants and the post\-hoc separate\-best combination on all three transfer scales, reducing Hard\-scale time from2299\.232299\.23seconds for separate\-best to806\.17806\.17seconds\. Disabling repair is also damaging: NoRepair is slower than MILP\-Evo on every scale and wins no instances, even on Easy\. Runtime gains are again not explained only by smaller trees; the evolved policy changes the cost and quality of the explored tree as well as its size\.

#### Repair effectiveness\.

Table[4\.3](https://arxiv.org/html/2607.18252#S4.SS3.SSS0.Px1)reports repair\-oriented success statistics over the stored candidate records\. Repair substantially improves the reliability of executable callback generation, increasing the aggregate success rate from79\.96%79\.96\\%to95\.64%95\.64\\%and reducing final failures to6060cases\. The effect is especially visible on the families with lower pre\-repair validity, where many otherwise discarded candidates can be projected back into the feasible callback space\. Across all triggered repairs, roughly four out of five repaired candidates become final successful records\. This suggests that repair is not only a convenience for handling syntax or interface mistakes, but also a stabilizing mechanism that lets the search retain useful solver logic proposed in imperfect executable form\.

Table 3: Repair success statistics\. “Without repair” treats triggered repairs as pre\-repair failures; “with repair” uses the final evaluation outcome\.

## 5Conclusion

We introduced MILP\-Evo, a framework for automatically designing MILP solver components as executable PySCIPOpt callbacks, which searches over native solver code and evaluates each candidate through end\-to\-end SCIP execution\. This design keeps the discovered cut\-selection and branching logic explicit, inspectable, and compatible with standard solver workflows\. Our experiments show that LLM\-guided executable search can discover competitive domain\-specialized solver components across standard learn2branch families\. The ablation and lineage analyses suggest that these gains come from jointly callback evolution, non\-monotone reuse of useful program motifs, and contract\-preserving repair\. More broadly, MILP\-Evo points to a practical path for automatic solver design, where the learned object is explicit algorithmic logic shaped by end\-to\-end solver behavior rather than a black\-box policy\.

#### Limitations\.

MILP\-Evo currently targets two callback interfaces, cut selection and branching; although we explored node selection, primal heuristics, and separators, these extensions did not yield consistent runtime improvements under the present search setting\. Transfer across instance scales is also uneven across families\. Finally, LLM\-guided program search remains sensitive to the model, prompts, sampling, budget, population state, and repair decisions; repair improves executability but does not guarantee semantic or solver\-version robustness\.

## References

- T\. Achterberg \(2009\)SCIP: solving constraint integer programs\.Mathematical Programming Computation1\(1\),pp\. 1–41\.Cited by:[Table 6](https://arxiv.org/html/2607.18252#A5.T6.3.1.6.5.2),[§1](https://arxiv.org/html/2607.18252#S1.p1.1),[§1](https://arxiv.org/html/2607.18252#S1.p4.1)\.
- Y\. Bengio, A\. Lodi, and A\. Prouvost \(2021\)Machine learning for combinatorial optimization: a methodological tour d’horizon\.European Journal of Operational Research290\(2\),pp\. 405–421\.Cited by:[§1](https://arxiv.org/html/2607.18252#S1.p1.1),[§1](https://arxiv.org/html/2607.18252#S1.p2.1)\.
- Z\. Chen \(2010\)Integrated production and outbound distribution scheduling: review and extensions\.Operations research58\(1\),pp\. 130–148\.Cited by:[§1](https://arxiv.org/html/2607.18252#S1.p1.1)\.
- S\. Du, J\. Tong, and W\. Fan \(2025\)Learning efficient branch\-and\-bound for solving mixed integer linear programs\.Applied Soft Computing172,pp\. 112863\.Cited by:[§1](https://arxiv.org/html/2607.18252#S1.p3.1),[§2\.1](https://arxiv.org/html/2607.18252#S2.SS1.p2.1)\.
- M\. Gasse, D\. Chételat, N\. Ferroni, L\. Charlin, and A\. Lodi \(2019\)Exact combinatorial optimization with graph convolutional neural networks\.Advances in neural information processing systems32\.Cited by:[§A\.1](https://arxiv.org/html/2607.18252#A1.SS1.p1.1),[Table 6](https://arxiv.org/html/2607.18252#A5.T6.3.1.2.1.2),[§1](https://arxiv.org/html/2607.18252#S1.p2.1),[§2\.1](https://arxiv.org/html/2607.18252#S2.SS1.p1.1),[§4\.1](https://arxiv.org/html/2607.18252#S4.SS1.SSS0.Px1.p1.1),[§4\.1](https://arxiv.org/html/2607.18252#S4.SS1.SSS0.Px2.p1.1)\.
- D\. Ge, Q\. Huangfu, Z\. Wang, J\. Wu, and Y\. Ye \(2023\)Cardinal Optimizer \(COPT\) userguide\.Note:https://guide\.coap\.online/copt/en\-docCited by:[Table 6](https://arxiv.org/html/2607.18252#A5.T6.3.1.8.7.2),[§4\.1](https://arxiv.org/html/2607.18252#S4.SS1.SSS0.Px1.p1.1)\.
- A\. Gleixner, G\. Hendel, G\. Gamrath, T\. Achterberg, M\. Bastubbe, T\. Berthold, P\. Christophel, K\. Jarck, T\. Koch, J\. Linderoth,et al\.\(2021\)MIPLIB 2017: data\-driven compilation of the 6th mixed\-integer programming library\.Mathematical Programming Computation13\(3\),pp\. 443–490\.Cited by:[§1](https://arxiv.org/html/2607.18252#S1.p1.1)\.
- P\. Gupta, M\. Gasse, E\. Khalil, P\. Mudigonda, A\. Lodi, and Y\. Bengio \(2020\)Hybrid models for learning to branch\.Advances in neural information processing systems33,pp\. 18087–18097\.Cited by:[Table 6](https://arxiv.org/html/2607.18252#A5.T6.3.1.3.2.2),[§1](https://arxiv.org/html/2607.18252#S1.p2.1),[§2\.1](https://arxiv.org/html/2607.18252#S2.SS1.p1.1),[§4\.1](https://arxiv.org/html/2607.18252#S4.SS1.SSS0.Px1.p1.1)\.
- Z\. Huang, K\. Wang, F\. Liu, H\. Zhen, W\. Zhang, M\. Yuan, J\. Hao, Y\. Yu, and J\. Wang \(2022\)Learning to select cuts for efficient mixed\-integer programming\.Pattern Recognition123,pp\. 108353\.Cited by:[§1](https://arxiv.org/html/2607.18252#S1.p2.1),[§2\.1](https://arxiv.org/html/2607.18252#S2.SS1.p1.1)\.
- Y\. Kuang, J\. Wang, H\. Liu, F\. Zhu, X\. Li, J\. Zeng, J\. Hao, B\. Li, and F\. Wu \(2024a\)Rethinking branching on exact combinatorial optimization solver: the first deep symbolic discovery framework\.InThe Twelfth International Conference on Learning Representations,Cited by:[Table 6](https://arxiv.org/html/2607.18252#A5.T6.3.1.4.3.2),[§1](https://arxiv.org/html/2607.18252#S1.p2.1),[§1](https://arxiv.org/html/2607.18252#S1.p3.1),[§2\.1](https://arxiv.org/html/2607.18252#S2.SS1.p2.1),[§4\.1](https://arxiv.org/html/2607.18252#S4.SS1.SSS0.Px1.p1.1)\.
- Y\. Kuang, J\. Wang, Y\. Zhou, X\. Li, F\. Zhu, J\. Hao, and F\. Wu \(2024b\)Towards general algorithm discovery for combinatorial optimization: learning symbolic branching policy from bipartite graph\.InForty\-first International Conference on Machine Learning,Cited by:[Table 6](https://arxiv.org/html/2607.18252#A5.T6.3.1.4.3.2),[§1](https://arxiv.org/html/2607.18252#S1.p3.1),[§2\.1](https://arxiv.org/html/2607.18252#S2.SS1.p2.1),[§4\.1](https://arxiv.org/html/2607.18252#S4.SS1.SSS0.Px1.p1.1)\.
- S\. Li, J\. Kulkarni, I\. Menache, C\. Wu, and B\. Li \(2024\)Towards foundation models for mixed integer linear programming\.arXiv preprint arXiv:2410\.08288\.Cited by:[§2\.1](https://arxiv.org/html/2607.18252#S2.SS1.p3.1)\.
- S\. Li, W\. Ouyang, M\. Paulus, and C\. Wu \(2023\)Learning to configure separators in branch\-and\-cut\.Advances in Neural Information Processing Systems36,pp\. 60021–60034\.Cited by:[§1](https://arxiv.org/html/2607.18252#S1.p2.1),[§2\.1](https://arxiv.org/html/2607.18252#S2.SS1.p1.1)\.
- J\. Lin, M\. Xu, Z\. Xiong, and H\. Wang \(2024\)CAMBranch: contrastive learning with augmented milps for branching\.arXiv preprint arXiv:2402\.03647\.Cited by:[§1](https://arxiv.org/html/2607.18252#S1.p2.1),[§2\.1](https://arxiv.org/html/2607.18252#S2.SS1.p1.1)\.
- C\. Liu, Z\. Dong, H\. Ma, W\. Luo, X\. Li, B\. Pang, J\. Zeng, and J\. Yan \(2024a\)L2p\-mip: learning to presolve for mixed integer programming\.InThe Twelfth International Conference on Learning Representations,Cited by:[§1](https://arxiv.org/html/2607.18252#S1.p2.1)\.
- F\. Liu, X\. Tong, M\. Yuan, X\. Lin, F\. Luo, Z\. Wang, Z\. Lu, and Q\. Zhang \(2024b\)Evolution of heuristics: towards efficient automatic algorithm design using large language model\.arXiv preprint arXiv:2401\.02051\.Cited by:[§2\.2](https://arxiv.org/html/2607.18252#S2.SS2.p1.1),[§3\.1](https://arxiv.org/html/2607.18252#S3.SS1.p2.1)\.
- S\. Liu, J\. M\. Pinto, and L\. G\. Papageorgiou \(2008\)A tsp\-based milp model for medium\-term planning of single\-stage continuous multiproduct plants\.Industrial & Engineering Chemistry Research47\(20\),pp\. 7733–7743\.Cited by:[§1](https://arxiv.org/html/2607.18252#S1.p1.1)\.
- A\. Lodi and G\. Zarpellon \(2017\)On learning and branching: a survey\.Top25\(2\),pp\. 207–236\.Cited by:[§1](https://arxiv.org/html/2607.18252#S1.p2.1)\.
- K\. Ma, L\. Xiao, J\. Zhang, and T\. Li \(2019\)Accelerating an fpga\-based sat solver by software and hardware co\-design\.Chinese Journal of Electronics28\(5\),pp\. 953–961\.Cited by:[§1](https://arxiv.org/html/2607.18252#S1.p1.1)\.
- S\. Maher, M\. Miltenberger, J\. P\. Pedroso, D\. Rehfeldt, R\. Schwarz, and F\. Serrano \(2016\)PySCIPOpt: mathematical programming in python with the scip optimization suite\.InInternational Congress on Mathematical Software,pp\. 301–307\.Cited by:[Table 6](https://arxiv.org/html/2607.18252#A5.T6.3.1.5.4.2),[§1](https://arxiv.org/html/2607.18252#S1.p4.1)\.
- A\. Novikov, N\. Vũ, M\. Eisenberger, E\. Dupont, P\. Huang, A\. Z\. Wagner, S\. Shirobokov, B\. Kozlovskii, F\. J\. Ruiz, A\. Mehrabian,et al\.\(2025\)Alphaevolve: a coding agent for scientific and algorithmic discovery\.arXiv preprint arXiv:2506\.13131\.Cited by:[§2\.2](https://arxiv.org/html/2607.18252#S2.SS2.p1.1),[§3\.1](https://arxiv.org/html/2607.18252#S3.SS1.p2.1)\.
- M\. B\. Paulus, G\. Zarpellon, A\. Krause, L\. Charlin, and C\. Maddison \(2022\)Learning to cut by looking ahead: cutting plane selection via imitation learning\.InInternational conference on machine learning,pp\. 17584–17600\.Cited by:[§1](https://arxiv.org/html/2607.18252#S1.p2.1),[§2\.1](https://arxiv.org/html/2607.18252#S2.SS1.p1.1)\.
- M\. Paulus and A\. Krause \(2023\)Learning to dive in branch and bound\.Advances in Neural Information Processing Systems36,pp\. 34260–34277\.Cited by:[§1](https://arxiv.org/html/2607.18252#S1.p2.1)\.
- P\. Puigdemont, S\. Skoulakis, G\. Chrysos, and V\. Cevher \(2024\)Learning to remove cuts in integer linear programming\.arXiv preprint arXiv:2406\.18781\.Cited by:[§1](https://arxiv.org/html/2607.18252#S1.p2.1),[§2\.1](https://arxiv.org/html/2607.18252#S2.SS1.p1.1)\.
- B\. Romera\-Paredes, M\. Barekatain, A\. Novikov, M\. Balog, M\. P\. Kumar, E\. Dupont, F\. J\. Ruiz, J\. S\. Ellenberg, P\. Wang, O\. Fawzi,et al\.\(2024\)Mathematical discoveries from program search with large language models\.Nature625\(7995\),pp\. 468–475\.Cited by:[§2\.2](https://arxiv.org/html/2607.18252#S2.SS2.p1.1),[§3\.1](https://arxiv.org/html/2607.18252#S3.SS1.p2.1)\.
- M\. Turner, T\. Koch, F\. Serrano, and M\. Winkler \(2023\)Adaptive cut selection in mixed\-integer linear programming\.Open Journal of Mathematical Optimization4,pp\. 1–28\.Cited by:[§1](https://arxiv.org/html/2607.18252#S1.p2.1),[§2\.1](https://arxiv.org/html/2607.18252#S2.SS1.p1.1)\.
- Z\. Wang, X\. Li, J\. Wang, Y\. Kuang, M\. Yuan, J\. Zeng, Y\. Zhang, and F\. Wu \(2023\)Learning cut selection for mixed\-integer linear programming via hierarchical sequence model\.arXiv preprint arXiv:2302\.00244\.Cited by:[§1](https://arxiv.org/html/2607.18252#S1.p2.1),[§2\.1](https://arxiv.org/html/2607.18252#S2.SS1.p1.1)\.
- H\. Ye, J\. Wang, Z\. Cao, F\. Berto, C\. Hua, H\. Kim, J\. Park, and G\. Song \(2024\)Reevo: large language models as hyper\-heuristics with reflective evolution\.Advances in neural information processing systems37,pp\. 43571–43608\.Cited by:[§2\.2](https://arxiv.org/html/2607.18252#S2.SS2.p1.1),[§3\.1](https://arxiv.org/html/2607.18252#S3.SS1.p2.1)\.
- H\. Ye, H\. Xu, A\. Yan, and Y\. Cheng \(2025\)Large language model\-driven large neighborhood search for large\-scale milp problems\.InForty\-second International Conference on Machine Learning,Cited by:[§2\.1](https://arxiv.org/html/2607.18252#S2.SS1.p3.1)\.
- S\. Zeng, S\. Zhang, S\. Li, F\. Wu, and X\. Li \(2025\)Beyond local selection: global cut selection for enhanced mixed\-integer programming\.arXiv preprint arXiv:2503\.15847\.Cited by:[§2\.1](https://arxiv.org/html/2607.18252#S2.SS1.p1.1)\.
- S\. Zhang, S\. Zeng, S\. Li, F\. Wu, and X\. Li \(2025\)Learning to select nodes in branch and bound with sufficient tree representation\.InThe Thirteenth International Conference on Learning Representations,Cited by:[§2\.1](https://arxiv.org/html/2607.18252#S2.SS1.p2.1)\.

## Appendix AImplementation Details

### A\.1Benchmark Instance Generation

We generate the MILP instances using the same learn2branch\-style generation protocol asGasseet al\.\[[2019](https://arxiv.org/html/2607.18252#bib.bib6)\]\. The released generation script writes CPLEX LP\-format instances under problem\-specific directories withtrain,valid,transfer, andtestprefixes\. For each benchmark family, MILP\-Evo searches on Easy\-scale training instances and evaluates the exported callback on held\-out Easy, Medium, and Hard instance scales\. The generator creates 1000 Easy\-scale training instances and 200 Easy\-scale validation instances per family; the evaluation scripts then select the held\-out instances used for the reported transfer experiments\.

The four benchmark families instantiate different MILP structures:

Set covering\.Given a universe of elements and a collection of subsets whose union contains the universe, the set covering problem asks for a subcollection that still covers all elements\. In our MILP instances, each binary variable indicates whether one subset is selected, and the objective is to obtain a cover with minimum total cost\.

Combinatorial auction\.In a combinatorial auction, bidders submit bids on packages of discrete, heterogeneous items rather than only on individual items\. The associated winner determination problem selects a compatible set of package bids that maximizes the auctioneer’s revenue or total accepted value\. In our MILP formulation, each binary variable corresponds to accepting one bid, and item\-conflict constraints ensure that no item is assigned more than once\.

Capacitated facility location\.Facility location problems ask where facilities should be placed or opened so that demand points can be served at low cost\. In the capacitated variant used here, the model chooses which candidate facilities to open and how to route customer demand to open facilities\. The objective combines fixed opening costs and transportation costs, while capacity constraints limit the total demand that each open facility may serve\.

Maximum independent set\.In graph theory, an independent set is a set of vertices with no edge between any selected pair\. The maximum independent set problem seeks an independent set of largest possible cardinality in a given graph\. Our MILP uses one binary variable per vertex, edge constraints to prevent adjacent vertices from being selected together, and a cardinality\-maximization objective\.

Table[4](https://arxiv.org/html/2607.18252#A1.T4)reports the main scale parameters used for the Easy, Medium, and Hard instance families\. Additional generator constants follow the learn2branch defaults used in our script: set\-covering density is0\.050\.05with objective coefficients sampled up to100100, the combinatorial\-auction bundle\-extension probability is0\.70\.7, the facility\-location capacity\-to\-demand ratio is55, and independent\-set graphs are generated by the Barabasi–Albert model with affinity44\.

Table 4:Instance generation hyperparameters for the benchmark families\.
### A\.2Search and Evaluation Protocol

We use the independent\-set benchmark as a representative example of the training and evaluation protocol\. The same protocol is applied to the other problem families with problem\-specific instance generators and callback evaluation files\.

#### Training\.

For a given problem family, MILP\-Evo searches over a population of executable Python artifacts\. Each artifact jointly defines a cut selector and a branching rule, and both callbacks are registered in the same SCIP model during evaluation\. The search is initialized with diverse LLM\-generated candidates and then alternates between mutation, crossover, reflection, and repair\. Candidate quality is never judged by the LLM itself: each program is compiled, checked against the callback contracts, executed inside SCIP on a small batch of training instances, and scored by mean process time when all instances are solved to optimality\. Programs that violate the interface, raise callback errors, or fail the required solve condition receive infinite fitness\.

The population is maintained as a quality\-diversity archive\. Language\-model feedback is used to propose code edits and to describe candidates, while selection within the archive is determined by SCIP execution\. This separation is important: the LLM explores the program space, but the solver supplies the fitness signal that drives selection\.

To make the search interface concrete, Config[1](https://arxiv.org/html/2607.18252#LST1)and Prompt[2](https://arxiv.org/html/2607.18252#LST2)provide shortened excerpts from the independent\-set configuration and task prompt\. The configuration excerpt shows how the benchmark, search budget, and population structure are specified\. The prompt excerpt shows how the LLM is instructed to produce one joint callback artifact and to respect the PySCIPOpt callback contracts\. The full configuration files and prompts are included in the supplementary material\.

mutation\_rate:0\.4

crossover\_rate:0\.6

batch\_size:10

instances:

source:learn2branch

problem:indset

limit:10

scip\_seed:0

population:

iterations:400

population\_size:20

island\_num:4

bins\_num:3

Config 1:Shortened independent\-set search configuration excerpt\.YouareanexpertinMILPsolverdesignformaximumindependentset

\(stableset\)instances\.Yourtaskistoco\-evolvetwoSCIPplugins:

\(1\)acustomcutselector\(CustomCutsel\)thatordersorfilters

candidatecutsatseparation,and

\(2\)acustombranchingrule\(CustomBranchingRule\)thatdecideshowto

branchonfractionalLPcandidates\.

BothpluginsruntogetheronthesamePySCIPOptModel\.Onesubmission

mustdefinebothclassesinthesamemodule\.CustomCutselmustreturna

dictionarywithkeyscuts,nselectedcuts,andresult,wherecutsisonly

areorderingorsubsetoftheinputcutpool\.CustomBranchingRulemust

branchwhenLPbranchingcandidatesexistandreturnSCIP\_RESULT\.BRANCHED\.

Fitnessisthemeanprocesstimetoreachoptimalityovertheevaluation

batch\.Co\-evolutionmeansjointchangestocutselectionandbranching

mustimproveend\-to\-endSCIPbehavior,notonlyonecomponentinisolation\.

Prompt 2:Shortened independent\-set task prompt excerpt\.
#### Evaluation\.

After search, the best finite\-fitness program for each family is exported as the family\-specific policy\. No further LLM calls or adaptation are performed during evaluation\. The exported callbacks are loaded into fresh SCIP models and tested on held\-out learn2branch transfer instances at Easy, Medium, and Hard scales\. We use the same joint registration path as in training and report solver status, process time, and branch\-and\-bound node counts under the time limit described in the main text\.

## Appendix BBest Discovered Cut\-Branch Callback

This section presents the best joint cut\-selection and branching callback artifact discovered by MILP\-Evo\. The artifact is an executable PySCIPOpt program registered inside SCIP during evaluation\. It contains both the cut selector and the branching rule used for the corresponding benchmark family\. For compactness, we show the independent\-set artifact in full because it is the setting where MILP\-Evo obtains its strongest gains and where we also report detailed search dynamics in the main paper\. The complete exported programs for all four benchmark families are included in the supplementary material underproblem/\.

frompyscipoptimportModel,Branchrule,SCIP\_RESULT

frompyscipopt\.scipimportCutsel

classCustomCutsel\(Cutsel\):

def\_\_init\_\_\(self\):

super\(\)\.\_\_init\_\_\(\)

defcutselselect\(self,cuts,forcedcuts,root,maxnselectedcuts\):

ifnotcuts:

return\{"cuts":\[\],"nselectedcuts":0,"result":SCIP\_RESULT\.SUCCESS\}

\#andParentB’s\(0\.05\)rawstrength,aimingforfastLPsolves\.

scored\_cuts=\[\]

forcincuts:

eff=self\.model\.getCutEfficacy\(c\)

nnz=c\.getNNonz\(\)

score=eff/\(nnz\+1\.0\)\*\*0\.15

scored\_cuts\.append\(\(c,score\)\)

scored\_cuts\.sort\(key=lambdax:x\[1\],reverse=True\)

best\_score=scored\_cuts\[0\]\[1\]

threshold=0\.85\*best\_score

n\_pass=0

for\_,scoreinscored\_cuts:

ifscore\>=threshold:

n\_pass\+=1

else:

break

pool\_limit=max\(1,len\(cuts\)//3\)

final\_n=min\(n\_pass,maxnselectedcuts,pool\_limit\)

return\{

"cuts":\[x\[0\]forxinscored\_cuts\],

"nselectedcuts":int\(final\_n\),

"result":SCIP\_RESULT\.SUCCESS

\}

classCustomBranchingRule\(Branchrule\):

def\_\_init\_\_\(self,model\):

super\(\)\.\_\_init\_\_\(\)

self\.model=model

defbranchexeclp\(self,additional\_cons\):

cands,sols,\_,nlpcands,\_,\_=self\.model\.getLPBranchCands\(\)

ifnlpcands==0:

return\{"result":SCIP\_RESULT\.DIDNOTRUN\}

best\_cand=None

best\_score=\(\-1,\-1\.0,1e12,\-1\.0\)

foriinrange\(nlpcands\):

v=cands\[i\]

s=sols\[i\]

locks=v\.getNLocksUp\(\)

obj=v\.getObj\(\)

idx=v\.getIndex\(\)

frac=s\*\(1\.0\-s\)

current\_score=\(locks,obj,\-idx,frac\)

ifcurrent\_score\>best\_score:

best\_score=current\_score

best\_cand=v

ifbest\_candisnotNone:

self\.model\.branchVar\(best\_cand\)

return\{"result":SCIP\_RESULT\.BRANCHED\}

else:

return\{"result":SCIP\_RESULT\.DIDNOTRUN\}

Program 3:Best discovered joint cut\-selection and branching callback for independent set\.
## Appendix CAdditional Experimental result

### C\.1Result Variability and Stability

Table[5](https://arxiv.org/html/2607.18252#A3.T5)compares standard deviations across methods on the same held\-out instances used in the main evaluation\. Because the test set is fixed for all methods, the reported deviations allow us to compare how much each method’s runtime varies across the same group of instances\. These deviations should not be interpreted as solver randomness alone: the instances within a benchmark family are fixed, but they can still differ substantially in difficulty\. Consistent with the main table, the discussion below focuses on the primary comparison methods; GNN\-GPU and COPT are included as external references\.

For process time, MILP\-Evo has the smallest standard deviation among the primary methods in half of the family\-scale settings and is among the three lowest in most settings\. The pattern is clearest on independent set and on the easy and medium combinatorial\-auction instances, where low variance is paired with strong win counts and low mean runtime\. This suggests that the improvement is not driven only by a few unusually easy instances: in these regimes, the discovered callback tends to reduce runtime consistently across the evaluation set\. Similar runtime\-stability behavior appears on the medium\-scale set\-covering and facility location instances\.

The comparison also shows where this claim should be qualified\. Very small runtime deviations for some baselines on hard instances can reflect consistent timeouts rather than robust solving, so standard deviation must be read together with mean time and win counts\. Node counts require the same joint reading\. Across several family\-scale settings, methods that explore fewer branch\-and\-bound nodes are not necessarily faster, and MILP\-Evo sometimes reaches a lower mean runtime while visiting more nodes\. This pattern is consistent with a tradeoff between tree size and per\-node overhead: a policy can reduce the number of nodes by spending more effort on branching or cut decisions, while a cheaper callback can traverse a larger tree but still finish sooner\.

Thus, the larger node\-count deviations of MILP\-Evo in some settings should not be read as a direct contradiction of its runtime stability\. They indicate that the evolved callbacks can produce more instance\-dependent search trees, whereas the process\-time columns show whether those trees are traversed efficiently enough to improve wall\-clock performance\. This distinction is most favorable on independent set and combinatorial auctions, where higher or more variable node counts often coincide with low mean runtime\. On harder set\-covering and facility\-location instances, however, both runtime and node\-count dispersion are larger, suggesting that transfer stability remains more problem\-dependent outside the families where the learned solver behavior aligns most strongly with the instance structure\.

Table 5:Main comparative results with standard deviations\. Time and node counts are reported as mean±\\pmstd over the same evaluation runs used for the main results\. Wins and boldface follow the convention of Table[1](https://arxiv.org/html/2607.18252#S4.T1): GNN\-GPU and COPT are external references and are excluded from primary win\-count and boldface comparisons\.Indset:EasyMediumHardModelTime\(s\)WinsNodesTime\(s\)WinsNodesTime\(s\)WinsNodesFSB87\.00±78\.1187\.00\{\\pm\}78\.111/5030\.2±27\.530\.2\{\\pm\}27\.53318\.97±789\.793318\.97\{\\pm\}789\.790/7150\.5±46\.0150\.5\{\\pm\}46\.03600\.06±0\.053600\.06\{\\pm\}0\.050/053\.9±16\.553\.9\{\\pm\}16\.5RPB9\.49±3\.779\.49\{\\pm\}3\.770/5046\.9±67\.646\.9\{\\pm\}67\.6194\.74±189\.02194\.74\{\\pm\}189\.020/507442\.9±8833\.17442\.9\{\\pm\}8833\.12587\.99±792\.072587\.99\{\\pm\}792\.070/1575329\.3±28439\.375329\.3\{\\pm\}28439\.3GNN5\.80±2\.555\.80\{\\pm\}2\.550/5062\.2±79\.162\.2\{\\pm\}79\.11673\.24±1473\.071673\.24\{\\pm\}1473\.070/3619872\.9±23832\.419872\.9\{\\pm\}23832\.43600\.01±0\.013600\.01\{\\pm\}0\.010/049010\.6±9406\.449010\.6\{\\pm\}9406\.4Hybrid6\.47±1\.456\.47\{\\pm\}1\.450/5053\.1±55\.453\.1\{\\pm\}55\.41502\.27±1143\.771502\.27\{\\pm\}1143\.770/3048887\.3±37997\.548887\.3\{\\pm\}37997\.53600\.01±0\.013600\.01\{\\pm\}0\.010/042854\.8±7286\.942854\.8\{\\pm\}7286\.9GS4CO7\.29±2\.277\.29\{\\pm\}2\.270/5054\.1±50\.754\.1\{\\pm\}50\.7147\.26±93\.78147\.26\{\\pm\}93\.780/502785\.0±3313\.02785\.0\{\\pm\}3313\.02057\.08±955\.492057\.08\{\\pm\}955\.490/3067083\.8±42269\.567083\.8\{\\pm\}42269\.5SCIP14\.80±5\.9114\.80\{\\pm\}5\.910/50164\.6±141\.2164\.6\{\\pm\}141\.2377\.99±254\.89377\.99\{\\pm\}254\.890/504023\.9±3369\.84023\.9\{\\pm\}3369\.83155\.52±715\.133155\.52\{\\pm\}715\.130/1822613\.1±6737\.822613\.1\{\\pm\}6737\.8MILP\-Evo2\.57±1\.04\\mathbf\{2\.57\{\\pm\}1\.04\}49/5084\.7±84\.084\.7\{\\pm\}84\.059\.20±47\.27\\mathbf\{59\.20\{\\pm\}47\.27\}50/501051\.9±1040\.41051\.9\{\\pm\}1040\.4806\.17±679\.78\\mathbf\{806\.17\{\\pm\}679\.78\}50/5017980\.3±19471\.117980\.3\{\\pm\}19471\.1GNN\-GPU4\.63±1\.244\.63\{\\pm\}1\.24\-/5062\.2±79\.162\.2\{\\pm\}79\.1858\.07±1214\.30858\.07\{\\pm\}1214\.30\-/4557818\.8±89060\.757818\.8\{\\pm\}89060\.73600\.00±0\.003600\.00\{\\pm\}0\.00\-/0107167\.4±20945\.0107167\.4\{\\pm\}20945\.0COPT2\.62±1\.692\.62\{\\pm\}1\.69\-/509\.6±12\.59\.6\{\\pm\}12\.562\.18±49\.6062\.18\{\\pm\}49\.60\-/50707\.7±724\.9707\.7\{\\pm\}724\.91531\.27±1169\.881531\.27\{\\pm\}1169\.88\-/4310279\.2±7357\.410279\.2\{\\pm\}7357\.4Cauctions:EasyMediumHardModelTime\(s\)WinsNodesTime\(s\)WinsNodesTime\(s\)WinsNodesFSB10\.80±4\.3910\.80\{\\pm\}4\.390/5025\.5±17\.225\.5\{\\pm\}17\.2286\.99±220\.88286\.99\{\\pm\}220\.880/50253\.1±165\.5253\.1\{\\pm\}165\.53177\.54±784\.123177\.54\{\\pm\}784\.120/14912\.3±231\.9912\.3\{\\pm\}231\.9RPB3\.70±1\.333\.70\{\\pm\}1\.330/5014\.8±12\.714\.8\{\\pm\}12\.721\.69±8\.9821\.69\{\\pm\}8\.981/501169\.0±1072\.41169\.0\{\\pm\}1072\.4271\.44±171\.11\\mathbf\{271\.44\{\\pm\}171\.11\}36/5017918\.5±12358\.217918\.5\{\\pm\}12358\.2GNN3\.13±1\.333\.13\{\\pm\}1\.330/50105\.8±65\.0105\.8\{\\pm\}65\.030\.05±22\.7630\.05\{\\pm\}22\.760/501047\.9±893\.21047\.9\{\\pm\}893\.2662\.39±451\.27662\.39\{\\pm\}451\.270/5017571\.3±12029\.117571\.3\{\\pm\}12029\.1Hybrid2\.07±0\.652\.07\{\\pm\}0\.650/50111\.2±70\.0111\.2\{\\pm\}70\.021\.26±15\.9121\.26\{\\pm\}15\.910/501210\.7±1069\.51210\.7\{\\pm\}1069\.5718\.47±565\.48718\.47\{\\pm\}565\.480/5030404\.5±24134\.530404\.5\{\\pm\}24134\.5GS4CO3\.07±1\.463\.07\{\\pm\}1\.460/50114\.3±82\.8114\.3\{\\pm\}82\.842\.55±41\.1942\.55\{\\pm\}41\.190/501353\.1±1435\.91353\.1\{\\pm\}1435\.91248\.98±866\.531248\.98\{\\pm\}866\.530/4524867\.6±16419\.124867\.6\{\\pm\}16419\.1SCIP3\.57±1\.343\.57\{\\pm\}1\.340/5030\.1±19\.830\.1\{\\pm\}19\.844\.96±24\.7644\.96\{\\pm\}24\.760/501169\.9±984\.01169\.9\{\\pm\}984\.0307\.55±172\.59307\.55\{\\pm\}172\.593/5015560\.5±10578\.315560\.5\{\\pm\}10578\.3MILP\-Evo0\.81±0\.39\\mathbf\{0\.81\{\\pm\}0\.39\}50/50196\.1±96\.7196\.1\{\\pm\}96\.711\.79±8\.53\\mathbf\{11\.79\{\\pm\}8\.53\}49/501536\.0±1087\.21536\.0\{\\pm\}1087\.2381\.90±396\.98381\.90\{\\pm\}396\.9811/5034534\.7±32040\.034534\.7\{\\pm\}32040\.0GNN\-GPU1\.60±0\.431\.60\{\\pm\}0\.43\-/50105\.8±65\.0105\.8\{\\pm\}65\.010\.36±5\.6210\.36\{\\pm\}5\.62\-/501047\.9±893\.21047\.9\{\\pm\}893\.2191\.11±132\.17191\.11\{\\pm\}132\.17\-/5017571\.7±12029\.417571\.7\{\\pm\}12029\.4COPT2\.18±0\.742\.18\{\\pm\}0\.74\-/50126\.8±118\.9126\.8\{\\pm\}118\.914\.11±6\.6114\.11\{\\pm\}6\.61\-/501542\.2±1246\.81542\.2\{\\pm\}1246\.8161\.34±97\.05161\.34\{\\pm\}97\.05\-/5019687\.7±13324\.319687\.7\{\\pm\}13324\.3Setcover:EasyMediumHardModelTime\(s\)WinsNodesTime\(s\)WinsNodesTime\(s\)WinsNodesFSB29\.07±32\.6829\.07\{\\pm\}32\.680/5045\.7±59\.145\.7\{\\pm\}59\.11291\.03±1153\.671291\.03\{\\pm\}1153\.670/45929\.5±640\.3929\.5\{\\pm\}640\.33600\.03±0\.023600\.03\{\\pm\}0\.020/0658\.3±330\.6658\.3\{\\pm\}330\.6RPB11\.20±4\.6111\.20\{\\pm\}4\.610/50129\.6±249\.7129\.6\{\\pm\}249\.7162\.69±233\.22\\mathbf\{162\.69\{\\pm\}233\.22\}29/5010349\.9±17486\.710349\.9\{\\pm\}17486\.72401\.92±876\.572401\.92\{\\pm\}876\.5719/20118275\.4±52191\.2118275\.4\{\\pm\}52191\.2GNN11\.32±8\.3911\.32\{\\pm\}8\.393/50172\.7±182\.5172\.7\{\\pm\}182\.5487\.64±709\.82487\.64\{\\pm\}709\.820/505990\.5±8593\.85990\.5\{\\pm\}8593\.83500\.75±300\.993500\.75\{\\pm\}300\.990/521036\.2±3297\.521036\.2\{\\pm\}3297\.5Hybrid8\.26±3\.59\\mathbf\{8\.26\{\\pm\}3\.59\}29/50201\.9±210\.3201\.9\{\\pm\}210\.3171\.41±225\.19171\.41\{\\pm\}225\.1915/507240\.7±9825\.57240\.7\{\\pm\}9825\.52359\.13±702\.19\\mathbf\{2359\.13\{\\pm\}702\.19\}0/1063408\.9±28316\.763408\.9\{\\pm\}28316\.7GS4CO13\.89±10\.3813\.89\{\\pm\}10\.380/50249\.1±268\.4249\.1\{\\pm\}268\.4609\.94±836\.20609\.94\{\\pm\}836\.200/4510303\.9±13451\.610303\.9\{\\pm\}13451\.62937\.46±189\.532937\.46\{\\pm\}189\.530/530500\.2±5994\.130500\.2\{\\pm\}5994\.1SCIP14\.18±8\.2414\.18\{\\pm\}8\.240/50124\.5±229\.6124\.5\{\\pm\}229\.6274\.02±309\.37274\.02\{\\pm\}309\.370/508361\.4±12497\.38361\.4\{\\pm\}12497\.32955\.81±982\.012955\.81\{\\pm\}982\.010/20115143\.9±50744\.5115143\.9\{\\pm\}50744\.5MILP\-Evo9\.03±5\.479\.03\{\\pm\}5\.4718/50232\.6±227\.9232\.6\{\\pm\}227\.9166\.69±176\.54166\.69\{\\pm\}176\.546/5010109\.2±14585\.510109\.2\{\\pm\}14585\.52895\.95±1040\.372895\.95\{\\pm\}1040\.375/24133883\.2±73442\.1133883\.2\{\\pm\}73442\.1GNN\-GPU5\.31±2\.145\.31\{\\pm\}2\.14\-/50172\.7±182\.5172\.7\{\\pm\}182\.5102\.20±138\.75102\.20\{\\pm\}138\.75\-/505990\.5±8593\.85990\.5\{\\pm\}8593\.82492\.68±1269\.692492\.68\{\\pm\}1269\.69\-/20102635\.8±54080\.0102635\.8\{\\pm\}54080\.0COPT6\.88±3\.326\.88\{\\pm\}3\.32\-/50297\.4±412\.9297\.4\{\\pm\}412\.999\.64±115\.8599\.64\{\\pm\}115\.85\-/5012207\.1±17679\.612207\.1\{\\pm\}17679\.62718\.71±1135\.032718\.71\{\\pm\}1135\.03\-/25175771\.1±80573\.4175771\.1\{\\pm\}80573\.4Facilities:EasyMediumHardModelTime\(s\)WinsNodesTime\(s\)WinsNodesTime\(s\)WinsNodesFSB81\.02±59\.5681\.02\{\\pm\}59\.560/5071\.0±61\.171\.0\{\\pm\}61\.1806\.48±669\.60806\.48\{\\pm\}669\.600/50233\.9±223\.3233\.9\{\\pm\}223\.32108\.21±1143\.002108\.21\{\\pm\}1143\.000/41109\.6±77\.2109\.6\{\\pm\}77\.2RPB36\.03±25\.7036\.03\{\\pm\}25\.7016/5090\.4±110\.290\.4\{\\pm\}110\.2305\.37±232\.06305\.37\{\\pm\}232\.066/50588\.6±645\.0588\.6\{\\pm\}645\.0607\.57±221\.14\\mathbf\{607\.57\{\\pm\}221\.14\}15/50260\.1±171\.7260\.1\{\\pm\}171\.7GNN50\.48±41\.7450\.48\{\\pm\}41\.740/50287\.6±271\.4287\.6\{\\pm\}271\.4478\.05±510\.82478\.05\{\\pm\}510\.827/50881\.4±827\.2881\.4\{\\pm\}827\.2669\.15±321\.01669\.15\{\\pm\}321\.018/50462\.3±300\.8462\.3\{\\pm\}300\.8Hybrid35\.09±28\.81\\mathbf\{35\.09\{\\pm\}28\.81\}17/50253\.2±244\.9253\.2\{\\pm\}244\.9325\.92±284\.35325\.92\{\\pm\}284\.3514/50895\.3±896\.8895\.3\{\\pm\}896\.8631\.09±296\.42631\.09\{\\pm\}296\.4217/50456\.6±297\.0456\.6\{\\pm\}297\.0GS4CO68\.69±64\.1768\.69\{\\pm\}64\.170/50273\.6±267\.3273\.6\{\\pm\}267\.3558\.56±475\.23558\.56\{\\pm\}475\.231/50933\.8±861\.2933\.8\{\\pm\}861\.2731\.28±387\.37731\.28\{\\pm\}387\.374/50449\.9±294\.0449\.9\{\\pm\}294\.0SCIP38\.27±22\.9338\.27\{\\pm\}22\.935/5099\.5±84\.399\.5\{\\pm\}84\.3305\.10±241\.99305\.10\{\\pm\}241\.992/50541\.1±606\.3541\.1\{\\pm\}606\.3675\.33±284\.41675\.33\{\\pm\}284\.413/50194\.6±148\.3194\.6\{\\pm\}148\.3MILP\-Evo35\.66±23\.3535\.66\{\\pm\}23\.3512/50235\.5±237\.6235\.5\{\\pm\}237\.6266\.21±218\.47\\mathbf\{266\.21\{\\pm\}218\.47\}20/50926\.8±957\.4926\.8\{\\pm\}957\.4761\.88±360\.30761\.88\{\\pm\}360\.303/50429\.1±288\.0429\.1\{\\pm\}288\.0GNN\-GPU33\.44±24\.3033\.44\{\\pm\}24\.30\-/50287\.6±271\.4287\.6\{\\pm\}271\.4267\.77±220\.73267\.77\{\\pm\}220\.73\-/50881\.4±827\.2881\.4\{\\pm\}827\.2546\.13±258\.44546\.13\{\\pm\}258\.44\-/50462\.3±300\.8462\.3\{\\pm\}300\.8COPT8\.20±5\.798\.20\{\\pm\}5\.79\-/50221\.0±194\.4221\.0\{\\pm\}194\.431\.56±27\.8831\.56\{\\pm\}27\.88\-/50572\.0±587\.5572\.0\{\\pm\}587\.558\.06±27\.4658\.06\{\\pm\}27\.46\-/50262\.8±164\.6262\.8\{\\pm\}164\.6

### C\.2Additional Search Curves

Figure[3](https://arxiv.org/html/2607.18252#A3.F3)reports the search traces for all four benchmark families\. Each curve tracks the best fitness found during the evolutionary search, providing a family\-level view of how useful callback programs emerge beyond the independent\-set example shown in the main text\. Since the plotted value is the best archived fitness, the curves are monotone and should be read as discovery traces rather than as the performance of every sampled program\.

The curves share a staircase pattern: long plateaus are interrupted by a small number of large drops\. This behavior is consistent with program search in a constrained solver API\. Many candidate edits are either invalid, behaviorally neutral, or only locally useful; occasionally, however, a structural change in cut filtering, branching priority, or their interaction produces a qualitatively better callback\. After such a candidate is found, the archive retains it and subsequent search starts from a stronger incumbent\.

The family\-level dynamics differ in ways that match the quantitative results\. Combinatorial auctions improve rapidly in the early part of search and then enter a long low\-fitness plateau, suggesting that the search finds an effective solver strategy relatively quickly and later iterations mostly refine it\. Independent set also improves early, but unlike combinatorial auctions it continues to obtain meaningful late\-stage gains; this is consistent with the strong transfer performance of the final independent\-set callback\. Set covering and facility location show longer plateaus and smaller late improvements\. Their curves indicate that the search still discovers better programs, but improvements arrive less frequently and the final incumbents are less dominant, matching the more mixed results in Table[5](https://arxiv.org/html/2607.18252#A3.T5)\.

Overall, the search curves indicate that progress is uneven and problem\-dependent\. All four families exhibit incumbent improvements after initialization, but the timing and magnitude of these improvements vary substantially\. Combinatorial auctions and independent set show clearer early or sustained gains, whereas set covering and facility location spend longer periods on plateaus and obtain smaller late\-stage improvements\. This pattern is consistent with the evaluation results, where transfer performance is strongest on the families with clearer search progress\.

![Refer to caption](https://arxiv.org/html/2607.18252v1/figures/appendix/token_analysis_milp-indset.png)

\(a\) Maximum independent set

![Refer to caption](https://arxiv.org/html/2607.18252v1/figures/appendix/token_analysis_milp-cauctions.png)

\(b\) Combinatorial auction

![Refer to caption](https://arxiv.org/html/2607.18252v1/figures/appendix/token_analysis_milp-setcover.png)

\(c\) Set covering

![Refer to caption](https://arxiv.org/html/2607.18252v1/figures/appendix/token_analysis_milp-facilities.png)

\(d\) Capacitated facility location

Figure 3:Additional search curves across the four benchmark families\. Lower fitness values indicate better candidate callback programs under the search objective\.

## Appendix DBroader Impacts

MILP\-Evo studies automatic design of explicit solver components for mixed\-integer linear programming\. The most direct positive impact is computational: better domain\-specialized cut\-selection and branching rules can reduce the time and energy required to solve recurring optimization problems\. Because the discovered artifacts are executable PySCIPOpt callbacks rather than opaque neural predictors, they can be inspected, modified, and deployed within standard solver workflows\. This transparency may make learned solver customization more usable for researchers and practitioners who need to audit optimization logic before using it in production systems\.

The same capability also has potential risks\. Faster MILP solving can improve decision systems in domains such as logistics, scheduling, manufacturing, network design, and resource allocation; some of these deployments may affect people if the underlying mathematical model encodes biased objectives, incomplete constraints, or sensitive business rules\. Our method optimizes solver behavior, not the social desirability of the optimization model being solved\. Thus, an automatically designed solver component should not be interpreted as a guarantee that the resulting decision process is fair, safe, or appropriate for a high\-stakes application\.

There are also technical risks specific to LLM\-generated solver code\. A candidate callback may be syntactically valid and fast on benchmark instances while still containing brittle assumptions, solver\-version dependencies, or edge\-case behavior that appears only on unseen instance distributions\. We mitigate these risks in the research setting by using public synthetic benchmark families, running candidates inside SCIP with explicit callback\-contract checks, assigning invalid or unsuccessful runs infinite fitness during search, and evaluating the final artifact by end\-to\-end solver execution\. For any deployment beyond benchmark evaluation, we recommend manual inspection of the exported callback, stress testing on representative and adversarial instances, solver\-version pinning, and domain\-specific review of the MILP formulation and objective\.

This work does not use private data, human\-subject data, or scraped personal information\. The experiments are conducted on standard synthetic MILP benchmark families, and the proposed method does not release a model that directly generates natural\-language content for end users\.

## Appendix EAssets and Licenses

Table[6](https://arxiv.org/html/2607.18252#A5.T6)lists the existing assets used in this work and their licenses or terms\. We retain third\-party notices and do not redistribute commercial solvers or code whose redistribution terms are not explicit\.

Table 6:Used assets and their licenses\.All benchmark instances used in this work are synthetic MILP instances from standard learn2branch\-style distributions\. They do not contain personal data, human\-subject data, copyrighted media, or scraped web content\.