---
title: 'EVOM: Evolving Executable Artifacts'
url: https://www.emergentmind.com/topics/evom
type: topic
---

# EVOM: Evolving Executable 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 [2604.00442] [2606.26327]. 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)** [1106.0190]. 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 [2604.00442] [2606.26327] [1106.0190].

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 [2604.00442]. 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 [2604.00442].

## 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** [2604.00442]. 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 \(c \in \{0,1\}\) is the execution success flag, \(\sigma\) is solver status, \(v\) is an objective value if available, and \(\ell\) 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:
\[
R(y,o;a)=r_{fmt}(y)+r_{ans}(o;a).
\]
The format reward enforces valid `<think>` and `<code>` structure. The main supervision comes from the outcome correctness reward, which gives reward \(1\) only if the code executes successfully and the returned status or objective matches the ground truth. For numeric optima, correctness uses
\[
IsClose(v,a)\iff \left(|v-a| < \epsilon_{abs}\right)\lor \left(\frac{|v-a|}{\max(|a|,\delta)} < \epsilon_{rel}\right),
\]
with
\[
\epsilon_{abs}=\epsilon_{rel}=10^{-4}, \quad \delta=10^{-12}.
\]
For status-only answers, the solver status must equal the ground-truth status. Otherwise the reward is \(0\).

Optimization is performed with **Group Relative Policy Optimization (GRPO)** and **DAPO**. In GRPO, rewards are standardized within a sampled group using
\[
A_i = \frac{R_i - \mu_R}{\sigma_R + \delta_A},
\]
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 \((q,a)\) pairs and solvers \(s\), builds \(x=(q,s)\), samples a group of candidate outputs, parses the unique `<code>` block, executes the code in the sandboxed solver environment, computes \(r_{fmt}\), \(r_{ans}\), 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 \((q,a)\) 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 [2606.26327]. 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 \(p \in \mathcal{A}\) be an architecture program. The actor and critic are defined by
\[
\mu_\theta(o)=\pi_\theta(o;p), \qquad v_\phi(o)=V_\phi(o;p).
\]
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 \((n_b, m)\) and `ValueNet(obs_length)` returning a value tensor of shape \((n_b,1)\). Valid programs must compile, produce correct tensor shapes, output finite values, and not crash during PPO training. Invalid programs receive a penalty fitness of **\(-1000\)**.

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 \(G\) 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 | \(2517.06 \pm 366.24\) | \(1691.42 \pm 495.26\) |
| MLES | \(1185.26 \pm 84.15\) | \(1045.71 \pm 134.04\) |
| Random Search | \(988.15 \pm 2.81\) | \(3612.87 \pm 1953.45\) |
| EVOM | \(4652.10 \pm 746.91\) | \(5381.07 \pm 1357.70\) |

Ablations show that **mixed reproduction performs best**, with mutation-only and crossover-only both worse. Population size **\(N=16\)** is reported as best, while **\(N=8\)** is worse and **\(N=32\)** 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)** [1106.0190]. 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 [2604.00442] [2606.26327] [1106.0190].

This spectrum is consistent with several neighboring 2026 directions. **EvoLen** argues that tokenization in DNA language models 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 \(\sum_i |t_i|^2\) [2604.08698]. **EvoLM** uses co-evolved, instance-specific discriminative rubrics to post-train language models 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 [2605.03871]. 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.

Source: https://www.emergentmind.com/topics/evom