VETR：基于执行的自我改进智能体，用于符号图形推理

# VETR: Execution-Grounded Self-Improving Agent for Symbolic Graphics Reasoning
Source: [https://arxiv.org/html/2610.13098](https://arxiv.org/html/2610.13098)
Kuangshi AiAffiliation:University of Notre DameGordon DaiAffiliation:New York UniversityChenglong YuAffiliation:New York UniversityChaoli WangAffiliation:University of Notre DameHua ShenAffiliation:New York University

###### Abstract

Visual agents for symbolic graphics reasoning depend on executable world representations, yet continued improvement remains bottlenecked by ambiguous supervision from final renders\. Recent agentic systems refine scenes through repeated interaction, but they lack mechanisms to recursively extract actionable evidence from execution traces, overlooking which proposed symbolic edits survived, disappeared, or interfered during program execution\. To address this, we propose VETR \(VerifiedExecutionTrajectories forRefinement\), a framework that enables*agentic recursive self\-improvement*over executable world representations for symbolic graphics reasoning\. Within each task, VETR retains aligned program/render records with bounded runtime observations and introduces an*execution refiner*that compiles observed writes and state changes into constrained alternative programs\. The refiner validates their endpoints and preservation conditions against captured runtime state; the ordinary visual verifier then assesses goal relevance\. Repair construction makes no additional language\-model calls, but can require additional executions\. Evaluations on BlenderGym \(280 tasks\) and BlenderBench \(27 released tasks\) with GPT\-5\.6\-luna and Qwen3\.8\-27B show that VETR consistently outperforms existing refinement strategies, including BlenderAlchemy and VIGA\. Controlled ablations evaluate the contributions of execution refinement and role\-asymmetric evidence organization under fixed generator\-interaction caps\.

## 1Introduction

Large Language Model \(LLM\) agents have made remarkable strides in code generation, visual reasoning, and interactive editing by equipping LLMs with tools, planning, and self\-refinement capabilities\([Madaan et al\., 2023](https://arxiv.org/html/2610.13098#bib.bib10);[Shinn et al\., 2023](https://arxiv.org/html/2610.13098#bib.bib12);[Gou et al\., 2024](https://arxiv.org/html/2610.13098#bib.bib6)\)\. Building on this progress, recent systems for symbolic graphics reasoning formulate scene understanding and editing as an iterative process where a generator proposes program modifications and a verifier evaluates the rendered output\([Yin et al\., 2026](https://arxiv.org/html/2610.13098#bib.bib17);[Kuang et al\., 2026](https://arxiv.org/html/2610.13098#bib.bib21)\)\. These systems demonstrate that agentic interaction improves over one\-shot generation and that executable programs can serve as world representations specifying geometry, materials, lighting, and spatial relationships\([Wang et al\., 2026a](https://arxiv.org/html/2610.13098#bib.bib27)\)\. However, final\-render feedback alone does not expose edit causality: an image comparison need not reveal which proposed symbolic edits survived execution, which were silently overwritten, or which interfered with shared scene resources\.

This motivates an execution\-evidence interface alongside visual feedback\([Yin et al\., 2026](https://arxiv.org/html/2610.13098#bib.bib17);[Kuang et al\., 2026](https://arxiv.org/html/2610.13098#bib.bib21)\)\. Additional iterations can supply new proposals, but do not directly expose effects omitted from the feedback interface\. Logging alone also leaves open how observed values should become alternative programs\([Wang et al\., 2026a](https://arxiv.org/html/2610.13098#bib.bib27)\)\. We address this with supported update operators and explicit runtime preservation checks\. Observed writes supply hypotheses about alternative executions, while visual verification remains responsible for assessing those alternatives against the task goal\.

![Refer to caption](https://arxiv.org/html/2610.13098v1/VETR_figure1.png)Figure 1:Conceptual overview of VETR\.VETR refines scenes through execution\-grounded evidence, bridging a scene program, its execution trace, and the realized 3D scene\. Given a start and goal image, the system performs iterative updates guided by observed writes and realized bindings\. This evidence\-supported refinement targets viewpoint alignment, appearance \(lighting/material\) editing, and geometry and placement adjustments\. Runtime checks test supported effects, while visual feedback guides subsequent proposals toward the goal\.To address this, we proposeVETR\(VerifiedExecutionTrajectories forRefinement\), a framework for execution\-grounded, within\-task program refinement\. VETR retains aligned executable records and uses a private execution refiner to construct alternatives from observed writes and state transitions\. The refiner compiles supported numerical changes and compatible resource bindings, then checks their endpoints and preservation conditions by fresh execution, without additional language\-model calls\. It delivers a runtime\-valid alternative when available, otherwise retaining the raw successful result or the preceding delivered record after failure\. The ordinary visual verifier assesses the delivered result, and the generator conditions its next proposal on the available execution outcomes and feedback\. This is the recursive program\-revision loop depicted in Figure[1](https://arxiv.org/html/2610.13098#S1.F1); Algorithms[1](https://arxiv.org/html/2610.13098#alg1)and[2](https://arxiv.org/html/2610.13098#alg2)specify its refiner and host loop\.

We evaluate VETR on BlenderGym \(280 editing tasks across five families\) and BlenderBench \(27 released tasks at three difficulty levels\) with GPT\-5\.6\-luna and Qwen3\.8\-27B\. VETR is the strongest complete system on both benchmarks and both backbones, and paired comparisons confirm gains are not artifacts of completion rates\. Ablations isolate the improvement to the execution refiner \(disabling it reduces six\-cell BlenderBench improvement from\+54\.45%\+54\.45\\%to\+35\.33%\+35\.33\\%on GPT and\+56\.17%\+56\.17\\%to\+30\.09%\+30\.09\\%on Qwen\), and to role asymmetry and execution history \(with GPT on BlenderGym, removing role asymmetry or limiting history raisesN​\-​C​L​I​PN\\text\{\-\}CLIP/P​LPLerrors by 12\.7%/23\.7% and 48\.5%/79\.0%, respectively\)\. These results support contributions from execution refinement and evidence organization within the evaluated agent loop; fixed generator\-interaction caps do not imply equal total execution cost\.

Our contributions are summarized as follows:

- •Executable world representation for symbolic graphics reasoning\.We build on scene representation work to establish executable programs as the foundation for iterative scene editing, enabling direct manipulation of geometry, materials, lighting, and spatial relationships\.
- •Agentic recursive self\-improvement with an execution refiner\.We formulate scene refinement as a propose–execute–observe–verify cycle and design a refiner that compiles execution\-trace evidence into bounded program updates under preservation constraints, without additional LLM inference\([Madaan et al\., 2023](https://arxiv.org/html/2610.13098#bib.bib10);[Shinn et al\., 2023](https://arxiv.org/html/2610.13098#bib.bib12);[Gou et al\., 2024](https://arxiv.org/html/2610.13098#bib.bib6)\)\.
- •Empirical validation on graphics editing benchmarks\.We evaluate on BlenderGym and BlenderBench across two backbones, showing consistent gains over VIGA\([Yin et al\., 2026](https://arxiv.org/html/2610.13098#bib.bib17)\)and BlenderAlchemy, with controlled ablations evaluating execution refinement and context organization within the host loop\.

![Refer to caption](https://arxiv.org/html/2610.13098v1/vetr_figure2.png)Figure 2:Execution\-evidence refinement before visual assessment\.Each complete program executes fromBB\. The private refiner constructs alternatives, compiles supported changes and compatible bindings, and checks their realization relative to the candidate’s reference record\. For the numerical channel,WhW\_\{h\}contains selected cells,𝒞h∖Wh\\mathcal\{C\}\_\{h\}\\setminus W\_\{h\}contains captured cells to preserve, and properties outside𝒞h\\mathcal\{C\}\_\{h\}are not covered by that contract\. Goal\-image comparison occurs only in the ordinary visual verifier\. Delivery, shortcuts, and the six\-execution cap are specified in Algorithm[1](https://arxiv.org/html/2610.13098#alg1)\. Repair construction makes no additional language\-model calls\.
## 2Method

VETR refines complete scene programs through a*propose–execute–observe–verify*loop\. A private execution refiner constructs alternatives from bounded runtime observations and checks their realization before ordinary visual verification\. Runtime acceptance and visual goal assessment serve different purposes: the former checks a candidate’s stated effects and preservation conditions; the latter guides subsequent editing toward the goal\.

### 2\.1Executable World Representation

A task supplies a base sceneBB, an editable initial programp0p\_\{0\}, a start imager0r\_\{0\}, and a goal imagey⋆y^\{\\star\}\. Following code\-based scene representations\([Wang et al\., 2026a](https://arxiv.org/html/2610.13098#bib.bib27)\), the generator submits a complete Python programqtq\_\{t\}, conditioned on the task and its retained interaction history\. Complete means executable relative to the supplied objects and assets inBB, not a standalone scene constructor\. Each submission and repair executes afresh fromBB; the initial program is not run as an extra preparation step before each submission\.

The*raw execution record*zt=\(qt,rt,St,τt\)z\_\{t\}=\(q\_\{t\},r\_\{t\},S\_\{t\},\\tau\_\{t\}\)associates the submitted program with its render, captured state, and observed writes\. The captured state isSt=\(θt,Πt,Gt\)S\_\{t\}=\(\\theta\_\{t\},\\Pi\_\{t\},G\_\{t\}\), whereθt\\theta\_\{t\}stores supported numerical properties,Πt\\Pi\_\{t\}stores object\-to\-resource references, andGtG\_\{t\}stores captured scene structure\. The bounded write trace is

τt=\[\(oi,ki,vi,ℓi\)\]i=1mt,\\tau\_\{t\}=\\bigl\[\(o\_\{i\},k\_\{i\},v\_\{i\},\\ell\_\{i\}\)\\bigr\]\_\{i=1\}^\{m\_\{t\}\},\(1\)where an event records the owner resolved at execution time, a supported property path, its observed value, and its source location\. The observer covers supported assignments in the submitted source, including local helpers; imported\-library writes and unresolved aliases do not provide owner\-qualified events\. Unobserved effects remain unknown\. Execution failures retain available observations and diagnostics, with unavailable record fields left undefined\.

We distinguishztz\_\{t\}from the*delivered record*z¯t\\bar\{z\}\_\{t\}, which may contain a repaired program, the raw result, or the preceding delivered recordz−z^\{\-\}\. Generated program/render pairs retain their common provenance\. Initial observations\(S0,τ0\)\(S\_\{0\},\\tau\_\{0\}\)are obtained by executingp0p\_\{0\}once without an additional render\. We denote the initial reference byz0=\(p0,r0,S0,τ0\)z\_\{0\}=\(p\_\{0\},r\_\{0\},S\_\{0\},\\tau\_\{0\}\), markingr0r\_\{0\}as the supplied visual anchor, not a render from that observation pass\. The refiner takesz0z\_\{0\}so that both initial writes and their final endpoints are available \(Appendix[B](https://arxiv.org/html/2610.13098#A2)\)\.

### 2\.2Execution Refiner

The refiner examines every submitted execution, including successful proposals whose images already improve\. Planning actions do not invoke it\. It usesztz\_\{t\}, the initial observations, andz−z^\{\-\}to construct and validate alternative complete programs without additional language\-model calls\.

#### Candidate effects from execution evidence\.

For a supported non\-light cell\(o,k\)\(o,k\)and source executions∈\{t,0\}s\\in\\\{t,0\\\}, define its*displaced\-value indices*inτs\\tau\_\{s\}as the observed writes whose values differ from that source’s final endpoint\. The recovery endpoint is the latest such value:

ℐs​\(o,k\)\\displaystyle\\mathcal\{I\}\_\{s\}\(o,k\)=\{i:oi=o,ki=k,vi≄θs\(o,k\)\},\\displaystyle=\\\{i:o\_\{i\}=o,\\ k\_\{i\}=k,\\ v\_\{i\}\\not\\simeq\\theta\_\{s\}\(o,k\)\\\},\(2\)v^s​\(o,k\)\\displaystyle\\widehat\{v\}\_\{s\}\(o,k\)=vmax⁡ℐs​\(o,k\)whenℐs\(o,k\)≠∅\.\\displaystyle=v\_\{\\max\\mathcal\{I\}\_\{s\}\(o,k\)\}\\quad\\text\{when \}\\mathcal\{I\}\_\{s\}\(o,k\)\\neq\\varnothing\.Here≃\\simeqdenotes the runtime checker’s numerical agreement predicate\. Current and initial traces supply separate recovery hypotheses, both applied to the current complete program\. The light\-recovery channel similarly reconstructs observed owner\-local energy/color requests displaced by later shared writes, resetting earlier requests after explicit data rebinding\. These values are alternative endpoints, not inferred user intent or proof that a later assignment was erroneous\.

In the ordered controller, if no recovery candidate has been accepted, the light channel considers eligible full and half effective changes betweenS−S^\{\-\}, the previous delivered state, andStS\_\{t\}\. For owners in the submitted edit’s supported scope, the*projected light endpoint*is

uα,o=ϕ⁡\(S−​\(o\)\)\+α⁡\[ϕ⁡\(St​\(o\)\)−ϕ⁡\(S−​\(o\)\)\],α∈\{1,12\},u\_\{\\alpha,o\}=\\phi\(S^\{\-\}\(o\)\)\+\\alpha\\bigl\[\\phi\(S\_\{t\}\(o\)\)\-\\phi\(S^\{\-\}\(o\)\)\\bigr\],\\qquad\\alpha\\in\\\{1,\\tfrac\{1\}\{2\}\\\},\(3\)whereϕ⁡\(E,c\)=E​c\\phi\(E,c\)=Ecis the compiler’s effective\-value map for light energyEEand colorcc\. Projection modifies the previous delivered program, retaining its other captured state\. It therefore differs from recovery, which modifies the raw proposal\. The map supplies algebraic parameter targets, not a guarantee about the rendered image\.

#### Compatible values and resource ownership\.

Each candidatehhspecifies a reference recordzhrefz\_\{h\}^\{\\mathrm\{ref\}\}, required endpoints, and permitted changes\. Recovery useszhref=ztz\_\{h\}^\{\\mathrm\{ref\}\}=z\_\{t\}; projection useszhref=z−z\_\{h\}^\{\\mathrm\{ref\}\}=z^\{\-\}\. The compiler appends a patch to that reference program, producingqh′q^\{\\prime\}\_\{h\}\. It retains reference values for other captured cells and makes permitted local resource copies when shared owners require incompatible endpoints\. Compatible sharing is retained\. Non\-light compilation restores supported values directly; light compilation uses a bounded reconstruction ofϕ\\phiand compatible owner tuples\. Becauseϕ\\phiis not one\-to\-one, its formula alone does not specify the reconstruction rule \(Appendix[B](https://arxiv.org/html/2610.13098#A2)\)\.

#### Runtime realization and preservation\.

The compiled program executes afresh fromBB\. For the numerical\-property channel, let𝒞h\\mathcal\{C\}\_\{h\}be the reference’s captured supported cells,Wh⊆𝒞hW\_\{h\}\\subseteq\\mathcal\{C\}\_\{h\}the selected write support, anddhd\_\{h\}its required numerical endpoints\. Fresh readback must satisfy

θh′​\(c\)≃\{dh​\(c\),c∈Wh,θhref​\(c\),c∈𝒞h∖Wh\.\\theta^\{\\prime\}\_\{h\}\(c\)\\simeq\\begin\{cases\}d\_\{h\}\(c\),&c\\in W\_\{h\},\\\\ \\theta\_\{h\}^\{\\mathrm\{ref\}\}\(c\),&c\\in\\mathcal\{C\}\_\{h\}\\setminus W\_\{h\}\.\\end\{cases\}\(4\)Additional checks cover captured node/mesh structure, protected object frames, and render context\. Light candidates are checked against their captured owner tuples, effective endpoints, and permitted reference changes\. The captured cells𝒞h∖Wh\\mathcal\{C\}\_\{h\}\\setminus W\_\{h\}are known values to preserve; properties outside𝒞h\\mathcal\{C\}\_\{h\}are not covered by this numerical contract\. Channel\-specific checks constrain the refiner’s changes relative to its reference, not every change made by the generator, and are not relaxed after failure\.

#### Validation and delivery\.

The fixed order is current/initial non\-light recovery, current/initial light recovery, then full\-/half\-effect projection\. Unsupported alternatives or those lacking required evidence cannot pass the contract\. Algorithm[1](https://arxiv.org/html/2610.13098#alg1)makes the six\-additional\-execution cap explicit and returns the first accepted alternative\. It also retains endpoint\-based skip rules: raw reuse as full\-effect projection requires that candidate’s complete runtime contract relative toz−z^\{\-\}\. If the endpoint matches but those checks fail, the reported branch skips the compiled full\-effect program rather than executing it\. Such a skip is not proof of an equivalent rerender; Appendix[B](https://arxiv.org/html/2610.13098#A2)explains its implications\. If no alternative is accepted, retain a successful raw result, otherwise reuse the exact preceding record\. Raw fallback is not certification under a repair contract\.

The ordinary visual verifier then evaluates the delivered result againsty⋆y^\{\\star\}\. Passing a runtime contract neither requires nor guarantees lower image error\. The recursion is within\-task program revision: subsequent proposals use the delivered result and retained feedback, without a monotonic\-improvement guarantee or a claim that each program encodes the entire history\.

### 2\.3Role\-Asymmetric Evidence Organization

The refiner’s internal evidence and the agents’ visible contexts are distinct\. The refiner consumes observed writes, captured endpoints, and resource bindings\. The generator retains its actions and delivered tool outcomes in a bounded multimodal history, with 24 recent messages by default and the task/planning inputs pinned separately\. The visual verifier receives the current delivered comparison and returns a goal\-directed critique; its default context is reset rather than sharing the generator’s accumulated transcript\. This organization does not require either agent to interpret the complete private trace\. The three\-message and shared\-memory variants change these context policies \(Appendix[G](https://arxiv.org/html/2610.13098#A7)\)\.

Algorithm[2](https://arxiv.org/html/2610.13098#alg2)places execution refinement inside the host loop and distinguishes the generator\-interaction cap from additional repair executions\. At widthN\>1N\>1, each executed candidate is refined before the visual tournament selects a delivered outcome\. Final evaluation uses the last successful selected render from a completed run, not the best historical image; failures do not replace its associated program\. The supplied start image alone does not constitute a successful generated answer \(Appendix[N](https://arxiv.org/html/2610.13098#A14.SS0.SSS0.Px3)\)\.

## 3Experiments

### 3\.1Experiment Setup

We evaluate the complete VETR system on two established test suites, BlenderGym\([Gu et al\., 2025](https://arxiv.org/html/2610.13098#bib.bib8)\)and BlenderBench\([Yin et al\., 2026](https://arxiv.org/html/2610.13098#bib.bib17)\), which evaluate program\-based 3D graphics editing across diverse visual modification tasks\. Throughout the main benchmark results, VETR denotes the full system with execution refinement enabled by default; the otherwise matched variant with refinement disabled is reported only in the ablation study\.

Tasks and systems\.BlenderGym contains 280 editing tasks: 85 blend\-shape, 50 placement, 55 geometry, 45 lighting, and 45 material tasks\([Gu et al\., 2025](https://arxiv.org/html/2610.13098#bib.bib8)\)\. Each task supplies an initial program, start image, and goal image\. BlenderBench contains 27 released tasks across three difficulty levels, with nine tasks per level\. We compare One\-Shot \(direct generation from the initial program and visual target without iterative feedback\), BlenderAlchemy, VIGA, and VETR\. GPT\-5\.6\-luna uses three separate 280\-task cohorts: systems, context ablations, and scene origin/guidance\. All GPT\-5\.6\-luna and Qwen3\.8\-27B runs use Blender 3\.6\.0, and every paired task shares a runtime\. VIGA/VETR allow ten generator interactions\. Each ablation changes only its named setting; system comparisons retain each system’s instructions and execution conventions\. Table[16](https://arxiv.org/html/2610.13098#A14.T16)maps these cohorts to the full results and configurations\.

Measurements\.We report negative CLIP similarityN​\-​C​L​I​P=1−⟨f^​\(r\),f^​\(y⋆\)⟩N\\text\{\-\}CLIP=1\-\\langle\\hat\{f\}\(r\),\\hat\{f\}\(y^\{\\star\}\)\\rangle, using unit\-normalized CLIP ViT\-B/32 embeddings, and photometric lossP​LPL, the RGB mean squared error in\[0,1\]\[0,1\]\([Radford et al\., 2021](https://arxiv.org/html/2610.13098#bib.bib11)\)\. Lower is better; tables scale both by 100\. The same stored answer renders also provide PSNR, SSIM, AlexNet LPIPS, Canny edge F1, and CLIP similarity\([Wang et al\., 2004](https://arxiv.org/html/2610.13098#bib.bib19);[Zhang et al\., 2018](https://arxiv.org/html/2610.13098#bib.bib20)\)\. For PSNR, SSIM, edge F1, and CLIP similarity, higher is better, whereas for LPIPS, lower is better\. PSNR is computed per image before averaging; CLIP andN​\-​C​L​I​PN\\text\{\-\}CLIPare algebraically related\. Edge F1 uses thresholds 100/200 on 8\-bit grayscale and a two\-pixel Chebyshev matching tolerance\. The evaluated iterative wrapper renders Camera1; the evaluator averages matched views when more than one is available\. Appendix[L](https://arxiv.org/html/2610.13098#A12)provides all definitions\. Paired comparisons use the tasks valid for both systems\. For each, we report a 95% task\-level bootstrap confidence interval \(5,000 resamples of tasks with replacement, seed 0\) for the relative reduction in mean error, and an exact two\-sided sign test on per\-task wins with ties excluded; a difference is*statistically significant*when the interval excludes zero andp<\.05p<\.05\(Appendix[J](https://arxiv.org/html/2610.13098#A10)\)\.

### 3\.2BlenderGym

We first evaluate the complete VETR system against one\-shot generation and iterative baselines across diverse editing families\. These system comparisons characterize visual quality under the reported configurations; the component ablations separately test execution refinement and evidence organization within the host loop\.

Table[2](https://arxiv.org/html/2610.13098#S3.T2)reports the complete\-system results\. VETR achieves the strongest overall performance on both GPT\-5\.6\-luna and Qwen3\.8\-27B, and consistently outperforms One\-Shot, VIGA, and BlenderAlchemy across the aggregate metrics and nearly all family\-level comparisons\. On GPT, VETR attains the bestP​LPLandN​\-​C​L​I​PN\\text\{\-\}CLIPin four of the five editing families, with material editing as the only exception; on Qwen, it achieves the best result in every reported family–metric cell\. These results are particularly notable in light of the original VIGA study\([Yin et al\., 2026](https://arxiv.org/html/2610.13098#bib.bib17)\), which reported substantial gains over a GPT\-4o One\-Shot baseline\. In our experiments with newer and stronger backbones, however, the gap between iterative visual refinement and One\-Shot becomes considerably smaller and can even reverse\. A plausible explanation is that improvements in foundation\-model capabilities have substantially strengthened one\-shot program generation, reducing the headroom available to refinement strategies that rely primarily on rendered visual feedback\. In contrast, VETR continues to improve substantially over these stronger One\-Shot outputs\. Rather than depending on an initially weak program that can be corrected through repeated visual inspection, VETR exploits execution evidence to identify which symbolic edits were actually realized, overwritten, or disrupted, and recursively incorporates this information into subsequent program states\. These gains are statistically significant against One\-Shot on both backbones: VETR lowersN​\-​C​L​I​PN\\text\{\-\}CLIP/P​LPLby 52\.7%/58\.8% on GPT and by 28\.1%/49\.6% on Qwen, and on Qwen it also improves over VIGA by 40\.0%/56\.3%\. In each case the bootstrap interval excludes zero and the sign test givesp≤\.0043p\\leq\.0043\(Appendix[J](https://arxiv.org/html/2610.13098#A10), Table[11](https://arxiv.org/html/2610.13098#A10.T11)\)\.

Table[2](https://arxiv.org/html/2610.13098#S3.T2)complements the primary error metrics with pixel, structural, perceptual, and semantic similarity measures, reporting VETR atN=4N=4\. On GPT\-5\.6\-luna, its improvements over One\-Shot satisfy the paired significance criterion for all five metrics on 214 jointly valid tasks \(sign testsp≤2\.2×10−12p\\leq 2\.2\\times 10^\{\-12\}\)\. Against VIGA, edge F1 and LPIPS improve by 5\.6% and 18\.5%, respectively, on 279 jointly valid tasks; both pass the criterion \(p=\.0030p=\.0030and\.0227\.0227\)\. Thus the gains extend beyond photometric error to edge agreement and learned perceptual similarity\. CLIP provides a similarity\-scale view of the primaryN​\-​C​L​I​PN\\text\{\-\}CLIPscore, rather than an independent metric \(Appendix[L](https://arxiv.org/html/2610.13098#A12), Table[14](https://arxiv.org/html/2610.13098#A12.T14)\)\.

On Qwen3\.8\-27B, VETR has the best reported means for PSNR, SSIM, LPIPS, and CLIP, and ties One\-Shot on edge F1 at the displayed precision\. These means use each system’s valid tasks, so we assess significance on matched subsets \(Table[14](https://arxiv.org/html/2610.13098#A12.T14)\)\. AtN=4N=4, all five metrics improve significantly over VIGA on 264 paired tasks; against One\-Shot, SSIM, LPIPS, and CLIP meet the criterion on 250 tasks, whereas PSNR and edge F1 do not\. No extended metric establishes an advantage ofN=4N=4overN=1N=1, separating the evidence for refinement from that for increased candidate breadth\.

Table 1:Visual editing performance on BlenderGym across editing families\.P​LPLandN​\-​C​L​I​PN\\text\{\-\}CLIPare scaled by 100 \(↓\\downarrow\)\. Parentheses indicate negative improvement\.Table 2:Complementary image\-similarity metrics\.Higher is better for PSNR, SSIM, Edge F1, and CLIP; lower is better for LPIPS\.GPT\-5\.6\-luna

Qwen3\.8\-27B

### 3\.3BlenderBench

BlenderBench is a more demanding testbed than BlenderGym, with camera adjustment, multi\-step editing, and compositional tasks that introduce stronger dependencies between successive scene modifications\. These settings create more opportunities for intermediate errors to propagate, making them particularly suitable for evaluating whether VETR can preserve reliable refinement under increasingly entangled execution trajectories\.

Across the 27 released BlenderBench tasks, VETR achieves the best result in every level–metric cell on both GPT\-5\.6\-luna and Qwen3\.8\-27B, outperforming One\-Shot and VIGA throughout the benchmark\. Relative to VIGA on the same tasks, VETR reducesN​\-​C​L​I​PN\\text\{\-\}CLIP/P​LPLby 55\.0%/67\.7% on GPT and 27\.6%/48\.6% on Qwen, showing that its advantage remains substantial even as task complexity increases\.

The strongest separation appears on GPT Level 3, the most compositional setting, where VETR lowersN​\-​C​L​I​PN\\text\{\-\}CLIP/P​LPLby 72\.4%/75\.2% relative to VIGA\. This is precisely the regime in which execution\-grounded refinement is most useful: when multiple edits interact, a failure may arise not only from an incorrect visual judgment but also from symbolic writes that are overwritten, only partially realized, or otherwise altered during execution\. By retaining the execution trace and converting witnessed state changes into bounded program updates, VETR can correct these failures before they cascade into later steps\. In contrast, render\-only refinement has less direct evidence about which intermediate edits actually survived execution\.

Every iterative row completes all 27 tasks; GPT One\-Shot renders 21/27, and its unrendered tasks are excluded from its reported means\.

Table 3:Visual editing on native BlenderBench by level\.Improvement is the mean relative reduction from the same\-backbone One\-Shot row over the six level–metric cells, as defined in Eq\. \([5](https://arxiv.org/html/2610.13098#S3.E5)\)\.The improvement column averages the six level–metric cells against the same\-backbone One\-Shot row\. Leteb,ℓ,me\_\{b,\\ell,m\}denote the error for baselinebb, levelℓ\\ell, and metricmm, and letes,ℓ,me\_\{s,\\ell,m\}denote the corresponding system error\. We report

Improvement⁡\(s\)=1006​∑ℓ=13∑m∈\{N​\-​C​L​I​P,P​L\}\(1−es,ℓ,meb,ℓ,m\)%,\\operatorname\{Improvement\}\(s\)=\\frac\{100\}\{6\}\\sum\_\{\\ell=1\}^\{3\}\\sum\_\{m\\in\\\{N\\text\{\-\}CLIP,PL\\\}\}\\left\(1\-\\frac\{e\_\{s,\\ell,m\}\}\{e\_\{b,\\ell,m\}\}\\right\)\\%,\(5\)which weights the three levels and two metrics equally\. Each method’s level means use only the tasks it rendered\.

#### Qualitative comparison\.

Figure[3](https://arxiv.org/html/2610.13098#S3.F3)compares three selected final outputs, not intermediate repair interventions\. Values here follow the figure’sP​L×100PL\\times 100scale\. On the displayed light task, VETR has error<0\.0001<0\.0001versus VIGA’s0\.03870\.0387; on geometry,<0\.0001<0\.0001versus0\.78200\.7820; on shape,0\.08010\.0801versus0\.09380\.0938\. The marked regions illustrate differences in illumination, placement, and facial shape\. These examples support the stated final\-image comparisons, but do not identify which repair produced a difference or independently verify preservation of scene properties\. The refiner’s contribution is evaluated by the controlled on/off comparison in Section[3\.4](https://arxiv.org/html/2610.13098#S3.SS4.SSS0.Px1)\.

![Refer to caption](https://arxiv.org/html/2610.13098v1/stored_render_comparison.png)Figure 3:Qualitative comparison of visual editing\.Columns display the goal, start, VIGA final output, and VETR final output across three editing categories: light \(color\), geometry \(chair position & orientation\), and shape \(facial expression\)\. Red arrows and boxes highlight local regions of comparison\. Reported values denote PL×100\\times 100\(lower is better\)\. VETR achieves near\-zero PL in the displayed light and geometry tasks and lower error in the displayed shape task\. These output comparisons illustrate visual fidelity, not an independent verification of the refiner’s runtime mechanism\.

### 3\.4Ablation Study

The ablation study examines three design choices: \(i\) adding the execution refiner within a fixed generator\-interaction cap; \(ii\) using separate generator and verifier contexts rather than shared memory; and \(iii\) retaining a longer generator history\. These interventions test the refiner and its surrounding evidence interface without assuming that both agents consume the private runtime trace\.

#### Execution refinement\.

We first isolate the execution\-refiner stage, which converts observed writes and state transitions into runtime\-validated updates\. Disabling only this stage holds prompts, tools, base\-scene execution policy, backbone, and the ten\-generator\-interaction cap fixed\. The enabled stage can still perform additional repair executions\.

Disabling refinement degrades performance in 11 of the 12 level–metric cells across the two backbones \(Table[4](https://arxiv.org/html/2610.13098#S3.T4)\), often by substantial margins\. On GPT, removing refinement increases bothP​LPLandN​\-​C​L​I​PN\\text\{\-\}CLIPerrors at every difficulty level, with the largest degradation on Level 3:P​LPLrises from 5\.3922 to 11\.8475 andN​\-​C​L​I​PN\\text\{\-\}CLIPfrom 6\.3201 to 15\.2108\. The same pattern holds on Qwen, where disabling refinement substantially increases errors on Levels 1 and 3 and raises Level 2P​LPLfrom 0\.2585 to 2\.9924\. Paired statistics over the 27 GPT tasks confirm the effect: refinement lowers meanP​LPLby 41\.8%, which is statistically significant \(bootstrap interval\[6\.7,49\.0\]\[6\.7,49\.0\]excludes zero; sign test 24/3 wins,p=4\.9×10−5p=4\.9\\times 10^\{\-5\}\), and lowers meanN​\-​C​L​I​PN\\text\{\-\}CLIPby 32\.2% with a bootstrap interval of\[14\.4,55\.5\]\[14\.4,55\.5\]\(Appendix[J](https://arxiv.org/html/2610.13098#A10.SS0.SSS0.Px1), Table[12](https://arxiv.org/html/2610.13098#A10.T12)\)\.

These results support adding execution refinement within the same generator\-interaction cap\. Constructing a repair makes no additional language\-model call, but validation can add up to six execution attempts per submitted program\. The comparison therefore holds the generator budget fixed, not total computation\.

Table 4:Ablation\.Left: execution refinement on the 27 released BlenderBench tasks, using GPT\-5\.6\-luna and Qwen3\.8\-27B\. Right: context ablations on 280 BlenderGym tasks with GPT\-5\.6\-luna, from a separate run in which all rows are paired on the same tasks\. Errors are scaled by 100 \(↓\\downarrow\); paired statistics are in Appendices[J](https://arxiv.org/html/2610.13098#A10.SS0.SSS0.Px1)and[G](https://arxiv.org/html/2610.13098#A7)\.
#### Component\-wise ablation\.

We ablate three design choices in one 280\-task GPT\-5\.6\-luna cohort, pairing each variant with the default on the same tasks \(Table[4](https://arxiv.org/html/2610.13098#S3.T4), right; statistics in Appendix[G](https://arxiv.org/html/2610.13098#A7)\): a memory shared by generator and verifier \(w/o role asymmetry\), no visual verifier, and a generator limited to its three most recent messages instead of 24 \(w/o full history\)\. Limiting history degrades most, raisingN​\-​C​L​I​PN\\text\{\-\}CLIP/P​LPLby 48\.5%/79\.0%; both increases are statistically significant, with bootstrap intervals excluding zero and sign testsp<10−5p<10^\{\-5\}, which supports retaining the longer generator history\. Removing role asymmetry raises them by 12\.7%/23\.7%, also statistically significant on both metrics \(bootstrap intervals exclude zero; sign testsp≤\.003p\\leq\.003\), supporting separate role contexts\. Full statistics are in Appendix[G](https://arxiv.org/html/2610.13098#A7)\(Table[6](https://arxiv.org/html/2610.13098#A7.T6)\)\. Removing the verifier raises them by 6\.6%/28\.2%, and the default wins on more tasks \(sign testsp≤\.016p\\leq\.016; Appendix[G](https://arxiv.org/html/2610.13098#A7)\)\.

## 4Discussion and Conclusion

VETR treats executions as evidence for revising an executable scene\. Authoritative records identify the result being refined; observed writes and state transitions expose how proposed changes become realized effects\. The refiner turns selected observations into executable updates by jointly choosing supported values and compatible bindings, then validates the resulting program against runtime contracts before visual verification\. On native BlenderBench, adding this execution stage lowers aggregate visual error on both evaluated model backbones\. Recorded interventions show how the same evidence\-to\-program pipeline operates inside ordinary visual reasoning, while the host\-loop studies characterize the surrounding execution and context interfaces\.

#### Scope and transfer\.

The BlenderGym history and execution\-origin contrasts cover broad target\-view editing; the native BlenderBench comparison evaluates the complete closed\-loop refiner on released tasks\. Runtime validation establishes realization and preservation only for the captured properties\. Goal relevance is assessed by the ordinary visual verifier, allowing subsequent proposals to build on the delivered result\. For another domain, such as SVG or CAD, the same principle requires observable program effects, supported update operators, and an explicit preservation contract\. The current refiner operates on a fixed set of write types derived from the Blender execution model, so extending it to new domains requires defining additional write grammars and preservation boundaries\. Future work could explore learned preservation models that infer coupling constraints directly from execution traces\.

## References

- Aiet al\.\(2026a\)K\. Ai, P\. P\. Do, and C\. WangHiLSVA: design and evaluation of a human\-in\-the\-loop agentic system for scientific visualization\.IEEE Transactions on Visualization and Computer Graphics\.External Links:2606\.26614,[Document](https://dx.doi.org/10.48550/arXiv.2606.26614),[Link](https://arxiv.org/abs/2606.26614)Cited by:[Appendix A](https://arxiv.org/html/2610.13098#A1.SS0.SSS0.Px2.p1.1)\.
- Aiet al\.\(2026b\)K\. Ai, H\. Miao, K\. Tang, N\. Gorski, J\. Sun, G\. Liu, H\. I\. Ingolfsson, D\. Lenz, H\. Guo, H\. Yu, T\. Leburu, M\. Molash, B\. Wang, T\. Peterka, C\. Wang, and S\. LiuSciVisAgentBench: a benchmark for evaluating scientific data analysis and visualization agents\.IEEE Transactions on Visualization and Computer Graphics\.External Links:2603\.29139,[Document](https://dx.doi.org/10.48550/arXiv.2603.29139),[Link](https://arxiv.org/abs/2603.29139)Cited by:[Appendix A](https://arxiv.org/html/2610.13098#A1.SS0.SSS0.Px2.p1.1)\.
- Aiet al\.\(2026c\)K\. Ai, K\. Tang, and C\. WangNLI4VolVis: natural language interaction for volume visualization via LLM multi\-agents and editable 3D gaussian splatting\.IEEE Transactions on Visualization and Computer Graphics32\(1\),pp\. 46–56\.External Links:[Document](https://dx.doi.org/10.1109/TVCG.2025.3633888),[Link](https://doi.org/10.1109/TVCG.2025.3633888)Cited by:[Appendix A](https://arxiv.org/html/2610.13098#A1.SS0.SSS0.Px1.p1.1)\.
- Caoet al\.\(2023\)M\. Cao, X\. Wang, Z\. Qi, Y\. Shan, X\. Qie, and Y\. ZhengMasaCtrl: tuning\-free mutual self\-attention control for consistent image synthesis and editing\.InProceedings of the IEEE/CVF International Conference on Computer Vision,pp\. 22560–22570\.External Links:[Link](https://openaccess.thecvf.com/content/ICCV2023/html/Cao_MasaCtrl_Tuning-Free_Mutual_Self-Attention_Control_for_Consistent_Image_Synthesis_and_ICCV_2023_paper.html)Cited by:[Appendix A](https://arxiv.org/html/2610.13098#A1.SS0.SSS0.Px2.p1.1)\.
- Chenet al\.\(2024\)X\. Chen, M\. Lin, N\. Schärli, and D\. ZhouTeaching Large Language Models to Self\-Debug\.InInternational Conference on Learning Representations,External Links:[Link](https://proceedings.iclr.cc/paper_files/paper/2024/hash/2460396f2d0d421885997dd1612ac56b-Abstract-Conference.html)Cited by:[Appendix A](https://arxiv.org/html/2610.13098#A1.SS0.SSS0.Px2.p1.1)\.
- Fenget al\.\(2023\)W\. Feng, W\. Zhu, T\. Fu, V\. Jampani, A\. Akula, X\. He, S\. Basu, X\. E\. Wang, and W\. Y\. WangLayoutGPT: Compositional Visual Planning and Generation with Large Language Models\.InAdvances in Neural Information Processing Systems,Vol\.36,pp\. 18225–18250\.External Links:[Document](https://dx.doi.org/10.52202/075280-0802),[Link](https://arxiv.org/abs/2305.15393)Cited by:[Appendix A](https://arxiv.org/html/2610.13098#A1.SS0.SSS0.Px1.p1.1)\.
- Gouet al\.\(2024\)Z\. Gou, Z\. Shao, Y\. Gong, Y\. Shen, Y\. Yang, N\. Duan, and W\. ChenCRITIC: Large Language Models Can Self\-Correct with Tool\-Interactive Critiquing\.InInternational Conference on Learning Representations,External Links:[Link](https://arxiv.org/abs/2305.11738)Cited by:[Appendix A](https://arxiv.org/html/2610.13098#A1.SS0.SSS0.Px2.p1.1),[2nd item](https://arxiv.org/html/2610.13098#S1.I1.i2.p1.1),[§1](https://arxiv.org/html/2610.13098#S1.p1.1)\.
- Guet al\.\(2025\)Y\. Gu, I\. Huang, J\. Je, G\. Yang, and L\. GuibasBlenderGym: Benchmarking Foundational Model Systems for Graphics Editing\.InProceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition \(CVPR\),pp\. 18574–18583\.External Links:[Link](https://arxiv.org/abs/2504.01786)Cited by:[§3\.1](https://arxiv.org/html/2610.13098#S3.SS1.p1.1),[§3\.1](https://arxiv.org/html/2610.13098#S3.SS1.p2.1)\.
- Heet al\.\(2026\)G\. He, R\. Luo, W\. Ma, and H\. Averbuch\-ElorThinking in blender: staged executable inverse graphics with vision\-language models\.arXiv preprint arXiv:2606\.02580\.External Links:[Link](https://arxiv.org/abs/2606.02580)Cited by:[Appendix A](https://arxiv.org/html/2610.13098#A1.SS0.SSS0.Px1.p1.1)\.
- Hertzet al\.\(2023\)A\. Hertz, R\. Mokady, J\. Tenenbaum, K\. Aberman, Y\. Pritch, and D\. Cohen\-OrPrompt\-to\-prompt image editing with cross attention control\.InInternational Conference on Learning Representations,External Links:[Link](https://arxiv.org/abs/2208.01626)Cited by:[Appendix A](https://arxiv.org/html/2610.13098#A1.SS0.SSS0.Px2.p1.1)\.
- Huet al\.\(2026\)Y\. Hu, Y\. Wang, and J\. McAuleyEvaluating Memory in LLM Agents via Incremental Multi\-Turn Interactions\.InInternational Conference on Learning Representations,External Links:[Link](https://proceedings.iclr.cc/paper_files/paper/2026/hash/fd1eff9dd295df50a41f2521942fa31d-Abstract-Conference.html)Cited by:[Appendix A](https://arxiv.org/html/2610.13098#A1.SS0.SSS0.Px2.p1.1)\.
- Huet al\.\(2024\)Z\. Hu, A\. Iscen, A\. Jain, T\. Kipf, Y\. Yue, D\. A\. Ross, C\. Schmid, and A\. FathiSceneCraft: An LLM Agent for Synthesizing 3D Scenes as Blender Code\.InProceedings of the 41st International Conference on Machine Learning,Vol\.235,pp\. 19252–19282\.External Links:[Link](https://proceedings.mlr.press/v235/hu24g.html)Cited by:[Appendix A](https://arxiv.org/html/2610.13098#A1.SS0.SSS0.Px1.p1.1)\.
- Huanget al\.\(2024\)I\. Huang, G\. Yang, and L\. GuibasBlenderAlchemy: Editing 3D Graphics with Vision\-Language Models\.InComputer Vision – ECCV 2024,pp\. 297–314\.External Links:[Document](https://dx.doi.org/10.1007/978-3-031-73024-5%5F18),[Link](https://dx.doi.org/10.1007/978-3-031-73024-5_18)Cited by:[Appendix A](https://arxiv.org/html/2610.13098#A1.SS0.SSS0.Px1.p1.1)\.
- Juet al\.\(2024\)X\. Ju, A\. Zeng, Y\. Bian, S\. Liu, and Q\. XuPnP inversion: boosting diffusion\-based editing with 3 lines of code\.InInternational Conference on Learning Representations,External Links:[Link](https://proceedings.iclr.cc/paper_files/paper/2024/hash/661caac7729aa7d8c6b8ac0d39ccbc6a-Abstract-Conference.html)Cited by:[Appendix A](https://arxiv.org/html/2610.13098#A1.SS0.SSS0.Px2.p1.1)\.
- Junget al\.\(2018\)R\. Jung, J\. Jourdan, R\. Krebbers, and D\. DreyerRustBelt: securing the foundations of the Rust programming language\.Proceedings of the ACM on Programming Languages2\(POPL\),pp\. 66:1–66:34\.External Links:[Document](https://dx.doi.org/10.1145/3158154),[Link](https://plv.mpi-sws.org/rustbelt/popl18/paper.pdf)Cited by:[Appendix A](https://arxiv.org/html/2610.13098#A1.SS0.SSS0.Px3.p1.1),[§B\.1](https://arxiv.org/html/2610.13098#A2.SS1.SSS0.Px6.p1.2)\.
- Kuanget al\.\(2026\)Z\. Kuang, R\. Lin, L\. Zhao, G\. Wetzstein, S\. Xie, and S\. WooVULCAN: Tool\-Augmented Multi Agents for Iterative 3D Object Arrangement\.InProceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition \(CVPR\),pp\. 23763–23773\.External Links:[Link](https://openaccess.thecvf.com/content/CVPR2026/html/Kuang_VULCAN_Tool-Augmented_Multi_Agents_for_Iterative_3D_Object_Arrangement_CVPR_2026_paper.html)Cited by:[Appendix A](https://arxiv.org/html/2610.13098#A1.SS0.SSS0.Px1.p1.1),[§1](https://arxiv.org/html/2610.13098#S1.p1.1),[§1](https://arxiv.org/html/2610.13098#S1.p2.1)\.
- Madaanet al\.\(2023\)A\. Madaan, N\. Tandon, P\. Gupta, S\. Hallinan, L\. Gao, S\. Wiegreffe, U\. Alon, N\. Dziri, S\. Prabhumoye, Y\. Yang, S\. Gupta, B\. P\. Majumder, K\. Hermann, S\. Welleck, A\. Yazdanbakhsh, and P\. ClarkSelf\-Refine: Iterative Refinement with Self\-Feedback\.InAdvances in Neural Information Processing Systems,Vol\.36,pp\. 46534–46594\.External Links:[Document](https://dx.doi.org/10.52202/075280-2019),[Link](https://arxiv.org/abs/2303.17651)Cited by:[Appendix A](https://arxiv.org/html/2610.13098#A1.SS0.SSS0.Px2.p1.1),[2nd item](https://arxiv.org/html/2610.13098#S1.I1.i2.p1.1),[§1](https://arxiv.org/html/2610.13098#S1.p1.1)\.
- Mayeret al\.\(2018\)M\. Mayer, V\. Kunčak, and R\. ChughBidirectional evaluation with direct manipulation\.Proceedings of the ACM on Programming Languages2\(OOPSLA\),pp\. 127:1–127:28\.External Links:[Document](https://dx.doi.org/10.1145/3276497),[Link](https://lara.epfl.ch/~kuncak/papers/MayerETAL18BidirectionalEvaluation.pdf)Cited by:[Appendix A](https://arxiv.org/html/2610.13098#A1.SS0.SSS0.Px3.p1.1)\.
- Miaoet al\.\(2026\)H\. Miao, Z\. Li, K\. Ai, K\. Tang, C\. Wang, P\. Bremer, and S\. LiuToward AI VIS co\-scientists: a general and end\-to\-end agent harness for solving complex data visualization tasks\.arXiv preprint arXiv:2605\.21825\.External Links:2605\.21825,[Link](https://arxiv.org/abs/2605.21825)Cited by:[Appendix A](https://arxiv.org/html/2610.13098#A1.SS0.SSS0.Px1.p1.1)\.
- Nguyenet al\.\(2013\)H\. D\. T\. Nguyen, D\. Qi, A\. Roychoudhury, and S\. ChandraSemFix: program repair via semantic analysis\.InProceedings of the International Conference on Software Engineering,pp\. 772–781\.External Links:[Document](https://dx.doi.org/10.1109/ICSE.2013.6606623),[Link](https://research.ibm.com/publications/semfix-program-repair-via-semantic-analysis)Cited by:[Appendix A](https://arxiv.org/html/2610.13098#A1.SS0.SSS0.Px3.p1.1)\.
- Nimier\-Davidet al\.\(2019\)M\. Nimier\-David, D\. Vicini, T\. Zeltner, and W\. JakobMitsuba 2: a retargetable forward and inverse renderer\.ACM Transactions on Graphics \(Proceedings of SIGGRAPH Asia\)38\(6\)\.External Links:[Document](https://dx.doi.org/10.1145/3355089.3356498),[Link](https://rgl.epfl.ch/publications/NimierDavidVicini2019Mitsuba2)Cited by:[Appendix A](https://arxiv.org/html/2610.13098#A1.SS0.SSS0.Px3.p1.1)\.
- Panet al\.\(2025\)Y\. Pan, X\. He, C\. Mao, Z\. Han, Z\. Jiang, J\. Zhang, and Y\. LiuICE\-Bench: a unified and comprehensive benchmark for image creating and editing\.InProceedings of the IEEE/CVF International Conference on Computer Vision,pp\. 16586–16596\.External Links:[Link](https://openaccess.thecvf.com/content/ICCV2025/html/Pan_ICE-Bench_A_Unified_and_Comprehensive_Benchmark_for_Image_Creating_and_ICCV_2025_paper.html)Cited by:[Appendix A](https://arxiv.org/html/2610.13098#A1.SS0.SSS0.Px2.p1.1)\.
- Panagopoulouet al\.\(2025\)A\. Panagopoulou, H\. Zhou, S\. Savarese, C\. Xiong, C\. Callison\-Burch, M\. Yatskar, and J\. C\. NieblesViUniT: Visual Unit Tests for More Robust Visual Programming\.InProceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition \(CVPR\),pp\. 24646–24656\.External Links:[Link](https://openaccess.thecvf.com/content/CVPR2025/html/Panagopoulou_ViUniT_Visual_Unit_Tests_for_More_Robust_Visual_Programming_CVPR_2025_paper.html)Cited by:[Appendix A](https://arxiv.org/html/2610.13098#A1.SS0.SSS0.Px2.p1.1)\.
- Pixar Animation Studios \(2023\)Pixar Animation StudiosUniversal Scene Description: Scenegraph Instancing\.Note:OpenUSD 23\.05 documentation\. Accessed September 20, 2026External Links:[Link](https://openusd.org/23.05/api/_usd__page__scenegraph_instancing.html)Cited by:[Appendix A](https://arxiv.org/html/2610.13098#A1.SS0.SSS0.Px3.p1.1)\.
- Radfordet al\.\(2021\)A\. Radford, J\. W\. Kim, C\. Hallacy, A\. Ramesh, G\. Goh, S\. Agarwal, G\. Sastry, A\. Askell, P\. Mishkin, J\. Clark, G\. Krueger, and I\. SutskeverLearning Transferable Visual Models From Natural Language Supervision\.InProceedings of the 38th International Conference on Machine Learning,Vol\.139,pp\. 8748–8763\.External Links:[Link](https://proceedings.mlr.press/v139/radford21a.html)Cited by:[§3\.1](https://arxiv.org/html/2610.13098#S3.SS1.p3.1)\.
- Reynolds \(2002\)J\. C\. ReynoldsSeparation logic: a logic for shared mutable data structures\.InProceedings of the 17th Annual IEEE Symposium on Logic in Computer Science,pp\. 55–74\.External Links:[Document](https://dx.doi.org/10.1109/LICS.2002.1029817),[Link](https://www.cs.cmu.edu/~jcr/seplogic.pdf)Cited by:[Appendix A](https://arxiv.org/html/2610.13098#A1.SS0.SSS0.Px3.p1.1),[§B\.1](https://arxiv.org/html/2610.13098#A2.SS1.SSS0.Px6.p1.2)\.
- Shinnet al\.\(2023\)N\. Shinn, F\. Cassano, A\. Gopinath, K\. Narasimhan, and S\. YaoReflexion: language agents with verbal reinforcement learning\.InAdvances in Neural Information Processing Systems,Vol\.36,pp\. 8634–8652\.External Links:[Document](https://dx.doi.org/10.52202/075280-0377),[Link](https://arxiv.org/abs/2303.11366)Cited by:[Appendix A](https://arxiv.org/html/2610.13098#A1.SS0.SSS0.Px2.p1.1),[2nd item](https://arxiv.org/html/2610.13098#S1.I1.i2.p1.1),[§1](https://arxiv.org/html/2610.13098#S1.p1.1)\.
- Sunet al\.\(2025\)C\. Sun, J\. Han, W\. Deng, X\. Wang, Z\. Qin, and S\. Gould3D\-GPT: Procedural 3D Modeling with Large Language Models\.In2025 International Conference on 3D Vision \(3DV\),pp\. 1253–1263\.External Links:[Document](https://dx.doi.org/10.1109/3dv66043.2025.00119),[Link](https://dx.doi.org/10.1109/3DV66043.2025.00119)Cited by:[Appendix A](https://arxiv.org/html/2610.13098#A1.SS0.SSS0.Px1.p1.1)\.
- Tumanyanet al\.\(2023\)N\. Tumanyan, M\. Geyer, S\. Bagon, and T\. DekelPlug\-and\-play diffusion features for text\-driven image\-to\-image translation\.InProceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition,pp\. 1921–1930\.External Links:[Link](https://pnp-diffusion.github.io/)Cited by:[Appendix A](https://arxiv.org/html/2610.13098#A1.SS0.SSS0.Px2.p1.1)\.
- Wanget al\.\(2026a\)H\. Wang, Y\. Cai, W\. Chen, J\. Chi, H\. Sun, Q\. Dai, Y\. Hung, X\. Guo, J\. Ren, R\. Yao, Z\. Liu, M\. Long, Y\. Duan, J\. Gao, J\. Lyu, F\. Liu, and J\. WuCode as worlds: agentic discovery of executable world representations for physical reasoning\.arXiv preprint arXiv:2608\.27549\.External Links:[Link](https://arxiv.org/abs/2608.27549)Cited by:[Appendix A](https://arxiv.org/html/2610.13098#A1.SS0.SSS0.Px1.p1.1),[§1](https://arxiv.org/html/2610.13098#S1.p1.1),[§1](https://arxiv.org/html/2610.13098#S1.p2.1),[§2\.1](https://arxiv.org/html/2610.13098#S2.SS1.p1.1)\.
- Wanget al\.\(2026b\)H\. Wang, W\. Zhu, S\. Tang, Z\. Wang, X\. Dong, X\. Li, X\. Chen, A\. Bastola, X\. Huang, Y\. Wang, and A\. RaziEZBlender: Efficient 3D Editing with Plan\-and\-ReAct Agent\.InProceedings of the IEEE/CVF Winter Conference on Applications of Computer Vision \(WACV\) Workshops,pp\. 1343–1352\.External Links:[Link](https://openaccess.thecvf.com/content/WACV2026W/VALED/html/Wang_EZBlender_Efficient_3D_Editing_with_Plan-and-ReAct_Agent_WACVW_2026_paper.html)Cited by:[Appendix A](https://arxiv.org/html/2610.13098#A1.SS0.SSS0.Px1.p1.1)\.
- Wanget al\.\(2023\)S\. Wang, C\. Saharia, C\. Montgomery, J\. Pont\-Tuset, S\. Noy, S\. Pellegrini, Y\. Onoe, S\. Laszlo, D\. J\. Fleet, R\. Soricut, J\. Baldridge, M\. Norouzi, P\. Anderson, and W\. ChanImagen editor and EditBench: advancing and evaluating text\-guided image inpainting\.InProceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition,pp\. 18359–18369\.External Links:[Link](https://imagen.research.google/editor/)Cited by:[Appendix A](https://arxiv.org/html/2610.13098#A1.SS0.SSS0.Px2.p1.1)\.
- Wanget al\.\(2024\)X\. Wang, Y\. Chen, L\. Yuan, Y\. Zhang, Y\. Li, H\. Peng, and H\. JiExecutable Code Actions Elicit Better LLM Agents\.InProceedings of the 41st International Conference on Machine Learning,Proceedings of Machine Learning Research, Vol\.235,pp\. 50208–50232\.External Links:[Link](https://proceedings.mlr.press/v235/wang24h.html)Cited by:[Appendix A](https://arxiv.org/html/2610.13098#A1.SS0.SSS0.Px2.p1.1)\.
- Wanget al\.\(2004\)Z\. Wang, A\. C\. Bovik, H\. R\. Sheikh, and E\. P\. SimoncelliImage quality assessment: from error visibility to structural similarity\.IEEE Transactions on Image Processing13\(4\),pp\. 600–612\.Cited by:[§3\.1](https://arxiv.org/html/2610.13098#S3.SS1.p3.1)\.
- Wuet al\.\(2024\)X\. Wu, Z\. Lin, S\. Zhao, T\. Wu, P\. Lu, N\. Peng, and K\. ChangVDebugger: harnessing execution feedback for debugging visual programs\.InFindings of the Association for Computational Linguistics: EMNLP 2024,pp\. 9845–9860\.External Links:[Document](https://dx.doi.org/10.18653/v1/2024.findings-emnlp.575),[Link](https://aclanthology.org/2024.findings-emnlp.575/)Cited by:[Appendix A](https://arxiv.org/html/2610.13098#A1.SS0.SSS0.Px2.p1.1)\.
- Xuet al\.\(2025\)W\. Xu, Z\. Liang, K\. Mei, H\. Gao, J\. Tan, and Y\. ZhangA\-Mem: Agentic Memory for LLM Agents\.InAdvances in Neural Information Processing Systems,Vol\.38, Main Conference,pp\. 17577–17604\.External Links:[Document](https://dx.doi.org/10.52202/085713-0593),[Link](https://arxiv.org/abs/2502.12110)Cited by:[Appendix A](https://arxiv.org/html/2610.13098#A1.SS0.SSS0.Px2.p1.1)\.
- Yanget al\.\(2024\)Y\. Yang, F\. Sun, L\. Weihs, E\. VanderBilt, A\. Herrasti, W\. Han, J\. Wu, N\. Haber, R\. Krishna, L\. Liu, C\. Callison\-Burch, M\. Yatskar, A\. Kembhavi, and C\. ClarkHolodeck: Language Guided Generation of 3D Embodied AI Environments\.InProceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition \(CVPR\),pp\. 16227–16237\.External Links:[Link](https://arxiv.org/abs/2312.09067)Cited by:[Appendix A](https://arxiv.org/html/2610.13098#A1.SS0.SSS0.Px1.p1.1)\.
- Yinet al\.\(2026\)S\. Yin, J\. Ge, Z\. Z\. Wang, C\. Wang, X\. Li, M\. J\. Black, T\. Darrell, A\. Kanazawa, and H\. FengVision\-as\-Inverse\-Graphics Agent via Interleaved Multimodal Reasoning\.arXiv preprint arXiv:2601\.11109\.External Links:[Link](https://arxiv.org/abs/2601.11109)Cited by:[Appendix A](https://arxiv.org/html/2610.13098#A1.SS0.SSS0.Px1.p1.1),[3rd item](https://arxiv.org/html/2610.13098#S1.I1.i3.p1.1),[§1](https://arxiv.org/html/2610.13098#S1.p1.1),[§1](https://arxiv.org/html/2610.13098#S1.p2.1),[§3\.1](https://arxiv.org/html/2610.13098#S3.SS1.p1.1),[§3\.2](https://arxiv.org/html/2610.13098#S3.SS2.p2.1)\.
- Zhanget al\.\(2023\)K\. Zhang, L\. Mo, W\. Chen, H\. Sun, and Y\. SuMagicBrush: a manually annotated dataset for instruction\-guided image editing\.InAdvances in Neural Information Processing Systems,Vol\.36\.External Links:[Link](https://osu-nlp-group.github.io/MagicBrush/)Cited by:[Appendix A](https://arxiv.org/html/2610.13098#A1.SS0.SSS0.Px2.p1.1)\.
- Zhanget al\.\(2026\)Q\. Zhang, C\. Hu, S\. Upasani, B\. Ma, F\. Hong, V\. Kamanuru, J\. Rainton, C\. Wu, M\. Ji, H\. Li, U\. Thakker, J\. Y\. Zou, and K\. OlukotunAgentic Context Engineering: Evolving Contexts for Self\-Improving Language Models\.InInternational Conference on Learning Representations,External Links:[Link](https://arxiv.org/abs/2510.04618)Cited by:[Appendix A](https://arxiv.org/html/2610.13098#A1.SS0.SSS0.Px2.p1.1)\.
- Zhanget al\.\(2018\)R\. Zhang, P\. Isola, A\. A\. Efros, E\. Shechtman, and O\. WangThe unreasonable effectiveness of deep features as a perceptual metric\.InCVPR,Cited by:[§3\.1](https://arxiv.org/html/2610.13098#S3.SS1.p3.1)\.
- Zhanget al\.\(2025\)Y\. Zhang, Z\. Li, M\. Zhou, S\. Wu, and J\. WuThe Scene Language: Representing Scenes with Programs, Words, and Embeddings\.InProceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition \(CVPR\),pp\. 24625–24634\.External Links:[Link](https://openaccess.thecvf.com/content/CVPR2025/html/Zhang_The_Scene_Language_Representing_Scenes_with_Programs_Words_and_Embeddings_CVPR_2025_paper.html)Cited by:[Appendix A](https://arxiv.org/html/2610.13098#A1.SS0.SSS0.Px1.p1.1)\.

### AI use statement

Generative AI assisted code inspection, literature organization, manuscript and figure preparation, and statistical scripting\. Experimental measurements come from the recorded runs and stored renders\. The authors are responsible for the final claims, references, analyses, and artifacts\.

### Reproducibility statement

The supplement provides execution and context settings, full paired tables, metric definitions, and per\-task provenance\. The supplied scripts and recorded programs, renders, and outcomes support regeneration of the reported analyses\. The native BlenderBench results retain per\-level measurements for both model backbones; the GPT records additionally retain per\-task scores, task identities, source hashes, and runtime counters for all 27 tasks of every iterative arm and the 21 rendered One\-Shot tasks\.

## Appendix ARelated Work

#### Executable representations and program revision\.

Programs provide compositional control over scene structure: LayoutGPT, 3D\-GPT, Holodeck, and SceneCraft generate scenes via language models\([Feng et al\., 2023](https://arxiv.org/html/2610.13098#bib.bib5);[Sun et al\., 2025](https://arxiv.org/html/2610.13098#bib.bib13);[Yang et al\., 2024](https://arxiv.org/html/2610.13098#bib.bib16);[Hu et al\., 2024](https://arxiv.org/html/2610.13098#bib.bib9)\); Scene Language unifies programs with semantic and visual representations\([Zhang et al\., 2025](https://arxiv.org/html/2610.13098#bib.bib23)\); Code\-as\-World treats executable worlds as revisable hypotheses\([Wang et al\., 2026a](https://arxiv.org/html/2610.13098#bib.bib27)\)\. NLI4VolVis combines language\-guided editing with multi\-agent control over editable 3D Gaussian representations\([Ai et al\., 2026c](https://arxiv.org/html/2610.13098#bib.bib1)\), while end\-to\-end agent harnesses coordinate planning, implementation, and validation of visual analysis applications\([Miao et al\., 2026](https://arxiv.org/html/2610.13098#bib.bib4)\)\. For iterative editing, BlenderAlchemy, VIGA, and VULCAN combine rendered feedback, visual memory, and geometric constraints\([Huang et al\., 2024](https://arxiv.org/html/2610.13098#bib.bib7);[Yin et al\., 2026](https://arxiv.org/html/2610.13098#bib.bib17);[Kuang et al\., 2026](https://arxiv.org/html/2610.13098#bib.bib21)\); EZBlender adds local validation\([Wang et al\., 2026b](https://arxiv.org/html/2610.13098#bib.bib14)\); SEIG imposes stage budgets and rollback\([He et al\., 2026](https://arxiv.org/html/2610.13098#bib.bib28)\)\. These systems establish feedback loops but lack mechanisms to extract alternatives from execution traces\. VETR fills this gap by compiling observed writes and bindings into bounded updates validated before the next proposal\.

#### Agent memory, execution evidence, and preservation\.

Feedback\-driven refinement is studied by Self\-Refine, Reflexion, CRITIC\([Madaan et al\., 2023](https://arxiv.org/html/2610.13098#bib.bib10);[Shinn et al\., 2023](https://arxiv.org/html/2610.13098#bib.bib12);[Gou et al\., 2024](https://arxiv.org/html/2610.13098#bib.bib6)\), Self\-Debugging, and CodeAct\([Chen et al\., 2024](https://arxiv.org/html/2610.13098#bib.bib25);[Wang et al\., 2024](https://arxiv.org/html/2610.13098#bib.bib26)\); VDebugger leverages stepwise traces\([Wu et al\., 2024](https://arxiv.org/html/2610.13098#bib.bib29)\); visual unit tests guide revision\([Panagopoulou et al\., 2025](https://arxiv.org/html/2610.13098#bib.bib24)\); and agent\-memory research examines experience reuse\([Hu et al\., 2026](https://arxiv.org/html/2610.13098#bib.bib22);[Xu et al\., 2025](https://arxiv.org/html/2610.13098#bib.bib15);[Zhang et al\., 2026](https://arxiv.org/html/2610.13098#bib.bib18)\)\. HiLSVA combines feedback\-driven adaptation with stepwise provenance\([Ai et al\., 2026a](https://arxiv.org/html/2610.13098#bib.bib3)\), while SciVisAgentBench evaluates agent performance through task outcomes and multimodal assessment\([Ai et al\., 2026b](https://arxiv.org/html/2610.13098#bib.bib2)\)\. Preservation is a complementary requirement: Prompt\-to\-Prompt, Plug\-and\-Play, and MasaCtrl maintain structure or appearance\([Hertz et al\., 2023](https://arxiv.org/html/2610.13098#bib.bib32);[Tumanyan et al\., 2023](https://arxiv.org/html/2610.13098#bib.bib37);[Cao et al\., 2023](https://arxiv.org/html/2610.13098#bib.bib36)\); PIE\-Bench, EditBench, MagicBrush, and ICE\-Bench evaluate preservation alongside editing\([Ju et al\., 2024](https://arxiv.org/html/2610.13098#bib.bib38);[Wang et al\., 2023](https://arxiv.org/html/2610.13098#bib.bib39);[Zhang et al\., 2023](https://arxiv.org/html/2610.13098#bib.bib40);[Pan et al\., 2025](https://arxiv.org/html/2610.13098#bib.bib41)\)\.

#### Execution\-guided updates and local reasoning\.

SemFix uses symbolic execution for repair synthesis\([Nguyen et al\., 2013](https://arxiv.org/html/2610.13098#bib.bib42)\); bidirectional evaluation propagates outputs backward through functional programs\([Mayer et al\., 2018](https://arxiv.org/html/2610.13098#bib.bib30)\)\. Unlike these methods targeting internal values, VETR derives candidates from witnessed imperative executions against an image objective, requiring no additional model inference\. Separation logic and RustBelt motivate local state reasoning\([Reynolds, 2002](https://arxiv.org/html/2610.13098#bib.bib31);[Jung et al\., 2018](https://arxiv.org/html/2610.13098#bib.bib34)\); we instantiate this as finite runtime checks over captured properties\. Graphics systems like Mitsuba 2 and OpenUSD provide the foundation of reusable, interacting scene resources\([Nimier\-David et al\., 2019](https://arxiv.org/html/2610.13098#bib.bib35);[Pixar Animation Studios, 2023](https://arxiv.org/html/2610.13098#bib.bib33)\), within which VETR performs recursive within\-task program revision using execution\-grounded evidence\.

## Appendix BExecution\-refiner implementation details

### B\.1Compiling trace evidence into realized edits

The execution refiner converts bounded observations into constrained executable updates between raw execution and visual verification \(Figure[2](https://arxiv.org/html/2610.13098#S1.F2)\)\. It constructs candidate effects from earlier writes displaced during execution or effective changes between runtime states, then compiles them into parameter updates and permitted resource\-ownership changes\. The generator still proposes complete programs with its original prompt and tool schema\. The refiner examines every submitted execution, including improving raw renders; planning actions do not invoke it\. No additional language model identifies an error or constructs a repair\.

#### Observe the write, its owner, and its fate\.

AlongsideExecute⁡\(B,qt\)\\operatorname\{Execute\}\(B,q\_\{t\}\), the observer records

τt=\[\(oi,ki,vi,ℓi\)\]i=1mt,St=\(θt,Πt,Gt\)\.\\tau\_\{t\}=\\bigl\[\(o\_\{i\},k\_\{i\},v\_\{i\},\\ell\_\{i\}\)\\bigr\]\_\{i=1\}^\{m\_\{t\}\},\\qquad S\_\{t\}=\(\\theta\_\{t\},\\Pi\_\{t\},G\_\{t\}\)\.\(6\)Hereoio\_\{i\}is the owner bound at the executed statement,kik\_\{i\}a supported numerical property path,viv\_\{i\}its observed value, andℓi\\ell\_\{i\}its source location\. Final numerical values, object\-to\-resource references, and captured structure reside inθt\\theta\_\{t\},Πt\\Pi\_\{t\}, andGtG\_\{t\}, respectively\. Resolving owners during execution distinguishes calls to the same submitted helper that write different objects\. The observer covers supported assignments in submitted source, including local helpers; imported\-library writes and unresolved aliases do not provide owner\-qualified candidate evidence\. A supported standalone assignment is read back at the next eligible Python trace event, observing application\-level coercion without evaluating its right\-hand side twice\. Unsupported bindings and incomplete observations remain unknown\.

#### Initial reference and required evidence\.

The public initial programp0p\_\{0\}is executed once for\(S0,τ0\)\(S\_\{0\},\\tau\_\{0\}\)without another render\. We writez0=\(p0,r0,S0,τ0\)z\_\{0\}=\(p\_\{0\},r\_\{0\},S\_\{0\},\\tau\_\{0\}\)for this initial reference, explicitly markingr0r\_\{0\}as the supplied visual anchor rather than the output of this observation pass\. Initial recovery needs bothτ0\\tau\_\{0\}and the initial endpoint mapθ0\\theta\_\{0\}inS0S\_\{0\}; Algorithm[1](https://arxiv.org/html/2610.13098#alg1)therefore takesz0z\_\{0\}, matching its caller\. Subsequent delivered program/render pairs retain the provenance of their generated render\. Reusing the initial anchor after failure is not a successful generated answer\.

Recovery requires a source write, its source endpoint, and a resolvable target in the reference program\. Projection requires the in\-scope light observations in bothStS\_\{t\}andS−S^\{\-\}\. A missing required observation cannot establish a candidate’s endpoint or preservation condition; unavailable evidence is not assigned a default value\. The exact supported\-path, owner\-matching, and missing\-data policies remain implementation details identified in Section[B\.1](https://arxiv.org/html/2610.13098#A2.SS1.SSS0.Px10)\.

#### Lost values become competing hypotheses\.

For source executions∈\{t,0\}s\\in\\\{t,0\\\}and a supported non\-light cell\(o,k\)\(o,k\), the recovery rule selects

v^s\(o,k\)=vi⋆,i⋆=max\{iinτs:oi=o,ki=k,vi≄θs\(o,k\)\},\\widehat\{v\}\_\{s\}\(o,k\)=v\_\{i^\{\\star\}\},\\qquad i^\{\\star\}=\\max\\\{i\\text\{ in \}\\tau\_\{s\}:o\_\{i\}=o,\\ k\_\{i\}=k,\\ v\_\{i\}\\not\\simeq\\theta\_\{s\}\(o,k\)\\\},\(7\)when this set is nonempty\. The current and initial traces supply separate source hypotheses\. Both propose restoring eligible cells in the current complete program; initial\-source recovery does not rewind the whole program top0p\_\{0\}\. The per\-cell rule supplies candidate values, not by itself a complete definition of how eligible cells are grouped into a write support\.

The light channel reconstructs observed owner\-local energy/color requests displaced by later shared writes, resetting earlier requests after explicit data rebinding\. This reset requires ordered binding evidence: the final reference mapΠs\\Pi\_\{s\}alone does not describe when a binding changed\. Last\-write\-wins defines the executed result but does not identify the program that best matches a new visual goal\. Displaced values remain hypotheses, not inferred intent or proof that a later assignment was erroneous\.

#### Compile values and compatible ownership\.

For a recovery hypothesis, letWhW\_\{h\}be the supported cells to change anddh​\(o,k\)d\_\{h\}\(o,k\)their required endpoints; other captured cells retain their raw endpoints\. Shared owners with incompatible requirements require permitted local copying before writes\. Compatible requirements do not force a split\. A shared geometry\-node group, for example, cannot realize two different required radii through one shared value; lamps with compatible requests may retain shared data\.

The light compiler uses the effective\-value mapϕ⁡\(E,c\)=E​c\\phi\(E,c\)=Ecto enumerate bounded scalar\-write supports and group owners by compatible required tuples\. Non\-light compilation restores supported values directly and detaches conflicting material, mesh, camera, or node\-group references where supported\. The mapϕ\\phidoes not uniquely determine the light reconstruction:\(E,c\)\(E,c\)and\(2​E,c/2\)\(2E,c/2\)have the same effect whenever both are admissible\. Consequently, the bounds, selected tuple components, ordering of feasible reconstructions, and allowed copying/rebinding must come from the compiler rather than being inferred fromϕ\\phi\.

#### Project observed effects into executable updates\.

In the ordered controller of Algorithm[1](https://arxiv.org/html/2610.13098#alg1), projection is considered if no recovery candidate has been accepted, subject to the projection channel’s evidence and scope requirements\. For each in\-scope owneroo, Eq\. \([3](https://arxiv.org/html/2610.13098#S2.E3)\) formsuα,ou\_\{\\alpha,o\}usingS−S^\{\-\}andStS\_\{t\}, withα=1\\alpha=1beforeα=12\\alpha=\\tfrac\{1\}\{2\}\. These endpoints come from executions, not hidden target parameters\. Projection compiles into the previous delivered program while retaining its other captured state; recovery instead uses the raw program\. Thus, candidate construction, compilation, and the decision to execute a compiled program are distinct steps\. The endpoint\-based shortcuts below can skip a constructed candidate\.

#### Preserve a bounded frame around the repair\.

Each compiled program runs afresh fromBB, not a scene mutated by a previous trial\. For numerical\-property*recovery*, the reference is the raw record and the check is

θh′​\(o,k\)≃\{dh​\(o,k\),\(o,k\)∈Wh,θt​\(o,k\),\(o,k\)∈𝒞h∖Wh\.\\theta^\{\\prime\}\_\{h\}\(o,k\)\\simeq\\begin\{cases\}d\_\{h\}\(o,k\),&\(o,k\)\\in W\_\{h\},\\\\ \\theta\_\{t\}\(o,k\),&\(o,k\)\\in\\mathcal\{C\}\_\{h\}\\setminus W\_\{h\}\.\\end\{cases\}\(8\)This is Eq\. \([4](https://arxiv.org/html/2610.13098#S2.E4)\) specialized to recovery, not a different reference rule for projection\. The captured complement𝒞h∖Wh\\mathcal\{C\}\_\{h\}\\setminus W\_\{h\}is known and checked; properties outside𝒞h\\mathcal\{C\}\_\{h\}are not covered by this numerical contract\. Further checks retain captured node/mesh structure, protected object frames, and render context\. Light candidates are checked against their owner tuples, effective endpoints, and allowed reference changes\. Every check uses the candidate’s designated reference: raw for recovery, previous delivered for projection\. This finite operational frame follows the local\-reasoning distinction between changed and retained state\([Reynolds, 2002](https://arxiv.org/html/2610.13098#bib.bib31);[Jung et al\., 2018](https://arxiv.org/html/2610.13098#bib.bib34)\); it is not a guarantee about uncaptured properties or visual quality\.

#### A single acceptance contract, including raw reuse\.

Write𝖵𝖺𝗅𝗂𝖽h​\(z′\)\\mathsf\{Valid\}\_\{h\}\(z^\{\\prime\}\)for the conjunction of successful execution, a readable render, realization of all required endpoints, preservation relative tozhrefz\_\{h\}^\{\\mathrm\{ref\}\}, and applicable scope/binding checks\. Required unknown values cannot make this predicate true\. It is the same acceptance obligation for a fresh trial and for reusing the raw record as a projection candidate\. In particular, raw reuse under full\-effect projection must satisfy preservation relative toz−z^\{\-\}, not merely agree with its own numerical endpoints\. This notation specifies the contract; it does not supply undocumented numerical tolerances or an implementation of the checks\.

#### Endpoint shortcuts and the skipped full\-effect candidate\.

The supplied controller skips a light\-recovery trial when its required endpoint is already realized by the raw record\. For full\-effect projection, it returns the raw record only if the endpoint\-match test and𝖵𝖺𝗅𝗂𝖽h​\(z\)\\mathsf\{Valid\}\_\{h\}\(z\)both pass\. If the endpoint matches but the contract fails, it*continues to the next candidate without executing the compiled full\-effect program*\. Algorithm[1](https://arxiv.org/html/2610.13098#alg1)retains this branch; it is not silently changed to fall through to execution\.

The distinction is substantive\. Under the effective\-endpoint interpretation,

u1,o=ϕ⁡\(S−​\(o\)\)\+\[ϕ⁡\(St​\(o\)\)−ϕ⁡\(S−​\(o\)\)\]=ϕ⁡\(St​\(o\)\)\.u\_\{1,o\}=\\phi\(S^\{\-\}\(o\)\)\+\[\\phi\(S\_\{t\}\(o\)\)\-\\phi\(S^\{\-\}\(o\)\)\]=\\phi\(S\_\{t\}\(o\)\)\.Hence, whenever these values are available, the raw light effect matches by construction\. If the shortcut tests only this effect, the full\-effect stage acts as a raw\-reuse check or skip, rather than a fresh full\-effect repair\. A check of a more restrictive required owner tuple is a different predicate and must be specified explicitly\. We do not infer such a tuple check from the effective\-value equation\.

As a schematic example, let a previous record have light energy11and a protected object positionx=0x=0, with fixed light color\. A raw proposal with energy22andx=5x=5realizes the full\-effect light target, but violates a projection that must retainx=0x=0\. A compiled program with energy22andx=0x=0is not equivalent to the raw program\. Skipping it is therefore a restriction of the search policy, not proof that rerendering would be redundant\. The endpoint\-match predicates need implementation confirmation \(Section[B\.1](https://arxiv.org/html/2610.13098#A2.SS1.SSS0.Px10)\)\.

#### Execution cap, delivery, and visual feedback\.

The order is current/initial non\-light recovery, current/initial light recovery, then full\-/half\-effect projection\. Supported alternatives are constructed on demand\. The counterbbin Algorithm[1](https://arxiv.org/html/2610.13098#alg1)makes the reported limit explicit: at most six*additional execution attempts*per submitted program, including failed attempts\. Enumerating scalar supports during compilation is not itself an execution\. The counter does not assume that each channel necessarily supplies exactly one alternative\.

A successful fresh trial passing𝖵𝖺𝗅𝗂𝖽h\\mathsf\{Valid\}\_\{h\}is returned immediately\. When no candidate is accepted, a successful raw execution is retained; execution/render failure returns the exact preceding delivered record\. Raw fallback is not a claim that the raw program passed a repair contract\. Diagnostics for a failed submission are kept distinct from a cached render’s provenance\. The ordinary visual verifier subsequently compares the delivered program/image with the goal\. No image\-error decrease is required by runtime acceptance, and no additional language\-model call constructs the repair\.

Algorithm 1Execution\-evidence refinement: reported skip policy and explicit execution cap1:base

BB, raw record

zz, initial reference

z0z\_\{0\}, previous delivered record

z−z^\{\-\}
2:

b←0b\\leftarrow 0⊳\\trianglerightadditional executions for this submission

3:Inspect available writes, endpoints, binding evidence, and supported edit scope

4:foreach supported alternative

hhin the fixed recovery/projection orderdo

5:ifa required observation or supported compilation is unavailablethen

6:continue

7:endif

8:Set

zhref←zz\_\{h\}^\{\\mathrm\{ref\}\}\\leftarrow zfor recovery, or

z−z^\{\-\}for projection

9:Compile

qh′q^\{\\prime\}\_\{h\}and its endpoint, preservation, scope, and binding requirements

10:if

hhis light recovery and its endpoint\-match predicate holds on

zzthen

11:continue⊳\\trianglerightreported endpoint\-based skip

12:endif

13:if

hhis full\-effect projection and its endpoint\-match predicate holds on

zzthen

14:if

𝖵𝖺𝗅𝗂𝖽h​\(z\)\\mathsf\{Valid\}\_\{h\}\(z\)then⊳\\trianglerightfull projection contract relative toz−z^\{\-\}

15:return

zz
16:endif

17:continue⊳\\trianglerightskipqh′q^\{\\prime\}\_\{h\}; do not fall through to execution

18:endif

19:if

b=6b=6then

20:break

21:endif

22:

b←b\+1b\\leftarrow b\+1;

z′←ExecuteAndTrace​\(B,qh′\)z^\{\\prime\}\\leftarrow\\textsc\{ExecuteAndTrace\}\(B,q^\{\\prime\}\_\{h\}\)
23:if

𝖵𝖺𝗅𝗂𝖽h​\(z′\)\\mathsf\{Valid\}\_\{h\}\(z^\{\\prime\}\)then

24:return

z′z^\{\\prime\}
25:endif

26:endfor

27:ifthe raw program executes successfully and produces a readable renderthen

28:return

zz
29:endif

30:return

z−z^\{\-\}⊳\\trianglerightreuse the exact preceding record

#### Specification boundary\.

The equations and listing above clarify the recorded procedure but do not fully specify its implementation\-dependent selectors\. Exact reproduction still requires the supported\-property registry, source\-to\-reference owner matching, selection/grouping ofWhW\_\{h\}, and the rule selecting projection scope\. The light inverse additionally requires admissible bounds, required tuple components, feasible\-solution ordering, allowed copies/rebindings, and infeasibility handling\. Ordered rebinding observations cannot be recovered from the finalΠs\\Pi\_\{s\}alone; their recording and alignment with numerical writes must be specified\. Finally, the numerical agreement predicate, missing\-readback behavior, shortcut endpoint tests, and recovery\-to\-projection eligibility must be tied to the evaluated code\. No undocumented values, selectors, or tie\-breaking rules are assumed here\. In particular, the ordered presentation of projection after unaccepted recovery must not be substituted for a different eligibility gate in the actual controller\.

#### Making an edit observable\.

LetRB​\(q\)R\_\{B\}\(q\)denote the rendered result of a complete program\. Distinct programs can satisfyq1≠q2q\_\{1\}\\neq q\_\{2\}yetRB​\(q1\)≃RB​\(q2\)R\_\{B\}\(q\_\{1\}\)\\simeq R\_\{B\}\(q\_\{2\}\)when execution erases their differing intermediate values\. Their traces may still supply different alternatives\. Conversely, multiple parameterizations of a light effect can differ in surrounding state\. Execution evidence supplies bounded hypotheses whose realization can be tested; the visual verifier assesses their goal relevance\. An improving raw image does not establish that every observed request survived, motivating examination of every submitted execution without asserting that each repair improves the image\.

## Appendix CExecution\-interface diagnostics and cost

### C\.1Diagnostic study: consistent realization of proposals

To diagnose execution consistency under the complete\-program interface, this study retains full generator history in both arms and changes the scene loaded for execution\. Rebuild loads the task’s initial scene each time; persistent scene loads and saves a job\-local scene across rounds\. Both use GPT,N=1N=1, the same verifier, a complete\-program interface, and ten generator interactions\. This separate run set completes 278/280 tasks in each arm, with 276 jointly valid answers\.

Rebuilding reduces meanN​\-​C​L​I​PN\\text\{\-\}CLIPby 33\.9%, with a 95% interval of\[19\.8,45\.8\]\[19\.8,45\.8\]and 154 wins, 120 losses, and two ties\. The effect is concentrated in geometry, with a 53\.4% reduction; Appendix[5](https://arxiv.org/html/2610.13098#A8.F5)reports every family\.

A deterministic replay isolates one mechanism\. Executing the same savedgeometry20program nine times on a persistent scene accumulates nine modifiers and reduces mesh volume to1/2561/256of its first\-execution value\. Rebuild keeps one modifier and constant volume\. Explicitly replacing previous modifiers on the persistent scene also prevents accumulation \(Appendix[P](https://arxiv.org/html/2610.13098#A16)\)\. Thus, the requirement is consistency between a program and its execution origin; a compatible incremental or replacement interface can also retain scene state\.

### C\.2Refinement cost and candidate breadth

With an interaction capTTand candidate widthNN, at mostT​NTNraw candidate programs enter the execution stage\. Each submission permits at mostR=6R=6additional repair executions, so the raw\-program/repair stage has a worst\-case bound of\(1\+R\)​T​N\(1\+R\)TNexecution attempts, plus the separate initial\-program observation\. This is an upper bound rather than a reconstruction of recorded cost counters\. Planning actions, unsupported candidates, failures, and no\-op shortcuts can reduce execution or render counts\. A tournament overkkavailable delivered renders usesk−1k\-1pairwise comparisons\. The refiner itself makes no additional language\-model calls; the generator, ordinary verifier, and tournament have their own inference costs\. The generator’s visible history is bounded by its message window, while archived trajectories grow with recorded interactions\.

Table 5:Recorded cost in the GPT Blender 3\.6 cohort\.Means use tasks with saved cost records \(nn\); completion is reported separately\. Quality for both widths is reported in Table[9](https://arxiv.org/html/2610.13098#A9.T9)\.Table[5](https://arxiv.org/html/2610.13098#A3.T5)makes the cost of wider search explicit:N=4N=4uses about3\.6×3\.6\\timesthe model calls and4\.0×4\.0\\timesthe renders ofN=1N=1\. The core contrasts useN=1N=1\.

## Appendix DComplete refinement procedure

Algorithm[2](https://arxiv.org/html/2610.13098#alg2)expands the single\-submission procedure to both candidate widths\. AtN=1N=1, action voting and the visual tournament reduce to the single available response\. AtN\>1N\>1, only candidates of the selected action type are executed\. Each render\-producing candidate passes through Algorithm[1](https://arxiv.org/html/2610.13098#alg1)before visual candidate selection\. All candidates in an interaction use the same previous delivered record; only the selected outcome advances that record\. The tournament compares delivered candidates, whereas runtime acceptance inside the refiner uses no visual\-improvement gate\. Planning and inspection actions consume generator interactions but do not invoke the refiner\.

Algorithm 2Complete refinement procedure with optional candidate selection1:task inputs

x=\(B,p0,r0,y⋆\)x=\(B,p\_\{0\},r\_\{0\},y^\{\\star\}\), interaction cap

TT, width

NN, history window

LGL\_\{G\}
2:Initialize generator history

HHwith its prompt and task inputs

3:Obtain

z0z\_\{0\}by observing

p0p\_\{0\}without rerendering; set

z−←z0z^\{\-\}\\leftarrow z\_\{0\}
4:for

j=1,…,Tj=1,\\ldots,Tdo

5:Sample

NNactions from the generator’s window

WG​\(H,LG\)W\_\{G\}\(H;L\_\{G\}\)
6:Parse actions and choose the most frequent valid action type

7:ifno valid actionthen

8:Append parsing feedback; log candidates;continue

9:endif

10:ifthe chosen action produces rendersthen

11:foreach candidate

aaof the selected type, with complete program

qaq\_\{a\}do

12:

za←ExecuteAndTrace​\(B,qa\)z\_\{a\}\\leftarrow\\textsc\{ExecuteAndTrace\}\(B,q\_\{a\}\)
13:

z¯a←Refine​\(B,za,z0,z−\)\\bar\{z\}\_\{a\}\\leftarrow\\textsc\{Refine\}\(B,z\_\{a\},z\_\{0\},z^\{\-\}\)⊳\\trianglerightAlgorithm[1](https://arxiv.org/html/2610.13098#alg1)

14:endfor

15:Select one delivered outcome by its render, otherwise use diagnostics

16:Set

z−z^\{\-\}to the selected delivered record, when available

17:else

18:Execute one instance of the chosen non\-render action

19:endif

20:ifno outcome is returnedthen

21:Append failure feedback; log candidates;continue

22:endif

23:Obtain visual\-verifier feedback when requested by the selected tool

24:Append selected action and delivered outcome to

HH; log all candidates

25:ifthe chosen action is endthen

26:break

27:endif

28:endfor

29:Evaluation:score the last successful selected generated render

30:under Appendix[N](https://arxiv.org/html/2610.13098#A14.SS0.SSS0.Px3); cached images retain their original provenance

The returned record and failure diagnostics have distinct provenance\. If an attempted script fails and the refiner returns a cached record, the cached render remains paired with its own program, not with the failed submission\. The supplied initial image is a reference, not a successful generated render\. Runs with no successful generated render, and timed\-out or incomplete runs, remain invalid under the existing answer rule\.

## Appendix EComplete system results

Table[2](https://arxiv.org/html/2610.13098#S3.T2)reports family\-level means and completion counts in the main text\. The complete paired comparisons in Appendix[J](https://arxiv.org/html/2610.13098#A10)provide the head\-to\-head analyses\. The descriptive improvement column in Table[2](https://arxiv.org/html/2610.13098#S3.T2)is

Impr⁡\(m\)=10010​∑k=110xkOne​\-​Shot−xkmxkOne​\-​Shot,\\operatorname\{Impr\}\(m\)=\\frac\{100\}\{10\}\\sum\_\{k=1\}^\{10\}\\frac\{x\_\{k\}^\{\\mathrm\{One\\text\{\-\}Shot\}\}\-x\_\{k\}^\{m\}\}\{x\_\{k\}^\{\\mathrm\{One\\text\{\-\}Shot\}\}\},\(9\)wherekkindexes the five families and two benchmark metrics\. GPT uses the single Blender 3\.6 system cohort, including BlenderAlchemy with four candidates per interaction\. Qwen retains its separately documented configuration \(Appendix[K](https://arxiv.org/html/2610.13098#A11)\)\.

#### GPT completion and paired quality\.

One\-Shot completes 214 tasks; failures concentrate in geometry \(23/55 valid\) and material \(13/45\)\. TheN=1N=1comparison therefore uses the 212 tasks completed by both systems, andN=4N=4uses all 214 One\-Shot tasks\. Table[10](https://arxiv.org/html/2610.13098#A10.T10)reports the matched One\-Shot reference for each intersection\. Relative reductions are 40\.3%/56\.3% \(N​\-​C​L​I​PN\\text\{\-\}CLIP/P​LPL\) forN=1N=1and 52\.7%/58\.8% forN=4N=4\. Both variants improve each extended metric on their corresponding pairs\.

#### Comparison with iterative systems\.

Against VIGA,N=1N=1reducesN​\-​C​L​I​PN\\text\{\-\}CLIPby 36\.3% \(CI\[24\.3,46\.4\]\[24\.3,46\.4\], 161 wins and 114 losses,p=\.0054p=\.0054\)\. AtN=4N=4, the mean reductions are 40\.6% inN​\-​C​L​I​PN\\text\{\-\}CLIPand 24\.6% inP​LPL\. Both widths improve both primary metrics relative to BlenderAlchemy\.

#### Qwen: gains over VIGA extend to a second backbone\.

On Qwen3\.8\-27B,N=1N\{=\}1reducesN​\-​C​L​I​PN\\text\{\-\}CLIP/P​LPLby 31\.9%/50\.8% on 261 paired tasks, andN=4N\{=\}4by 40\.0%/56\.3% on 264; all four comparisons meet both criteria\. Against One\-Shot,N=4N\{=\}4establishes 28\.1%/49\.6% reductions \(250 tasks\), andN=1N\{=\}1yields 22\.1%/43\.6% \(248 tasks\)\. Both widths outperform BlenderAlchemy on both metrics\. Completion is 251/280 for One\-Shot, 265 for VIGA, 279 for BlenderAlchemy, 276 forN=1N\{=\}1, and 279 forN=4N\{=\}4\.

#### Additional image metrics\.

Table[2](https://arxiv.org/html/2610.13098#S3.T2)summarizes image similarity, while Table[14](https://arxiv.org/html/2610.13098#A12.T14)reports matched effects, confidence intervals, and win counts\. On GPT\-5\.6\-luna, both VETR variants improve all five metrics significantly over One\-Shot; against VIGA, theN=1N=1CLIP comparison and theN=4N=4edge F1 and LPIPS comparisons meet the paired criterion\. On Qwen3\.8\-27B,N=1N=1establishes gains in PSNR, LPIPS, and CLIP over VIGA, and in LPIPS over One\-Shot\. AtN=4N=4, all five comparisons with VIGA and the SSIM, LPIPS, and CLIP comparisons with One\-Shot meet the criterion\. Neither backbone establishes an extended\-metric advantage ofN=4N=4overN=1N=1

## Appendix FEditing strategies

\(a\)Start program \(geometry28, 86 lines; excerpt\)

frominfinigen\.core\.nodes\.node\_wranglerimportNodes

frominfinigen\.coreimportsurface

defshader\_material\_002\_002\(nw\):

bsdf=nw\.new\_node\(Nodes\.PrincipledBSDF,

input\_kwargs=\{’BaseColor’:\(0,\.0086,\.8,1\)\}\)

\.\.\.

defgeometry\_nodes\(nw\):

subdiv=nw\.new\_node\(Nodes\.SubdivideMesh,

input\_kwargs=\{’Mesh’:\.\.\.,’Level’:7\}\)

noise=nw\.new\_node\(Nodes\.NoiseTexture\)

ramp=nw\.new\_node\(Nodes\.ColorRamp,

input\_kwargs=\{’Fac’:noise\.outputs\["Fac"\]\}\)

ramp\.color\_ramp\.elements\[0\]\.position=0\.0

ramp\.color\_ramp\.elements\[1\]\.position=1\.0

delete=nw\.new\_node\(Nodes\.DeleteGeometry,

input\_kwargs=\{’Geometry’:subdiv,

’Selection’:ramp\.outputs\["Color"\]\}\)

apply\(bpy\.context\.active\_object\)

\(b\)GPT\-5\.6\-luna One\-Shot: 293\-line rewrite, no render

importbpy,math,random

frommathutilsimportVector

forobjinlist\(bpy\.data\.objects\):

ifobj\.type=="MESH":

bpy\.data\.objects\.remove\(obj,do\_unlink=True\)

mat=bpy\.data\.materials\.new\("FragmentBlue"\)

nodes=mat\.node\_tree\.nodes

nodes\.clear\(\)

bsdf=nodes\.new\("ShaderNodeBsdfPrincipled"\)

bsdf\.inputs\["BaseColor"\]\.default\_value=\.\.\.

bsdf\.inputs\["SpecularIORLevel"\]\.default\_value=\.28

scene=bpy\.context\.scene

scene\.render\.engine="BLENDER\_EEVEE\_NEXT"

Retains 4% of the start lines\. Blender 3\.6 raisesKeyError: "Specular IOR Level" not foundat the incompatible socket binding; there is no second attempt, so the task is lost\.

\(c\)GPT\-5\.6\-luna inside VETRN=1N\{=\}1: rounds 1–9

subdiv=nw\.new\_node\(Nodes\.SubdivideMesh,

input\_kwargs=\{’Mesh’:\.\.\.,’Level’:4\}\)

pos=nw\.new\_node\(Nodes\.InputPosition\)

noise=nw\.new\_node\(Nodes\.NoiseTexture,

input\_kwargs=\{’Vector’:pos\.outputs\["Position"\]\}\)

ramp\.color\_ramp\.elements\[0\]\.position=0\.40

ramp\.color\_ramp\.elements\[1\]\.position=0\.55

Round\-1 program retains 99% of the start lines; 9 of 9 rounds render; answerN​\-​C​L​I​PN\\text\{\-\}CLIP14\.1 \(N=4N\{=\}4: 8\.7; VIGA: 16\.8\)\.

Figure 4:Editing strategy and execution outcome on the same task\.\(a\) The supplied procedural program\. \(b\) Under the One\-Shot prompt, GPT\-5\.6\-luna rewrites the scene and accesses a socket absent in Blender 3\.6, so this attempt yields no render\. Orange highlights the rewrite and incompatible identifiers\. \(c\) With VETR’s prompt and iterative feedback, GPT preserves most of the program and makes the edits highlighted in blue\. Comments summarize observed changes and feedback; ellipses omit unchanged or lengthy code\. Scores areN​\-​C​L​I​P×100N\\text\{\-\}CLIP\\times 100\(↓\\downarrow\)\.The examples below characterize the archived program trajectories under the One\-Shot prompt\. On the 100 geometry and material tasks, the One\-Shot runner and Blender 3\.6 runtime are fixed\. We characterize the observed editing behavior by the fraction of initial\-program lines retained in the generated program \(Appendix[M](https://arxiv.org/html/2610.13098#A13), Table[15](https://arxiv.org/html/2610.13098#A13.T15)\)\. GPT\-5\.6\-luna retains a median10%10\\%of the start lines: 92 of 100 programs keep less than half, 46 begin by deleting the scene’s objects or clearing the node tree, 65 contain a binding that exists only in Blender 4\.x \("Specular IOR Level"44,"Lacunarity"13,BLENDER\_EEVEE\_NEXT12\); 66 fail, 40 of them with such a binding as the first exception\. Figure[4](https://arxiv.org/html/2610.13098#A6.F4)\(b\) shows this strategy on one task\. The observed strategy changes with the full configuration: inside VETR’s loop, whose prompt asks for one to three edits over bindings present in the program or supplied by the verifier, GPT\-5\.6\-luna’s*first\-round*program retains a median96%96\\%of the start lines on the same 100 tasks \(89 above90%90\\%\), 4 first\-round programs contain a 4\.x binding, 2 fail to render, and the line completes 100/100 \(Figure[4](https://arxiv.org/html/2610.13098#A6.F4)\(c\)\)\.

## Appendix GComplete context ablations

The context ablations form one cohort: Blender 3\.6\.0, GPT\-5\.6\-luna,N=1N\{=\}1, ten generator interactions, and 280 attempted tasks per arm\. The default run and three variants differ only in the named switch, and quality metrics were computed only after sampling had finished\. Every arm has a valid answer on all 280 tasks, so each comparison is paired on the full benchmark\. Table[6](https://arxiv.org/html/2610.13098#A7.T6)reports the paired statistics, computed with the procedure of Appendix[J](https://arxiv.org/html/2610.13098#A10)\.

Table 6:Context ablations in one cohort\(GPT\-5\.6\-luna,N=1N\{=\}1, Blender 3\.6\.0, 280 tasks\)\. Means are scaled by 100\. Red\.: relative reduction of the default mean error against the ablated mean \(positive favors the default\); the main text instead expresses each ablated error relative to the default\. CI: 95% task bootstrap \(5,000 resamples, seed 0\)\. W/L/T: default wins/losses/ties\.pp: exact two\-sided sign test excluding ties\.†\\dagger: CI excludes zero andp<\.05p<\.05\.#### Execution history\.

Limiting the generator to its three most recent messages produces the largest effect: the default has 32\.7%/44\.2% lowerN​\-​C​L​I​PN\\text\{\-\}CLIP/P​LPLthan the ablated arm, equivalently the ablated errors are 48\.5%/79\.0% higher than the default\. Both metrics meet the paired criterion\.

#### Role asymmetry\.

Sharing one memory between the generator and verifier raises both errors\. The default wins on 164 and 169 of the 280 tasks, and both metrics meet the paired criterion\.

#### Visual verification\.

Removing the verifier raises both mean errors, and the default wins on more tasks \(159 and 161;p=\.016p=\.016and\.0098\.0098\)\.

## Appendix HScene\-origin details and additional trajectories

Table[7](https://arxiv.org/html/2610.13098#A8.T7)and Figure[5](https://arxiv.org/html/2610.13098#A8.F5)give the aggregate origin contrast and its recorded trajectories\. Both arms retain history; only the scene supplied to complete\-program execution changes\.

Table 7:Scene origin matters under complete\-program execution\.Both arms retain generator history; only the scene\-persistence setting is changed\. Means use jointly valid tasks and are scaled by100100\. Red\.: reduction of rebuild relative to persistent; CI: 95% task bootstrap \(5,000 resamples, seed 0\)\. W/L/T: rebuild wins/losses/ties\.pp: exact two\-sided sign test excluding ties;†\\dagger: CI excludes zero andp<\.05p<\.05\. Both arms complete 278/280 tasks\. Family results are in Appendix[5](https://arxiv.org/html/2610.13098#A8.F5)\.![Refer to caption](https://arxiv.org/html/2610.13098v1/vetr_scene_execution.png)Figure 5:A complete program can compound edits left in a persistent scene\.Selected execution attempts from the scene\-origin ablation; both arms retain the full generator history\. \(a\) Ongeometry22, the persistent trajectory elongates the object until it leaves the visible frame, while rebuild retains a target\-like object\. Rebuild’s round 9 has no render; its scored answer is round 8 \(N​\-​C​L​I​P×100=1\.44N\\text\{\-\}CLIP\\times 100=1\.44\), versus persistent’s round 9 \(23\.5223\.52\)\. \(b\) Ongeometry20, the first programs are byte\-identical and produce equal scores; later persistent renders become progressively flatter, while rebuild finishes closer to the goal \(1\.291\.29vs\.7\.197\.19\)\. The sharedsurface\.add\_geomodhelper creates a new modifier on each call\. Appendix[P](https://arxiv.org/html/2610.13098#A16)separately executes the identical first program repeatedly and measures modifier counts, mesh volume, and object bounds\.This independent GPT\-5\.6\-luna run set uses all 280 tasks, the full generator context, one candidate per interaction, and a ten\-interaction cap\. Both arms request complete scripts and use the same final\-answer rule\. The persistent\-scene switch copies the initial\.blendto a job\-local path and uses that path for both loading and saving; the rebuild arm loads the initial task file without saving over it\. Successful scene changes persist only in the first arm\. The execution script saves the scene after execution and rendering\. The two arms are separate sampled trajectories with the same inference settings\.

Table 8:Scene\-origin ablation by task family\.Same definitions and joint criterion as Table[7](https://arxiv.org/html/2610.13098#A8.T7)\. Both means use the paired task set; means are×100\\times 100\. Intervals bootstrap the relative reduction of mean error\.Rebuild has no valid answer onblendshape40andgeometry53; persistent has none ongeometry32andgeometry37\. The intersection therefore contains 84 blend\-shape, 50 placement, 52 geometry, 45 lighting and 45 material tasks\. Both arms’ stored final renders were scored together with the same evaluator, without agent calls or scene rerendering\. The bootstrap follows the main paired implementation: sorted task IDs, 5,000 samples with replacement using seed 0, and percentile endpoints of the relative mean reduction; exact ties are excluded from the two\-sided sign test\. On the persistent\-relative scale, the overall and geometryN​\-​C​L​I​PN\\text\{\-\}CLIPreductions are 33\.9% and 53\.4%; on the rebuild\-relative scale, persistent increases error by 51\.2% and 114\.5%, respectively\.

#### Reading the trajectory figure\.

Figure[5](https://arxiv.org/html/2610.13098#A8.F5)displays selected execution attempts 1, 2, 3, 8 and 9; the ten\-interaction budget also includes the initial planning action\. Forgeometry22, rebuild’s ninth script fails to produce a render, so its answer is the eighth render\. Forgeometry20, the first submitted programs have identical SHA\-256 hashes\. The helper’s modifier allocation is verified in the implementation\.

## Appendix ICandidate breadth

Table[9](https://arxiv.org/html/2610.13098#A9.T9)compares the two candidate widths in the current GPT cohort\. Completion is 278/280 atN=1N=1and 280/280 atN=4N=4\. On the 278 shared tasks, meanN​\-​C​L​I​PN\\text\{\-\}CLIPdecreases by 7\.7% \(CI\[−4\.6,18\.4\]\[\-4\.6,18\.4\],p=\.278p=\.278\) andP​LPLby 9\.4% \(CI\[−14\.7,26\.6\]\[\-14\.7,26\.6\],p=\.436p=\.436\)\. TheN=4N=4tournament selects a candidate other than candidate zero in 497 of 2,453 interactions \(20\.3%\)\. The observed costs are3\.6×3\.6\\timesthe model calls,4\.0×4\.0\\timesthe renders, and3\.6×3\.6\\timesthe agent time ofN=1N=1\. The controlled history result uses the defaultN=1N=1setting\.

Table 9:Candidate breadth in the GPT Blender 3\.6 cohort\.Means use each variant's valid tasks; the paired row uses their intersection\. Costs are in Table[5](https://arxiv.org/html/2610.13098#A3.T5)\. The saved candidate logs contain 2,453 interactions forN=4N=4, with 497 nonzero winners; selected indices 0/1/2/3 occur 1,955/222/194/81 times\.
## Appendix JDetailed paired comparisons

Table[11](https://arxiv.org/html/2610.13098#A10.T11)reports current GPT system comparisons and all ten Qwen method pairs\. Each comparison pairs valid task identities within its backbone\. Table[10](https://arxiv.org/html/2610.13098#A10.T10)shows the GPT quality means for each One\-Shot intersection\.

Table 10:Matched\-task GPT image quality\.Each system is paired with One\-Shot on their valid\-task intersection; the One\-Shot reference is recomputed for that exact set\. The benchmark errors are scaled by 100\. Paired effects and tests are in Tables[11](https://arxiv.org/html/2610.13098#A10.T11)and[14](https://arxiv.org/html/2610.13098#A12.T14)\.Table 11:Detailed paired comparisons by backbone\.N1/N4: VETRN=1/4N\{=\}1/4; Alchemy: BlenderAlchemy \(2×22\\times 2for Qwen\)\.nn: tasks valid for both systems; Red\.: relative reduction of the first system's mean error against the second \(positive favors the first\); CI: 95% task\-bootstrap interval \(5,000 resamples, seed 0\); Wins: strictly lower error;pp: exact two\-sided sign test, excluding ties\.†\\dagger: CI excludes zero andp<\.05p<\.05\(unadjusted\)\. Qwen includes all ten method pairs; BlenderAlchemy uses depth 2, breadth 2, one try, and disabled thinking \(Appendix[K](https://arxiv.org/html/2610.13098#A11)\)\.N​\-​C​L​I​PN\\text\{\-\}CLIPP​LPLComparisonnnRed\. \(%\) \[95% CI\]WinsppRed\. \(%\) \[95% CI\]WinsppGPT\-5\.6\-lunaN1 vs\. VIGA277\+36\.3\+36\.3\[24\.324\.3,46\.446\.4\]†161\.0054\.0054\+16\.7\+16\.7\[−9\.1\-9\.1,36\.636\.6\]149\.2294\.2294N4 vs\. VIGA279\+40\.6\+40\.6\[30\.230\.2,49\.349\.3\]149\.1845\.1845\+24\.6\+24\.6\[5\.65\.6,40\.040\.0\]152\.1506\.1506N1 vs\. One\-Shot212\+40\.3\+40\.3\[29\.429\.4,50\.550\.5\]†159×10−148\.41\\\!\\times\\\!10^\{\-14\}\+56\.3\+56\.3\[44\.644\.6,66\.766\.7\]†144×10−87\.70\\\!\\times\\\!10^\{\-8\}N4 vs\. One\-Shot214\+52\.7\+52\.7\[44\.944\.9,60\.360\.3\]†168×10−181\.19\\\!\\times\\\!10^\{\-18\}\+58\.8\+58\.8\[45\.945\.9,68\.868\.8\]†156×10−122\.19\\\!\\times\\\!10^\{\-12\}N4 vs\. N1278\+7\.7\+7\.7\[−4\.6\-4\.6,18\.418\.4\]147\.2777\.2777\+9\.4\+9\.4\[−14\.7\-14\.7,26\.626\.6\]146\.4356\.4356VIGA vs\. One\-Shot214\+14\.9\+14\.9\[−6\.9\-6\.9,34\.134\.1\]153×10−114\.58\\\!\\times\\\!10^\{\-11\}\+36\.8\+36\.8\[18\.318\.3,51\.551\.5\]†147×10−84\.69\\\!\\times\\\!10^\{\-8\}N1 vs\. Alchemy260\+72\.5\+72\.5\[67\.167\.1,77\.377\.3\]†234×10−435\.08\\\!\\times\\\!10^\{\-43\}\+83\.3\+83\.3\[77\.877\.8,87\.587\.5\]†222×10−338\.49\\\!\\times\\\!10^\{\-33\}N4 vs\. Alchemy262\+75\.6\+75\.6\[71\.071\.0,79\.779\.7\]†241×10−481\.54\\\!\\times\\\!10^\{\-48\}\+83\.8\+83\.8\[79\.579\.5,87\.487\.4\]†227×10−351\.25\\\!\\times\\\!10^\{\-35\}VIGA vs\. Alchemy261\+59\.7\+59\.7\[51\.351\.3,67\.667\.6\]†228×10−374\.92\\\!\\times\\\!10^\{\-37\}\+76\.9\+76\.9\[69\.869\.8,82\.482\.4\]†217×10−281\.17\\\!\\times\\\!10^\{\-28\}Alchemy vs\. One\-Shot212\(178\.9\)\(178\.9\)\[−238\.3\-238\.3,−133\.0\-133\.0\]†39×10−212\.45\\\!\\times\\\!10^\{\-21\}\(214\.1\)\(214\.1\)\[−314\.4\-314\.4,−141\.4\-141\.4\]†56×10−124\.18\\\!\\times\\\!10^\{\-12\}Qwen3\.8\-27BN4 vs\. N1275\+11\.7\+11\.7\[−1\.8\-1\.8,23\.823\.8\]148\.2277\.2277\+11\.5\+11\.5\[−6\.7\-6\.7,28\.528\.5\]141\.7176\.7176N4 vs\. VIGA264\+40\.0\+40\.0\[30\.230\.2,49\.049\.0\]†171×10−61\.82\\\!\\times\\\!10^\{\-6\}\+56\.3\+56\.3\[42\.442\.4,66\.966\.9\]†169×10−66\.16\\\!\\times\\\!10^\{\-6\}N4 vs\. One\-Shot250\+28\.1\+28\.1\[16\.016\.0,39\.039\.0\]†148\.0043\.0043\+49\.6\+49\.6\[31\.831\.8,62\.662\.6\]†149\.0023\.0023N4 vs\. Alchemy278\+29\.5\+29\.5\[18\.218\.2,40\.040\.0\]†186×10−81\.80\\\!\\times\\\!10^\{\-8\}\+44\.5\+44\.5\[30\.630\.6,56\.156\.1\]†174×10−52\.36\\\!\\times\\\!10^\{\-5\}N1 vs\. VIGA261\+31\.9\+31\.9\[20\.120\.1,42\.442\.4\]†162×10−41\.16\\\!\\times\\\!10^\{\-4\}\+50\.8\+50\.8\[34\.334\.3,63\.063\.0\]†152\.0092\.0092N1 vs\. One\-Shot248\+22\.1\+22\.1\[9\.49\.4,32\.732\.7\]139\.0653\.0653\+43\.6\+43\.6\[21\.221\.2,59\.459\.4\]137\.0979\.0979N1 vs\. Alchemy275\+17\.5\+17\.5\[4\.64\.6,28\.628\.6\]†170×10−41\.06\\\!\\times\\\!10^\{\-4\}\+37\.2\+37\.2\[18\.518\.5,50\.750\.7\]†163\.0020\.0020Alchemy vs\. VIGA264\+19\.2\+19\.2\[7\.57\.5,29\.829\.8\]133\.9509\.9509\+19\.9\+19\.9\[−8\.2\-8\.2,39\.039\.0\]129\.7584\.7584Alchemy vs\. One\-Shot250\(0\.7\)\(0\.7\)\[−15\.7\-15\.7,12\.312\.3\]105\.0186\.0186\+8\.0\+8\.0\[−28\.7\-28\.7,35\.635\.6\]119\.6108\.6108VIGA vs\. One\-Shot238\(15\.0\)\(15\.0\)\[−35\.6\-35\.6,2\.12\.1\]109\.2180\.2180\(14\.2\)\(14\.2\)\[−63\.2\-63\.2,22\.522\.5\]111\.3309\.3309

#### Paired statistics for the execution\-refinement ablation\.

Table[12](https://arxiv.org/html/2610.13098#A10.T12)pairs the default VETR run with the refinement\-disabled run on the 27 released BlenderBench tasks for GPT\-5\.6\-luna, using the archived per\-task ledger; both arms complete all 27 tasks\. Reductions compare mean errors across tasks, and intervals, wins, and sign tests follow the procedure above\. Refinement lowers meanP​LPLby 41\.8% \(24/3 wins,p=4\.9×10−5p=4\.9\\times 10^\{\-5\}\), meeting the paired criterion, and lowers meanN​\-​C​L​I​PN\\text\{\-\}CLIPby 32\.2%, with a bootstrap interval of\[14\.4,55\.5\]\[14\.4,55\.5\]that excludes zero\.

Table 12:Paired effect of execution refinement on BlenderBench \(GPT\-5\.6\-luna, 27 tasks\)\.Means are scaled by 100\. Red\.: relative reduction of the default mean error against the refinement\-disabled run \(positive favors refinement\); CI: 95% task bootstrap \(5,000 resamples, seed 0\); W/L: per\-task wins/losses of the default \(no ties\);pp: exact two\-sided sign test;†\\dagger: CI excludes zero andp<\.05p<\.05\.
#### Paired statistics for the BlenderBench system comparison\.

Table[13](https://arxiv.org/html/2610.13098#A10.T13)pairs VETR with VIGA on the 27 released BlenderBench tasks for GPT\-5\.6\-luna, using the same archived per\-task ledger\. Both systems complete all 27 tasks, so the means equal the averages of the level means in Table[3](https://arxiv.org/html/2610.13098#S3.T3)\. VETR lowers meanN​\-​C​L​I​PN\\text\{\-\}CLIPby 55\.0% and meanP​LPLby 67\.7%, and both bootstrap intervals exclude zero\.

Table 13:Paired comparison with VIGA on BlenderBench \(GPT\-5\.6\-luna, 27 tasks\)\.Means are scaled by 100\. Red\.: relative reduction of the VETR mean error against VIGA; CI: 95% task bootstrap \(5,000 resamples, seed 0\); W/L: per\-task wins/losses of VETR \(no ties\);pp: exact two\-sided sign test;†\\dagger: CI excludes zero andp<\.05p<\.05\.

## Appendix KQwen3\.8\-27B evaluation: settings and scope

#### Backbone and runtime\.

The second\-backbone runs use a locally served Qwen endpoint, denoted Qwen3\.8\-27B, on all 280 tasks\. The run environment uses four H100 80 GB GPUs, Blender 3\.6\.0, and BlenderGym’s Infinigen fork, Cycles CUDA rendering with 512 samples, and the same CLIP ViT\-B/32 and RGB\-MSE evaluator\. One\-Shot, VIGA, and VETR use enabled thinking; VIGA and VETR have a ten\-round budget\.

#### Budgets and failures\.

VIGA and VETRN=1N\{=\}1have 7,200 s timeouts;N=4N\{=\}4and BlenderAlchemy have 21,600 s\. A timeout remains a failure even if an intermediate render exists\. One\-Shot has 29 no\-render failures; VIGA has three timeouts and 12 no\-render failures;N=1N\{=\}1has four timeouts;N=4N\{=\}4has one \(geometry37\)\. BlenderAlchemy’s only failure \(material5\) produced no candidate render after an upstream planning error\.

#### BlenderAlchemy configuration\.

The Qwen line uses the released implementation with family\-specific edit styles and refinement strategies \(depth 2, breadth 2, one try\)\. Visual imagination is disabled because the target render is supplied, and thinking is disabled to obtain parseable planning responses\.

#### Statistical scope and traceability\.

All means use successful renders from normally completed tasks\. Paired comparisons intersect valid task IDs, bootstrap tasks 5,000 times \(seed 0\), and apply an exact two\-sided sign test after removing ties\. Tests are reported without a multiple\-comparison correction, as in the primary evaluation\. The export contains 1,400 task–method records inper\_task\_metrics\.csvand full\-precision merged records inraw/qwen38\_all\_\_metrics\_committed\.json, undersupplement/blendergym\_tables\_export/\. Table[2](https://arxiv.org/html/2610.13098#S3.T2)’s Qwen block and Table[11](https://arxiv.org/html/2610.13098#A10.T11)’s Qwen block have their tabulated values independently recomputed and numerically cross\-checked bysupplement/update\_results\.py\.

## Appendix LExtended image metrics

#### Definitions\.

The extended scorer reads the same stored final\-answer images used for the primary metrics, matches render/goal filenames, and averages per\-image values over available views and then over valid tasks\. Images are loaded as RGB in\[0,1\]\[0,1\]at goal resolution; a size mismatch is resized to that resolution\.*PSNR*is−10​log10​MSE\-10\\log\_\{10\}\\mathrm\{MSE\}in dB, with 100 dB used whenMSE≤10−10\\mathrm\{MSE\}\\leq 10^\{\-10\}\. It is computed per image before averaging\.*SSIM*usesskimage\.metrics\.structural\_similarity, RGB channels,data\_range=1, and the default uniform7×77\\times 7window\.*LPIPS*uses the AlexNet backbone with the package's default learned calibration and inputs scaled to\[−1,1\]\[\-1,1\]\.*Edge F1*applies OpenCV Canny to both 8\-bit grayscale images with thresholds\(100,200\)\(100,200\)\. Each edge map is dilated by a5×55\\times 5all\-ones kernel: a match is within two pixels in Chebyshev distance\. Precision is the fraction of predicted edges matched to a goal edge, and recall the converse; their harmonic mean is reported\. Both maps empty gives 1; exactly one empty gives 0\.*CLIP*is cosine similarity from ViT\-B/32 image embeddings, equal to1−N​\-​C​L​I​P1\-N\\text\{\-\}CLIPbefore the latter’s×100\\times 100table scaling\. All CLIP tables derive it from the same canonical per\-taskN​\-​C​L​I​PN\\text\{\-\}CLIPscore, so their favorable orderings and ties agree exactly; separately recomputed cosine scores are retained in the scoring exports\. For a higher\-is\-better metric, paired relative improvement is\(m¯first−m¯second\)/m¯second\(\\bar\{m\}\_\{\\mathrm\{first\}\}\-\\bar\{m\}\_\{\\mathrm\{second\}\}\)/\\bar\{m\}\_\{\\mathrm\{second\}\}; for LPIPS its sign is reversed\. Reported percentages multiply these ratios by 100\. Task\-bootstrap CIs, wins, and sign tests follow Appendix[J](https://arxiv.org/html/2610.13098#A10)\.

#### One\-Shot means\.

One\-Shot extended metrics cover all 214 of its valid GPT tasks\. Its family composition differs from that of iterative systems because failures concentrate in geometry and material\. GPT comparisons use 212 jointly valid tasks forN=1N=1and 214 forN=4N=4, with each reference recomputed on the same set \(Table[10](https://arxiv.org/html/2610.13098#A10.T10)\)\.

Table 14:Paired comparisons on the extended metrics\.N1/N4 denote VETR atN=1/4N=1/4\.nn: paired sample size;Δ\\Delta: PSNR difference in dB and relative improvement \(%\) for the other metrics, in the first system's favorable direction; CI: 95% task bootstrap \(5,000 resamples, seed 0\); W/L: per\-task wins/losses \(ties excluded\);pp: exact two\-sided sign test \(unadjusted\);†\\dagger: recorded CI excludes zero andp<\.05p<\.05\.

## Appendix MOne\-Shot editing strategy: statistics behind Section[F](https://arxiv.org/html/2610.13098#A6)

#### Measure\.

For this program\-form analysis, each source line is truncated at its first\#, whitespace is normalized, and empty lines are removed; thus inline comments are stripped\.*Retention*counts initial\-line occurrences whose normalized text appears anywhere in the generated program, divided by the initial line count\.*Changed lines*counts initial\-line occurrences absent from the generated program plus generated\-line occurrences absent from the initial program\. Identical means equality of the normalized line sequences\. A program is*scene\-clearing*if the source containsread\_factory\_settings,bpy\.ops\.object\.delete,objects\.remove\(, ornodes\.clear\(\)\. A program*contains a 4\.x binding*if it names a Blender identifier introduced in 4\.0–4\.2 and absent in 3\.6 \(BLENDER\_EEVEE\_NEXT,surface\_render\_method, the Principled\-BSDF socketsSpecular IOR Level,Subsurface Weight,Subsurface Scale,Transmission Weight,Coat Weight,Coat Roughness,Sheen Weight,Emission Color, and the Noise\-Texture socketLacunarity\)\. The 100 geometry and material tasks are used because they are the tasks whose archived GPT One\-Shot programs were produced and executed under Blender 3\.6\.

Table 15:One\-Shot program form\.GPT\-5\.6\-luna on the 100 geometry and material tasks under Blender 3\.6, and the first\-round program of the same backbone inside VETRN=1N\{=\}1on the same tasks\. Valid: tasks with a render for One\-Shot; rendered programs / tasks run for round 1\. First\-error counts name the exception that ended the failed program\.One\-ShotVETRN=1N\{=\}1, round 1Valid3498 / 100Median retention of start lines0\.100\.96Programs retaining≥50%\\geq 50\\%\(valid\)8 \(7\)99Programs retaining<50%<50\\%\(valid\)92 \(27\)1Programs identical to the start program0–Median changed lines188–Scene\-clearing programs46–Programs containing a 4\.x binding654Specular IOR Level/Lacunarity/BLENDER\_EEVEE\_NEXT44 / 13 / 12–First error = 4\.x binding \(same three\)21 / 10 / 9–First error = other socket, type or syntax error18–Failed with no Python exception in the log \(crash / kill\)8–No\-render generator rounds, all rounds of the 100 tasks–41 / 814

#### Reading\.

The GPT One\-Shot failures are concentrated in programs that discarded the start program: of the 92 programs retaining less than half of it, 65 fail, against 1 of the 8 that kept at least half\. With VETR’s prompt and loop, GPT produces first\-round programs on all 100 tasks, with median retention 0\.96 and 98 rendered outcomes; the full run has 41 logged no\-render outcomes in 814 interactions on these tasks\.

## Appendix NExecution settings

Table 16:Experiment map\.Each row identifies a separate source cohort\. Iterative VIGA/VETR runs allow ten generator interactions;NNis the number of candidate actions per interaction\. Within each ablation, the backbone, Blender version, tools, prompts, and budget are fixed except for the named switch\. Completion and paired task intersections are reported with the corresponding results\.#### Runtime configuration\.

All GPT and Qwen runs use Blender 3\.6\.0 with BlenderGym’s Infinigen fork\. BlenderGym’s unmodified initial programs execute on all 280 tasks in the benchmark\-compatible environment\.

#### Result provenance\.

Each task/system has one designated source result\. The GPT system table uses one complete Blender 3\.6 run set, and the context ablations use one separately identified run set; failures in every source are retained\. The GPT BlenderAlchemy row uses the same Blender 3\.6 environment as the other current GPT systems, with four candidates per interaction\. Per\-task sources and scripts are enumerated in Appendix[Q](https://arxiv.org/html/2610.13098#A17)\.

#### Answer extraction\.

All iterative systems are scored using their last successful selected render from a completed run\. A later execution failure contributes feedback and does not replace that answer\. Tasks without a successful render, and timed\-out or incomplete runs, are invalid\. Stored renders are rescored by the same evaluator\. Primary comparisons use the intersection of valid task identities; separate completion counts retain the information about missing answers\.

## Appendix OWithin\-run progress and guidance controls

#### First executed program versus the final answer\.

We evaluate the first executed script in each Full trajectory from the scene\-origin cohort\. This proposal may follow an initial planning action but precedes feedback from any executed program in that run\. It uses the same task, role instructions, backbone, and fixed\-origin backend as the subsequent refinements\. We score stored first\-attempt renders irrespective of eventual completion: 258/280 first proposals render, 278/280 final runs are valid, and 256 tasks have both\. No metric\-based historical selection is applied\.

Table 17:Refinement of the same initial proposals\.All 256 jointly available tasks; means are scaled by 100\. Reduction compares final versus first executed program\. Bootstrap, sign tests, and†\\daggeruse the same definitions as the main experiments\. W/L/T favors the final answer\.
#### Role\-instruction sensitivity\.

Two existing controls retain the Full runner, full generator history,N=1N=1, and fixed execution origin\. The first replaces the generator and verifier role\-system prompts with the released VIGA role prompts \(277/280 valid; 276 paired with Full\)\. The second removes the body\-skin recipe and worked example on the 85 blend\-shape tasks \(84 valid; 83 paired\)\. Full completes 278/280 tasks overall\. Table[18](https://arxiv.org/html/2610.13098#A15.T18)reports both primary metrics for both controls; neither control produces a significant paired difference\. Source hashes and task\-level configuration records accompany the measurements\.

Table 18:Guidance controls under the same refinement configuration\.Positive reductions favor Full\. Complete paired intervals and exact sign tests are shown, with ties excluded from the latter\. The no\-recipe control is restricted to blend\-shape tasks\.

## Appendix PIdentical\-program replay of scene operations

We replay the archived first program ofgeometry20, which is byte\-identical in the two closed\-loop trajectories of Figure[5](https://arxiv.org/html/2610.13098#A8.F5)\(b\)\. Its node transform sets scale\(0\.5,1,1\)\(0\.5,1,1\)and azz\-rotation of0\.350\.35radians, then callssurface\.add\_geomod\. The original base scene and script are held fixed\. We execute it nine times under three policies: reload the base before each execution; retain the edited scene; or retain the scene but remove modifiers absent from the initial base before executing the unchanged script\. This last policy supplies a compatible replacement contract\. No language\-model requests or rendering calls are made\.

Figure 6:The same program has different repeated\-execution semantics\.Measured modifier count and evaluated mesh volume ongeometry20\. Persistent appending creates one additional modifier per execution and halves the current volume each time\. Rebuild and explicit modifier replacement coincide at one modifier and constant volume\. All three use the same archived program and Blender 3\.6\.0; the volume is normalized by each policy’s identical first execution\.Persistent execution yields one, three, and nine modifiers at steps 1, 3, and 9; the corresponding measured volumes are approximately 4, 1, and 0\.015625 Blender units cubed\. Rebuild and replacement both retain one modifier and volume 4 throughout\. The evaluated meshes retain eight vertices and six faces under all policies: the effect here is repeated transformation, not growing mesh topology\. Object bounds, modifier identities, script/base/helper hashes, and all 27 observations are supplied\. This single\-program intervention explains a concrete accumulation mechanism and identifies a compatible persistent alternative; the 280\-task closed\-loop experiment separately measures the overall backend policy\.

## Appendix QArtifacts and traceability

Table[16](https://arxiv.org/html/2610.13098#A14.T16)identifies the experiment associated with each result\. The following records and scripts connect those results to their task\-level sources\.

- •GPT system metrics\.supplement/gpt\_single\_runtime/metrics\.jsoncontains all 1,400 task–system records in the Blender 3\.6 comparison\. The same directory contains per\-task extended metrics, complete paired analyses, and saved cost counters\. The 212\-task intersection used for theN=1N\{=\}1comparisons is listed inanalysis\.json\. The context\-ablation and scene\-origin experiments use their separately identified run sets\.
- •Paired tests\.paired\_stats\.pyproduces task bootstraps and exact sign tests\. Cost counters are inrun\_stats\.json\.
- •Scene\-origin ablation\.supplement/scene\_execution/metrics\.jsoncontains all 560 task–arm records, including invalid tasks and hashes of scored renders\.paired\_stats\.pyin the same directory producespaired\_stats\.json,paired\_tasks\.csv, and both scene\-ablation tables\. The source run iscommit\_gate\_grid, with armscomp\_fullandcomp\_persistent\_scene;source\_audit/preserves the runner, evaluator, task manifest, status records and representative logs\. Figure[5](https://arxiv.org/html/2610.13098#A8.F5)is built byfig/scene\_execution/build\_figure\.pyfrom stored images and candidate CSVs; its manifest records source hashes\.
- •Runtime audit\.The runtime validation records useenv\_check\_start\_scripts\.pyoutputs \(results\.jsonand renders\) andenv\_fix\_report\.py\.
- •Extended metrics\.scripts/extended\_metrics\.pyscores stored final\-answer images; per\-task and paired records are underextended\_metrics/\. Qwen sources are listed in Appendix[K](https://arxiv.org/html/2610.13098#A11)\.
- •Program\-strategy examples\.Figure[4](https://arxiv.org/html/2610.13098#A6.F4)and Table[15](https://arxiv.org/html/2610.13098#A13.T15)use One\-Shot programs under<run\>/sampled\_data/<task\>/baseline/<model\>\.py, iterative scripts under<line\>/<task\>/scripts/<k\>\.py,generator\_candidates\.json, and the corresponding One\-Shot logs\.

#### Base scene and proposal contract\.

The task supplies bothblender\_file\.blend\(BB\) andstart\.py\(p0p\_\{0\}\)\. The latter is the editable reference program shown to the generator; the runner does not execute it as an extra preparation step before a proposal\. It loads the supplied native scene and executes the submitted script once\. Thus, a complete proposal is complete relative to the assets and objects already supplied inBB\. The answer rule in Appendix[N](https://arxiv.org/html/2610.13098#A14.SS0.SSS0.Px3)associates the evaluated render with the program in its selected delivered record, which may be a repaired program rather than the submitted script\. A cached fallback retains the provenance of its earlier render and does not assign that render to a failed submission\.

#### Pinned planning channel\.

The BlenderGym planning tool accepts a free\-formdetailed\_planstring covering visual analysis, code analysis, and intended edits\. Its response is inserted into the second pinned message underInitial plan:; a subsequent planning call replaces that text in place\. Both history settings use this mechanism\.

#### Implementation\-to\-claim mapping\.

agents/generator\.pysamples and executes candidate actions, selects a returned outcome, invokes the verifier when requested, appends the selected interaction, and logs all candidates\.agents/prompt\_builder\.pypins the initial two messages and applies the role\-specific recent\-message window, with tool\-boundary handling\. The runner sets the generator window to three for the short\-history variant, enables shared history for the role\-asymmetry control, and bypasses verification for the no\-verifier control\. The complete\-script response field and latest\-render guidance are prompt instructions; the final\-answer evaluator separately selects the last successful render\. TheN\>1N\{\>\}1path votes over action types before executing candidates of the selected type; Algorithm[2](https://arxiv.org/html/2610.13098#alg2)explicitly places refinement before the selection of delivered outcomes\.

#### Prompt scope and system controls\.

The released generator prompts combine shared evidence\-use instructions, Blender binding/API conventions, and family\-specific guidance\. All context\-window conditions share these instructions\. The VIGA runner saves successful scene updates, whereas the VETR runner loads the task base scene for each complete\-script execution\. History and scene\-origin contrasts change individual settings; the same\-run prefix analysis holds initial guidance fixed, and role\-prompt/recipe controls are reported in Appendix[O](https://arxiv.org/html/2610.13098#A15)\.