LongWoF-Bench: Evaluating Evolved Procedural Guidance for Verifiable Long-Workflow Tasks

Chapter 1: Introduction

As large models improve at long-context modeling, tool use, and code execution, their applications are expanding from isolated question answering to complex scenarios that require a sequence of operations. In a Markdown-to-Repository task, for example, a model must read a requirements document and an existing codebase, produce an implementation plan and task list, modify the code, and run tests to validate the result. In a rule-driven task, the model must maintain intermediate state, perform multi-step reasoning, and ultimately return a valid result that satisfies every constraint.

We call these tasks end-to-end long-workflow tasks. Formally, given an initial input $(x)$, an actionable environment $(E_0)$, a constraint set $(C)$, and a verifier $(V)$, the model must generate a sequence of interdependent actions $a_1,a_2,\ldots,a_T$. These actions drive state transitions $E_t=f(E_{t-1},a_t)$ and ultimately produce an outcome $(y)$. A task is an end-to-end long workflow when later actions depend on state or intermediate artifacts created by earlier actions and success is determined uniformly by the verifiable terminal condition $V(x,E_T,y,C)=1$. Here, “long workflow” refers to cross-stage dependency and continuously evolving state, not merely input length, output length, or execution time.

Under explicit output constraints, the model must turn multiple dependent judgments or operations into a final deliverable that a program or rule can verify precisely. A “workflow” does not always mean external tool calls. In code and agent tasks, it can include reading input files, obeying a CLI contract, producing specified JSON/TXT artifacts, and passing hidden tests. In mathematical and rule tasks, it can involve selecting a formula, handling boundaries, applying rule priority, and normalizing the answer format. In every case, success depends both on understanding the task and on correctly implementing a series of constraints in a verifiable deliverable.

To study this capability, we draw on programming tasks from SkillsBench (Li et al., 2026) and the rule-retrieval framing of GuideBench (Diao et al., 2025). We identify common long-workflow task types and sources of difficulty created by combinations of constraints, then introduce LongWoF-Bench. Its 778 verified tasks cover four common task types: code generation (code_generation), mathematical reasoning (math_reasoning), rule following (rule_following), and agent orchestration (agent_env_synth). The tracks also cover different forms of verifiable delivery. Code emphasizes program generation and hidden tests; mathematics emphasizes exact short answers and normalization; rule following emphasizes priorities and discrete decisions; and agent environments emphasize package interfaces, multiple output files, and pytest-style verification. A shared task manifest, hidden evaluator, and strict scoring protocol place these different tasks in one workflow-completion framework.

The benchmark addresses three research questions:

• RQ1: How reliable are current models on cross-track, machine-verifiable long-workflow tasks?
• RQ2: How do auxiliary prompts such as Skill and Gene affect task pass rate and token consumption?
• RQ3: Which task types, model types, and Gene construction sources benefit most from procedural guidance?

These questions examine a model's ability to complete tasks independently, use procedural knowledge, and trade off the applicability and cost of different assistance methods.

To answer them, we evaluate several models on the same tasks, execution environments, and hidden evaluators under three conditions: no auxiliary context (no_context), a predefined task manual (Skill), and an experience-derived procedural prompt, Gene (Wang et al., 2026). Skill describes the workflow, interface use, rule-execution procedure, and common pitfalls. Gene uses structured fields to represent the task pattern, applicability signals, execution strategy, preflight checks, and critical constraints. Genes are constructed either from model trajectories that passed verification or, when no successful trajectory exists, from teacher signals provided by a reference solution. All auxiliary assets undergo leakage auditing so that answers and other critical information are not exposed in the prompt. We compare strict pass rates and token use under the three conditions, then group results by task type, model type, and Gene source.

The experiment yields three main findings. First, even the strongest model, Opus 4.8, reaches only a 20.2% strict pass rate without auxiliary context, showing that current models still cannot complete these long-workflow tasks reliably. Second, procedural assistance improves performance, but its benefits and costs differ by form. Overall, Gene provides more effective task guidance with fewer tokens than Skill. Third, the benefit is not uniform: it changes substantially with task type, model capability, and Gene construction source. The value of procedural knowledge therefore depends on how well it matches both the model and the task.

The report makes three contributions corresponding to those questions.

• First, we build a unified benchmark for end-to-end long-workflow tasks. LongWoF-Bench covers four task types with 778 verifiable tasks and uses hidden evaluators plus strict output rules to measure completion on every task.
• Second, we introduce and implement Gene as a structured auxiliary prompt. Compared with a more complete Skill manual, Gene represents procedural experience in shorter, more auditable fields. Under a defined evolution process, it extracts the highest-value information from a strong model's execution flow and packages that information as an auxiliary prompt. This turns assistance from an ordinary long prompt into an experimental condition that can be compared and analyzed.
• Third, we systematically compare three conditions across models and task tracks: no auxiliary context, Skill, and Gene. Without prompt assistance, even Opus 4.8 reaches only a 20.2% strict pass rate, confirming that the benchmark remains challenging. Evolved Genes are more valuable than Skills for solving long-workflow tasks and consume fewer tokens.

Chapter 2: Building LongWoF-Bench

2.1 Benchmark task design

2.1.1 Building end-to-end long-workflow tasks

The core LongWoF-Bench task unit consists of a public task specification, a deliverable space, and a hidden verifier:

The public specification $(S)$ provides the initial input $(x)$, actionable environment $(E_0)$, and constraint set $(C)$. The deliverable space $\mathcal{Y}$ describes what the model must submit, and $(V)$ is a verifier hidden from the model. The model performs a sequence of interdependent actions $a_1,\ldots,a_T$, driving the environment from $(E_0)$ to $(E_T)$ and producing a final deliverable $y\in\mathcal{Y}$. The task passes when $V(x,E_T,y,C)=1$.

Consider the LongWoF-Bench task that asks a model to build orchestration code for an adaptive cruise-control system. Its specification $(S)$ includes vehicle-parameter files, 150 seconds of sensor data, and interface and performance requirements for cruise, following, and emergency-braking modes. Its deliverable space $\mathcal{Y}$ includes code files for the PID controller, cruise-control system, and simulator, together with tuning results, simulation data, and an analysis report. The model must implement the controller and mode-switching logic, tune the PID parameters, run the full simulation, and keep all deliverables consistent.

The hidden verifier $(V)$ checks file existence and several additional properties. It imports and invokes the submitted classes, reruns the simulation, verifies control modes, interfaces, and output formats, and checks performance measures including rise time, overshoot, steady-state error, safe following distance, and acceleration bounds. It also changes the PID parameters and verifies that system behavior changes accordingly. This distinguishes a functioning control system from hard-coded simulation output.

A structurally complete or superficially plausible program is therefore insufficient. The final code and every derived deliverable must jointly satisfy $V(x,E_T,y,C)=1$.

This definition also sets the admission criteria for benchmark tasks. First, a task must have a describable public specification from which the model can obtain the information needed to solve it, through the prompt, accessible inputs, callable interfaces, or output instructions. Second, the task must support machine execution or exact matching so that the outcome does not depend on subjective grading. Third, the evaluator must separate model-visible and hidden information. The model may see the prompt, input files, accessible package interfaces, output protocol, and the Skill or Gene injected under the relevant condition. It must not see hidden test data, gold answers, internal verifier logic, reference solutions, or private constants available only to the evaluator. This boundary is required for the later comparison to be fair.

2.1.2 LongWoF-Bench workflow tracks

The current LongWoF-Bench release retains 778 verified tasks. The four evaluation tracks differ as follows:

The tracks produce different kinds of deliverables, but all require the model to turn constraints in the public specification into a verifiable result. Code and agent failures appear through program execution and file checks. Mathematics and rule failures appear through answer normalization and exact matching. The shared framework prevents those differences from disappearing into one aggregate score and lets later analysis reveal which tasks depend most on external procedural guidance.

2.1.3 LongWoF-Bench task synthesis

Tasks follow a “public prompt plus hidden evaluation” design. Starting from a predefined seed, each task receives a model-visible task.md that explains the objective, input and output formats, and available data. The task directory also contains test data, a reference solution, hidden gold output, and an automatic evaluator. During formal evaluation, the model receives only the public prompt and any auxiliary context for its assigned condition. After it produces an answer or program, the hidden evaluator executes it, compares outputs, records whether it passed, and measures token use. The benchmark therefore measures whether a model can actually complete a task under complex rules, data processing, code execution, and formatting constraints, not whether it remembers a multiple-choice answer.

Unlike a conventional single-format benchmark, LongWoF-Bench consistently asks whether the end-to-end deliverable works. Code and agent programs must execute. Mathematics and rule answers must parse and match under a strict format. Later experiments can fairly compare no auxiliary context, Skill, and Gene because all three conditions face the same tasks and verifiers; only the auxiliary information supplied to the model changes.

2.2 Constructing auxiliary prompts: Skill and Gene

Many failures in complex workflows occur not because the model lacks all relevant knowledge, but because it fails to invoke the right execution process consistently. It may know to read the data but overlook the output protocol; understand a rule but fail to check a higher-priority override first; or choose a common algorithm without noticing that a boundary condition defeats its default strategy. The precise failing step is not known in advance, so task execution must yield genuinely useful procedural experience that can be supplied as assistance.

We introduce a new auxiliary prompt: a Gene based on the GEP protocol (EvoMap, 2026a). Unlike a conventional Skill, Skill resembles a predefined task manual, while Gene resembles procedural experience distilled from successful execution (EvoMap, 2026b). Skill is a human-authored auxiliary document defined before the task runs and cannot adapt to the model's execution process. Gene summarizes procedural experience that a model itself distills under the Gene rules while executing the task.

Gene has a different objective. It does not try to cover all background information. Instead, it compresses a verified successful path into a structured procedural prompt: the problem pattern, the signals showing when the strategy applies, the critical execution steps, the boundaries that need preflight checks, and the checks required before submission. Genes in this experiment come from two sources. One is a successful model trajectory that passed verification on the task. The other, used when no successful trajectory exists, is distilled from a teacher signal provided by the reference solution. The former most directly represents experience distilled from actual success: it keeps the part that changed the execution path instead of writing another longer manual.

The two prompts are also synthesized differently:

• Skill is a fairly complete task manual covering task type, recommended process, interface rules, common pitfalls, and output requirements. In this benchmark version, Skills are primarily rewrites of task-construction and reference-solution material followed by auditing. They are therefore strong instructional conditions, rather than marketplace-style Skills generated from only the public prompt.
• Gene is shorter and can be understood as an execution prompt compressed from successful experience. When a model finds a passing solution using the public prompt and verifier feedback, the Gene is distilled from that trajectory. If the first attempt fails, the next rollout mutates: the model receives a truncated public task, its earlier attempt, and sanitized execution feedback, then produces a corrected solution. The process repeats until the verifier passes or the rollout budget is exhausted. If exploration never succeeds, the current pipeline falls back to distillation from the reference solution.

Consider a simple example. A task asks the model to select a cleaning action for equipment after producing a “sunflower and sesame paste,” using residue-risk rules for a food-processing line. The difficulty is rule ordering, not output format. Both ingredients are seeds and are co-processed into a homogeneous paste. The model must apply exemption precedence before calculating the maximum risk score and mapping it to a threshold.

The case shows the distinction. Skill gives a complete process and warns the model not to omit exemptions, but still leaves the critical priority decision to the model. Gene compresses the correction learned after two strong-model failures into a harder execution order: first apply the co-processing exemption so the sesame allergen surcharge is not added directly to the highest risk; then take the maximum post-exemption score and map it to the middle tier. Gene is not merely a shorter manual. It turns the most error-prone step and its correct ordering into procedural guidance available in one run.

Thus, Skill provides static instruction, while Gene supplies a compressed execution strategy; Skill is a signpost, while Gene is a path already traveled. The three experimental conditions can now be defined precisely:

• no_context measures end-to-end completion using only the public prompt;
• with_skill measures whether the model can use a relatively complete but static task description;
• with_gene measures whether the model can use a shorter, more structured procedural guide derived from successful experience or a teacher signal.

Chapter 3: Experimental results

3.1 Experimental setup and statistical definitions

We evaluate seven models on the 778 LongWoF-Bench tasks. The set contains 127 agent_env_synth, 341 code_generation, 151 math_reasoning, and 159 rule_following tasks. Every model runs under three conditions:

• no_context: the model receives only the public prompt;
• with_skill: the public prompt is supplemented by a complete Skill for the current task;
• with_gene: the public prompt is supplemented by a procedural Gene.

The primary metric is strict task pass rate. A task counts as passed only when all checkpoints pass and the verifier returns passed=true. Token cost is the sum of input, output, and recordable thinking tokens.

We distinguish four evaluation sets by Gene source:

The model used to construct Genes in this experiment is Claude Opus 4.8. The evolution strategy increases thinking effort from weak to strong across rollout attempts rather than fixing a thinking level and changing a conventional temperature coefficient. The strong model first solves the public task. After a failure, it revises the solution using sanitized verifier feedback, for at most three rollouts. As soon as one rollout actually passes the verifier, a Gene is distilled from that successful trajectory.

3.2 Overall experimental results (RQ1: How reliable are current models on cross-track, machine-verifiable long-workflow tasks?)

The following table reports the complete results on the Opus-evolved subset. Under no_context, the strongest model, Claude Opus 4.8, passes only 54.8% of tasks; the other models range from 31.7% to 47.6%. Even the best model therefore fails nearly half the tasks during one unassisted run. Current models do not handle these cross-track, machine-verifiable workflows reliably on their own and still benefit from auxiliary prompts.

Every with_opus_gene result here uses a Gene distilled from a verified real execution trajectory produced by Claude Opus 4.8, rather than a rewrite of the reference answer. The Opus Gene clearly outperforms Skill for every tested model. When a Gene compresses the process learned through successful model exploration, downstream models can use it more reliably than a complete descriptive Skill.

We run a contrasting analysis to separate the effect of Gene structure from the effect of successful evolution. On the remaining reference-distilled tasks, the conclusion reverses: Gene generally underperforms Skill. This result strengthens the interpretation that the advantage does not come from merely compressing answer-related information. It comes from the evolved strategy distilling a successful execution process into reusable procedural guidance. Evolved process structure, rather than prompt compression alone, produces the gain.

3.3 Token-cost analysis (RQ2: How do Skill and Gene affect pass rate and token use?)

The experiment compares two ways for Opus 4.8 to solve the same tasks:

• Conventional strong-model exploration: a capable model attempts the task, reads sanitized verifier feedback after failure, and tries again up to the allowed limit until one attempt passes. This is the baseline.
• EvoMap Gene-assisted execution: a Gene distilled from strong-model experience becomes procedural context that any model can use for one with_gene attempt. The pass rate is much higher than without Gene, while token consumption is substantially lower than multi-round exploration. This is our mode.

This section counts input_tokens + output_tokens + thoughts_tokens. For Claude Opus 4.8, provider output tokens already include thinking, so “Output incl. Thinking” denotes the recoverable completion-side total. The multi-round baseline counts only the tokens used in solve/mutate rollouts that discover a passing trajectory; it does not include the later Gene-distillation cost.

Conventional multi-round exploration:
252 tasks
  -> Round 1 solve, thinking off
     -> pass: distill Gene
     -> fail: sanitized verifier feedback
  -> Round 2 mutate, thinking low
     -> pass: distill Gene
     -> fail: sanitized verifier feedback
  -> Round 3 mutate, thinking high
     -> pass: distill Gene

Total: 404 model calls, 252 verified successful trajectories

Single-round Gene reuse:
252 tasks + Opus Genes
  -> one with_gene_opus attempt per task
  -> 252 model calls, 200 passed tasks

This evaluation set contains every task that ultimately produced a verified trajectory during multi-round exploration. The first row below simulates the conventional multi-round process and is not a one-call pass rate. The remaining rows report one-shot solving on the same tasks with the corresponding auxiliary condition.

The table supports four direct conclusions:

1. no_context appears to use the fewest tokens, but passes only 138 of 252 tasks. It saves context while also discarding a large amount of procedural information.
2. Skill raises the pass count from 138 to 161 but total tokens reach 803,099. A static task manual helps, but is not necessarily economical.
3. Opus Gene passes 200 tasks in one round, 39 more than Skill, while using 79,619 fewer tokens, a 9.9% reduction.
4. Compared with Opus multi-round exploration, one-round Gene reuse reduces calls from 404 to 252, eliminating 152 exploratory calls, and lowers total tokens from 1,333,968 to 723,480, a 45.8% reduction.

Gene's token efficiency does not come solely from a shorter prompt. It turns failure feedback, correction steps, and the eventual successful workflow from multi-round exploration into injectable procedural memory. A later model receives the resulting execution strategy instead of beginning trial and error from zero. Gene does not place the answer in the prompt; it makes an execution path that originally required multiple attempts available as reusable procedural context.

3.4 Opus Gene versus Skill by task type (RQ3: Which task types, model types, and Gene sources benefit from procedural guidance?)

Splitting the 252 Opus-evolved tasks by type produces a more detailed view. The four groups contain 64, 62, 30, and 96 tasks, totaling 252. These tables therefore describe only evolved Genes and exclude reference-distilled Genes. Opus Gene delivers its most consistent gains on agent environments and rule following, while code and mathematics depend more strongly on the target model.

agent_env_synth (64 tasks)

code_generation (62 tasks)

math_reasoning (30 tasks)

rule_following (96 tasks)

On agent_env_synth, Opus Gene outperforms Skill for all seven models, with gains from +15.6 to +29.7 percentage points. Environment tasks still require package behavior, multiple files, and test constraints, but interface and execution ordering distilled from successful trajectories consistently reduce omissions.

Rule following also improves for all seven models, by +2.1 to +22.9 percentage points. Many rule-task failures come from inconsistent handling of priority, overrides, equality boundaries, or discrete option constraints rather than an inability to read the prompt. Gene makes those procedural checks explicit and helps the model reach the correct decision.

Code generation is mixed. Sonnet, Gemini Flash, and Qwen Coder benefit from Gene; Opus, Gemini Pro, and Qwen 3.5 decline slightly; MiniMax is unchanged. Compressed procedural guidance can reduce interface and workflow omissions, but does not always replace a more complete Skill. The effect depends on how the target model uses the two forms of context.

Mathematical reasoning requires the most caution. Opus 4.8 rises from 43.3% to 83.3%; Gemini Pro and the two models at 0% remain unchanged; Sonnet, MiniMax, and Qwen 3.5 decline. Short-answer mathematics depends heavily on exact symbolic execution, boundary calculation, and answer normalization. Procedural guidance can suggest a method but cannot replace computation and may distract some models.

These track-level results explain why LongWoF-Bench spans multiple tracks. An aggregate score can show that assistance helps, but only track-level analysis reveals which task forms benefit and where the problems remain.

3.5 Common evolved overlap: Gemini Gene versus Opus Gene

The evolved task sets for Gemini Gene and Opus Gene are not identical, so comparing each on its own full set would be invalid. We instead use the 180 tasks evolved by both. Opus Gene remains consistently stronger than Gemini Gene on this overlap, showing that the capability of the Gene-authoring model affects the usability of the resulting Gene.

3.6 Case studies

Case 1: code_generation / T0161, drillhole assay compositing

Task. A geoscience pipeline reads collars.csv and assays.csv. Assay rows may contain overlapping depth intervals and below-detection markers such as '<0.01'. The program must: (1) convert <x into x/2; (2) resolve overlapping depth intervals into mutually exclusive segments; (3) re-composite those segments into fixed two-meter bins from depth 0 to max_depth; (4) calculate an alteration_index for each bin; and (5) calculate each hole's mineralization_score as the sum of composite Au/Cu values above the prospect-wide median, where the median is computed across every two-meter composite in the dataset.

Conventional process and how Opus evolved the Gene:

• Rollout 1 (solve) → FAIL (pass_rate=0.875). Opus resolved overlaps with a “later interval wins” rule: the later row overwrote the earlier one wherever they overlapped.
• Rollout 2 (mutate) → FAIL (pass_rate=0.875). Opus kept the same convention and only strengthened NaN handling. The overlap test still failed.
• Rollout 3 (mutate) → PASS (pass_rate=1.0). Opus changed the overlap semantics. Instead of letting the later interval win, it averaged values from every interval covering the segment, then length-weighted those segments into the two-meter bins. This matched the expected compositing semantics and passed.

The breakthrough was semantic: overlapping assay intervals must be averaged rather than overwritten. That is what the Gene captures.

Evolved Gene (T0161.json, payload):

{
  "type": "Gene",
  "summary": "Build a geoscience/interval pipeline that cleans below-detection markers, resolves overlapping depth intervals, composites into fixed-length bins, and emits per-row and per-entity aggregate CSVs.",
  "category": "innovate",
  "signals_match": [
    "drillhole assay compositing",
    "below-detection limit markers like '<0.01'",
    "overlapping depth intervals to mutually exclusive segments",
    "fixed-length 2-meter downhole composites",
    "alteration index / mineralization score formulas",
    "prospect-wide median threshold aggregation",
    "--input/--output directory CLI with named CSV outputs",
    "length-weighted interval averaging"
  ],
  "strategy": [
    "Parse CLI --input/--output dirs; read collars and assays CSVs by exact column names; create output dir with makedirs(exist_ok=True).",
    "Clean value columns: convert '<x' strings to x/2 (half detection limit), '>x' to x, blanks/'na' to NaN, else float; coerce depth columns to numeric.",
    "Per hole, resolve overlaps: collect breakpoints from all from/to bounds, for each adjacent segment use midpoint to find covering intervals and average their values into one exclusive segment.",
    "Composite into exact fixed-length bins from 0 to max_depth (ceil(max_depth/len) bins); for each bin length-weight each value by overlap length with segments, divide by total weight, NaN if none.",
    "Compute per-bin derived index per given formula guarding zero/NaN denominators; write one CSV with hole_id, bin from/to, and index using the required header order.",
    "Compute dataset-wide medians across ALL bins for threshold columns; per hole sum bin values exceeding their respective medians for the score and take per-hole max values; write the summary CSV with exact headers.",
    "Verify both output files exist, column names/order match the contract, and every hole appears even with empty or missing assays."
  ],
  "preconditions": [
    "Medians for scoring must be computed across the full composited dataset, not per hole.",
    "Bins must span exactly 0..max_depth and exist for holes with no assay coverage (values NaN).",
    "Overlap resolution must produce mutually exclusive segments before any compositing aggregation.",
    "String/NaN/empty assay cells must be sanitized before numeric ops to avoid type errors."
  ],
  "constraints": { "max_files": 1, "forbidden_paths": [".env", "secrets", "credentials"] },
  "validation": []
}

Gemini Pro without Gene: failed. Gemini's resolve_overlaps sorted the intervals and truncated the previous interval at the next interval's start, a “trim, do not combine” method that discarded overlapping values:

prev = resolved[-1]
if row['depth_from'] < prev['depth_to']:
    if row['depth_from'] > prev['depth_from']:
        prev['depth_to'] = row['depth_from']   # trim only; discard overlap contribution
    else:
        resolved.pop()
resolved.append(row)

The result was FAIL:L2_prospect_summary_adv_overlap - Mismatch in mineralization_score for key ('H003',): got 0.0, expected 202.0. Overlap handling removed the contribution that drove the score.

Gemini Pro with Gene: passed. Guided by the Gene's “collect breakpoints, average covering intervals, then length-weight into bins” strategy, Gemini built breakpoint segments, averaged every covering interval, and then length-weighted the segments into two-meter bins:

boundaries = sorted(set(hole_assays['depth_from']).union(hole_assays['depth_to']))
for seg_from, seg_to in adjacent_pairs(boundaries):
    covering = hole_assays[(hole_assays.depth_from <= seg_from) & (hole_assays.depth_to >= seg_to)]
    seg_data[col] = np.average(vals[valid], weights=w[valid])   # average, not overwrite

Without Gene, the model defaulted to the common interval-merge heuristic “later wins / trim the previous interval.” It looks reasonable, but is wrong for assay compositing and reduced H003's mineralization score to zero. Opus had learned across two failed rollouts that the correct convention is length-weighted averaging. Gene gave Gemini that precise convention, allowing it to composite correctly on the first attempt.

Case 2: rule_following / T0659, emergency dispatch code

Task. Given a 911 scenario involving an indoor domestic disturbance, a subject holding a kitchen knife (bladed weapon), no visible injuries, and a geolocation exactly 5 ZDU away, choose the correct dispatch code from dispatch_omega, dispatch_sigma, dispatch_theta, and dispatch_zeta. The decision depends on two interacting rules: the distance-threshold comparison (does exactly 5 strictly exceed the cutoff?) and weapon/injury precedence (weapon present with no injury maps to the armed-without-injury tier).

Conventional process and how Opus evolved the Gene:

• Rollout 1 (solve) → FAIL (pass_rate=0.667). Opus declined to commit, argued that the rule table was missing, emitted the placeholder dispatch_omega, and said the choice could not be verified.
• Rollout 2 (mutate) → FAIL (pass_rate=0.667). Opus selected dispatch_theta, reasoning that a weapon escalated the response regardless of the distance threshold. This over-escalated the case: it ignored the no-injury downgrade and treated the boundary distance as an escalation trigger.
• Rollout 3 (mutate) → PASS (pass_rate=1.0). Opus applied the precedence correctly. Exactly 5 ZDU does not strictly exceed the threshold, so the distance escalation does not trigger. A weapon with no injury maps to the armed-without-injury tier: dispatch_sigma.

Evolved Gene (T0659.json, payload):

{
  "type": "Gene",
  "summary": "Select a dispatch/response code by applying weapon and injury precedence rules combined with a strict ZDU/distance threshold comparison, emitting an exact two-line ANSWER/ANALYSIS contract.",
  "category": "other",
  "signals_match": [
    "dispatch code selection",
    "threshold comparison on distance units (ZDU)",
    "rule precedence for weapon-involved incidents",
    "ANSWER and ANALYSIS exact two-line output",
    "weapon present but no visible injuries",
    "911 / emergency dispatch scenario",
    "choose one of several action tokens",
    "case-insensitive exact-match grading"
  ],
  "strategy": [
    "Extract every decision factor from the prompt: weapon present?, injuries present?, distance value, and the exact stated threshold.",
    "Apply the threshold as written: treat 'exactly equal' as NOT exceeding unless rule says >= (strict vs non-strict matters most for boundary values).",
    "Resolve precedence order: injury-tier > armed-no-injury > distance-only codes; pick the highest-priority rule whose conditions are fully satisfied.",
    "When a weapon exists but injuries are explicitly denied, choose the armed-but-no-injury tier, not the injury escalation or plain distance code.",
    "Map the satisfied rule to its corresponding code token and verify it is one of the allowed options.",
    "Emit exactly two lines: 'ANSWER: <token>' then 'ANALYSIS: <one paragraph ≤80 words citing the rule>', with no extra output or whitespace lines."
  ],
  "preconditions": [
    "Confirm whether the boundary value triggers escalation (strict > vs >=) before deciding distance effect.",
    "Verify the chosen token is spelled exactly as an allowed option for case-insensitive exact match.",
    "Ensure precedence (weapon/injury rules) overrides distance-only codes when both apply."
  ],
  "constraints": { "max_files": 1, "forbidden_paths": [".env", "secrets", "credentials"] },
  "validation": []
}

Gemini Pro without Gene: failed. Gemini over-escalated the weapon and mishandled the boundary, selecting dispatch_theta:

ANSWER: dispatch_theta
ANALYSIS: ... because the subject is exactly 5 ZDU away ..., the threshold comparison for a weapon-related incident indicates dispatch_theta ...

This is the same mistake Opus made in rollout 2: treating the boundary distance plus weapon as requiring the higher tier while ignoring the no-injury downgrade.

Gemini Pro with Gene: passed.

ANSWER: dispatch_sigma
ANALYSIS: ... a bladed weapon with no visible injuries at exactly 5 ZDU ... under the rule precedence, the combination of weapon and close distance ... no active injury indicates the dispatch_sigma code.

The task has two well-known traps: a strict versus non-strict boundary (does exactly 5 “exceed” the threshold?) and precedence order (injury > armed without injury > distance only). The no-context model failed on both, as Opus had before converging. Gene states both rules explicitly: treat equality as not exceeding unless the rule says >=, and map weapon present with denied injury to the armed-without-injury tier rather than injury escalation. Gemini therefore applies the precedence correctly and selects dispatch_sigma.

What the two cases share

Both cases expose the same failure pattern: a reasonable default heuristic violates a task-specific contract.

• T0161: treating a later interval as overwriting an earlier one discards overlap contributions.
• T0659: assuming that a weapon always escalates the response ignores the no-injury downgrade and the strict distance threshold.

Opus needed two or three rollouts to isolate the corrective rule in each case. The evolved Gene records that rule in a few strategy and preconditions lines, allowing Gemini to apply it on the first attempt.

The code case shows how Gene can avoid repeated debugging and large rewrites. The rule-following case shows how it can prevent repeated priority and boundary mistakes. Together they explain why procedural guidance can reduce exploration cost without implying a uniform gain on every task type.

References

• Diao, L., Xu, X., Sun, W., Yang, C., & Zhang, Z. (2025). GuideBench: Benchmarking Domain-Oriented Guideline Following for LLM Agents. ACL 2025, 11361-11399.
• EvoMap. (2026a). GEP Protocol Deep Dive: Genetic Engineering for AI Agent Self-Evolution.
• EvoMap. (2026b). Agent Skill vs GEP Gene: The Fundamental Divide Between Tools and Evolution.
• Li, X., et al. (2026). SkillsBench: Benchmarking How Well Agent Skills Work Across Diverse Tasks. arXiv:2602.12670.
• Wang, J., Ren, Y., & Zhang, H. (2026). From Procedural Skills to Strategy Genes: Towards Experience-Driven Test-Time Evolution. arXiv:2604.15097.