EVOM: Evolving Executable Artifacts

• EVOM is a cluster of research programs using execution feedback to evolve executable artifacts across optimization modeling, RL architecture search, and physical systems.
• Execution-Verified Optimization Modeling transforms natural language problems into solver-specific code verified in a sandboxed loop, bypassing cumbersome process-level supervision.
• Agentic Meta-Evolution automatically discovers actor-critic architectures via an LLM-driven evolutionary search, while the 'Evolution of Things' vision pioneers evolving tangible artifacts.

Searching arXiv for relevant EVOM usages and the cited papers. EVOM is an overloaded term in the arXiv literature. In 2026 it names two distinct machine-learning frameworks: Execution-Verified Optimization Modeling, which trains an LLM to convert natural-language optimization problems into solver-specific executable code, and Agentic Meta-Evolution of Actor-Critic Architectures for Reinforcement Learning, which automates actor-critic network design through an outer evolutionary loop wrapped around PPO training (Guan et al., 1 Apr 2026, Zhang et al., 24 Jun 2026). In a broader evolutionary-computing lineage, the related vision “Evolution of Things” describes a move from “the evolution of code” to the evolution of physical, tangible artifacts under Embodied Artificial Evolution (EAE) (Eiben et al., 2011). This suggests that EVOM is best understood not as a single canonical method, but as a cluster of research programs centered on executable artifacts, iterative selection, and the replacement of manual design by structured search or verification.

1. Terminological scope and disambiguation

The acronym EVOM does not denote a single research object. In the supplied arXiv corpus, it refers to two 2026 frameworks with different problem settings, while also standing adjacent to the earlier “Evolution of Things” formulation in embodied evolutionary systems.

Usage	Full name	Core target
EVOM	Execution-Verified Optimization Modeling	Solver-specific optimization code from natural language
EVOM	Agentic Meta-Evolution of Actor-Critic Architectures for Reinforcement Learning	Actor-critic architecture programs
Evolution of Things	Embodied Artificial Evolution umbrella vision	Physical, tangible evolving artifacts

The first EVOM addresses optimization modeling as a natural-language-to-program synthesis problem in which correctness is checked by an actual mathematical programming solver. The second EVOM addresses RL architecture search as a bi-level optimization problem in which candidate architecture programs are repeatedly trained and selected. “Evolution of Things,” by contrast, is a field-defining vision about moving evolutionary computation from disembodied simulation into physically embodied systems (Guan et al., 1 Apr 2026, Zhang et al., 24 Jun 2026, Eiben et al., 2011).

A common misconception is that these usages are minor variants of one another. They are not. One is execution-verified RL for solver code, one is agentic meta-evolution for actor-critic architectures, and one is a broader conceptual program in embodied evolution.

2. EVOM as execution-verified optimization modeling

Execution-Verified Optimization Modeling is a framework for automating optimization modeling from natural-language problem statements by having an LLM produce solver-specific executable code that can be checked by an actual mathematical programming solver (Guan et al., 1 Apr 2026). The target setting is standard operations research workflow: a model must interpret the problem correctly, formulate variables, constraints, and objectives precisely, and obey solver-specific APIs and syntax for backends such as Gurobi, OR-Tools, and COPT.

The framework is motivated by limitations in two prior paradigms. Prompting-based methods use agentic, multi-turn prompting, reflection, or self-correction, often with strong closed-source LLMs, but tend to have high inference latency, high cost, and dependence on closed-source models. Process-supervised SFT methods train smaller open-source models with intermediate variable definitions, derivations, or reference code, but process supervision is expensive and such models often overfit to one solver API, generalizing poorly across solvers. EVOM replaces that dependence on process-level annotations with outcome-only supervision plus execution feedback from the solver.

The core formulation conditions on a natural-language problem $q$ and a target solver $s$, with input $x=(q,s)$. The policy produces structured output $y=(y_{think},y_{code})$, where $y_{code}$ is solver-specific Python code and the prompt asks for exactly

$<think>\dots</think><code>\dots</code>.$

The prompt inserts the solver name as a plain string and does not provide solver-specific exemplars or reference programs. This is important because the model is expected to learn solver conventions through execution feedback rather than supervised imitation.

Training data are built from OR-Instruct-3K, using 3,000 optimization problems while keeping only natural-language descriptions and ground-truth outcomes and discarding intermediate process annotations. Evaluation is reported on NL4OPT, MAMO, IndustryOR, and OptiBench, with the main base model being Qwen2.5-7B. The reported findings are that EVOM matches or beats process-supervised SFT, supports zero-shot solver transfer, enables low-cost solver adaptation by continuing training under a new solver backend, shows nearly identical performance curves for GRPO and DAPO, benefits smaller Qwen2.5 models as well, and can use a light cold-start strategy for COPT based on translating Gurobi code to COPT, filtering by execution, doing a small amount of SFT, and then continuing EVOM (Guan et al., 1 Apr 2026).

3. Verification loop, rewards, and optimization in execution-verified EVOM

The distinctive mechanism in execution-verified EVOM is the closed loop generate $\rightarrow$ execute $\rightarrow$ feedback $\rightarrow$ update (Guan et al., 1 Apr 2026). Generated code is run in a sandboxed harness under a 10s timeout and 2 GB memory cap. The harness returns a standardized observation

$o=(c,\sigma,v,\ell),$

where $s$0 is the execution success flag, $s$1 is solver status, $s$2 is an objective value if available, and $s$3 contains logs. The paper presents this standardization as making verification deterministic and solver-agnostic.

Reward construction is split into a format term and an outcome term: $s$4 The format reward enforces valid > and <code> structure. The main supervision comes from the outcome correctness reward, which gives reward $s$5 only if the code executes successfully and the returned status or objective matches the ground truth. For numeric optima, correctness uses

$s$6

with

$s$7

For status-only answers, the solver status must equal the ground-truth status. Otherwise the reward is $s$8.

Optimization is performed with Group Relative Policy Optimization (GRPO) and DAPO. In GRPO, rewards are standardized within a sampled group using

$s$9

followed by the clipped policy objective with a KL term relative to a reference policy. DAPO removes the KL penalty, uses asymmetric clipping, and can skip uninformative groups such as all-failure samples. The paper reports that the resulting performance curves are nearly identical, which it interprets as evidence that the main benefit comes from execution-verified learning itself rather than the specific optimizer choice.

Algorithmically, the training loop samples $x=(q,s)$0 pairs and solvers $x=(q,s)$1, builds $x=(q,s)$2, samples a group of candidate outputs, parses the unique <code> block, executes the code in the sandboxed solver environment, computes $x=(q,s)$3, $x=(q,s)$4, and total reward, standardizes rewards within each group, and updates the policy with GRPO or DAPO until convergence. A frequent misunderstanding is that EVOM depends on chain-of-thought labels or reference programs; the paper explicitly defines it as outcome-only supervision, using only problem-answer pairs $x=(q,s)$5 together with the solver’s execution result.

4. EVOM as agentic meta-evolution of actor-critic architectures

The second 2026 EVOM is “Agentic Meta-Evolution of Actor-Critic Architectures for Reinforcement Learning”, a framework for automatically discovering actor-critic network architectures by combining an LLM-based architecture designer with a meta-evolution loop that evaluates those designs with PPO (Zhang et al., 24 Jun 2026). Its starting point is that actor-critic architectures are usually manually chosen, even though design choices such as hidden size, depth, residual blocks, normalization, activation functions, and actor-critic asymmetry can strongly affect training stability and final return.

The paper formulates the problem as bi-level optimization. Let $x=(q,s)$6 be an architecture program. The actor and critic are defined by

$x=(q,s)$7

The outer loop searches over architecture programs; the inner loop learns weights. Full-budget evaluation is too expensive, so search uses a low-fidelity PPO training run as a proxy fitness estimate. In practice, PPO is used in two regimes: 100k timesteps during search and 5M timesteps for full-budget retraining of the selected best architecture.

A crucial design point is that the LLM is not the RL controller. It acts only as an architecture designer: it initializes the population, mutates architecture programs, and performs crossover. It is explicitly decoupled from policy execution and environment control: it does not observe raw trajectories, does not learn policy weights, does not interact with the environment directly, and does not replace PPO. Candidate programs must define PolicyNet(obs_length, act_length) returning an action mean of shape $x=(q,s)$8 and ValueNet(obs_length) returning a value tensor of shape $x=(q,s)$9. Valid programs must compile, produce correct tensor shapes, output finite values, and not crash during PPO training. Invalid programs receive a penalty fitness of $y=(y_{think},y_{code})$0.

The outer loop is iterative rather than one-shot: initialize a population with the LLM design agent, generate offspring with mutation or crossover, train and evaluate each offspring using low-budget PPO, rank all candidates, select elites, repeat for $y=(y_{think},y_{code})$1 generations, and then retrain the best architecture under the full budget. The default reproduction schedule generates half the offspring by mutation and half by crossover.

Quantitative results are reported on Ant-v4 and HalfCheetah-v4, both using VecNormalize.

Method	Ant-v4	HalfCheetah-v4
Manual PPO	$y=(y_{think},y_{code})$2	$y=(y_{think},y_{code})$3
MLES	$y=(y_{think},y_{code})$4	$y=(y_{think},y_{code})$5
Random Search	$y=(y_{think},y_{code})$6	$y=(y_{think},y_{code})$7
EVOM	$y=(y_{think},y_{code})$8	$y=(y_{think},y_{code})$9

Ablations show that mixed reproduction performs best, with mutation-only and crossover-only both worse. Population size $y_{code}$0 is reported as best, while $y_{code}$1 is worse and $y_{code}$2 is not better and sometimes worse, which the paper attributes to noise in low-budget PPO evaluation. The LLM backbone also matters: Claude Opus 4.7 is best on Ant-v4, whereas DeepSeek V4 is best on HalfCheetah-v4. The discovered elite architectures often contain residual blocks, normalization, SiLU activations, dropout, output-scale handling, deeper MLPs, LayerNorm-SiLU combinations, and actor-critic asymmetry. A common misunderstanding here is that EVOM is an LLM-based controller; the paper emphasizes the opposite, namely that it is a search procedure over trainable architectures while PPO remains the learner.

5. “Evolution of Things” and embodied artificial evolution

The earlier “Evolution of Things” paper introduces an umbrella vision for a new field called Embodied Artificial Evolution (EAE) (Eiben et al., 2011). In this framing, evolution is moved out of purely digital, simulation-based spaces and into the physical world, so that the evolved entities are physical, tangible objects rather than only virtual individuals. The paper presents this explicitly as a transition from “the evolution of code” to the evolution of things.

The contrast with traditional evolutionary computation is central. Classical evolutionary computation is described as disembodied: populations consist of virtual entities such as bitstrings, expressions, or neural nets; all operators occur inside a computer; and the process is usually used as an off-line design tool. Even when the end target is a physical artifact, the artifact is typically built only after the evolutionary process ends. EAE instead aims at evolution taking place “outside the computer” and acting directly on real artifacts such as robots, bacteria, synthetic cells, programmable matter, fabricated objects, or other embodied artifacts.

The paper gives a four-point characterization of EAE. It: involves physical units, has real birth and death, is fully asynchronous and autonomous with no centrally orchestrated main loop, and is driven by a mixture of task-based and open-ended, environmental fitness. This definition is used to distinguish EAE from weaker forms of embodiment. In weakly embodied systems, the evolved objects remain digital but are hosted by robots or other physical devices, with fitness evaluated in vivo. In strongly embodied EAE, the objects themselves are physical, so reproduction, mutation, crossover, selection, and death all occur in the material world.

The enabling technologies are organized into hardware, wetware, and hybrid systems. Hardware refers to mechatrono-robotic systems. Wetware refers to bio-chemical systems, including top-down synthetic biology and bottom-up chemical systems. Hybrid systems combine mechatronic and biochemical components. The paper identifies 3D printing, soft robotics, molecular engineering, synthetic biology, combinatorial chemistry, programmable matter, microfluidics, and functional fluids as especially relevant.

Illustrative applications include robot companions or artificial pets, environment-friendly organisms such as synthetically designed bacteria for oil-spill cleanup, and evolutionary 3-D printing or evolutionary fabrication, described through the phrase “the co-evolution of form and formation.” The paper also identifies major grand challenges: body types, robot reproduction, kill switch, evolvability and speed of evolution, and process control methodology, including the need for on-line monitoring, steering, directed evolution, and a freeze switch. Another frequent misconception is to equate EAE with online evolutionary robotics; the paper argues that strongly embodied evolution is a more radical shift because reproduction and selection themselves must occur in the material world.

6. Broader research context and recurring design principles

Across these usages, EVOM-related work occupies different points on a spectrum from verification-driven learning to evolutionary search to embodied evolutionary systems. The execution-verified EVOM treats a solver as a deterministic interactive verifier and removes the need for process-level supervision. The actor-critic EVOM treats architecture search as program evolution under noisy low-fidelity PPO evaluation. “Evolution of Things” generalizes the evolutionary paradigm to physical birth, death, and selection in the material world (Guan et al., 1 Apr 2026, Zhang et al., 24 Jun 2026, Eiben et al., 2011).

This spectrum is consistent with several neighboring 2026 directions. EvoLen argues that tokenization in DNA LLMs is an inductive bias and injects cross-species evolutionary information by stratifying the genome with phyloP, training separate BPE tokenizers, merging vocabularies with a conservation-prioritized rule, and decoding with a length-aware dynamic-programming objective that maximizes $y_{code}$3 (Huang et al., 9 Apr 2026). EvoLM uses co-evolved, instance-specific discriminative rubrics to post-train LLMs without human annotation or external supervision, alternating between a rubric generator and a policy while preference signals come from temporal contrast between current and earlier checkpoints (Li et al., 5 May 2026). These are not themselves EVOM frameworks, but they show that “evolution,” “co-evolution,” and executable feedback are increasingly used as explicit inductive biases rather than only as loose metaphors.

A plausible implication is that the most important commonality across EVOM usages is not the acronym but the methodological stance: search and learning are organized around artifacts that can be executed, evaluated, or physically instantiated. In one case the artifact is solver code; in another it is an architecture program; in the embodied-evolution vision it is the physical unit itself. Under that interpretation, EVOM names a family of approaches in which correctness, fitness, or survival arises from interaction with a concrete environment rather than from static annotation alone.