Paper deep dive

VIGOR: Verifiable Industrial Geometry Optimization and Repair in Scene Programs

Fuqiang Wang, Zheng Guo, Xiaoming Wu, Hanlin Kong, Nayu Liu, Chuanting Zhang, Daojun Liang, Jingxuan Wei

Year: 2026Venue: arXiv preprintArea: cs.AIType: PreprintEmbeddings: 77

Intelligence

Status: succeeded | Model: Gemma-4-26B-A4B | Prompt: intel-v1 | Confidence: 93%

Last extracted: 10/12/2026, 6:58:12 AM

Summary

The paper introduces VIGOR, a framework addressing the 'executability-engineering-feasibility gap' in industrial scene program generation by Large Language Models. While LLMs can generate executable programs, these often violate coupled engineering constraints (boundary, collision, clearance, aisle, structural). VIGOR combines supervised fine-tuning for program generation with execution-grounded verification and staged geometric refinement (local projection and joint conflict-graph repair). The authors also present a new dataset of 1,749 constructible industrial scenarios with 94 geometric checks each. VIGOR achieves 96.86% Complete Feasibility and an Overall score of 91.20, significantly outperforming strong baselines.

Entities (8)

VIGOR · methodframework · 98%VIGOR Dataset · dataset · 96%Executability-Engineering-Feasibility Gap · conceptproblem · 95%Joint Conflict-Graph Repair · technique · 93%Local Refinement · technique · 93%Qwen3-VL-8B-Instruct · model · 92%DeepSeek V4.1 Flash · model · 90%LoRA · technique · 90%

Relation Signals (7)

VIGOR Dataset → contains → 1,749 constructible scenarios

confidence 96% · dataset with 1,749 constructible scenarios

VIGOR → achieves → 96.86% Complete Feasibility

confidence 95% · VIGOR achieves 96.86% Complete Feasibility

VIGOR → addresses → Executability-Engineering-Feasibility Gap

confidence 95% · We identify this mismatch as the executability-engineering-feasibility gap... We further propose VIGOR... to make this gap measurable

VIGOR → uses → Local Refinement

confidence 93% · local projection resolves independently correctable violations

VIGOR → uses → Joint Conflict-Graph Repair

confidence 93% · joint conflict-graph repair coordinates residual multi-object conflicts

VIGOR → isbuiltupon → Qwen3-VL-8B-Instruct

confidence 92% · we fine-tune Qwen3-VL-8B-Instruct... with LoRA

VIGOR → outperforms → DeepSeek V4.1 Flash

confidence 90% · outperforming the strongest evaluated baseline by 10.42 points in Overall

Cypher Suggestions (0)

No Cypher suggestions yet.

Abstract

Abstract:Large language models (LLMs) increasingly generate structured layouts and executable scene programs from natural-language instructions. However, executability does not imply engineering feasibility: an industrial scene program may execute successfully while its final state still violates coupled boundary, collision, clearance, aisle, or structural constraints. We identify this mismatch as the executability-engineering-feasibility gap, where locally plausible placements can remain globally infeasible because corrections to one device may introduce violations elsewhere. To make this gap measurable in a controlled setting, we construct an execution-grounded industrial scene-program dataset with 1,749 constructible scenarios, complete executable programs, and 94 final-state geometric checks per scenario. We further propose VIGOR, which combines supervised scene-program generation with execution-grounded verification and staged geometric refinement. Supervised fine-tuning establishes complete program generation, local projection resolves independently correctable violations, and joint conflict-graph repair coordinates residual multi-object conflicts while preserving structural relations. Experiments show that VIGOR achieves 96.86% Complete Feasibility and an Overall score of 91.20, outperforming the strongest evaluated baseline by 10.42 points in Overall. These results show that, under controlled industrial layout conditions, reliable scene-program generation requires not only executable programs, but also explicit verification and coordinated resolution of coupled engineering constraints.

PDF

Open source PDF →Open local PDF →

Trouble viewing inline? Open PDF directly →

Full Text

74,153 characters extracted from source content.

Expand or collapse full text

Preprint VIGOR: VERIFIABLE INDUSTRIAL GEOMETRY OPTI- MIZATION AND REPAIR IN SCENE PROGRAMS Fuqiang Wang 2 , Zheng Guo 2 , Xiaoming Wu 2 , Hanlin Kong 2 , Nayu Liu 3 , Chuanting Zhang 4 , Daojun Liang 5 , Jingxuan Wei 1,2,6,∗ 1 University of Chinese Academy of Sciences, Beijing, China 2 Qilu University of Technology, Jinan, China 3 Tianjin University, Tianjin, China 4 Shandong University, Jinan, China 5 Qilu University of Technology (Shandong Academy of Sciences), Jinan, China 6 Shandong Computer Science Center, Jinan, China ∗ Corresponding author: Jingxuan Wei , weijingxuan20@mails.ucas.edu.cn ABSTRACT Large language models (LLMs) increasingly generate structured layouts and exe- cutable scene programs from natural-language instructions. However, executabil- ity does not imply engineering feasibility: an industrial scene program may execute successfully while its final state still violates coupled boundary, colli- sion, clearance, aisle, or structural constraints. We identify this mismatch as the executability–engineering-feasibility gap, where locally plausible placements can remain globally infeasible because corrections to one device may introduce vio- lations elsewhere. To make this gap measurable in a controlled setting, we con- struct an execution-grounded industrial scene-program dataset with 1,749 con- structible scenarios, complete executable programs, and 94 final-state geomet- ric checks per scenario. We further propose VIGOR, which combines super- vised scene-program generation with execution-grounded verification and staged geometric refinement. Supervised fine-tuning establishes complete program gen- eration, local projection resolves independently correctable violations, and joint conflict-graph repair coordinates residual multi-object conflicts while preserving structural relations. Experiments show that VIGOR achieves 96.86% Complete Feasibility and an Overall score of 91.20, outperforming the strongest evaluated baseline by 10.42 points in Overall. These results show that, under controlled industrial layout conditions, reliable scene-program generation requires not only executable programs, but also explicit verification and coordinated resolution of coupled engineering constraints. 1INTRODUCTION Language-driven scene generation increasingly turns natural-language requirements into structured layouts and executable scene programs. Recent systems have advanced from compositional layout synthesis toward programmatic and industrial scene construction (Feng et al., 2023; Lin & Mu, 2024; Hu et al., 2024; Xia et al., 2025; Zhang et al., 2025). However, successful execution does not guarantee that the resulting layout satisfies its engineering constraints. This leaves a basic capability boundary unresolved: can a model generate industrial scene programs that are not only executable, but also engineering-feasible? We investigate this boundary through industrial scene-program generation. Given a natural-language requirement and explicit engineering constraints, the model must generate a complete structured pro- gram that instantiates and arranges the required devices while preserving structural relations. We intentionally adopt a controlled industrial setting with a fixed asset inventory and program schema, allowing us to systematically isolate the central question of whether executable scene programs can satisfy coupled engineering constraints under varying spatial conditions. As illustrated in Figure 1, this setting changes the success criterion from program execution to complete engineering feasi- 1 arXiv:2610.13145v1 [cs.AI] 9 Oct 2026 Preprint Attachment Boundary Main Aisle Clearance Work Needs Current Limitations Multi-Object CouplingStructure Broken Executable Program ≠ Feasible Layout Figure 1: Industrial scene-program generation exposes an engineering-feasibility gap hidden by suc- cessful execution. A valid industrial layout must simultaneously satisfy boundary, aisle, clearance, and attachment constraints, while executable programs may still contain coupled multi-object con- flicts or broken structural relations that invalidate the final scene. bility of the final scene state. Moreover, engineering constraints are coupled through shared device transforms: adjusting one device to satisfy a local constraint may create new collisions, clearance violations, or aisle conflicts elsewhere. We refer to this mismatch as the executability–engineering-feasibility gap. It lies at the intersec- tion of executable scene, constraint-aware layout reasoning, and execution-guided repair. Existing work increasingly produces structured or executable scenes (Hu et al., 2024; Xia et al., 2025; Zhang et al., 2025; Wang et al., 2026a), improves spatial and multi-object validity (Wang et al., 2019; Dupty et al., 2024; Sun et al., 2025; Li et al., 2026), or uses execution feedback and geometric vali- dation to refine generated artifacts (Zhong et al., 2024; Gumin et al., 2025; Barkley et al., 2026). Yet complete post-execution feasibility under all task-specified engineering constraints remains insufficiently characterized. To make this gap measurable, we construct an execution-grounded dataset with 1,749 constructible scenarios. Each contains 11 required instances and a complete 25-operation scene program.v1, whose final state is evaluated for structural consistency and 94 geometric checks covering boundaries, collisions, clearances, and the main aisle. We further propose VIGOR, which couples supervised scene-program generation with execution- grounded verification and staged geometric refinement. Supervised fine-tuning first learns to gener- ate complete programs from task requirements and engineering constraints. Since token-level imita- tion does not directly optimize final-state feasibility, executable outputs may retain hard-constraint violations. VIGOR therefore verifies the executed state, applies local refinement to independently correctable violations, and invokes joint refinement for residual coupled conflicts requiring coordi- nated multi-object adjustments. The refined program is then re-executed and re-verified. Experiments reveal a pronounced executability–engineering-feasibility gap: strong models can achieve high geometric quality while still failing complete feasibility. Ablations show that su- pervised fine-tuning establishes strong structural and geometric priors, local refinement resolves independent violations, and joint refinement addresses residual coupled conflicts. Together, these components yield the strongest complete-feasibility performance. Our main contributions are as follows: 2 Preprint • We formalize complete engineering feasibility for industrial scene-program generation and characterize an executability–engineering-feasibility gap, where successful execution does not guarantee satisfaction of all task-specified engineering constraints. • We construct a controlled execution-grounded benchmark for industrial scene- program generation with 1,749 constructible scenarios, complete structured programs, and final-state verification of structural consistency and geometric feasibility under sys- tematically varied engineering conditions. • We propose VIGOR, combining supervised scene-program generation with execution- grounded verification and complementary local–joint geometric refinement. Experiments show that VIGOR substantially improves complete engineering feasibility over general models and representative code and layout generation methods. 2RELATED WORK 2.1LANGUAGE-DRIVEN EXECUTABLE SCENE GENERATION Language-driven scene generation translates natural-language descriptions into structured layouts, 3D environments, or executable scene programs. Prior work has advanced from object layout and semantic relation modeling to programmatic scene construction and executable generation (Feng et al., 2023; Lin & Mu, 2024; Hu et al., 2024; Khan et al., 2024; Zhang et al., 2025). Recent systems further extend this paradigm toward industrial, physically validated, and simulation-ready scenes (Xia et al., 2025; 2026; Wang et al., 2026a; Xiao et al., 2026). Our work studies complete executable scene generation from natural-language industrial requirements, emphasizing the spatial and structural feasibility of the final executed state. 2.2SCENE CONSTRAINT SATISFACTION AND COMPLETE FEASIBILITY Constraint-aware scene generation incorporates spatial, physical, and relational conditions to im- prove geometric and functional feasibility (Wang et al., 2019; Yang et al., 2024b;a; Raistrick et al., 2024). Subsequent methods model interacting constraints through structured representations, opti- mization, and global validation to reduce collisions, boundary violations, and other layout inconsis- tencies (Dupty et al., 2024; Sun et al., 2025; Wang et al., 2026b; Li et al., 2026; Huang et al., 2026; Bisht et al., 2022). Our work instead focuses on complete feasibility: whether the final executed scene simultaneously satisfies all task-specified spatial and structural constraints. 2.3EXECUTION-GUIDED SCENE GENERATION AND SCENE LEGALIZATION Execution and verification feedback have long been used in program synthesis to refine generated programs through tests, runtime states, or counterexamples (Solar-Lezama et al., 2006; Nguyen et al., 2013; Mechtaev et al., 2015; 2016; Le et al., 2022; Zhong et al., 2024). Related ideas have been adopted in scene and CAD generation through execution feedback, geometric verification, program search, and layout legalization (Hu et al., 2024; Xia et al., 2025; Barkley et al., 2026; Gumin et al., 2025; Spindler et al., 2008; Von Essen & Jobstmann, 2015). Our work integrates legalization into language-to-scene generation, correcting residual spatial violations while preserving program structure, instance identities, hierarchy, and attachment consistency. 3METHOD 3.1PROBLEM FORMULATION We study executable industrial scene-program generation. Given context X containing an instruc- tion, constraints, asset geometry, and instance/hierarchy contracts, the model generates a program P = (a 1 ,...,a L ), a ℓ = (κ ℓ ,ξ ℓ ), S ℓ =E (S ℓ−1 ,a ℓ ),(1) whereE is the frozen state engine, κ ℓ ∈create,transform,parent,save is the operation type, and ξ ℓ contains its instance identifiers and typed parameters. 3 Preprint Task Constraints Workspace boundary Main aisle(keep clear) Clearance requirement Parent /attachment relation AssetCatalog Instance ID Category M1 M2 R1 C1 V1 Station Rack Conveyor Forklift CNC SFT Generation & Geometric Repair Authority Verification Qwen3-8B Initial Output Initial scene_program Scene state Initial Generation & Authority Verification Authority Verification Violations Violation Detection & Repair Collision Aisle Blocked Clearance Violation Repair Loop Local Repair (L) Joint Repair (J) Local geometric adjustment Coupled multi-object adjustment Re-verify before after Feasible Scene Program Feasible Industrial Layout Feasible layout without violations Task&Constraint Input Industrial Layout Task Main aisle Workspace (boundary) Preservation & Final Output Figure 2: Overview of VIGOR. SFT generates the initial scene program, verification detects residual violations, and local–joint repair produces a feasible layout. Successful execution alone is insufficient. Let t(P ) denote the executed transforms and H(X) workspace, boundary, collision, clearance, aisle, and structural constraints. Complete feasibility is Feasible(P | X) =    Y h∈H(X) h(t(P );X), Exec(P ) = 1, 0,otherwise, (2) where the predicates are evaluated on the final reloaded scene, including its identities and hierarchy. These constraints are coupled through shared transforms. For constraint h, let m h (t I(h) ;X) denote its signed satisfaction margin over the involved devicesI(h). A correction ∆t induces ∆m h = m h (t + ∆t) I(h) ;X − m h t I(h) ;X , I(h)∩ supp(∆t)̸= ∅.(3) Thus, improving one constraint may inadvertently degrade others, motivating iterative local correc- tion followed by joint refinement of residual conflicts. 3.2VIGOR: GENERATION WITH LOCAL–JOINT REFINEMENT As shown in Figure 2, VIGOR combines scene-program generation, execution-grounded verifica- tion, and staged geometric refinement. The generator produces P 0 = f θ (X), which is executed and verified against the public constraints. The verifier returnsV(P,X), containing violated constraint atoms, their involved devices, and violation deficits. For an executable P 0 , VIGOR proceeds as P loc = P 0 ,Feasible(P 0 | X) = 1, L(P 0 ,X;V(P 0 ,X)), otherwise, P F = P loc ,Feasible(P loc | X) = 1, J (P loc ,X;V(P loc ,X)), otherwise. (4) Local refinement L handles independently correctable violations, while joint refinement J coor- dinates residual multi-object conflicts. Candidate programs are re-executed and verified, while preserving the program structure, instance identities, hierarchy, and attachment relations. Non- executable outputs bypass refinement and remain failed. 3.3SUPERVISED SCENE-PROGRAM GENERATION Given training pairs (X,P ∗ ), where P ∗ is a reference scene program.v1, we fine-tune Qwen3- VL-8B-Instruct (Bai et al., 2025) with LoRA. Writing P ∗ as (p ∗ 1 ,...,p ∗ M ), we minimize L SFT =− X (X,P ∗ )∈D train M X m=1 logp θ (p ∗ m | X,p ∗ <m ).(5) 4 Preprint The supervision covers complete programs, including device creation, transform assignment, hi- erarchy construction, and scene saving.The complete scene program.v1 interface and model- visible generation template are provided in Appendix D. At inference time, a single greedy decoding pass produces P 0 . Since token-level imitation does not directly optimize final-state feasibility, the generated program is executed and verified, and any residual violations are passed to geometric refinement. 3.4LOCAL–JOINT GEOMETRIC REFINEMENT Geometric refinement operates on the executed scene through local projection followed by joint con- flict resolution. Local candidatesC L (P ) apply boundary projections, aisle push-outs, and clearance corrections. Their admissibility is determined after re-execution: A L (P ) = P ′ ∈C L (P ) : Valid(P ′ ), V(P ′ ,X)⊆V(P,X), n T (P ′ ) < n T (P )∨ D T (P ′ ) < D T (P ), V(P ′ ,X) =V(P,X)⇒ s(P ′ )≥ s(P ) , (6) whereT denotes the targeted constraint atoms, n T counts violations, D T sums their deficits, and s is mean functional quality. Valid(P ′ ) requires successful execution and structural correctness. Among admissible candidates, local refinement favors fewer modified devices and smaller displacement. Residual violations induce a conflict graph whose connected components identify coupled device groups. For a valid search state z = (P,M,D), joint refinement uses the lexicographic objective Φ(z) = |V|, X h∈V ̄ d h , max h∈V ̄ d h ,−s(P ),|M|,D,σ(P ) ! ,(7) where ̄ d h is the normalized violation deficit,M records modified devices, D accumulates displace- ment, and σ(P ) provides deterministic tie-breaking. LetN (z) contain all valid successors that preserve satisfied parent-link and attachment constraints. Beam search iteratively updates B d+1 = TopB lexΦ [ z∈B d N (z) ! .(8) Search terminates upon feasibility or budget exhaustion, and the best state is retained only when it improves the input objective and preserves attachment consistency. (a) Data Collection Public Sources Guidelines •NIST ARIAC •AWS Robot •CCOHS •OSHA Environment Resources & 3D Assets • industrial assets • geometry • environment resources (b) Condition Grid Expansion (c) Feasibility Filtering Project-defined Task Constraints Candidate Conditions Grid Expansion 2754 0.05 m grid w c b o Aisle width Equipment clearance Boundary clearance Aisle orientation w c b o (17) (9)(9) (2) 17×9×9×2 (d) Authoritative Layout Generation Feasibility Check Boundary Aisle CollisionClearance 1749 Constructible Conditions (w 4 , c 4 , b 4 , o 4 ) (w 5 , c 5 , b 5 , o 5 ) (w 6 , c 6 , b 6 , o 6 ) ... ... baseline construction candidate search selection Valid Condition Authoritative Layout Generator Complete Legal Layout I reference layout pervalid condition (e) Scene Program Conversion (f) Execution & Geometry Validation Deterministic Program Conversion Convert layout representation to structured program(fixed schema) Executable ‘scene program’ “version”: “1.0”, “operations”:[ “op”: “create_object”,..., “op”: “set_transform”,..., (11 create_object + 11 set_transfo rm + 2 set_parent + 1 save_scene) Scene State Execute program and obtain scene state Geometry & Structure Validation Schema & Operation Check Instance Identity Check ......... Final Output Figure 3: Construction pipeline of the VIGOR dataset. Public assets and engineering constraints are expanded into candidate conditions, filtered for constructibility, converted into executable scene programs, and finally executed and validated. 5 Preprint 4DATASET 4.1DATASET CONSTRUCTION Asset and Task Condition Construction. Candidate assets and environments are collected from NIST ARIAC, Poly Haven, and AWS RoboMaker Small Warehouse. Since these resources cannot directly form a unified industrial layout task, we standardize units, coordinate systems, pivots, and local AABBs, and unify instance identities, parent–child relations, and the scene-program interface. Based on these standardized resources, we construct a candidate condition space over main-aisle width, device clearance, boundary clearance, and aisle orientation, providing unified inputs for sub- sequent constructibility screening and reference layout generation. The complete condition grid and constructibility-screening protocol are provided in Appendix C. Constructibility Screening and Reference Layout Generation. Candidate conditions are first processed by a predefined layout generation and validation pipeline to remove those for which a complete valid layout cannot be constructed under the current construction procedure. For each retained condition, a unified layout generator and deterministic search procedure are used to produce candidate reference layouts, from which the final layout is selected through a consistent validation and scoring process. This stage yields a complete reference layout aligned with each task condition, serving as the intermediate representation for subsequent structured scene-program conversion. Structured Scene-Program Conversion. Each reference layout is then mapped to a unified scene program.v1 representation. Object identities, spatial transformations, and parent–child relations are encoded as object-creation, transformation-setting, and hierarchy-setting operations, respectively, and organized according to a consistent program order. This conversion only struc- tures the established reference layout without re-searching or modifying its spatial configuration. As a result, each reference layout is converted into a complete executable scene program for subse- quent execution and state validation. The complete program interface and model-visible generation template are provided in Appendix D. Execution Validation and Final Packaging. Each complete scene program is executed by a Python state engine, and the final scene state is obtained after saving and reloading. The exe- cuted state is then consistently validated for instance completeness, parent–child and attachment relations, as well as spatial conditions including boundaries, collisions, clearances, and the main aisle. The validated task input and scene program are finally packaged as a dataset sample, ensur- ing that each supervision target has both a standardized program structure and an execution-verified complete scene state. Detailed schema, execution, save–reload, structural, and geometric validation procedures are provided in Appendix E. 4.2DATASET ANALYSIS Loose 17.21% Moderate 9.32% Tight 4.12% Loose 28.47% Moderate 3.89% Tight 1.77% Loose 23.44% Moderate 7.43% Tight 4.35% Clearance- Intensive 30.65% Aisle- Intensive 34.13% Boundary- Intensive 35.22% Figure 4: Constraint-profile com- position of the VIGOR dataset. Figure 4 and Table 1 summarize the engineering-constraint composition and structured generation scale of the dataset. From 2,754 candidate conditions, we obtain 1,749 con- structible scenarios, which are split into 1,399 training sam- ples, 175 interpolation test samples, and 175 compositional test samples. To characterize the variation in engineering con- ditions within the final dataset, we perform a normalized post- hoc grouping based on main-aisle width, equipment clearance, and boundary clearance, resulting in three similarly sized con- straint profiles. Each profile spans Loose, Moderate, and Tight feasibility margins, indicating that constraint composition and feasibility tightness constitute two complementary dimensions of dataset variation. On the structured-generation side, each scenario contains 11 instances and a complete, fixed-length 25-operation scene program.v1 program, covering object creation, spatial transformation, parent–child relations, and scene saving. After program execution and 6 Preprint Table 1: Key statistics of the industrial scene program dataset. Dataset statisticsGeneration statistics StatisticCountStatisticCount Candidate conditions2,754Scene instances19,239 Final scenarios1,749Scene programs1,749 Train / I / C1,399 / 175 / 175Program operations43,725 Reference layouts1,749Geometric checks164,406 Validated scenarios1,749Verified programs1,749 save/reload, each scenario is further subjected to 94 geometric checks covering boundary constraints, collisions, equipment clearances, and main-aisle constraints. All 1,749 reference programs pass the complete validation pipeline. 5EXPERIMENTS 5.1EXPERIMENTAL SETUP We use Qwen3-VL-8B-Instruct (Bai et al., 2025) as the base model and apply LoRA for supervised fine-tuning (SFT). The training set contains 1,399 samples, and the model is trained for 3 epochs, corresponding to 4,197 sample exposures and 525 optimization steps. At test time, we adopt single- pass greedy decoding, where each task produces exactly one complete scene program.v1 pro- gram without retries or multi-candidate sampling. We systematically compare VIGOR against three distinct groups of methods.Open-weight models include GLM-4-9B-0414 (Z.ai, 2025), Qwen3-14B (Yang et al., 2025), Gemma-3-12B- IT (Gemma Team et al., 2025), DeepSeek-Coder-V2-Lite-Instruct (DeepSeek-AI, 2024), Granite- 3.3-8B-Instruct (IBM Granite Team, 2025), Qwen3.5-9B (Qwen Team, 2026), and Ministral- 3-8B-Instruct-2512 (Liu et al., 2026).Closed-source/API models include GPT-5.5 (OpenAI, 2026), Claude Sonnet 5 (Anthropic, 2026), DeepSeek-V4.1-Flash (DeepSeek-AI, 2026), and Grok- 4.5 (xAI, 2026). We further compare against published code and layout generation methods, in- cluding OpenCodeReasoning-Nemotron-7B (Ahmad et al., 2025), CodeRL+ (Jiang et al., 2026), and ReSpace (Bucher & Armeni, 2025). This comprehensive benchmark suite covers general open- weight generative models, proprietary large language models, and representative methods for code and structured layout generation. Detailed metric definitions and aggregation rules are provided in Appendix G, and the complete machine-evaluation prompts are provided in Appendix F. 5.2MAIN RESULTS Table 2 shows that VIGOR achieves the best Overall score of 91.20, outperforming the strongest baseline, DeepSeek-V4.1-Flash, by 10.42 points (12.9%). It also obtains the best Bottleneck Geom- etry, Functional Layout, and Tight-FQ scores, indicating stronger geometric feasibility, functional quality, and robustness under tight constraints. Notably, although DeepSeek-V4.1-Flash reaches comparable GVB and Bottleneck Geometry scores of 0.33 and 98.55, its Functional Layout score is only 42.24, compared with 72.39 for VIGOR. This suggests that VIGOR better converts geometric validity into overall engineering-layout quality. The results further expose a clear executability–engineering-feasibility gap. GPT-5.5 and Claude Sonnet 5 obtain GVB scores of 6.05 and 10.11 and Bottleneck Geometry scores of 77.40 and 55.29, while their Complete Feasibility remains only 11.71 and 0.00, respectively. In contrast, VIGOR reaches 0.30 GVB, 99.51 Bottleneck Geometry, and 96.86 Complete Feasibility. This shows that reliable scene-program generation is bottlenecked not only by program generation, but by simulta- neous satisfaction of coupled engineering constraints. Compared with published code and layout generation methods, VIGOR highlights the limitations of existing approaches. OpenCodeReasoning-Nemotron-7B and CodeRL+ achieve Overall scores of 7 Preprint Table 2: Main results on industrial scene-program generation. Models are grouped into open-weight models, closed-source/API models, published methods, and our method. Best and second-best re- sults are highlighted in blue and pink. MethodGVB↓ BG↑ Feas.↑ Func.↑ BQ-FQ↑ Interp-FQ↑ Comp-FQ↑ Tight-FQ↑ Overall↑ LLMJudge↑ Open-weight Models GLM-4-9B-0414 (Z.ai, 2025)11.30 34.96 0.0053.2824.5354.5652.0049.7227.071.975 Qwen3-14B (Yang et al., 2025)15.47 44.48 0.0040.7824.1542.8138.7542.7425.463.225 Gemma-3-12B-IT (Gemma Team et al., 2025)38.21 0.650.0029.876.2529.7130.0319.4513.270.325 DeepSeek-Coder-V2-Lite-Instruct (DeepSeek-AI, 2024) 80.84 0.000.002.650.003.062.233.462.320.300 Granite-3.3-8B-Instruct (IBM Granite Team, 2025)44.25 11.01 0.0011.580.0011.6811.4715.6110.511.225 Qwen3.5-9B (Qwen Team, 2026)15.97 20.32 0.0043.0225.3342.8043.2437.3022.503.275 Ministral-3-8B-Instruct-2512 (Liu et al., 2026)18.09 64.30 0.0034.7526.2436.1033.3939.3326.623.125 Closed-source/API Models GPT-5.5 (OpenAI, 2026)6.05 77.40 11.71 37.0118.0737.0836.9438.1155.093.425 Claude Sonnet 5 (Anthropic, 2026)10.11 55.29 0.0045.56 30.8946.2544.8742.4652.573.900 DeepSeek-V4.1-Flash (DeepSeek-AI, 2026)0.3398.5584.00 42.2426.3941.9842.5047.0080.783.625 Grok-4.5 (xAI, 2026)25.21 41.07 0.0026.796.2526.4427.1527.6523.252.800 Published Methods OpenCodeReasoning-Nemotron-7B (Ahmad et al., 2025) 92.91 0.280.000.000.000.000.000.000.250.125 CodeRL+ (Jiang et al., 2026)83.00 0.000.000.000.000.000.000.001.460.000 ReSpace (Bucher & Armeni, 2025)14.59 29.61 0.000.000.000.000.000.0014.262.000 VIGOR0.3099.5196.8672.3959.0572.7572.0366.9091.204.050 Table 3: Ablation study of different VIGOR variants. Best results are highlighted in blue. MethodGeometry↑Functional↑Feasibility↑Overall↑LLMJudge↑ Base24.7811.020.008.951.23 Base +L→J68.4222.110.0024.031.98 VIGOR-SFT92.7970.3114.5769.34 4.15 VIGOR-SFT +L97.76 70.3756.8681.184.10 VIGOR-SFT +J98.8868.4081.4387.114.13 VIGOR99.5968.6296.8691.204.05 only 0.25 and 1.46, while ReSpace reaches 14.26, far below VIGOR’s 91.20. These results indicate that code generation or spatial layout capability alone is insufficient for engineering feasibility. Overall, reliable industrial scene-program generation requires not only executable structured pro- grams, but also engineering-constraint verification and coordinated resolution of geometric conflicts. Additional process–result and task-capability analyses are provided in Appendices A and B. 5.3ABLATION STUDY Table 3 analyzes the contribution of each component in VIGOR. VIGOR-SFT substantially im- proves Geometry from 24.78 to 92.79 and Overall from 8.95 to 69.34, but its Feasibility remains only 14.57, indicating that supervised fine-tuning alone cannot ensure complete engineering con- straint satisfaction. Applying the refinement pipeline directly to the untuned Base model improves Geometry to 68.42, but Feasibility remains 0.00, showing that refinement alone cannot compensate for the lack of a structured initial program. Starting from the SFT-generated program, local refine- mentL raises Feasibility to 56.86 and Overall to 81.18, while joint refinementJ further improves them to 81.43 and 87.11, respectively. Combining both refinement stages yields the full VIGOR, achieving 99.59 Geometry, 96.86 Feasibility, and 91.20 Overall. These results indicate that SFT and verification-guided refinement play complementary roles: SFT provides a feasible initialization space, whileL andJ progressively resolve remaining geometric violations and coupled conflicts. 5.4CASE STUDY AND ERROR ANALYSIS Figure 5 presents a representative industrial scene-program generation task requiring simultaneous satisfaction of aisle, clearance, boundary, and structural constraints. VIGOR produces a feasible layout despite minor numerical deviations. In contrast, GPT-5.5 violates the main aisle and clear- ance requirements, while Claude Sonnet 5 produces overlapping equipment with insufficient opera- tional space. These failures show that the main challenge lies in coordinating coupled multi-object 8 Preprint constraints rather than simply generating complete scene programs. This case further supports the effectiveness of VIGOR’s post-execution verification and local–joint geometric refinement. Generate an executable industrial scene program that places all required equipment within the workspace while preserving the main aisle, safety clearances, and attachment relations. Question √Assembly Table [-6.7033, -1.1302] √Assembly Insert [-6.7033, -1.1302] √Robot Proxy [-6.1658, 0.0699] √ Container [-4.8057, 1.1732] ...... √Assembly Table [-6.7033, -1.1302] √Assembly Insert[-6.7033, -1.1302] √Robot Proxy [-6.1658, 0.0699] √ Container [-4.8057, 1.1732] Ground Truth Error Analysis Error Analysis Successful Grounding ...... ✗Assembly Table[-6.7033, -1.2303] √Assembly Insert[-6.7033, -1.2303] ✗Robot Proxy[-6.7033, -0.0353] ✗Container[-4.9033, 0.9697] ...... ...... The assembly table intrudes into the main aisle, while the table–robot and robot–container clearances fall below the required 0.45 m. The scene is executable but not engineering-feasible. ✗Assembly Table[-6.7033, -1.1302] √Assembly Insert[-6.7033, -1.1302] ✗Robot Proxy[-6.1658, 0.0699] ✗Metal Office Desk[-6.7033, 1.3907] The workbench and desk visibly overlap around the robot workspace, leaving insufficient operational space despite complete object generation. The reference program provides a feasible arrangement in which all required equipment is placed within the workspace, while the main aisle, safety clearances, and attachment relations are preserved. The generated program correctly grounds all required instances at valid positions. The executed scene preserves the main aisle, satisfies spatial clearances, and maintains the required attachment relations. Ours GPT-5.5 Claude Sonnet 5 Reference Layout Figure 5: Qualitative comparison. VIGOR better preserves spatial constraints and structural rela- tions, avoiding aisle, clearance, and overlap violations. 5.5CONSISTENCY WITH HUMAN JUDGMENTS 0 1 2 3 4 5 012345 GLM-4-9BGLM-4-9BGLM-4-9B Qwen3-14BQwen3-14BQwen3-14B Gemma-3-12BGemma-3-12BGemma-3-12B DS-Coder-V2DS-Coder-V2DS-Coder-V2 Granite-3.3Granite-3.3Granite-3.3 Qwen3.5-9BQwen3.5-9BQwen3.5-9B Ministral-3-8BMinistral-3-8BMinistral-3-8B GPT-5.5GPT-5.5GPT-5.5 Claude S5Claude S5Claude S5 DeepSeek-V4.1DeepSeek-V4.1DeepSeek-V4.1 Grok-4.5Grok-4.5Grok-4.5 OpenCode-N7BOpenCode-N7BOpenCode-N7B CodeRL+CodeRL+CodeRL+ ReSpaceReSpaceReSpace OursOursOurs r = 0.9773r = 0.9773r = 0.9773 Human Proxy (0–5)Human Proxy (0–5)Human Proxy (0–5) LLMJudge (0–5)LLMJudge (0–5)LLMJudge (0–5) 标签 Ours 模型名 Ours 字号 24px 颜色 Figure 6: Automatic vs. human rat- ings. Figure 6 shows a clear alignment between LLMJudge and hu- man ratings. Lower-performing methods cluster toward the lower-left region, while stronger models move consistently to- ward the upper-right. VIGOR occupies the top-right region, achieving high scores under both evaluation protocols. The near-perfect correlation (r = 0.9773) demonstrates strong agreement between LLMJudge and independent human judg- ments across the evaluated methods. This consistency indicates that the automated visual evaluation captures model-level differ- ences that are also reflected in human assessments, supporting its use as a reliable complement to the objective engineering metrics. Detailed definitions and aggregation rules for the vi- sual evaluation are provided in Appendix G, and the complete machine-evaluation prompts are provided in Appendix F. 6CONCLUSION We study structured industrial scene-program generation from the perspective of complete engineer- ing feasibility, where producing an executable program is not sufficient unless the executed scene also satisfies the required spatial, structural, and functional constraints. This setting is challenging because multiple constraints are coupled through shared device transforms, so resolving one viola- tion may introduce another. To make this problem measurable, we construct an execution-grounded benchmark in which complete scene program.v1 programs are executed, save/reloaded, and verified against the final scene state. We further propose VIGOR, which combines supervised scene-program generation with post-execution verification and deterministic local–joint geomet- ric refinement. Experiments reveal a clear executability–engineering-feasibility gap: strong models can generate structured and geometrically plausible programs while still failing complete engineer- ing feasibility, whereas VIGOR substantially narrows this gap and achieves the strongest overall engineering performance. This work focuses on a controlled industrial layout setting with a fixed asset inventory, structured program schema, and deterministic state-based verification. Extending 9 Preprint the same principle to broader asset libraries, richer scene programs, dynamic process constraints, and live simulation or editor environments remains a natural direction for future work. AI USE STATEMENT Generative AI tools were used solely during dataset construction to assist with the generation and organization of structured task instances. The authors designed the benchmark, dataset construction procedures, evaluation criteria, and experimental protocols, and independently verified all generated data and reported results. REPRODUCIBILITY STATEMENT We provide detailed descriptions of the benchmark construction, scene-program specification, exe- cution protocol, and evaluation criteria. The paper and appendix include the complete task construc- tion procedure, dataset statistics, program interface, validation pipeline, and metric definitions. We further report the model architecture, fine-tuning strategy, training schedule, inference protocol, and baseline evaluation settings to facilitate reproduction of the reported experiments. REFERENCES Wasi Uddin Ahmad, Sean Narenthiran, Somshubra Majumdar, Aleksander Ficek, Siddhartha Jain, Jocelyn Huang, Vahid Noroozi, and Boris Ginsburg. Opencodereasoning: Advancing data distil- lation for competitive coding. arXiv preprint arXiv:2504.01943, 2025. Anthropic.Introducing Claude Sonnet 5.Anthropic, June 2026.URL https://w. anthropic.com/news/claude-sonnet-5. Shuai Bai, Yuxuan Cai, Ruizhe Chen, Keqin Chen, Xionghui Chen, Zesen Cheng, Lianghao Deng, Wei Ding, Chang Gao, Chunjiang Ge, et al.Qwen3-VL technical report. arXiv preprint arXiv:2511.21631, 2025. Jesse Barkley, Rumi Loghmani, and Amir Barati Farimani. Cadsmith: Multi-agent cad generation with programmatic geometric validation. arXiv preprint arXiv:2603.26512, 2026. Sumit Bisht, Krishnendra Shekhawat, Nitant Upasani, Rahil N Jain, Riddhesh Jayesh Tiwaskar, and Chinmay Hebbar. Transforming an adjacency graph into dimensioned floorplan layouts. In Computer Graphics Forum, volume 41, p. 5–22. Wiley Online Library, 2022. Martin J Bucher and Iro Armeni. Respace: Text-driven autoregressive 3d indoor scene synthesis and editing. arXiv preprint arXiv:2506.02459, 2025. DeepSeek-AI. DeepSeek-Coder-V2: Breaking the barrier of closed-source models in code intelli- gence. arXiv preprint arXiv:2406.11931, 2024. DeepSeek-AI. DeepSeek-V4.1-Flash: Pushing the limits of KV cache compression. arXiv preprint arXiv:2609.19969, 2026. Mohammed Haroon Dupty, Yanfei Dong, Sicong Leng, Guoji Fu, Yong Liang Goh, Wei Lu, and Wee Sun Lee. Constrained layout generation with factor graphs. In 2024 IEEE/CVF Conference on Computer Vision and Pattern Recognition (CVPR), p. 12851–12860. IEEE, 2024. Weixi Feng, Wanrong Zhu, Tsu-jui Fu, Varun Jampani, Arjun Akula, Xuehai He, Sugato Basu, Xin Eric Wang, and William Yang Wang. Layoutgpt: Compositional visual planning and gen- eration with large language models. Advances in neural information processing systems, 36: 18225–18250, 2023. Gemma Team, Aishwarya Kamath, Johan Ferret, Shreya Pathak, Nino Vieillard, Ramona Merhej, Sarah Perrin, et al. Gemma 3 technical report. arXiv preprint arXiv:2503.19786, 2025. Maxim Gumin, Do Heon Han, Seung Jean Yoo, Aditya Ganeshan, R Kenny Jones, Kailiang Fu, Rio Aguina-Kang, Stewart Morris, and Daniel Ritchie. Procedural scene programs for open- universe scene generation: Llm-free error correction via program search. In Proceedings of the SIGGRAPH Asia 2025 Conference Papers, p. 1–11, 2025. 10 Preprint Ziniu Hu, Ahmet Iscen, Aashi Jain, Thomas Kipf, Yisong Yue, David A Ross, Cordelia Schmid, and Alireza Fathi. Scenecraft: An llm agent for synthesizing 3d scenes as blender code. In ICML, p. 19252–19282, 2024. Jialu Huang, Yingxuan You, Fei Wang, and Zheng Dang. Global graph-validated optimization for vlm-based 3d indoor scene generation. arXiv preprint arXiv:2608.03064, 2026. IBM Granite Team. Granite-3.3-8B-Instruct model card. Hugging Face, 2025. URL https: //huggingface.co/ibm-granite/granite-3.3-8b-instruct. Xue Jiang, Yihong Dong, Mengyang Liu, Deng Hongyi, Tian Wang, Yongding Tao, Zhi Jin, Wenpin Jiao, and Ge Li. Coderl+: Improving code generation via reinforcement with execution semantics alignment. In Proceedings of the 64th Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers), p. 3608–3622, 2026. Mohammad S Khan, Sankalp Sinha, Talha U Sheikh, Didier Stricker, Sk A Ali, and Muhammad Z Afzal. Text2cad: Generating sequential cad designs from beginner-to-expert level text prompts. Advances in Neural Information Processing Systems, 37:7552–7579, 2024. Hung Le, Yue Wang, Akhilesh Deepak Gotmare, Silvio Savarese, and Steven Chu Hong Hoi. Coderl: Mastering code generation through pretrained models and deep reinforcement learning. Advances in Neural Information Processing Systems, 35:21314–21328, 2022. Shuqing Li, Anson Y Lam, Yun Peng, Wenxuan Wang, and Michael R Lyu. 3d software syn- thesis driven by constraint-expressive intermediate representation. In Proceedings of the 2026 IEEE/ACM 48th International Conference on Software Engineering, p. 1354–1366, 2026. Chenguo Lin and Yadong Mu. Instructscene: Instruction-driven 3d indoor scene synthesis with semantic graph prior. In International Conference on Learning Representations, volume 2024, p. 25687–25718, 2024. Alexander H. Liu, Kartik Khandelwal, Sandeep Subramanian, Victor Jouault, Abhinav Rastogi, Adrien Sad ́ e, Alan Jeffares, et al. Ministral 3. arXiv preprint arXiv:2601.08584, 2026. Sergey Mechtaev, Jooyong Yi, and Abhik Roychoudhury. Directfix: Looking for simple program repairs. In 2015 IEEE/ACM 37th IEEE International Conference on Software Engineering, vol- ume 1, p. 448–458. IEEE, 2015. Sergey Mechtaev, Jooyong Yi, and Abhik Roychoudhury. Angelix: Scalable multiline program patch synthesis via symbolic analysis. In Proceedings of the 38th international conference on software engineering, p. 691–701, 2016. Hoang Duong Thien Nguyen, Dawei Qi, Abhik Roychoudhury, and Satish Chandra. Semfix: Pro- gram repair via semantic analysis. In 2013 35th International Conference on Software Engineer- ing (ICSE), p. 772–781. IEEE, 2013. OpenAI. GPT-5.5 system card. OpenAI Deployment Safety Hub, April 2026. URL https: //deploymentsafety.openai.com/gpt-5-5. Qwen Team. Qwen3.5: Towards native multimodal agents, February 2026. URL https://qwen. ai/blog?id=qwen3.5. Alexander Raistrick, Lingjie Mei, Karhan Kayan, David Yan, Yiming Zuo, Beining Han, Hongyu Wen, Meenal Parakh, Stamatis Alexandropoulos, Lahav Lipson, et al. Infinigen indoors: Photo- realistic indoor scenes using procedural generation. In 2024 IEEE/CVF Conference on Computer Vision and Pattern Recognition (CVPR), p. 21783–21794. IEEE, 2024. Armando Solar-Lezama, Liviu Tancau, Rastislav Bodik, Sanjit Seshia, and Vijay Saraswat. Com- binatorial sketching for finite programs. In Proceedings of the 12th international conference on Architectural support for programming languages and operating systems, p. 404–415, 2006. Peter Spindler, Ulf Schlichtmann, and Frank M Johannes. Abacus: Fast legalization of standard cell circuits with minimal movement. In Proceedings of the 2008 international symposium on Physical design, p. 47–53, 2008. 11 Preprint Fan-Yun Sun, Weiyu Liu, Siyi Gu, Dylan Lim, Goutam Bhat, Federico Tombari, Manling Li, Nick Haber, and Jiajun Wu. Layoutvlm: Differentiable optimization of 3d layout via vision-language models. In 2025 IEEE/CVF Conference on Computer Vision and Pattern Recognition (CVPR), p. 29469–29478. IEEE, 2025. Christian Von Essen and Barbara Jobstmann. Program repair without regret. Formal Methods in System Design, 47(1):26–50, 2015. Kai Wang, Yu-An Lin, Ben Weissmann, Manolis Savva, Angel X Chang, and Daniel Ritchie. Planit: Planning and instantiating indoor scenes with relation graph and spatial prior networks. ACM Transactions on Graphics (TOG), 38(4):1–15, 2019. Puyi Wang, Yuhao Wang, Linjie Li, Zhengyuan Yang, Kevin Qinghong Lin, Yangguang Li, and Yu Cheng. Scenecode: Executable world programs for editable indoor scenes with articulated objects. arXiv preprint arXiv:2605.19587, 2026a. Ruiqi Wang, Qimin Chen, Daniel Ritchie, Angel X Chang, Manolis Savva, Kai Wang, and Hao Zhang. Function2scene: 3d indoor scene layout from functional specifications. arXiv preprint arXiv:2605.30819, 3, 2026b. xAI. Introducing Grok 4.5. xAI, July 2026. URL https://x.ai/news/grok-4-5. Hongchi Xia, Xuan Li, Zhaoshuo Li, Qianli Ma, Jiashu Xu, Ming-Yu Liu, Yin Cui, Tsung-Yi Lin, Wei-Chiu Ma, Shenlong Wang, et al. Sage: Scalable agentic 3d scene generation for embodied ai. arXiv preprint arXiv:2602.10116, 2026. Xiao Xia, Dan Zhang, Zibo Liao, Zhenyu Hou, Tianrui Sun, Jing Li, Ling Fu, and Yuxiao Dong. Scenegenagent: Precise industrial scene generation with coding agent. In Proceedings of the 63rd Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers), p. 17847–17875, 2025. Zijian Xiao, Zipeng Ye, Jinkun Hao, Xiong Yang, Yuchen Xie, and Ran Yi.Beyond place- ment and articulation: Usage-driven code scenes for embodied interaction. arXiv preprint arXiv:2608.18840, 2026. An Yang, Anfeng Li, Baosong Yang, Beichen Zhang, Binyuan Hui, Bo Zheng, Bowen Yu, Chang Gao, Chengen Huang, Chenxu Lv, et al.Qwen3 technical report. arXiv preprint arXiv:2505.09388, 2025. Yandan Yang, Baoxiong Jia, Peiyuan Zhi, and Siyuan Huang. Physcene: Physically interactable 3d scene synthesis for embodied ai. In 2024 IEEE/CVF Conference on Computer Vision and Pattern Recognition (CVPR), p. 16262–16272. IEEE, 2024a. Yue Yang, Fan-Yun Sun, Luca Weihs, Eli VanderBilt, Alvaro Herrasti, Winson Han, Jiajun Wu, Nick Haber, Ranjay Krishna, Lingjie Liu, et al. Holodeck: Language guided generation of 3d embodied ai environments. In 2024 IEEE/CVF Conference on Computer Vision and Pattern Recognition (CVPR), p. 16277–16287. IEEE, 2024b. Z.ai. GLM-4-9B-0414 model card. Hugging Face, 2025. URL https://huggingface.co/ zai-org/GLM-4-9B-0414. Yunzhi Zhang, Zizhang Li, Matt Zhou, Shangzhe Wu, and Jiajun Wu. The scene language: Rep- resenting scenes with programs, words, and embeddings. In 2025 IEEE/CVF Conference on Computer Vision and Pattern Recognition (CVPR), p. 24625–24634. IEEE, 2025. Li Zhong, Zilong Wang, and Jingbo Shang. Debug like a human: A large language model debugger via verifying runtime execution step by step. In Findings of the Association for Computational Linguistics: ACL 2024, p. 851–870, 2024. 12 Preprint APERFORMANCE RESULTS WITH RADAR CHART ANALYSIS To further analyze the capability profiles of different methods, we compare VIGOR with representa- tive open-weight models, closed-source/API models, and published code/layout generation methods across three complementary dimensions, as shown in Figure 7. Program Process Score measures the quality of the structured program-construction process, Final Scene Score evaluates the engi- neering quality of the executed scene, and Unified Capability Score summarizes the two perspec- tives into a single diagnostic view. The radar chart reveals a clear process–result mismatch in existing methods. Several general models, including GLM-4-9B, Qwen3-14B, Gemma-3-12B, Qwen3.5-9B, and Ministral-3-8B, achieve near- saturated Program Process scores while showing substantially weaker Final Scene performance. This indicates that reliably producing a structurally complete program does not necessarily trans- late into an engineering-feasible executed scene. The gap is even more pronounced for CodeRL+, which attains a Program Process score of 100.0 but only 2.0 in Final Scene quality, illustrating that program-level correctness alone is insufficient under coupled geometric constraints. Closed-source models exhibit stronger final-scene capability. GPT-5.5 and Claude Sonnet 5 reach Final Scene scores of 69.5 and 70.1, respectively, while DeepSeek-V4.1-Flash further improves this score to 79.7. Nevertheless, their process and result profiles remain imbalanced, suggesting that high-quality scene-program generation still requires stronger alignment between structured program formation and final engineering feasibility. VIGOR achieves the most balanced capability profile, reaching 99.7 in Program Process, 89.3 in Final Scene, and 94.5 in Unified Capability. Unlike methods whose process scores remain high while final-scene quality degrades, VIGOR maintains strong performance across both stages. These results provide further evidence of the executability–engineering-feasibility gap: successful program construction is only a prerequisite, while reliable industrial scene generation additionally requires execution-grounded verification and coordinated resolution of residual geometric conflicts. BFINE-GRAINED TASK CAPABILITY ANALYSIS To further investigate the task-level bottlenecks of existing methods, we decompose the evaluation into ten capability categories spanning generalization, constraint density, aisle orientation, and con- straint stress. As shown in Figure 8, each cell reports the mean unified task capability over the corresponding evaluation subset, jointly reflecting structural, geometric, and functional scene qual- ity. Across the two evaluation splits, VIGOR maintains consistently high capability, achieving 90.9 on the interpolation split and 90.3 on the held-out compositional split.In contrast, the strongest baseline, DeepSeek-V4.1-Flash, reaches 80.3 and 80.6, while most open-weight models remain substantially lower. The small difference between VIGOR’s interpolation and compositional scores indicates that its scene-program generation and refinement pipeline maintains strong performance on held- out combinations of engineering conditions, even when those specific parameter combinations are absent from training. Constraint density exposes a stronger distinction between program generation and complete scene feasibility. VIGOR achieves 91.3, 89.6, and 88.8 under loose-, medium-, and tight-space plan- ning, respectively, showing only limited degradation as geometric margins become more restrictive. DeepSeek-V4.1-Flash remains the strongest baseline across these settings, whereas several other models exhibit larger fluctuations. These results suggest that tightly coupled boundary, collision, clearance, and aisle constraints remain difficult for general-purpose models even when they can produce structurally valid scene programs. A similar pattern appears across aisle orientations. VIGOR reaches 90.3 on X-aisle planning and 90.7 on Z-aisle planning, indicating little sensitivity to orientation changes. Strong closed-source models also remain comparatively stable, but at lower absolute capability levels. In contrast, several weaker models show larger orientation-dependent variation, suggesting that their generated layouts are less robust to changes in the spatial organization of the workspace. 13 Preprint GLM-4-9B Qwen3-14B Gemma-3-12B DeepSeek-Coder V2-Lite Llama-3.1-8B Granite-3.3-8B Qwen3.5-9B Ministral-3-8BGPT-5.5 Claude Sonnet 5 DeepSeek-V4.1 Flash Grok-4.5 CODEI/O OpenCode Reasoning CodeRL+ ReSpace Ours Program Process ScoreFinal Scene ScoreUnified Capability Score 100.0100.0100.0 69.569.569.5 84.884.884.8 100.0100.0100.0 70.170.170.1 85.085.085.0 100.0100.0100.0 79.779.779.7 89.989.989.9 99.499.499.4 31.031.031.0 65.265.265.2 99.799.799.7 89.389.389.3 94.594.594.5 Figure 7: Process–result capability profiles across industrial scene-program generation methods. Program Process Score measures structured program construction, Final Scene Score measures executed-scene quality, and Unified Capability Score summarizes both perspectives. The three stress categories further evaluate challenging input conditions involving wide aisles, high equipment-clearance requirements, and large boundary margins. VIGOR scores 91.2, 90.2, and 89.6 across these settings, respectively, while DeepSeek-V4.1-Flash remains around 80. These categories place stronger pressure on coordinated multi-object placement because satisfying one constraint can reduce the feasible region available to neighboring devices. The consistently high VIGOR scores therefore indicate that local correction and joint conflict resolution remain effective even when the available placement space is constrained by multiple simultaneous engineering requirements. Overall, VIGOR exhibits the most stable profile across all ten capability categories, ranging only from 88.8 to 91.3. This contrasts with the substantially lower and more variable profiles of ex- isting general models and published code/layout methods. The fine-grained results reinforce the central observation of our main experiments: reliable industrial scene generation requires not only successful structured-program construction, but also robust final-state verification and coordinated resolution of coupled engineering constraints. CTASK CONSTRUCTION AND CONSTRUCTIBILITY SCREENING Our dataset is constructed from explicit industrial layout conditions. Each task uses a fixed 7.5× 7.0 m workspace and eleven required instances organized into nine top-level equipment groups and two attachments. Task variation is controlled by the condition tuple (w,c,b,o), where w is the minimum main-aisle width, c is the clearance between independent equipment groups, b is the work- area boundary clearance, and o∈X,Z specifies the aisle orientation. 14 Preprint Interpolation Generalization Compositional Generalization Loose-Space Planning Medium-Space Planning Tight-Space Planning X-Aisle Planning Z-Aisle Planning Wide-Aisle Planning High-Clearance Planning Large-Boundary-Margin Planning Ours DeepSeek-V4.1 Flash Claude Sonnet 5 GPT-5.5 Ministral-3-8B Grok-4.5 Qwen3-14B GLM-4-9B ReSpace Qwen3.5-9B Granite-3.3-8B Gemma-3-12B DeepSeek-Coder V2-Lite CodeRL+ OpenCodeReasoning Llama-3.1-8B CODEI/O 90.990.980.380.368.168.170.170.123.722.221.120.718.917.011.29.92.62.00.40.00.0 90.390.380.680.673.173.168.968.924.627.621.520.319.217.510.110.12.12.00.20.00.0 91.391.380.180.173.373.370.270.224.025.221.220.619.217.310.010.71.82.00.40.00.0 89.689.680.780.760.168.868.824.519.921.420.318.817.211.38.93.22.00.40.00.0 88.888.882.082.071.971.967.167.124.626.521.820.518.716.912.88.13.22.00.20.00.0 90.390.381.181.174.174.172.572.526.125.523.220.519.018.211.16.04.42.00.50.00.0 90.790.780.180.169.069.068.268.223.324.620.520.519.016.810.511.81.42.00.20.00.0 91.291.279.779.768.568.567.067.022.820.620.820.718.916.710.610.42.42.00.40.00.0 90.290.280.280.268.868.865.424.126.821.120.319.117.410.310.32.12.00.20.00.0 89.689.680.980.966.466.467.967.922.819.819.620.518.615.611.411.22.42.00.10.00.0 Figure 8: Fine-grained task capability analysis across ten industrial scene-generation conditions. Higher values indicate stronger unified structural, geometric, and functional capability. Candidate conditions. We enumerate the parameter grid in Table 4, yielding 17×9×9×2 = 2,754 candidate conditions. Distances are specified in metres, with a uniform increment of 0.05 m. The equipment inventory, asset geometry, workspace, and required attachment relations remain fixed across conditions. Table 4: Parameter grid used for task construction. ParameterValuesCount Main-aisle width w 1.00–1.80 m17 Equipment clearance c 0.20–0.60 m9 Boundary clearance b 0.30–0.70 m9 Aisle orientation oX , Z2 Constructibility screening. Screening is performed by a deterministic layout generator and val- idator, rather than a language-model classifier. For each condition, the generator attempts its two predefined construction variants in a fixed order. A condition is retained when a generated layout passes the corresponding validation checks. This procedure retains 1,749 conditions and records 1,005 unsuccessful conditions. An unsuccessful construction indicates that the prescribed proce- dure did not produce a valid layout; it does not establish that the condition is mathematically infea- sible.The complete condition grid, constructibility-screening protocol, and reference-construction details are provided in Appendix C. Reference construction. For each retained condition, the reference pipeline constructs a baseline layout, performs the prescribed layered candidate search, and selects the highest-ranked legal can- didate. The selected layout is converted into a complete scene program.v1 program without changing its transforms or attachment relations. Each condition contributes one reference program. Reference layouts, execution traces, and verification results are retained separately from the model- visible task input. Dataset partition. The final partition contains 1,399 training conditions, 175 interpolation-test conditions, and 175 compositional-test conditions. The compositional split holds out the joint re- gion w ∈ [1.20, 1.30] and c ∈ [0.35, 0.55] across both aisle orientations. These width–clearance combinations are absent from training, while their individual parameter values remain represented in training for the same orientation. The interpolation split is selected from the remaining pool using stratified systematic sampling with seed 42. Each interpolation condition has a same-orientation 15 Preprint training neighbour one 0.05 m grid step away. Split assignment does not use model predictions or evaluation scores. DSCENE-PROGRAM SPECIFICATION AND GENERATION INPUT The model receives an answer-free task description containing the public coordinate convention, task constraints, asset geometry, and program interface. Condition-dependent fields specify the clearance thresholds, workspace bounds, and reserved aisle. The asset catalog provides local collision AABBs and canonical scales, rather than target object positions. Reference programs, reference layouts, execution traces, and evaluation scores are excluded from the input. Deterministic task template. The following box presents the model-visible input in parameter- ized form. Braced fields are expanded deterministically from public task metadata. The asset- geometry field expands into eleven entries, each containing the asset name, local AABB minimum and maximum, and canonical scale. It contains no reference-layout coordinates. Deterministic industrial task template # Code task input (model-visible) Write one complete scene_program.v1 JSON program for the supplied public asset catalog. The program must create nine top-level equipment groups and the two required attachments, set each explicit world Transform, establish the requested parent links, save a new scene, and independently export object identity, world/local Transform, and parent relations. The required output is this program JSON itself; do not output a layout JSON or a prose-only plan in its place. Do not load a scene by task number or use a standard-answer shortcut. ## Public world contract - Units: metres. - Coordinate system: Unity left-handed, +Y up, X-Z ground plane, +Z forward. - Position is world position in metres; rotation is Unity Euler degrees (x, y, z); scale is component-wise. - Asset root/pivot is the imported prefab root. The public normalized assets use the documented collision-footprint/lowest-Y convention; imported PolyHaven prefabs retain their project prefab root and must be verified in Unity. - Use explicit world transforms and do not silently convert, snap, repair, or infer coordinates. ## Public task constraints - Main aisle minimum width: w m; aisle orientation: o. - Independent equipment horizontal clearance: c m. - Work-area boundary clearance: b m. - Required parent links: kit_tray -> AGV at tray_mount; assembly_insert -> assembly_table at table_top; all other listed devices are top-level with 16 Preprint ground_anchor. - The following selected work area and reserved aisle are public scene constraints; they do not specify an answer layout. - Selected work area Unity X-Z: min=workspace_min max=workspace_max. - Reserved main aisle Unity X-Z: min=aisle_min max=aisle_max. ## Public asset geometry ## (collision local AABB, metres) public_asset_geometry_entries Return one JSON object with schema_version=scene_program.v1 and a complete ordered operations array. Do not include a save path, run id, source path, seed id, or expected-state field. ## JSON program interface (model-visible) - Allowed operations are exactly create_object, set_transform, set_parent, and save_scene. - create_object: "op":"create_object", "instance_id":"...", "asset_id":"..." It starts an unparented identity object. - set_transform: "op":"set_transform", "instance_id":"...", "position":[x,y,z], "rotation_deg":[x,y,z], "scale":[sx,sy,sz] Position is world metres and all values must be finite; scale is positive. - set_parent: "op":"set_parent", "child_id":"...", "parent_id":"...", "keep_world_transform":true It keeps the child’s world Transform and uses full parent rotation/scale conversion. - All creates come first, then all transforms, then parent links, then exactly one final save_scene operation. No operation may follow save. - The executor supplies the output path. Do not add fields, paths, answer references, implicit defaults, coordinate repairs, or a solver. Generic format example (illustrative identifiers and values only; not a task answer): 17 Preprint "schema_version": "scene_program.v1", "operations": [ "op": "create_object", "instance_id": "device_A", "asset_id": "public_asset_A" , "op": "set_transform", "instance_id": "device_A", "position": [1.0, 0.0, 2.0], "rotation_deg": [0.0, 90.0, 0.0], "scale": [1.0, 1.0, 1.0] , "op": "save_scene" ] Program structure. A complete reference program contains 25 operations:eleven createobject operations, eleven settransform operations, two setparent operations, and one final savescene operation. The required instances comprise a kit-tray station, an AGV, a kit tray, an assembly table, an assembly insert, a ceiling-robot proxy, a tool cart, a metal office desk, a storage rack, a container, and a warning sign. The kit tray is attached to the AGV, and the assembly insert is attached to the assembly table. Execution semantics. Execution begins from an empty device state. Each instance must be cre- ated once and receive an explicit world transform before parenting. Parenting preserves the child’s world transform and derives its local transform using the parent’s full translation, rotation, and scale. Unknown operations or assets, duplicate identifiers, invalid numbers, non-positive scales, cyclic par- ent relations, and operation-order violations are rejected. The output path is supplied by the runner rather than generated by the model. EEXECUTION-BASED DATASET QUALITY ASSURANCE Reference programs are validated through execution and independent state checks. A valid JSON representation alone is insufficient: the program must produce the required scene structure and sat- isfy the public geometric constraints after execution. Dataset acceptance uses deterministic checks rather than language-model ratings. Schema and execution checks. Each program is checked against the scene program.v1 schema and executed by the Python state engine in operation order. The execution trace records the resulting state as operations are applied. A successful run must reach the final savescene op- eration and produce a new state file. Diagnostic partial states from failed execution are not accepted as completed scenes. Identity, transforms, and attachments. The saved state must contain all eleven required in- stances with unique identities and the correct asset assignments. World and local transforms, parent links, and placement anchors are checked against the reference construction and public task con- tract. The two required attachments must be preserved, while the remaining equipment forms nine top-level groups. Reference information is used for post-execution verification; it is not supplied to the executor to complete or repair the program. Independent geometry verification. World collision AABBs are computed by transforming the eight corners of each public local AABB using the executed transform. The resulting geometry is independently recomputed and checked for consistency. The unified geometric evaluation ap- plies 94 checks per scene, covering boundary clearance, main-aisle preservation, pairwise collision avoidance, and independent-equipment clearance. Structural and attachment checks are evaluated in addition to these geometric checks. 18 Preprint Save–reload consistency. The runner independently reloads the newly saved state and checks that its serialized object state is preserved. This verifies persistence of the Python scene representation, including identities, transforms, and parent relations. It does not constitute verification of Unity prefab identity, Unity collider geometry, or Unity scene save–reload behaviour. Input isolation. The model-visible input is checked against the fixed task template. Only five public-constraint lines vary across conditions: the main-aisle requirement, equipment clearance, boundary clearance, workspace bounds, and reserved-aisle bounds. Additional checks inspect source identifiers, file paths, expected-state references, and reference-position triples. Test inputs and reference artifacts are stored separately; test-request construction reads the answer-free inputs. Validation outcome. All 1,749 retained conditions pass program conversion, schema validation, state-engine execution, save–reload verification, identity and attachment checks, independent ge- ometry verification, and the unified hard-constraint evaluation. The resulting reference set therefore contains 1,749× 94 = 164,406 passing geometric checks. These results establish consistency under the public asset geometry and Python execution semantics; they do not imply that every reference scene has been executed in Unity. FMACHINE EVALUATION PROMPTS We use gpt-5.6-terra to evaluate each valid anonymous scene card. Operational Usability (OU) and Spatial Organization (SO) are evaluated in separate calls. The judge returns an integer score from 0 to 5 and a concise evidence-based reason for one dimension. Machine judge prompt for Operational Usability You are an expert industrial-engineering assessor. You are judging ONE dimension of ONE candidate workcell layout: ** OPERATIONAL USABILITY (OU) ** . You are shown a single anonymous evaluation card. It contains: * a plan view (X-Z) of the final scene produced by executing one candidate program, with the figure legend that explains every colour and marker; * the public task condition of the question; * the work area and the reserved main aisle, which are public scene constraints and not an answer; * the eleven devices and the function each one plays; * the executed world transform of every device in the scene. ## What you judge Judge only how usable the resulting workcell would be in real industrial operation: * whether the devices are convenient to operate and to maintain; * whether material handling and the human/robot workflow are sensible; * whether devices that have to work together are placed so that they can work together; * whether the arrangement contains something that would visibly get in the way of real use. ## What you must not do * ** Do not re-derive centimetre-level geometry. ** Do not measure exact distances, do not recompute boundary margins, net clearances or collisions, and do not check whether the reserved aisle band is exactly wide enough. A separate automatic geometric scorer already owns those exact checks, and they cannot be reproduced reliably from a figure. 19 Preprint * ** Do not compare the layout against a reference arrangement. ** The task admits many legal solutions. Never penalise a layout for not resembling some imagined answer. * ** Do not try to guess which method produced this layout ** , and do not let any such guess affect the score. ## Scale (integer 0-5) 5 professional and sensible; almost nothing would need changing 4 good overall; only minor shortcomings 3 basically usable, but with clearly unreasonable aspects 2 several important problems; hard to use in practice 1 most of the arrangement is not sensible 0 no valid scene, or completely unusable ## Output Reply with exactly one JSON object and nothing else: "anonymous_id": "<the anonymous_sample_id printed on the card>", " dimension": "OU", "score": 4, "reason": "Concise evidence-based explanation." score must be an integer between 0 and 5. reason must be one or two sentences naming the evidence you actually saw on the card. Do not output a total score, and do not output any field other than these four. Machine judge prompt for Spatial Organization You are an expert industrial-engineering assessor. You are judging ONE dimension of ONE candidate workcell layout: ** SPATIAL ORGANIZATION (SO) ** . You are shown a single anonymous evaluation card. It contains: * a plan view (X-Z) of the final scene produced by executing one candidate program, with the figure legend that explains every colour and marker; * the public task condition of the question; * the work area and the reserved main aisle, which are public scene constraints and not an answer; * the eleven devices and the function each one plays; * the executed world transform of every device in the scene. ## What you judge Judge only how well the layout is organised in space: * whether the functional zones are clear; * whether related devices are sensibly grouped together; * whether the devices are oriented in a coordinated way rather than at odds with each other; * whether the space is used compactly without becoming excessively crowded; * whether the overall arrangement reads as clear and orderly. ## What you must not do * ** Do not re-derive centimetre-level geometry. ** Do not measure exact distances, do not recompute boundary margins, net clearances or collisions, and do not check whether the reserved aisle band is exactly wide enough. A separate automatic geometric scorer already 20 Preprint owns those exact checks, and they cannot be reproduced reliably from a figure. * ** Do not compare the layout against a reference arrangement. ** The task admits many legal solutions. Never penalise a layout for not resembling some imagined answer. * ** Do not try to guess which method produced this layout ** , and do not let any such guess affect the score. ## Scale (integer 0-5) 5 professional and sensible; almost nothing would need changing 4 good overall; only minor shortcomings 3 basically usable, but with clearly unreasonable aspects 2 several important problems; hard to use in practice 1 most of the arrangement is not sensible 0 no valid scene, or completely unusable ## Output Reply with exactly one JSON object and nothing else: "anonymous_id": "<the anonymous_sample_id printed on the card>", " dimension": "SO", "score": 4, "reason": "Concise evidence-based explanation." score must be an integer between 0 and 5. reason must be one or two sentences naming the evidence you actually saw on the card. Do not output a total score, and do not output any field other than these four. “‘latex GEVALUATION METRICS We evaluate each method from three complementary perspectives: rule-based engineering metrics computed from executed scene states, visual judgments of scene quality, and an aggregate engineer- ing score. Unless otherwise specified, metrics are computed using the method’s actual evaluation set. Invalid or unscorable outputs remain in the denominator and receive the prescribed zero score. G.1STRUCTURAL AND GEOMETRIC METRICS Parent–Attach. Each task requires the specified parent relations and attachment relations to be satisfied. Let r parent i and r attach i denote the corresponding ratios for task i. We count a task as structurally correct only when both relations are fully satisfied: z PA i = I r parent i = 1∧ r attach i = 1 ,Parent-Attach = 1 N N X i=1 z PA i .(9) The reported value lies in [0, 1]. A task without a valid scene state receives zero. Geometric Violation Burden. The geometric verifier evaluates 94 constraint atoms per task: 11 boundary-clearance atoms, 36 pairwise collision atoms, 36 pairwise equipment-clearance atoms, and 11 main-aisle atoms. Let u i,k denote the number of unsatisfied atoms in constraint family k for task i. The per-task and method-level violation burden are v i = u i,boundary + u i,collision + u i,clearance + u i,aisle , GVB = 1 N N X i=1 v i . (10) GVB ranges from 0 to 94, with lower values indicating fewer unsatisfied geometric constraints. A task without a valid scene state is assigned v i = 94. 21 Preprint Bottleneck Geometry. GVB counts violated atoms jointly, whereas Bottleneck Geometry mea- sures the weakest of the four geometric constraint families in each task. For family k, let n k be its number of atoms and define its satisfaction rate as ρ i,k = 1− u i,k n k ,(n boundary ,n collision ,n clearance ,n aisle ) = (11, 36, 36, 11).(11) We then compute BottleneckGeometry = 1 N N X i=1 100 min k∈K ρ i,k , K =boundary, collision, clearance, aisle. (12) The minimum is taken per task before averaging across tasks. Therefore, Bottleneck Geometry is not obtained by linearly converting the mean GVB. Complete Feasibility. Let f i be the task-level complete-feasibility indicator recorded by the au- thoritative evaluator. It is one only when the required execution and final-state hard constraints pass, and zero otherwise. The method-level score is CompleteFeasibility = 100 N N X i=1 f i .(13) This metric is reported on a 0–100 scale. G.2FUNCTIONAL QUALITY AND TEST-SUBSET METRICS Functional Layout. The authoritative evaluator assigns six functional-quality scores to each task: process-chain organization, tool/kitting organization, rack placement, container placement, desk placement, and hazard-sign placement. Let q i,j ∈ [0, 100] denote the score for task i and func- tional dimension j. The task-level and method-level scores are FL i = 1 6 6 X j=1 q i,j ,FunctionalLayout = 1 N N X i=1 FL i .(14) All six dimensions are equally weighted. Invalid or unscorable tasks receive zero and remain in the denominator. Functional-quality subsets. We report four additional summaries of Functional Layout. BQ-FQ measures performance on the lower tail: after sorting the N task-level scores in ascending order, it averages the lowest⌈0.25N⌉ scores. Interp-FQ and Comp-FQ are the full-denominator means over the frozen interpolation and compositional test subsets, respectively. Tight-FQ is the mean over the frozen tight-condition subset. For methods evaluated on a reduced test set, the corresponding frozen subset assignment and denominator are used; subsets are not selected using model scores. G.3OVERALL SCORE Overall summarizes structural correctness, geometric quality, functional quality, and complete fea- sibility. All four components are placed on a 0–100 scale before averaging. We define S = 100× Parent-Attach, GS = 100 1− GVB 94 , G = GS + BottleneckGeometry 2 , Q = FunctionalLayout + BQ-FQ + Interp-FQ + Comp-FQ + Tight-FQ 5 , F = CompleteFeasibility, Overall = S + G + Q + F 4 . (15) 22 Preprint Here, GS is the overall geometric-atom satisfaction rate, while G combines this rate with the per- task bottleneck measure. Overall gives equal weight to structural correctness, geometric quality, functional quality, and complete feasibility. Visual judgments are reported separately and are not included in Overall. G.4VISUAL JUDGMENT SCORES We use 20 fixed dual-view evaluation cards per method. Each card shows the executed scene and its overview under the same legend. The visual judges score Operational Usability (OU) and Spatial Organization (SO) independently on an integer scale from 0 to 5. LLMJudge. A single machine judge evaluates each card in separate OU and SO calls. For method m, let J OU m,i and J SO m,i denote the two scores for card i. We compute J OU m = 1 N visual N visual X i=1 J OU m,i , J SO m = 1 N visual N visual X i=1 J SO m,i , LLMJudge m = J OU m + J SO m 2 . (16) LLMJudge is reported on the original 0–5 scale. Human Rating. Human Rating aggregates the scores from three independent human raters. Each rater independently evaluates the same fixed set of visual evaluation cards using the same OU and SO criteria. Let R be the set of the three human raters and H d r,m,i the score assigned by human rater r to method m, card i, and dimension d ∈ OU, SO. We first average over cards and raters for each dimension, then average the two dimensions: H d m = 1 |R|N visual X r∈R N visual X i=1 H d r,m,i , HumanRating m = H OU m + H SO m 2 . (17) Human Rating is also reported on the 0–5 scale. LLMJudge and Human Rating are presented as separate visual-evaluation measures and are not combined with one another or with Overall. “‘ 23

Instant research discovery