PaperlayerView exact revision on arXiv

Source-linked AI summary

Co-DSL: Human-LLM Co-design of Reusable Spatial Concepts for Layout Generation

R. Kenny Jones, Jiajun Wu, Maneesh Agrawala

arXiv:2610.15290v1cs.GRcs.AIcs.CV

TL;DR

Fixed-operation layout systems can make it difficult for LLMs to express users’ recurring spatial patterns reliably. Co-DSL lets users and LLMs co-design reusable concepts, then uses concept-graphs and a solver for layout generation. Across five domains, its concepts improve layout outcomes over fixed-operation systems, and support generative programs with high-level controls.

  • Problem

    Fixed operation sets may not fit users’ spatial patterns, and composing low-level relationships can cause LLMs to miss intended patterns.

    Source: §1 · pp. 1–2

  • Method

    Users and LLMs iteratively co-design reusable spatial concepts, which an LLM composes into concept-graphs that a solver searches for satisfying layouts.

    Source: §1 · p. 2

  • Results

    Across five domains, Co-DSL layouts better satisfy requested spatial relationships, maintain physical validity, and are more often preferred than layouts from fixed-operation systems.

    Source: §1 · p. 2, §8 · p. 16

  • Takeaways & Limitations

    Co-DSL supports generative layout programs with high-level controls and lets users extend concept libraries when prompts reveal missing patterns.

    Source: §1 · p. 2, §8 · p. 16

    The current repair loop interleaves multiple LLM calls with solver search and may be made more efficient.

    Source: §8 · p. 16

Abstract

from arXiv · show

We present Co-DSL, a framework in which users and LLMs co-design reusable spatial concepts for layout generation. In the first stage, our system allows users to create a library of personalized operations. To add a concept, a user provides a description, which the LLM converts into an initial implementation. The user can then observe the concept's execution behavior over example scenarios and provide lightweight feedback to the LLM, which revises the concept's implementation logic. In the second stage, given a library, an LLM can author a layout program that meets a new layout request from a user. Executing a layout program instantiates a concept-graph, a declarative composition of library concepts. In this way, we require the LLM only to specify which concepts should hold, while we use a solver to search for a layout that satisfies them. Across five spatial layout domains, we find that Co-DSL libraries let LLMs capture layout patterns that are challenging for prior fixed-operation systems, and demonstrate that our concept-graph representation is needed for LLMs to reliably compose concepts together. We further find that Co-DSL lets LLMs author generative layout programs that expose high-level parametric controls users can manipulate to explore a distribution of related layouts without re-prompting.

1 INTRODUCTION

Co-DSL addresses the mismatch between fixed operation sets and users’ reusable spatial patterns by letting users and LLMs co-design concept libraries. Across five domains, it combines that library with concept-graphs and solving to generate layouts that better satisfy requests.

1 INTRODUCTION

  • Fixed, general-purpose operation sets may not fit new users’ layouts, while coordinating low-level relations makes reusable patterns difficult for LLMs to express reliably.LLMs can satisfy fragments of a prompt while missing its intended pattern.Source: §1 · pp. 1–2
  • Co-DSL lets users and LLMs co-design reusable spatial concepts, which the LLM composes into layout programs for new requests.These programs expose interpretable parameters for exploring layout variations.Source: §1 · p. 2
  • Users describe a concept, inspect its behavior on application scenarios, and give lightweight feedback for the LLM to revise its implementation without manual DSL coding.The user reasons about intended behavior while the LLM handles implementation.Source: §1 · p. 2
  • A layout program instantiates a declarative concept-graph, and a solver searches for a layout satisfying the graph’s concepts.The solver and program-repair loop enable the LLM to compose concepts without directing the search itself.Source: §1 · p. 2
  • Across five spatial domains, Co-DSL concepts produce layouts that better satisfy requested spatial relationships, maintain physical validity, and are more often preferred than layouts from fixed-operation systems.Ablations show that concepts alone are insufficient: concept-graphs, solving, and concept-level program repair improve reliable composition.Source: §1 · p. 2

2 RELATED WORK

Co-DSL draws on symbolic layout representations, LLM-based generation, reusable abstractions, and interactive design. Its distinction is user-guided co-design of reusable spatial concepts rather than reliance on fixed operations or removing users after setup.

2 RELATED WORK

  • Procedural and constraint-based layout systems encode design knowledge in rules, costs, constraints, hierarchies, symmetry groups, or relationship graphs.Co-DSL follows this lineage with a concept-graph while allowing users and LLMs to co-design operations.Source: §2 · p. 2
  • Data-driven generators learn common spatial patterns from datasets, whereas Co-DSL uses no task-specific training data and lets users encode patterns as reusable code.The paper describes expert-knowledge regularizers as complementary to user co-designed concepts.Source: §2 · p. 3
  • LLM layout systems use direct entity generation, procedural code, or solvers with expert-designed constraints, but their available operations are fixed in advance.The paper contrasts those fixed operation sets with Co-DSL’s reusable encoding of user-valued patterns.Source: §2 · p. 3
  • Library-learning and tool-creation methods develop reusable abstractions, but the cited related systems remove users from the loop after initial setup.Co-DSL instead supports iterative user-guided co-design toward agreed-upon concept behavior.Source: §2 · p. 3
  • Interactive design systems support revising designs, exploring parameterized alternatives, or specifying procedures, while Co-DSL places interaction at the level of reusable spatial concepts.The user judges concept behavior and the LLM implements it as executable code.Source: §2 · p. 3

3 CO-DSL OVERVIEW

Co-DSL separates concept co-design from layout generation: users and LLMs develop executable concepts, then an LLM composes them into a graph that a solver searches. The framework targets bounded spatial domains with shared base domain knowledge.

3 CO-DSL OVERVIEW

  • Users describe recurring spatial concepts in natural language, inspect their behavior in application scenarios, and provide feedback for the LLM to revise implementations.The example concepts include mounting an object on a wall, arranging sofas around a TV, and aligning objects.Source: §3 · p. 4
  • For a new layout request, the LLM writes a program that instantiates a concept-graph, and a solver searches for a layout satisfying its concepts.The LLM chooses which concepts should hold; the solver searches for a layout that meets them.Source: §3 · p. 4
  • Co-DSL targets bounded coordinate spaces with entities, attributes, and geometric or semantic relationships, using shared domain knowledge such as bounds, entity models, initialization, and validity checks.Examples of validity checks include remaining in bounds, not floating, and avoiding collisions.Source: §3 · p. 4

4 STAGE 1: HUMAN-LLM CONCEPT CO-DESIGN

Stage 1 turns user-specified spatial patterns into executable concepts through iterative LLM implementation and user feedback. Users inspect scenarios and outputs, refine synthesis and verification behavior, and confirm concepts for the library.

4 STAGE 1: HUMAN-LLM CONCEPT CO-DESIGN

  • Co-DSL represents relationships as parameterized Relation classes and logical collections as Group classes, with synthesis and verification execution modes.Synthesis transforms a layout; verification returns whether the concept is satisfied, and repeated synthesis can produce alternatives that pass verification.Source: §4 · p. 4
  • A concept specification gives its name, Group or Relation type, intended behavior, and parameters; the LLM proposes an interface and then initial synthesis and verification implementations.The user may accept the interface or provide feedback to revise it.Source: §4 · pp. 4–5
  • Application scenarios apply a concept to a few entities under varying initial conditions so users can inspect synthesis transformations and verification judgments.The interface exposes class, scenario, synthesis, and verification views, with feedback available from any view.Source: §4 · p. 5, Figure 4 · p. 5
  • Users can guide revisions with text feedback or existing concepts, and can correct verifier judgments using labeled layouts and an auto-fix action.The LLM revises the verifier using the current function and layouts on which the user disagreed.Source: §4 · p. 5

4.1 Walkthrough of Concept Development

  • In the Surround walkthrough, the user specifies a central entity among outer entities, with distance and spacing_mode parameters, then tests scenarios with chairs or tables.When chairs face incorrectly, the user describes the intended orientation and the LLM updates synthesis behavior.Source: §4.1 · pp. 5–6
  • The walkthrough shows users correcting false-positive verification when a fountain falls outside the surrounding tables’ convex hull, adjusting unequal-spacing behavior, and confirming a concept after reviewing diagnostics.Confirmation diagnostics include scenario coverage, verifier agreement on user-labeled examples, and how often synthesized outputs pass verification.Source: §4.1 · p. 6

5 STAGE 2: LAYOUT GENERATION WITH CONCEPT-GRAPHS

Co-DSL separates layout-program authoring from layout search: an LLM declares which library concepts should hold, and a solver searches for a satisfying layout. Nested search, synthesis and verification, and LLM-driven repair address alternative graph instantiations and unsatisfied concepts.

5 STAGE 2: LAYOUT GENERATION WITH CONCEPT-GRAPHS

  • The LLM authors programs that instantiate concept-graphs, while a solver searches for layouts satisfying the graph’s concepts.Programs can make randomized or parameterized choices, giving the solver alternative graphs to explore when one has no satisfying layout.Source: §5 · p. 6

5.1 Authoring Layout Programs

  • The LLM receives concept interfaces and documentation, but not synthesis or verification logic, so it composes concepts through their documented behavior.The prompt can also include base-domain knowledge and user-approved layout-program examples.Source: §5.1 · p. 6

5.2 Concept-Graphs

  • A concept-graph represents entities and spatial constraints, with Group concepts and child graphs as nodes and Relation concepts as edges.It specifies which concepts should hold without requiring the program to schedule synthesis and verification calls.Source: §5.2 · p. 6

5.3 Solving Concept-Graphs

  • The solver measures graph error across base-validity failures, unsatisfied verifications, and child-graph errors, returning a zero-error scene or the lowest-error scene within its time budget.It searches over program executions and retains the best scene found across attempts; child graphs are solved before their layouts are combined in the parent.Source: §5.3 · pp. 6–7

5.3.1 Interleaving Synthesis and Verification

  • SolveLocal uses dependency-aware traversal and applies synthesis only when a concept fails verification, avoiding unnecessary transformations.A verification-driven repair loop revisits failing concepts and retains an update only when it improves the best local layout; the authors report that removing the loop or verification substantially reduces solved graphs.Source: §5.3.1 · p. 7

5.4 LLM-Driven Program Repair

  • When solving fails, an outer correction loop gives the LLM the program, original prompt, and unsatisfied concepts or validity errors, then reruns the solver on its revision.Concept-level errors keep correction aligned with the concepts users care about rather than low-level entity manipulation or constraint repair.Source: §5.4 · p. 7

6 RESULTS

Across the evaluated domains, Co-DSL libraries supported reusable spatial patterns, and Co-DSL generated layouts with high physical validity and prompt adherence. Ablations and a non-expert study further examined concept composition and co-design.

6.1 Evaluation Domains and Concept Libraries

  • An expert co-designed over 90 concepts across five domains; each concept took under 10 minutes and less than $1 in LLM API calls on average.Free-form guidance averaged three times per concept; each auto-fix call improved verifier accuracy by an average of 35 percentage points and achieved perfect agreement in half of cases.Source: §6.1 · pp. 7–8

6.2 Encoding Spatial Patterns as Reusable Concepts

  • Co-DSL preserved user-defined pattern semantics in every evaluated generation, whereas PSDL, Holodeck, and the initial-implementation ablation preserved them in at most one third.Fixed-operation methods sometimes met parts of a request but diverged from intent; Co-DSL reused co-designed concepts in new contexts.Source: §6.2 · pp. 8, 10

6.3 Generating Layout Programs from Text

  • Co-DSL achieved 95% to 100% physical validity and 90% average prompt adherence; Holodeck satisfied 19% of requested constraints, while PSDL achieved 83% adherence but 63% validity.These results compare methods on standard prompts in the bedroom, dining, and living-room domains.Source: §6.3 · p. 10
  • Human raters chose Co-DSL layouts over PSDL generations 76% of the time, excluding ties, across 180 responses from nine participants.The study asked raters which of two layouts better respected the prompt or whether they were tied.Source: §6.3 · pp. 10, 12

6.3.1 Analysis of Prompt and Program Complexity

  • On 30 challenge prompts averaging 220 words and 18 constraints, Co-DSL maintained 97% physical validity and 78% prompt adherence, while PSDL validity fell to 37%.Co-DSL adherence was down from 90% on the standard set; its validity gap over PSDL grew from approximately 37 to 60 percentage points.Source: §6.3.1 · p. 12

6.4 Ablation on Concept Composition

  • Removing concept-graphs reduced average valid generation to 30%; removing hierarchy lowered solve rate from 81% to 73%, while removing LLM correction reduced it from 81% to 35%.Without LLM correction, base validity errors increased from 0.065 to 0.975 violations per layout.Source: §6.4 · p. 12
  • The full solver achieved an 81% solve rate, compared with 48% without solver repair and 13% without verification.Both synthesis and verification are needed to reliably search for satisfying layouts.Source: §6.4 · p. 12

6.5 Non-Expert Concept Co-design

  • Participants created 20 concepts across three domains in around 15 minutes on average; all agreed the concepts matched intended behavior, and examples show synthesis and verification refined without hand-authored code.On held-out test scenarios, after iteration recall was 74% and specificity was 89%; initially, verifiers agreed with the expert on 59% of expert-valid layouts and 92% of expert-invalid ones.Source: §6.5 · pp. 12–13

7 EXTENSIONS

Co-DSL extends fixed-operation layout generation with reusable concepts that support controllable programs and on-demand library growth. These extensions let users explore related layouts and address spatial patterns missing from an existing library.

7.1 Generative Layout Programs

  • Parameterized programs map user-facing controls to concept parameters, concept choices, or graph structure, and can be run with new settings without re-prompting.During authoring, example parameterizations are tested and solver failures are fed back for program repair.Source: §7.1 · p. 14
  • Co-DSL programs expose high-level controls that produce related layout variations, unlike prior systems that generate individual static scenes.Examples include changing a chair’s height and accommodating different dorm-room occupant counts and preferences.Source: §7.1 · pp. 14–15
  • 93% of program executions were physically valid, and 83% of programs produced valid layouts across all evaluated parameterizations; adapted PSDL reached 48% and 22%, respectively.Both systems had 84% prompt adherence.Source: §7.1 · p. 15

7.2 Extending Concept Libraries on Demand

  • Users can co-design and add a concept when an existing library misses a requested pattern, improving layouts for the same prompts while preserving compatibility with existing concepts.Examples include a corner reading nook, twin beds with grouped nightstands, and horseshoe table seating.Source: §7.2 · p. 15

8 CONCLUSION

Co-DSL combines co-designed concepts with concept-graphs and a solver to support spatial layouts across five domains. The paper also identifies interface, abstraction, and repair-loop limitations, while its appendix describes domain representations and rendering.

8 CONCLUSION

  • Across five spatial layout domains, Co-DSL concepts and user guidance support reliable capture of domain-relevant patterns; layouts better respect requested relationships and are more often physically valid than those from fixed, general-purpose operation sets.Ablations indicate that concepts alone are insufficient: concept-graphs, the solver, and program repair are each needed for reliable composition.Source: §8 · pp. 15–16
  • Concepts are independent, so one concept cannot directly reuse another’s execution behavior; implemented concepts can instead be included as in-context examples during co-design.The authors identify more explicit use of concept hierarchies as a beneficial direction.Source: §8 · p. 16
  • The current repair loop interleaves multiple LLM calls with solver search, and the authors note it could be more efficient.LLM-authored programs may yield unsatisfiable concept-graphs or solutions that fail to meet the prompt requirements.Source: §8 · p. 16
  • Users currently drive all library-design ideation: they must identify useful concepts and recognize when a new one is needed.The authors suggest automatic concept suggestions as a possible aid.Source: §8 · p. 16

A.1 Family: 3D Rooms

  • In 3D rooms, objects are upright oriented bounding boxes with placement types; validity checks enforce room bounds, nonpenetration, and support paths.Regular and floor-anchored objects begin at random floor positions, while wall- and ceiling-anchored objects begin on those surfaces.Source: §A.1 · p. 18

A.2 Family: 2D layered arrangements

  • The 2D layered-arrangement family uses oriented boxes with an integer layer whose meaning varies by domain, including physical stacking for dining and front-to-back placement for bookshelves.Both domains check scene bounds and non-overlap within a layer; bookshelves also check support and structural anchoring.Source: §A.2 · pp. 18–19

A.3 Family: 3D shape assemblies

  • In 3D shape assemblies, parts are oriented primitives with proxy-shape tags and semantic roles, and validity requires each part to remain inside the envelope and connect to the floor.Parts begin at random horizontal positions with their bottoms on the floor.Source: §A.3 · p. 19

A.4 Final 3D Rendering Pipeline

  • The final rendering pipeline converts structured layouts into Blender scenes, using category-matched assets for non-chair domains and proxy primitives for chair parts.2D layered layouts are lifted into 3D using their layering parameter before assets are retrieved.Source: §A.4 · pp. 19–20

B ADDITIONAL METHOD DETAILS

The solver searches over instantiated concept-graphs, using graph structure and verification to evaluate candidate layouts. The representation supports groups and dual synthesis-verification modes, allowing a comparatively lightweight solver.

B.1 Solver Details

  • The outer solve loop has a 15-second budget and can stop early at zero error; repeated executions may produce structurally different concept-graphs for the solver to search.Solved child graphs are inserted into parents as single nodes, whose internal arrangements parent concepts cannot change.Source: §B.1 · p. 20
  • Concept synthesis and verification inspect only referenced entities, so scene-wide checks are needed to catch collisions or violations involving other objects or concepts.The solver combines concept verification with base validity checks over the whole scene.Source: §B.1 · p. 20
  • Graph error weights base-validity failures at 2.0, failed concept verifications at 1.0, and unscheduled synthesis calls at 0.5; a repair loop keeps synthesis updates only when they reduce error.Base-validity failures receive the highest weight because they indicate physical errors that obstruct further constraint satisfaction.Source: §B.1 · p. 20
  • A cache lets later attempts reuse solved sub-scenes when solving a larger graph.Source: §B.1 · p. 20

B.2 Concept-Graphs in Relation to Prior Work

  • Group concepts support hierarchical composition by collecting entities as one unit and can add entities, allowing graphs to construct scenes from prototypes.The representation differs from prior graph-based approaches because the operation set is co-designed rather than fixed in advance.Source: §B.2 · p. 20
  • Each concept-graph defines both a proposal mechanism through synthesis and a validity check through verification, supporting a lightweight solver rather than specialized inference procedures.The passage contrasts Co-DSL with Yeh et al..Source: §B.2 · p. 20

B.3 Ablation Conditions

Co-DSL is evaluated on validity, prompt adherence, challenge prompts, human preferences, and concept semantics, alongside ablations that remove user guidance, concepts, graph structure, or solver components. Across the standard prompts, Co-DSL satisfies more requested constraints than PSDL and Holodeck; on harder prompts, PSDL has higher adherence but lower physical validity.

B.3 Ablation Conditions

  • The ablations separately remove user refinement, concept libraries, or concept-graph search by using initial implementations, direct concept calls, or direct coordinate authoring.The user-guidance condition keeps concept interfaces fixed, while the no-graph condition also removes solver search.Source: §B.3 · pp. 20–21

C.1 Per-Domain Base Validity

  • Table 2 reports average base-validity violations and the share of valid layouts over completed generations; some no-graph and no-concepts prompts do not complete.No-graph misses four generations and no-concepts misses one.Source: Table 2 · p. 21, §C.1 · p. 21

B.3 Ablation Conditions

  • Other ablations restrict programs to a single root graph or remove LLM program correction, verification-driven solver repair, or concept-specific verification.The no-verification condition retains base-validity checks but excludes concept-specific verification.Source: §B.3 · p. 21

C.2 Per-Domain Prompt Adherence

  • Prompt-adherence judgments include every completed generation, even physically invalid layouts; the no-concepts condition has the highest adherence but low validity in living rooms, bedrooms, and dining arrangements.Its base-validity pass rates are 26.3%, 15.0%, and 35.0%, respectively.Source: §C.2 · p. 21
  • 90.5% of requested constraints are satisfied by Co-DSL, versus 83.5% for PSDL and 19.4% for Holodeck.The pooled prompt-adherence comparison covers the standard evaluation prompts.Source: Table 3 · p. 21, §C.2 · p. 21

C.4 Human Perceptual Study

  • Raters preferred Co-DSL in 61.7% of responses and PSDL in 19.4%; excluding ties, Co-DSL was preferred 76.0% of the time.The study collected 180 responses, with three raters per domain.Source: Table 4 · p. 21, §C.4 · p. 22

C.3 Challenge Prompt Set Results

  • On the 30-prompt set, Co-DSL produces valid layouts for 29/30 (96.7%) versus PSDL’s 11/30 (36.7%), while PSDL satisfies 83.9% of requested constraints versus Co-DSL’s 77.5%, trading higher adherence for lower physical validity.Source: §C.3 · p. 21

C.5 Concept-Adherence Expert Analysis

  • The expert concept-adherence analysis uses binary judgments and short justifications for 18 layouts per method across three concepts in each of three domains.Each concept is tested with two layout prompts.Source: §C.5 · p. 22

C.6 Generative Layout Program Results

Co-DSL’s generative programs retain high execution validity and constraint adherence, and more programs remain valid across their evaluated parameter ranges than with PSDL. Qualitative comparisons highlight hierarchical concept composition and bounded solver execution, while failure cases include unsatisfiable graphs and satisfying graphs that miss implicit expectations.

C.8 Failure Modes

  • Two failure modes are unsatisfiable concept-graphs and solved graphs that yield bad layouts because implicit expectations are not captured by constraints.Examples include conflicting placement requirements, a bookshelf blocking the only door, and sparse room coverage.Source: Figure 14 · p. 23, §C.8 · p. 24

C.6 Generative Layout Program Results

  • 93.4% of Co-DSL executions are valid and 83.5% of requested constraints are satisfied; 83% of programs remain valid across their evaluated parameter ranges.PSDL matches 83.5% adherence, but has 47.6% valid executions and only 22% of programs valid across their ranges.Source: Table 6 · p. 23, §C.6 · p. 23

C.7 Additional Qualitative Comparisons

  • FlairGPT and LayoutVLM struggle with compositional scenes, while Co-DSL composes reusable sub-scenes in hierarchical concept-graphs; FlairGPT timed out in 15 of 72 trials after constraint-solving runs of up to one hour.Co-DSL uses an initial LLM call, up to two correction calls, and bounded solver execution, compared with roughly 20 prompting calls for FlairGPT.Source: §C.7 · pp. 23–24

D.1 Layout Program Generation Procedure

  • Layout-program experiments use gpt-5.5, with calls averaging 17 seconds and a mean cost of $0.25 per program; correction averages 1.2 rounds, capped at two.Prompts include in-context programs previously marked good by the user.Source: §D.1 · p. 24

D.2 Prompt Sets

  • The standard set uses 20 prompts per domain, while the 30-prompt challenge set averages about 220 words, 18 constraints, and 38 objects per prompt.Standard prompts average about 70 words and seven constraints.Source: §D.2 · p. 24

D.3 Comparison Methods

The comparison methods use matched LLMs and object sets where applicable, with distinct generation pipelines and an added concept-pattern comparison.

D.3 Comparison Methods

  • The comparisons use the same gpt-5.5 model without reasoning for both baselines and Co-DSL runs.The authors note that this model is more recent and capable than those used in the original baseline works.Source: §D.3 · p. 24
  • PSDL drafts a template, writes and executes a procedural layout program, then uses solver violations in a correction loop; its full pipeline takes about 15 seconds per prompt.For comparison, PSDL receives the same object instances and room dimensions as Co-DSL.Source: §D.3 · p. 24
  • For spatial-pattern comparisons, three concepts in each of three shared domains are tested with two prompts each; baselines receive concept descriptions in prompts, while Co-DSL uses its corresponding library concepts.Holodeck’s asset-coupled output is rendered through its own pipeline rather than the final shared renderer.Source: §D.3 · p. 24

D.4 Quantitative Metrics

The evaluation defines base validity and prompt adherence measures, distinguishes valid layouts from solved layouts, and describes how parameterized layout programs are tested.

D.4 Quantitative Metrics

  • Base-validity checks count out-of-bounds entities, intersections, and floating objects; 2D arrangements are evaluated after category assets are inserted into a 3D scene.Chair-domain checks relax intersection and support, while Holodeck intersection violations are not counted, making its reported violation counts a lower bound.Source: §D.4 · pp. 24–25
  • A valid layout passes all base checks, whereas a solved layout also satisfies every concept verification in its concept-graph.Solved is the stricter criterion.Source: §D.4 · p. 25
  • Prompt adherence is judged against LLM-extracted checklists of object-based constraints, with a true-or-false verdict for each check.The judge receives the checklist and a text description of the parameterized layout.Source: §D.4 · p. 25

D.5 Extensions Setup

  • Generative programs are tested with two controls, sampled parameterizations, and repeated solves; a program counts as valid across its range only if every execution is valid.The setup uses 30 prompts and tests each program with three example parameterizations and four solves per combination.Source: §D.5 · p. 25

E NON-EXPERT USER STUDY DETAILS

The study examined student co-design of library concepts; participants rated the results positively and described scenario-based refinement, though some feedback was hard to verbalize.

E NON-EXPERT USER STUDY DETAILS

  • Every participant rated the resulting concepts as matching intended behavior, with ratings of agree or strongly agree.Eight university students took part across dining, living, and bedroom domains.Source: E NON-EXPERT USER STUDY DETAILS · p. 25
  • Concept development averaged about 15 minutes, with about 4.5 rounds of text guidance and 2.5 uses of auto-fix per concept.Participants co-designed two expert-specified concepts each; four also proposed a concept of their own.Source: E NON-EXPERT USER STUDY DETAILS · p. 25
  • Participants described initial implementations as reasonable starting points that were easy to refine by inspecting scenarios, though some struggled to verbalize changes when verifiers disagreed.In those cases, participants used example labeling and auto-fix; one participant used this approach on the harder CornerBedGroup task.Source: E NON-EXPERT USER STUDY DETAILS · p. 25
  • Scenario inspection helped some participants surface or settle design intent, including new requirements for Surround and a directed search through LookAt's concept space.One participant had no precise formulation of Surround beforehand; another described the LookAt session as a directed search.Source: E NON-EXPERT USER STUDY DETAILS · p. 25

F LAYOUT PROGRAM AUTHORING WALKTHROUGH

This section walks through the LLM’s composition and solver-feedback revision of a dining concept-graph program, then details the Surround concept’s synthesis and verification logic, including optional even spacing and center-facing orientations.

F LAYOUT PROGRAM AUTHORING WALKTHROUGH

G CONCEPT LIBRARY DETAILS

  • Surround takes a center and outer nodes with a target distance, arranging them at uniform angles or with angular and radial jitter while orienting them toward the center.Its inputs require at least four node names and use either “even” or “uneven” spacing.Source: G CONCEPT LIBRARY DETAILS · p. 28
  • When even spacing is requested, Surround checks angular gaps between outer nodes against the expected gap with a ±35% tolerance.The implementation reports a violation when a gap exceeds that tolerance.Source: G CONCEPT LIBRARY DETAILS · p. 29
  • Surround checks whether each outer node’s local +y_dir points toward the center, reporting missing or invalid orientations and violations below a 60° cosine threshold.The facing check skips nodes essentially at the center and reports a violation for a near-zero orientation vector.Source: G CONCEPT LIBRARY DETAILS · p. 29

Related papers

Loading 2610.15290v1…