Paper deep dive
CANDO: Cooperative Agentic Network for Layout Design Optimization
Athanasios Masouris, Zheng Jing, Benjamin Sam Chandler, Hadi Jamali-Rad
Intelligence
Status: succeeded | Model: Gemma-4-26B-A4B | Prompt: intel-v1 | Confidence: 94%
Last extracted: 10/8/2026, 6:03:40 AM
Summary
The paper introduces CANDO, a training-free multi-agent framework for constraint-aware layout design optimization, and ALPS-Bench, a benchmark of 1,000 professionally annotated real-world facility layouts. CANDO utilizes specialized agents (Verifier, Historian, Planner, Generator) in a cooperative loop to refine layouts based on hard and soft constraints, outperforming existing baselines on PubLayNet, RICO, and PKU-PosterLayout benchmarks.
Entities (10)
Relation Signals (9)
ALPS-Bench → contains → 1,000 layouts
confidence 98% · ALPS-Bench, a benchmark of 1,000 professionally annotated real-world facility layouts
CANDO → comprises → Verifier
confidence 95% · four specialized agents (Verifier, Historian, Planner, and Generator) cooperate
CANDO → comprises → Historian
confidence 95% · four specialized agents (Verifier, Historian, Planner, and Generator) cooperate
CANDO → comprises → Planner
confidence 95% · four specialized agents (Verifier, Historian, Planner, and Generator) cooperate
CANDO → comprises → Generator
confidence 95% · four specialized agents (Verifier, Historian, Planner, and Generator) cooperate
CANDO → uses → ALPS-Bench
confidence 95% · As a strong baseline for ALPS-Bench, we propose CANDO
CANDO → outperforms → PubLayNet
confidence 90% · CANDO surpasses state-of-the-art trained and LLM-based baselines on the widely adopted PubLayNet
CANDO → outperforms → RICO
confidence 90% · CANDO surpasses state-of-the-art trained and LLM-based baselines on the widely adopted ... RICO
CANDO → →
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
Abstract:Layout generation for real-world facilities is a challenging problem, requiring reasoning over irregular site boundaries, heterogeneous orientations, access-aware placements, and motion-planning feasibility. Yet, most existing layout benchmarks in the generative AI space target simpler placements over rectangular domains and rely on distributional metrics such as FID and IoU that reward conformity to dataset priors, thus discounting design innovation. Motivated by these gaps, we introduce ALPS-Bench, a benchmark of $1,000$ professionally annotated real-world facility layouts paired with an instance-specific scoring protocol grounded in a structured design manual. As a strong baseline for ALPS-Bench, we propose CANDO, a training-free multi-agent framework in which specialized agents iteratively refine layouts through a verification-grounded loop, concentrating reasoning on strategic spatial decisions. We demonstrate that CANDO surpasses state-of-the-art trained and LLM-based baselines on the widely adopted PubLayNet, RICO, and PKU-PosterLayout benchmarks, establishing cooperative agentic design as a broadly effective recipe for constraint-aware layout synthesis.
Tags
Links
- Source: https://arxiv.org/abs/2610.10044v1
- Canonical: https://arxiv.org/abs/2610.10044v1
Trouble viewing inline? Open PDF directly →
Full Text
170,609 characters extracted from source content.
Expand or collapse full text
CANDO: Cooperative Agentic Network for Layout Design Optimization Athanasios Masouris Affiliation: Shell Information Technology International Jing Zheng Affiliation: Shell China Limited Benjamin Chandler Affiliation: Shell Information Technology International Hadi Jamali-Rad Affiliation: Shell Information Technology International Affiliation: Delft University of Technology (TU Delft) Abstract Layout generation for real-world facilities is a challenging problem, requiring reasoning over irregular site boundaries, heterogeneous orientations, access-aware placements, and motion-planning feasibility. Yet, most existing layout benchmarks in the generative AI space target simpler placements over rectangular domains and rely on distributional metrics such as FID and IoU that reward conformity to dataset priors, thus discounting design innovation. Motivated by these gaps, we introduce ALPS-Bench, a benchmark of 1,0001,000 professionally annotated real-world facility layouts paired with an instance-specific scoring protocol grounded in a structured design manual. As a strong baseline for ALPS-Bench, we propose CANDO, a training-free multi-agent framework in which specialized agents iteratively refine layouts through a verification-grounded loop, concentrating reasoning on strategic spatial decisions. We demonstrate that CANDO surpasses state-of-the-art trained and LLM-based baselines on the widely adopted PubLayNet, RICO, and PKU-PosterLayout benchmarks, establishing cooperative agentic design as a broadly effective recipe for constraint-aware layout synthesis. 1 Introduction Layout generation has recently received an upsurge of attention as a subfield of generative modeling, with strong results reported across floor planning [54, 24, 49, 1], document design [59, 39], poster design [17], and graphical user interfaces synthesis [7, 52] tasks. Yet the regime captured by these interesting benchmarks is notably simpler than real-world design practice: floor-planning datasets are dominated by indoor, largely axis-aligned room arrangements; document and web layouts reduce to rectangular composition over discrete canvases. Besides, their evaluation strategy is predominantly distributional, with metrics such as FID, IoU, SSIM, and graph similarity rewarding resemblance to the dataset prior. The consequence is twofold. First, design innovation is implicitly penalized; i.e., valid yet atypical configurations are scored down simply for departing from the empirical distribution, collapsing the task into prior matching. Second, methods that excel under these protocols rarely transfer to settings where compositionality, orientation, and inter-element spatial relations are first-class concerns rather than emergent regularities of the dataset. A canonical real-world instance of this overlooked regime is asset layout design: arranging service units, parking bays, access points, and auxiliary buildings within an operational facility. Unlike its document and floor-plan counterparts, this problem requires reasoning over irregular, instance-specific site boundaries; enforcing orientation consistency across heterogeneous functional groups; organizing elements with respect to designated access points; and certifying motion-planning feasibility for multiple vehicle scenarios traversing the site. These requirements are entangled, namely: a placement that satisfies non-overlap may still block a routing scenario, and a compositionally clean clustering may violate access-aware constraints. We find empirically that neither distributional metrics nor (well-equipped) single-agent baselines can adequately address this challenging problem. More specifically, monolithic generators struggle on precisely the joint demands of spatial arithmetic, multi-constraint reasoning, and long-horizon planning that the problem entails, pointing to the need for an explicitly decomposed, verification-grounded solution architecture. Intrigued by these gaps and challenges, we make the following three core contributions: I. We introduce the Asset Layout Planning and Synthesis Benchmark (ALPS-Bench): 1,000 real-asset professionally-annotated layouts, each paired with a structured design manual of diverse spatial constraints. Our proposed evaluation protocol scores compliance across a variety of design criteria for standardized evaluation on a held-out test set. I. We propose CANDO, to the best of our knowledge, one of the first cooperative agentic AI frameworks for constraint-aware layout synthesis and a strong baseline for ALPS-Bench. CANDO offers several innovative design choices, including structured cooperation among agents, tool-grounded verification, and motion planning. I. We demonstrate that even a simplified version of CANDO achieves state-of-the-art mIoU and alignment on the widely adopted PubLayNet and RICO benchmarks, and leading overlap and strict-underlay performance on PKU-PosterLayout, corroborating that cooperative agentic frameworks are a broadly effective recipe for layout generation. 2 Related Work Layout Design and Its Benchmarks. Automated layout generation has been studied across a range of domains, including graphical user interfaces [7], document design [59], content-aware poster design [17], indoor scene arrangement [38, 47], and architectural floor planning [35, 43]. Early work relied on GANs [31] and VAEs [23, 29], achieving reasonable qualitative results but at the cost of task-specific training on large labeled datasets. Transformer-based methods then broadened the scope, with LayoutTransformer [14] enabling layout completion via self-attention, and LayoutFormer++ [22] unifying diverse constraint types into a single sequence format. Diffusion models followed, with LayoutDM [19], LayoutFlow [13], and DiffuScene [47] pushing generation quality further. These methods require training and are evaluated on distributional metrics like FID and overlap that reward proximity to the training prior rather than actual constraint satisfaction. Large language models (LLMs) have offered a different path. LayoutPrompter [32] and LayoutGPT [10] pioneered training-free layout generation via in-context learning (ICL), while fine-tuned variants such as LayoutNUWA [48] and PosterLlama [42] improved quality by representing layouts as structured HTML code. More recently, LayoutCoT [44] incorporated chain-of-thought (CoT) reasoning, while LaRa [27] introduced reinforcement learning (RL) from verifiable rewards. An emerging agentic direction pushes this further, with DisCo-Layout [11] and AutoLayout [4] proposing multi-agent loops for iterative spatial refinement. Notably, RICO [7] and PubLayNet [59] remain the predominant benchmarks adopted by almost all of the above, focusing on much simpler tasks and relying on prior matching metrics (such as mIoU and FID), leaving a gap in the literature that jointly motivated the proposed ALPS-Bench and CANDO. Cooperative Agentic AI. The structured reasoning capabilities of LLMs through CoT have been further enhanced by methods that guide such models to verify and refine their own responses, including Self-Refine [34] and Reflexion [45]. ReAct [58] established the interplay between structured reasoning and environment-grounded actions, paving the way for the modern agentic systems. Toolformer [41] demonstrated that LLMs benefit from offloading computations to external tools, which is particularly important given their known spatial arithmetic limitations [3]. Frameworks, such as Generative Agents [37], MemGPT [36], and A-Mem [55], further showed that episodic memory management is essential for coherent long-horizon behavior. Building upon these findings, multi-agent orchestration frameworks, such as AutoGen [53], MetaGPT [15], CAMEL [30], AgentVerse [5], and MINDcraft [51], establish that role-specialized cooperating agents consistently outperform monolithic models on complex tasks [8]. Inspired by this prior art, we propose CANDO, a novel approach to constraint-aware layout design consisting of a cooperative agentic network that leverages tool-grounded verification, episodic feedback memory, role-specialized cooperation, and block-wise BoN [2] (a.k.a CoDe [46]) into a single training-free framework. 3 Problem Formulation We formalize layout synthesis as constrained optimization of rigid-body placement over a 22D plane. The goal is to determine the position and orientation of each element so as to satisfy geometric feasibility requirements and minimize violation of design constraints. Layout Domain. It is comprised of the layout premise ⊂ℝ2P ^2; an empty outer polygon within which the elements are to be placed. And, a set of access points (i.e., entrance, exit) sitting on the edges of the premise P. Access points define designated regions through which vehicles may enter or leave the domain, and they take a pivotal role in operational constraints such as routing feasibility. Elements Configuration. Elements eie_i (i∈[E]i∈[E]) are to be placed within the premise P. Each ei=(ci,Gi)e_i=(c_i,G_i) has a semantic class ci∈c_i and a fixed canonical shape/body Gi⊂ℝ2G_i ^2, a compact region centered at the origin (e.g. a rectangle). We denote ℰ=(ci,Gi)i=1EE=\(c_i,\,G_i)\_i=1^E for the full element specification. Element shapes/sizes, classes, and counts are fixed inputs; only their spatial placement is optimized. See Fig. 1 for an example layout illustrating premise, access points and elements. Each eie_i is displaced by assigning a centroid i=(xi,yi)∈ℝ2p_i=(x_i,y_i) ^2 and an orientation angle θi∈[0,2π) _i∈[0,2π). The displaced element is the element canonical shape GiG_i rotated by θi _i and translated to ip_i following: Ωi(i,θi)=R(θi)Gi+i,R(θi)=(cosθi−sinθisinθicosθi). _i(p_i, _i)=R( _i)\,G_i+p_i, R( _i)= pmatrix _i&- _i\\ _i& - _i pmatrix. (1) For the sake of simplicity, we omit the fixed canonical shape GiG_i and class label cic_i in denoting the displaced elements Ωi _i resorting only to the parameters (i,θi)(p_i, _i). We bundle these tuples in the elements configuration =(i,θi)i=1E∈q=\(p_i, _i)\_i=1^E , with Q being the set of all possible configurations. As a result, q now can serve as our optimization parameter, focusing only on the variable parts of the elements and not the layout domain (premise and access points). Constraints. Design manual ℳ=ℋ,M=\HC,SC\ covers two sets of desired specifications: Hard constraints (ℋHC) encode three necessary conditions that yield valid configurations valid⊂Q_ valid : (i) Containment. Every placed element lies within the premise: Ωi⊆ _i , ∀i∈[E]∀ i∈[E]. (i) Non-overlap. Distinct elements do not intersect or fully overlap: Ωi∩Ωj=∅ _i∩\, _j= , ∀i≠j∀ i≠ j. (i) Routing feasibility. A finite set of predefined scenarios ℛR specifies required vehicle routes as ordered sequences of intermediate points (e.g., [vehicle type, entrance→waypoint→⋯→exit entrance→ waypoint→·s→ exit]). For every scenario and every concrete instance of intermediate points, a collision-free path must exist through the free space ∖⋃iΩiP _i _i. Soft constraints (SC) quantify how well a configuration satisfies the following design properties: (i) Compositionality. Prescribes arrangement patterns and intra-group distance thresholds. (i) Orientation. Defines permitted orientations and intra-group element-wise alignment. (i) Proximity. Encodes stacking relations, clearance zones, and inter-element distance bounds. Objective. The goal is to find a valid configuration that maximizes total weighted score: ⋆=argmax∈valid()≜∑s=1Swsfs(), \;q = _q\,∈\,Q_valid\;J(q)\; \; _s=1^Sw_s\,f_s(q),\; (2) with S=||S=|SC|, and scoring function fs∈[0,1]f_s∈[0,1] indicating compliance against soft constraint s∈s when fs()=1f_s(q)=1. Scoring weights sum up to ∑sws=1 _sw_s=1. A configuration is considered compliant if it is valid (satisfying all hard constraints ℋHC) and ()=1J(q)=1. Definition 1 (Input requirements). A layout input requirement is a tuple ℐ=(,,ℰ,ℳ)I=(P,\;A,\;E,M), specifying the layout premise, access points, element set, and constraint partition. Remark 1 (Generalization to higher dimensions). The formulation extends naturally to volumetric layout synthesis (e.g., multi-floor facility planning) by extending Eq.1 to its 3-D counterpart [12]. 4 Asset Layout Planning and Synthesis (ALPS) Benchmark As discussed in Section 1, prior layout benchmarks do not fully capture the geometric and operational intricacies of real-life complex design problems such as outdoor facility/asset design, and are typically evaluated by similarity scores against dataset priors rather than constraint satisfaction. Figure 1: Left: Sample from ALPS-Bench. Right: Voronoi-based motion planning. Intrigued by these gaps, we introduce the Asset Layout Planning and Synthesis Benchmark (ALPS-Bench), a collection of 1,0001,000 annotated layouts from real operational sites. Polygon-level annotations were produced by professional annotators working directly from original CAD design drawings of each facility, yielding geometrically accurate element boundaries that reflect the as-built state of the sites. Each layout is composed of elements drawn from 1414 semantic classes organized into four functional groups: (i) site premise and access: referring to layout premise P, entrance and exit); (i) service infrastructure: three service unit variants differentiated by vehicle size (csa, bsa, hgvs), an electric vehicle charging area (evsa), an underground service facility (usf), and an underground access point (uap); (i) building and auxiliary services: a retail building (shop); and (iv) parking: four bay variants: car (cp), bicycle (bp), priority (p), and heavy-goods vehicle (hgvp). Element composition is instance-specific: not all 1414 classes appear in every layout, introducing compositional variability and class imbalance characteristic of real facility layout design. An example layout is illustrated in Fig. 1 (left). The layouts are governed by a shared design manual ℳM (as discussed in Section 3, with details in Appendix D.4), released alongside the dataset. The full routing scenarios and soft constraint specification are detailed in Appendices D.5 and D.4.2. In contrast to existing web and document layout benchmarks, ALPS-Bench offers challenging design through variable premise shape, varying numbers of elements and access points, and an imbalanced class distribution. Data Split and Structure. The 1,0001,000 layouts are partitioned into a development set of 900900 instances (devD dev) and a held-out test set of 100100 instances (testD test). Development instances are released with full annotations (input requirements ℐI together with the ground-truth configuration †q ) making this set suitable for training, in-context learning, and hyperparameter selection. For test instances, only the input requirements ℐI will be made public; ground-truth configurations are withheld to support standardized automated evaluation on a hosted online server. Further details on dataset statistics and annotation format can be found in Appendix D.3 and D.2, respectively. 4.1 Evaluation and Benchmarking To evaluate newly designed layouts, we propose an instance-specific scorer instead of metrics such as IoU or FID, which can penalize design innovation by promoting prior matching. The scoring function evaluates generated instances from two perspectives: (i) satisfaction of design manual (ℳ=ℋ,M=\HC,SC\); and (i) comparison against withheld ground-truth layouts †q in terms of routing efficiency. Let us delve deeper into the evaluation metrics. Hard Constraints Metrics (HCM). To evaluate satisfaction of the hard constraints (ℋHC) of the design manual (ℳM) in Section 3, this metric investigates the existence and correct sizing of all elements specified by input requirement ℐI; containment (Ωi⊆ _i , ∀i∀ i); non-overlap (Ωi∩Ωj=∅ _i∩ _j= , ∀i≠j∀ i≠ j); and routing feasibility across scenarios in ℛR. While the other conditions are straightforward to measure, routing feasibility is a non-trivial assessment task. To assess unobstructed navigation for a routing scenario, we adopt a simple Voronoi-based motion-planning approach [28, 6]. We first inflate the borders of obstacles (i.e., ei∉ℛe_i ) by a scenario-dependent safety margin ϵε. We then sample seed points on the inflated borders and use them to construct a Voronoi diagram. The Voronoi medial axes are used to identify paths with maximum clearance. This is shown in Fig. 1 (right), with further details in Appendix D.6. Missing or incorrectly sized elements result in HCM =0=0. Otherwise, the score is a continuous value in (0,1](0,1], computed as HCM=αg×HCg+αf×HCfHCM= _g×HC_g+ _f×HC_f, where the geometric validity score HCg proportionally penalizes out-of-boundary and overlapping areas, and the flow score HCf is the fraction of feasible routing scenarios. We use αg=0.2 _g=0.2 and αf=0.8 _f=0.8, assigning more weight to valid routing because it is considerably more complex to address. Soft Constraint Metrics (SCM). To evaluate satisfaction of the soft constraints (SC) part of the design manual (ℳM), this metric investigates three aspects. Proximity (PR) ∈[0,1]∈[0,1] checks stacking/adjacency, minimum clearance, and maximum inter-element distance requirements, penalizing each violation at −0.1-0.1. Compositionality (CO) ∈[0,1]∈[0,1] checks whether elements of each semantic class form the spatial formations required by the design manual (e.g., line arrays, matrix grids), also penalizing fragmentation and wrong formations at −0.1-0.1 per violation. Orientation (OR) ∈[0,1]∈[0,1] checks intra-group angular alignment, with penalties scaling continuously with angular deviation. The score is a continuous value in [0,1][0,1], computed as SCM=αp×PR+αc×CO+αo×ORSCM= _p×PR+ _c×CO+ _o×OR. We currently use αp=0.6,αc=0.3 _p=0.6,~ _c=0.3 and αo=0.1 _o=0.1, reflecting the proportional number of soft constraint rules for each category included in ℳM. Ground Truth Metrics (GTM). To go beyond constraint satisfaction, this metric compares generated layouts against the withheld ground-truth configurations †q along three operational dimensions: path length (PL), maneuverability (MN), and path clearance (PC), each normalized to [0,1][0,1] with 0.50.5 indicating equivalence to the ground truth. PL is scored as ℓ¯gt/(ℓ¯gt+ℓ¯gen) _gt/( _gt+ _gen); MN as n¯gt/(n¯gt+n¯gen) n_gt/( n_gt+ n_gen), where n¯ n is the average number of turns; and PC as c¯gen/(c¯gt+c¯gen) c_gen/( c_gt+ c_gen), where c¯ c is the average minimum distance to obstacles along the paths. Subscripts (.)gt(.)_gt and (.)gen(.)_gen refer to ground-truth and generated layouts, respectively. Values above 0.50.5 indicate shorter routes, fewer turns, or wider clearances relative to the ground truth. Invalid scenarios receive PL=MN=PC=0PL=MN=PC=0. Aggregate Score (AGG). With all sub-metrics bounded in [0,1][0,1], we define the final scores: AGG=12(CS+RE),CS=SCMif HCM=1α×HCM×SCMif HCM<1,RE=13(PL+MN+PC).AGG= 12(CS+RE),~CS= casesSCM&if HCM=1\\ α×HCM×SCM&if HCM<1 cases,~RE= 13(PL+MN+PC). (3) Our constraint satisfaction metrics are summarized in CS, where invalid final layouts (HCM<1HCM<1) are penalized with a capped score of α. We set α=0.5α=0.5 to emphasize that invalid layouts are undesirable. The routing efficiency metrics are summarized in RE, and CS and RE are averaged to produce the aggregate score (AGG). All scores are computed per layout and then averaged over the relevant split. Figure 2: The interplay and cooperation among the agents in CANDO. Upon an ICL Initialization, Verifier, Historian, Planner and Generator communicate in a structured manner within a loop. 5 Methodology To solve the optimization problem introduced in Section 3 and instantiated with ALPS-Bench, we propose Cooperative Agentic Network for Design Optimization (CANDO), a multi-agent framework for constraint-aware layout synthesis. As motivated in Section 1, this cooperative architecture distributes reasoning tasks across specialized agents to avoid the failure modes of single-model generation and to enable processing with resource-constrained agents (with smaller backbones). This design choice is supported by both prior art [30, 15, 53, 50] and our experiments in Section 6. The proposed solution operates in two phases. First, an in-context learning initializer (ICL Initializer) produces a seed configuration (0)q^(0) by conditioning an LLM on structurally similar layouts retrieved from the development data. Second, four specialized agents (Verifier, Historian, Planner, and Generator) cooperate to refine (0)q^(0) toward ⋆q through a parallel-branching iterative loop adapted from CoDe’s blockwise sampling scheme for diffusion models [46]. Crucially, since language models struggle with spatial understanding and coordinate arithmetic [56], CANDO deliberately offloads low-level geometric computations to deterministic tools. The two-phase design reflects the asymmetric interplay between feasibility and design quality, as hard-constraint violations would render soft-constraint quality irrelevant. The proposed solution design and inner-mechanics of the agentic cooperation are illustrated in greater detail in Fig. 2. The overall optimization process is summarized in Algorithm 1. In-Context Learning Initialization. Given an input requirement ℐnewI_new (Definition 1), the ICL Initializer agent produces an initial configuration (0)q^(0) by conditioning layout synthesis on structurally similar examples retrieved from devD dev. The example retrieval process starts by embedding new input requirements ℐnewI_new into a feature vector ϕ(ℐnew)∈ℝdφ(I_new) ^d covering four aspects: (i) per-class element counts and area coverages, (i) access-point counts and their positions, (i) element size statistics, and (iv) layout descriptors (area, perimeter, compactness). The most similar layouts to the query are retrieved with a weighted kkNN search over the embedding space representing ϕ(ℐ)∣ℐ∈dev\φ(I) dev\. The retrieved examples are serialized as input–output pairs (input: ℐI, output: q) and provided as context to the agent, which is conditioned on ℐnewI_new. Next, KinitK_init candidate layouts are generated in parallel and ranked using a geometric hard-constraint satisfaction proxy: σ()≔11+Vout()+Vov(),Vout()≔1||∑i=1E|Ωi∖|,Vov()≔1||∑i<j≤E|Ωi∩Ωj|σ(q) 11+V_out(q)+V_ov(q),~V_out(q) 1|P| _i=1^E| _i |,~V_ov(q) 1|P| _i<j≤ E| _i∩ _j| (4) where Vout()V_out(q) and Vov()V_ov(q) are dimensionless out-of-premise and unique-pair overlap violations, normalized by premise area. Thus, σ()=1σ(q)=1 exactly when the candidate satisfies containment and pairwise non-overlap. We rank the candidates by σ(⋅)σ(·) and select the highest-scoring one. The result is returned as (0)q^(0). Further details on specific feature definitions and the weighted kkNN approach can be found in Appendix F.1. Verification. It lies at the core of our proposed approach, providing reward signals that guide the refinement of intermediate layouts. Given K candidates in (t)Q^(t), the Verifier evaluates them against the design manual ℳM using dedicated deterministic tools and selects the best-scoring candidate ¯(t) q^(t). The Verifier and benchmark evaluator intentionally share ground-truth-free design-manual checks (HCg, HCf, CO, PR, OR), but final scores are recomputed independently and the optimization never observes a held-out target layout. In particular, PL, MN, and PC compare against †q and are available only to the benchmark evaluator; hence, RE and AGG are not optimization signals. For richer diagnostics, the Verifier treats routing separately rather than integrating it into HCM, reports the five constraint aspects and CS, and aggregates fine-grained diagnostics (e.g., obstacles blocking a route) into ℱ(t)F^(t) for the Historian and Planner. History Management. The Historian agent maintains a running record of how the layout design evolves. After each step t, it computes the change in feedback and annotates it with a concise description of the spatial changes that led to it. A sliding window containing at most W recent changes, ℋ(t)=Δℱ(s)s=max(1,t−W+1)tH^(t)=\ ^(s)\_s= (1,t-W+1)^t, is passed to the Planner, grounding its decisions in the evolution of feedback over time rather than only its current state. Planner. The Planner agent drafts its remediation plan along the same five evaluation categories used by the Verifier. Category-level plans are produced by the same agent, if the agent is capable of handling the full context (with a large backbone), or decomposed and processed in parallel by specialized planning sub-agents/workers, with task-specific tools, and then reconciled by a supervisor into a remediation plan Π(t) ^(t) at each time step t (as shown in Fig. 2). To resolve cross-category conflicts and prioritize repairs, the supervisor grounds its decisions in a multi-modal input context defined by four complementary pieces of information: (i) the targeted diagnostic feedback from the specialist workers, (i) the history ℋ(t)H^(t), (i) the geometric coordinate representation of the layout, and (iv) its visual rendering created by a simple plotting tool. By incorporating a subset or all of these signals, the supervisor formulates a coherent global intervention plan. Generator. This agent translates the remediation plan Π(t) ^(t) into a set of K revised candidate configurations (t)=k(t)k=1KQ^(t)=\q_k^(t)\_k=1^K by applying a sequence of modifications to ¯(t−1)=(i,θi)i=1E q^(t-1)=\(p_i, _i)\_i=1^E (Eq. (1)). The Generator adopts a strategy-diversified ensemble generation, with candidates either applying the plan conservatively through local repairs, prioritizing a single category or allowing larger layout-wide modifications. This ensemble design is important in practice because different layouts benefit from different remediation strategies. The strategy ensemble and their detailed definitions are discussed in detail in Appendix F.2. Algorithm 1 CANDO 1: ℐI, devD^dev, N, B, K, W, T 2: ℋ(0)←∅;t←0H^(0)← ;~~t← 0 3: (¯(0),ℱ(0))←Verifier(ICLInit(ℐ,dev))( q^(0),F^(0))← Verifier(\ ICLInit(I,D^dev)\) 4: while t≤T−Bt≤ T-B do 5: ℋn(t),ℱn(t),n(t)n=1N←Replicate(ℋ(t),ℱ(t),¯(t))\H_n^(t),F_n^(t),q_n^(t)\_n=1^N← Replicate(H^(t),F^(t), q^(t)) 6: for b=0,…,B−1b=0,…,B-1 do ⊳ ∀n∈[N]∀ n∈[N], in parallel 7: ℋn(t+b+1)←Historian(ℋn(t+b),ℱn(t+b),W)H_n^(t+b+1)← Historian(H_n^(t+b),\,F_n^(t+b),W) 8: Πn(t+b+1)←Planner(n(t+b),ℱn(t+b),ℋn(t+b+1)) _n^(t+b+1)← Planner(q_n^(t+b),\,F_n^(t+b),\,H_n^(t+b+1)) 9: n(t+b+1)←Generator(n(t+b),Πn(t+b+1),K)Q_n^(t+b+1)← Generator(q_n^(t+b),\, _n^(t+b+1),K) 10: (¯n(t+b+1),ℱn(t+b+1))←Verifier(n(t+b+1))( q_n^(t+b+1),F_n^(t+b+1))← Verifier(Q_n^(t+b+1)) 11: end for 12: t←t+Bt← t+B 13: (¯(t),ℱ(t),ℋ(t))←BoN(¯n(t),ℱn(t),ℋn(t)n=1N)( q^(t),F^(t),H^(t))← BoN\! (\ q_n^(t),F_n^(t),H_n^(t)\_n=1^N ) 14: end while, return ¯(T) q^(T) Cooperative Refinement Loop. Starting from (0)q^(0), CANDO refines the layout through a parallel-branching loop that adapts CoDe’s blockwise sampling scheme from diffusion models [46], as summarized in Algorithm 1. Until the budget of T refinement steps is exhausted, in every iteration, CANDO spawns N independent exploration branches from ¯(t) q^(t) (Line 6). Every branch has its own local history (ℋn(t)H_n^(t)) and pursues its own trajectory of B sequential steps. Each step corresponds to an execution of the history-aware planning-generation-verification sequence (Lines 7–10). At the end of each block (B steps) a BoN reduce operation (Line 13) selects the branch with the highest score (the new ¯(t) q^(t)), as well its corresponding history and feedback (the new ℋ(t)H^(t) and ℱ(t)F^(t), respectively), and passes it onto the next step where it will be replicated N times to start the next block (Line 5). The (block-wise) BoN approach enables the system to simultaneously explore structurally different refinements without committing prematurely to any single branch. Note that setting B=TB=T transforms CoDe back to BoN. The interested reader is referred to Appendix F for more elaborate discussions on the individual agents. 6 Experiments Experimental Setup. We assess CANDO on our proposed ALPS-Bench and three public benchmarks: PubLayNet [59], RICO [7], and PKU-PosterLayout [17]. For ALPS-Bench, the problem setting and corresponding evaluation metrics are defined in Sections 3 and 4, respectively. For PubLayNet and RICO, we evaluate all tasks defined and adopted by prior art: type-conditioned generation (Gen-T), type/size-conditioned generation (Gen-TS), relational generation (Gen-R), refinement, and completion (latter three in Appendix E.4). A simplified version of CANDO is applied on the public benchmarks because not all agents are needed; its complete configuration is given in Appendix E.2. For PubLayNet and RICO, we follow the evaluation criteria in the literature with the adjusted mIoU (as per [25]), alignment (“Align.”), overlap, and FID scores. For the latter three, we adopt the implementations of [22]. For most of our experiments we opt Qwen3.6 [40] (Qwen/Qwen3.6-35B-A3B-FP8) as a backbone for our agents. This variant of Qwen is a lightweight, yet powerful open-source Mixture-of-Experts (MoE) [21, 9] model of 3535B total parameters and 33B active parameters. For quantitative evaluations, we used NVIDIA H100 GPUs with 8080GB of VRAM. For our experiments with ALPS-Bench, we also provide experimental results with GPT-5.2 (API access via a cloud provider), a model with strong reasoning capabilities and orders of magnitude larger size. Results on ALPS-Bench. Table 1 summarizes the performance of CANDO using our adaptation of CoDe’s blockwise sampling procedure [46] with two backbone variants (Qwen and GPT-5.2). ALPS-Bench goes beyond standard generation tasks conditioned on type and size through an elaborate design manual. Therefore, few baselines apply directly to the newly defined tasks without considerable architectural modification and retraining. To compare against training-based approaches, we additionally adapt and train LayoutDM [19] from scratch on ALPS-Bench and fine-tune Qwen3-VL-8B-Instruct [57] using LoRA-SFT [18]. LayoutDM requires an adaptation of its native axis-aligned layout representation to accommodate the polygonal geometry and element orientations of ALPS-Bench, whereas Qwen-LoRA-ALPS generates the complete polygonal layout in a single pass conditioned on the rendered site and structured requirements. Adaptation details for both baselines are provided in Appendix E.1. We further compare against the pioneering LLM-based approaches LayoutPrompter [32] and LayoutCoT [44], as well as our implementation of a Single-Agent using a strong backbone (GPT-5.2) and equipped with the evaluation scores and toolset devised for CANDO. Figure 3: Mean CS Score vs. T for Table 1 The summary statistics demonstrate that CANDO variants substantially outperform all considered baselines, including the two models trained specifically on ALPS-Bench, while requiring an order of magnitude smaller total number of refinement steps (T) than the Single-Agent baseline, with a time-evolution graph shown in Fig. 3. LayoutDM frequently violates geometric hard constraints because its bounding-box-based representation only approximates the true polygonal site geometry, while the single-pass Qwen-LoRA-ALPS can capture high-level compositional patterns but struggles with exact containment, non-overlap, and routing feasibility. These results suggest that dataset-specific training alone is insufficient for the hard geometric constraints of ALPS-Bench and further highlight the importance of iterative, tool-grounded verification. Additionally, paired, instance-level two-sided Wilcoxon tests with Holm correction and paired-bootstrap 95%95\% CIs over the 100100 test instances confirm that both CANDO variants significantly outperform all considered baselines on AGG, CS, and RE (all pHolm≤0.0059p_Holm≤ 0.0059), while the Qwen and GPT-5.2 variants are statistically comparable across all three metrics (pHolm=1.000p_Holm=1.000). Full results are reported in Appendix E.8. For the sake of fair comparison, we also provide time complexity of each approach averaged over the samples in testD^test. To measure time complexity, we assume a single LLM inference call to incur a fixed complexity of τ. To provide a more complete picture, we compute the average number of iterations per method to reach compliance (on the samples achieving that). Considering a factor of ×4× 4 taking into account the number of sequential calls to each agent in CANDO, we arrive at the summary provided in the table. The results show that CANDO requires the same order of complexity (half or even less, to be precise). This underscores that despite the increased operational complexity per step, the parallelized nature of CANDO yields a competitive overall complexity that scales more favorably than the extensive sequential Single-Agent counterpart. Table 1: Quantitative results of layout generation models evaluated on the ALPS-Bench test set (testD test). † denotes methods trained or fine-tuned on ALPS-Bench; all other methods are training-free with respect to ALPS-Bench. Symbols indicate the generation paradigm: ⧫ diffusion-based, ▲ single-LLM/MLLM, and ∙ agentic. Method Summary Statistics T Avg. Iterations to Comply Time Complexity Compliance (%) AGG↑ CS↑ RE↑ ▲ Qwen-LoRA-ALPS† 0.07±0.120.07_± 0.12 0.01±0.080.01_± 0.08 0.13±0.220.13_± 0.22 11 – τ – ⧫ LayoutDM† [19] 0.13±0.130.13_± 0.13 0.01±0.030.01_± 0.03 0.24±0.250.24_± 0.25 – – – – ▲ LayoutPrompter (GPT-5.2) [32] 0.17±0.110.17_± 0.11 0.01±0.060.01_± 0.06 0.33±0.210.33_± 0.21 11 – τ – ▲ LayoutCoT (GPT-5.2) [44] 0.19±0.200.19_± 0.20 0.13±0.240.13_± 0.24 0.25±0.240.25_± 0.24 44 – 4τ4τ – ∙ Single-Agent (GPT-5.2) 0.40±0.270.40_± 0.27 0.47±0.370.47_± 0.37 0.32±0.220.32_± 0.22 200200 80.680.6 80.6τ80.6τ 22.422.4 ∙ CANDO (BoN/GPT-5.2) 0.59±0.250.59_± 0.25 0.77±0.360.77_± 0.36 0.41±0.170.41_± 0.17 2020 8.558.55 8.55×4τ=34.2τ8.55× 4τ=34.2τ 60.660.6 ∙ CANDO (CoDe/GPT-5.2) 0.60±0.250.60_± 0.25 0.78±0.350.78_± 0.35 0.42±0.170.42_± 0.17 2020 8.818.81 8.81×4τ=35.24τ8.81× 4τ=35.24τ 63.663.6 ∙ CANDO (CoDe/Qwen3.6) 0.62±0.190.62_± 0.19 0.83±0.250.83_± 0.25 0.41±0.160.41_± 0.16 2020 5.095.09 5.09×4τ=20.36τ5.09× 4τ=20.36τ 74.074.0 Table 2: Quantitative results on PubLayNet and RICO datasets. Extended version in Appendix E.4. RICO [7] PubLayNet [59] Task Method mIoU↑ FID↓ Align↓ Over↓ mIoU↑ FID↓ Align↓ Over↓ Gen-T LayoutGAN++ [25] 0.298 5.954 0.261 0.620 0.297 14.875 0.124 0.148 BLT [26] 0.216 25.633 0.150 0.983 0.140 38.684 0.036 0.196 LayoutFormer++ [22] 0.432 1.096 0.230 0.530 0.348 8.411 0.020 0.008 LayoutPrompter [32] 0.604 2.134 0.002 0.029 0.619 1.648 0.001 0.004 LayoutCoT [44] 0.719 2.189 0.001 0.022 0.772 1.227 0.000 0.002 CANDO (ours) 0.866 2.101 0.000 0.005 0.893 3.455 0.000 0.000 Gen-TS BLT [26] 0.604 0.951 0.181 0.660 0.428 7.914 0.021 0.419 LayoutFormer++ [22] 0.620 0.757 0.202 0.542 0.471 0.720 0.024 0.037 LayoutPrompter [32] 0.707 3.072 0.002 0.051 0.727 1.863 0.001 0.076 LayoutCoT [44] 0.795 3.506 0.000 0.031 0.847 1.430 0.000 0.004 CANDO (ours) 0.879 1.371 0.000 0.052 0.881 2.023 0.000 0.000 Results on PubLayNet and RICO. To further assess the efficacy of CANDO beyond the proposed ALPS-Bench, we extended our evaluations against state-of-the-art layout generation models on two widely adopted benchmarks: PubLayNet and RICO. Table 2 summarizes the performance for type-conditioned (Gen-T) and type/size-conditioned (Gen-TS) layout generation tasks. CANDO achieves the highest mIoU on both settings by a substantial margin, and perfect alignment scores across both benchmarks and tasks. This is noteworthy given that here CANDO runs on a comparatively lightweight open-source backbone Qwen with 3535B parameters compared to GPT-4 used in LayoutCoT [44] and the most recent (and the best) reported results for LayoutPrompter [32]. Across all five RICO tasks, CANDO also improves overlap over LayoutCoT in four cases, with Gen-TS as the exception (Appendix E.4). These alignment and overlap results reflect CANDO’s verification and tool-calling strategies. By offloading axis-alignment and overlap checks to dedicated geometric tools, rather than relying on the (M)LLM to reason about coordinates, CANDO handles such violations precisely. The FID scores here present a more nuanced picture. Despite leading on mIoU, CANDO does not consistently achieve competitive FID, ranking second or last depending on the setting. This inconsistency is not incidental but rather symptomatic of the broader limitation of distributional evaluation we discussed in Sections 1 and 4. We argue that a method that produces geometrically precise layouts that satisfy desired constraints and requirements yet happens to deviate from the distribution of the training data will incur a high FID penalty, even if its outputs are arguably of higher design quality. Methods such as LayoutFormer++, which are trained explicitly against the prior distribution, are inherently better at minimizing FID, even though as the mIoU results suggest, at the cost of spatial accuracy. Notably, this is known in the context of reward-aligned foundation models (analogous to meeting design requirements through a verification scheme in our setting) where more innovative samples can be generated at the cost of larger KL divergence from prior data [20, 46]. Table 3: Quantitative results on PKU-PosterLayout dataset. Additional tasks are reported in Appendix E.5. Task Method Occ↓ Rea↓ UndS↑ Ove↓ FID↓ Gen-T RALF [16] 0.136 0.0127 0.890 0.0091 2.36 UniLayDiff [33] 0.122 0.0129 0.963 0.0018 3.09 CANDO (ours) 0.144 0.0196 1.000 0.0009 9.83 Gen-TS RALF [16] 0.138 0.0123 0.876 0.0113 0.61 UniLayDiff [33] 0.128 0.0132 0.918 0.0046 0.66 CANDO (ours) 0.145 0.0197 0.990 0.0000 4.47 Results on PKU-PosterLayout. To further assess the generalizability of CANDO, we additionally adapt and evaluate it on PKU-PosterLayout, considering its controllable generation tasks. Table 3 reports results for type-conditioned (Gen-T) and type/size-conditioned (Gen-TS) layout generation tasks. Results for relationship-conditioned generation, completion, and refinement are deferred to Appendix E.5. Across both tasks, CANDO exhibits particularly strong performance on metrics directly associated with explicit spatial constraint satisfaction. Specifically, it attains the best Strict Underlay scores (1.0001.000 and 0.9900.990) while simultaneously reducing overlap to 0.00090.0009 and 0.00.0, respectively, outperforming both RALF [16] and UniLayDiff [33] on these metrics. Conversely, CANDO obtains higher FID scores and does not consistently improve occurrence or readability. This behavior is consistent with the observations on PubLayNet and RICO: CANDO’s verification-driven generation procedure explicitly optimizes compliance with geometric and relational requirements rather than reproducing the empirical layout distribution of the dataset, as measured by distribution-sensitive metrics such as FID. Table 4: Component ablation of CANDO. Regression rate denotes the percentage of refinement iterations for which the verification score decreases after applying the proposed changes. Variant AGG↑ CS↑ RE↑ Verifier-Compliant Layouts Mean Iterations Regression Rate CANDO (full) 0.62±0.190.62_± 0.19 0.83±0.250.83_± 0.25 0.41±0.160.41_± 0.16 74% 13.28 7.0% w/o CoDe 0.35±0.300.35_± 0.30 0.38±0.450.38_± 0.45 0.32±0.230.32_± 0.23 44% 16.75 6.3% w/o Historian 0.61±0.230.61_± 0.23 0.80±0.340.80_± 0.34 0.42±0.160.42_± 0.16 59% 13.35 6.7% w/o ICL 0.57±0.260.57_± 0.26 0.75±0.370.75_± 0.37 0.40±0.190.40_± 0.19 53% 14.39 5.8% w/o Planner 0.62±0.220.62_± 0.22 0.82±0.320.82_± 0.32 0.43±0.150.43_± 0.15 51% 14.63 6.7% w/o Strategies 0.61±0.230.61_± 0.23 0.80±0.320.80_± 0.32 0.42±0.160.42_± 0.16 53% 14.60 18.4% w/o Tool-grounded Verifier 0.27±0.230.27_± 0.23 0.28±0.270.28_± 0.27 0.25±0.240.25_± 0.24 95%∗ 4.63 19.6% w/o Visual Rendering 0.61±0.240.61_± 0.24 0.80±0.350.80_± 0.35 0.42±0.160.42_± 0.16 61% 13.35 7.3% ∗Without tool access, the Verifier acts solely as an LLM-as-a-Judge, inflating its scores. Component Ablation. Table 4 assesses the contribution of the main architectural components of CANDO. We define the regression rate as the percentage of refinement iterations in which the verification score decreases after applying the proposed changes, capturing how often a refinement step inadvertently introduces or worsens constraint violations. CoDe and tool-grounded verification have the most pronounced impact. Replacing CoDe with a single refinement trajectory reduces AGG from 0.620.62 to 0.350.35, CS from 0.830.83 to 0.380.38, and verifier-compliant layouts from 74%74\% to 44%44\%, while increasing the mean number of iterations from 13.2813.28 to 16.7516.75. This demonstrates the importance of parallel exploration for escaping difficult constraint violations rather than committing to a single refinement trajectory. Tool-grounded verification is similarly critical. Without deterministic verification tools, the LLM-based Verifier declares 95%95\% of layouts compliant and terminates after only 4.634.63 iterations on average, despite the independent evaluation yielding only 0.270.27 AGG and 0.280.28 CS. The corresponding regression rate also increases from 7.0%7.0\% to 19.6%19.6\%. This discrepancy highlights that an LLM-as-a-Judge can substantially overestimate constraint satisfaction and corroborates the importance of grounding feedback in deterministic tools. Strategy diversification primarily affects the stability of refinement. Removing the alternative refinement strategies leaves the average scores comparatively unchanged, but increases the regression rate from 7.0%7.0\% to 18.4%18.4\% and reduces compliance from 74%74\% to 53%53\%. Thus, a single generic repair strategy is substantially more likely to resolve one violation while introducing another. The distribution of winning strategies, reported in Appendix E.6, further shows that no individual strategy dominates the refinement process. ICL provides the next most pronounced benefit, with its removal reducing AGG from 0.620.62 to 0.570.57, CS from 0.830.83 to 0.750.75, and compliance from 74%74\% to 53%53\%, while requiring more refinement iterations. The remaining components primarily improve robustness rather than mean performance. Notably, removing the Planner leaves mean AGG nearly unchanged (0.620.62) but reduces compliance from 74%74\% to 51%51\%, suggesting that direct Verifier feedback can often repair individual violations but is less reliable at jointly reconciling all constraints. Hyperparameter Tuning. Detailed hyperparameter ablations for ALPS-Bench are reported in Appendix E.7. Based on a development-set sweep using Qwen for cost efficiency, we select N=4N=4, B=10B=10, K=6K=6, and W=6W=6, which achieve 0.760.76 CS and 0.590.59 AGG. We retain this configuration across backbone variants and increase the refinement budget to T=20T=20 for the reported ALPS-Bench experiments. Appendix E.2 details the fixed configurations used on all public benchmarks. 7 Concluding Remarks We introduced ALPS-Bench, a benchmark of 1,0001,000 professionally annotated facility layouts with an instance-specific scoring protocol that measures actual constraint satisfaction, and CANDO, a training-free cooperative agentic framework that refines layouts through a verification-grounded loop. CANDO establishes a strong baseline on ALPS-Bench and achieves state-of-the-art mIoU and alignment on PubLayNet and RICO with a comparatively lightweight backbone. On PKU-PosterLayout, it obtains the lowest overlap across all five tasks and the highest strict-underlay score in four of five tasks. These results corroborate that cooperative agentic design is a broadly effective recipe for constraint-aware layout synthesis. We hope ALPS-Bench shifts the focus of layout generation research beyond the current regime and toward the operational complexity of real-world design, and that CANDO motivates further work in this direction, positioning cooperative agentic design with tool-grounded verification as a strong recipe for constraint-aware synthesis. Limitations. The proposed ALPS-Bench is built from outdoor service facility layouts, and transferring CANDO to a new domain requires a corresponding design manual and, if ICL is used, a development corpus. The parallel-branching strategy also incurs more (M)LLM calls than single-agent baselines, with a clear performance-cost tradeoff (Table 15). Finally, CANDO does not optimize for distributional similarity, yielding strong mIoU but weaker FID on PubLayNet, RICO, and PKU. Acknowledgments and Disclosure of Funding Acknowledgments. The authors thank Stylianos Poulakakis-Daktylidis (Shell) for his assistance with data curation, as well as Prof. Hamed Pirsiavash (UC Davis) for early insightful discussions. Funding in direct support of this work. This work was funded by Shell. Competing interests. The authors declare no competing interests. References [1] M. Abouagour and E. Garyfallidis (2025) ResPlan: a large-scale vector-graph dataset of 17,000 residential floor plans. arXiv preprint arXiv:2508.14006. Cited by: §1. [2] A. Beirami, A. Agarwal, J. Berant, A. D’Amour, J. Eisenstein, C. Nagpal, and A. T. Suresh (2024) Theoretical guarantees on the best-of-n alignment policy. arXiv preprint arXiv:2401.01879. Cited by: §2. [3] B. Chen, Z. Xu, S. Kirmani, B. Ichter, D. Sadigh, L. Guibas, and F. Xia (2024) Spatialvlm: endowing vision-language models with spatial reasoning capabilities. In Proceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition, p. 14455–14465. Cited by: §2. [4] W. Chen, D. Chi, Y. Liu, Y. Yang, Y. Zhang, Y. Zhuang, X. Quan, J. Hao, G. Li, and L. Lin (2025) AutoLayout: closed-loop layout synthesis via slow-fast collaborative reasoning. arXiv preprint arXiv:2507.04293. Cited by: §2. [5] W. Chen, Y. Su, J. Zuo, C. Yang, C. Yuan, C. Chan, H. Yu, Y. Lu, Y. Hung, C. Qian, et al. (2023) Agentverse: facilitating multi-agent collaboration and exploring emergent behaviors. In The Twelfth International Conference on Learning Representations, Cited by: §2. [6] H. Choset and J. Burdick (1995) Sensor based planning. i. the generalized voronoi graph. In Proceedings of 1995 IEEE international conference on robotics and automation, Vol. 2, p. 1649–1655. Cited by: §4.1. [7] B. Deka, Z. Huang, C. Franzen, J. Hibschman, D. Afergan, Y. Li, J. Nichols, and R. Kumar (2017) Rico: a mobile app dataset for building data-driven design applications. In Proceedings of the 30th annual ACM symposium on user interface software and technology, p. 845–854. Cited by: 2nd item, §1, §2, Table 2, §6. [8] Y. Du, S. Li, A. Torralba, J. B. Tenenbaum, and I. Mordatch (2024) Improving factuality and reasoning in language models through multiagent debate. In Forty-first international conference on machine learning, Cited by: §2. [9] W. Fedus, B. Zoph, and N. Shazeer (2022) Switch transformers: scaling to trillion parameter models with simple and efficient sparsity. Journal of Machine Learning Research 23 (120), p. 1–39. Cited by: §6. [10] W. Feng, W. Zhu, T. Fu, V. Jampani, A. Akula, X. He, S. Basu, X. E. Wang, and W. Y. Wang (2023) Layoutgpt: compositional visual planning and generation with large language models. Advances in Neural Information Processing Systems 36, p. 18225–18250. Cited by: §2. [11] J. Gao, D. Zhou, M. Liang, L. Liu, C. Fu, X. Hu, and P. Heng (2025) DisCo-layout: disentangling and coordinating semantic and physical refinement in a multi-agent framework for 3d indoor layout synthesis. arXiv preprint arXiv:2510.02178. Cited by: §2. [12] J. C. Gower (1975) Generalized procrustes analysis. Psychometrika 40 (1), p. 33–51. Cited by: Remark 1. [13] J. J. A. Guerreiro, N. Inoue, K. Masui, M. Otani, and H. Nakayama (2024) Layoutflow: flow matching for layout generation. In European Conference on Computer Vision, p. 56–72. Cited by: §2. [14] K. Gupta, J. Lazarow, A. Achille, L. S. Davis, V. Mahadevan, and A. Shrivastava (2021) Layouttransformer: layout generation and completion with self-attention. In Proceedings of the IEEE/CVF International Conference on Computer Vision, p. 1004–1014. Cited by: §2. [15] S. Hong, M. Zhuge, J. Chen, X. Zheng, Y. Cheng, J. Wang, C. Zhang, Z. Wang, S. K. S. Yau, Z. Lin, et al. (2023) MetaGPT: meta programming for a multi-agent collaborative framework. In The twelfth international conference on learning representations, Cited by: §2, §5. [16] D. Horita, N. Inoue, K. Kikuchi, K. Yamaguchi, and K. Aizawa (2024) Retrieval-augmented layout transformer for content-aware layout generation. In Proceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition, p. 67–76. Cited by: Table 3, Table 3, §6. [17] H. Y. Hsu, X. He, Y. Peng, H. Kong, and Q. Zhang (2023) Posterlayout: a new benchmark and approach for content-aware visual-textual presentation layout. In Proceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition, p. 6018–6026. Cited by: 3rd item, §1, §2, §6. [18] E. J. Hu, Y. Shen, P. Wallis, Z. Allen-Zhu, Y. Li, S. Wang, L. Wang, and W. Chen (2021) Lora: low-rank adaptation of large language models. arXiv preprint arXiv:2106.09685. Cited by: §E.1, §6. [19] N. Inoue, K. Kikuchi, E. Simo-Serra, M. Otani, and K. Yamaguchi (2023) Layoutdm: discrete diffusion model for controllable layout generation. In Proceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition, p. 10167–10176. Cited by: §E.1, 7th item, §2, Table 1, §6. [20] S. Jayasumana, S. Ramalingam, A. Veit, D. Glasner, A. Chakrabarti, and S. Kumar (2024) Rethinking fid: towards a better evaluation metric for image generation. In Proceedings of the IEEE/CVF conference on computer vision and pattern recognition, p. 9307–9315. Cited by: §6. [21] A. Q. Jiang, A. Sablayrolles, A. Roux, A. Mensch, B. Savary, C. Bamford, D. S. Chaplot, D. d. l. Casas, E. B. Hanna, F. Bressand, et al. (2024) Mixtral of experts. arXiv preprint arXiv:2401.04088. Cited by: §6. [22] Z. Jiang, J. Guo, S. Sun, H. Deng, Z. Wu, V. Mijovic, Z. J. Yang, J. Lou, and D. Zhang (2023) Layoutformer++: conditional graphic layout generation via constraint serialization and decoding space restriction. In Proceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition, p. 18403–18412. Cited by: Table 12, Table 12, Table 12, Table 12, Table 12, §2, Table 2, Table 2, §6. [23] A. A. Jyothi, T. Durand, J. He, L. Sigal, and G. Mori (2019) Layoutvae: stochastic scene layout generation from a label set. In Proceedings of the IEEE/CVF International Conference on Computer Vision, p. 9895–9904. Cited by: §2. [24] A. Kalervo, J. Ylioinas, M. Häikiö, A. Karhu, and J. Kannala (2019) Cubicasa5k: a dataset and an improved multi-task model for floorplan image analysis. In Scandinavian Conference on Image Analysis, p. 28–40. Cited by: §1. [25] K. Kikuchi, E. Simo-Serra, M. Otani, and K. Yamaguchi (2021) Constrained graphic layout generation via latent optimization. In Proceedings of the 29th ACM International Conference on Multimedia, p. 88–96. Cited by: Table 12, Table 2, §6. [26] X. Kong, L. Jiang, H. Chang, H. Zhang, Y. Hao, H. Gong, and I. Essa (2022) Blt: bidirectional layout transformer for controllable layout generation. In European Conference on Computer Vision, p. 474–490. Cited by: Table 12, Table 12, Table 2, Table 2. [27] L. Lara, Z. Luo, A. Milios, A. Sharma, G. Y. Luo, C. Beckham, F. Golemo, and C. Pal (2025) Generative floor plan design with llms via reinforcement learning with verifiable rewards. In UrbanAI: Harnessing Artificial Intelligence for Smart Cities, Cited by: §2. [28] J. Latombe (2012) Robot motion planning. Vol. 124, Springer Science & Business Media. Cited by: §4.1. [29] H. Lee, L. Jiang, I. Essa, P. B. Le, H. Gong, M. Yang, and W. Yang (2020) Neural design network: graphic layout generation with constraints. In European conference on computer vision, p. 491–506. Cited by: §2. [30] G. Li, H. Hammoud, H. Itani, D. Khizbullin, and B. Ghanem (2023) Camel: communicative agents for" mind" exploration of large language model society. Advances in neural information processing systems 36, p. 51991–52008. Cited by: §2, §5. [31] J. Li, J. Yang, A. Hertzmann, J. Zhang, and T. Xu (2019) Layoutgan: generating graphic layouts with wireframe discriminators. arXiv preprint arXiv:1901.06767. Cited by: §2. [32] J. Lin, J. Guo, S. Sun, Z. Yang, J. Lou, and D. Zhang (2023) Layoutprompter: awaken the design ability of large language models. Advances in Neural Information Processing Systems 36, p. 43852–43879. Cited by: Table 12, Table 12, Table 12, Table 12, Table 12, §2, Table 1, Table 2, Table 2, §6, §6. [33] Z. Liu, L. Wang, S. Zhou, Y. Wu, X. Sun, G. Hua, and H. Li (2026) UniLayDiff: a unified diffusion transformer for content-aware layout generation. In Proceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition, p. 4668–4677. Cited by: Table 3, Table 3, §6. [34] A. Madaan, N. Tandon, P. Gupta, S. Hallinan, L. Gao, S. Wiegreffe, U. Alon, N. Dziri, S. Prabhumoye, Y. Yang, et al. (2023) Self-refine: iterative refinement with self-feedback. Advances in neural information processing systems 36, p. 46534–46594. Cited by: §2. [35] N. Nauata, S. Hosseini, K. Chang, H. Chu, C. Cheng, and Y. Furukawa (2021) House-gan++: generative adversarial layout refinement network towards intelligent computational agent for professional architects. In Proceedings of the IEEE/CVF conference on computer vision and pattern recognition, p. 13632–13641. Cited by: §2. [36] C. Packer, S. Wooders, K. Lin, V. Fang, S. G. Patil, I. Stoica, and J. E. Gonzalez (2024) MemGPT: towards llms as operating systems. External Links: 2310.08560, Link Cited by: §2. [37] J. S. Park, J. O’Brien, C. J. Cai, M. R. Morris, P. Liang, and M. S. Bernstein (2023) Generative agents: interactive simulacra of human behavior. In Proceedings of the 36th annual acm symposium on user interface software and technology, p. 1–22. Cited by: §2. [38] D. Paschalidou, A. Kar, M. Shugrina, K. Kreis, A. Geiger, and S. Fidler (2021) Atiss: autoregressive transformers for indoor scene synthesis. Advances in neural information processing systems 34, p. 12013–12026. Cited by: §2. [39] B. Pfitzmann, C. Auer, M. Dolfi, A. S. Nassar, and P. Staar (2022) Doclaynet: a large human-annotated dataset for document-layout segmentation. In Proceedings of the 28th ACM SIGKDD conference on knowledge discovery and data mining, p. 3743–3751. Cited by: §1. [40] Qwen Team (2026) Qwen3.6-35B-A3B: agentic coding power, now open to all. External Links: Link Cited by: 4th item, §6. [41] T. Schick, J. Dwivedi-Yu, R. Dessì, R. Raileanu, M. Lomeli, E. Hambro, L. Zettlemoyer, N. Cancedda, and T. Scialom (2023) Toolformer: language models can teach themselves to use tools. Advances in neural information processing systems 36, p. 68539–68551. Cited by: §2. [42] J. Seol, S. Kim, and J. Yoo (2024) Posterllama: bridging design ability of language model to content-aware layout generation. In European Conference on Computer Vision, p. 451–468. Cited by: §2. [43] M. A. Shabani, S. Hosseini, and Y. Furukawa (2023) Housediffusion: vector floorplan generation via a diffusion model with discrete and continuous denoising. In Proceedings of the IEEE/CVF conference on computer vision and pattern recognition, p. 5466–5475. Cited by: §2. [44] H. Shi, J. Su, T. Han, J. Luo, and J. Gao (2025) Layoutcot: unleashing the deep reasoning potential of large language models for layout generation. arXiv preprint arXiv:2504.10829. Cited by: Table 12, Table 12, Table 12, Table 12, Table 12, 8th item, §2, Table 1, Table 2, Table 2, §6, §6. [45] N. Shinn, F. Cassano, A. Gopinath, K. Narasimhan, and S. Yao (2023) Reflexion: language agents with verbal reinforcement learning. Advances in neural information processing systems 36, p. 8634–8652. Cited by: §2. [46] A. Singh, S. Mukherjee, A. Beirami, and H. Jamali-Rad (2025) Code: blockwise control for denoising diffusion models. arXiv preprint arXiv:2502.00968. Cited by: §2, §5, §5, §6, §6. [47] J. Tang, Y. Nie, L. Markhasin, A. Dai, J. Thies, and M. Nießner (2024) Diffuscene: denoising diffusion models for generative indoor scene synthesis. In Proceedings of the IEEE/CVF conference on computer vision and pattern recognition, p. 20507–20518. Cited by: §2. [48] Z. Tang, C. Wu, J. Li, and N. Duan (2023) Layoutnuwa: revealing the hidden layout expertise of large language models. arXiv preprint arXiv:2309.09506. Cited by: §2. [49] C. Van Engelenburg, F. Mostafavi, E. Kuhn, Y. Jeon, M. Franzen, M. Standfest, J. van Gemert, and S. Khademi (2024) Msd: a benchmark dataset for floor plan generation of building complexes. In European Conference on Computer Vision, p. 60–75. Cited by: §1. [50] J. Wang, W. Jue, B. Athiwaratkun, C. Zhang, and J. Zou (2024) Mixture-of-agents enhances large language model capabilities. In The Thirteenth International Conference on Learning Representations, Cited by: §5. [51] I. White, K. Nottingham, M. Robinson, A. P. Maniar, M. Maheshwari, H. Lillemark, L. Qin, and P. Ammanabrolu (2025) Blocks, bots, and bottlenecks: studying real-time and adaptive multi-agent llm collaboration. In NeurIPS 2025 Workshop on Bridging Language, Agent, and World Models for Reasoning and Planning, Cited by: §2. [52] J. Wu, S. Wang, S. Shen, Y. Peng, J. Nichols, and J. P. Bigham (2023) Webui: a dataset for enhancing visual ui understanding with web semantics. In Proceedings of the 2023 CHI Conference on Human Factors in Computing Systems, p. 1–14. Cited by: §1. [53] Q. Wu, G. Bansal, J. Zhang, Y. Wu, B. Li, E. Zhu, L. Jiang, X. Zhang, S. Zhang, J. Liu, et al. (2024) Autogen: enabling next-gen llm applications via multi-agent conversations. In First conference on language modeling, Cited by: §2, §5. [54] W. Wu, X. Fu, R. Tang, Y. Wang, Y. Qi, and L. Liu (2019) Data-driven interior plan generation for residential buildings. ACM Transactions on Graphics (TOG) 38 (6), p. 1–12. Cited by: §1. [55] W. Xu, Z. Liang, K. Mei, H. Gao, J. Tan, and Y. Zhang (2025) A-mem: agentic memory for llm agents. arXiv preprint arXiv:2502.12110. Cited by: §2. [56] Y. Yamada, Y. Bao, A. K. Lampinen, J. Kasai, and I. Yildirim (2023) Evaluating spatial understanding of large language models. arXiv preprint arXiv:2310.14540. Cited by: §5. [57] A. Yang, A. Li, B. Yang, B. Zhang, B. Hui, B. Zheng, B. Yu, C. Gao, C. Huang, C. Lv, C. Zheng, D. Liu, F. Zhou, F. Huang, F. Hu, H. Ge, H. Wei, H. Lin, J. Tang, J. Yang, J. Tu, J. Zhang, J. Yang, J. Yang, J. Zhou, J. Zhou, J. Lin, K. Dang, K. Bao, K. Yang, L. Yu, L. Deng, M. Li, M. Xue, M. Li, P. Zhang, P. Wang, Q. Zhu, R. Men, R. Gao, S. Liu, S. Luo, T. Li, T. Tang, W. Yin, X. Ren, X. Wang, X. Zhang, X. Ren, Y. Fan, Y. Su, Y. Zhang, Y. Zhang, Y. Wan, Y. Liu, Z. Wang, Z. Cui, Z. Zhang, Z. Zhou, and Z. Qiu (2025) Qwen3 technical report. External Links: 2505.09388, Link Cited by: §E.1, 6th item, §6. [58] S. Yao, J. Zhao, D. Yu, N. Du, I. Shafran, K. Narasimhan, and Y. Cao (2022) React: synergizing reasoning and acting in language models. arXiv preprint arXiv:2210.03629. Cited by: §2. [59] X. Zhong, J. Tang, and A. J. Yepes (2019) Publaynet: largest dataset ever for document layout analysis. In 2019 International conference on document analysis and recognition (ICDAR), p. 1015–1022. Cited by: 1st item, §1, §2, Table 2, §6. Appendix A Broader Impact We do hope that the ALPS-Bench shifts the focus of layout generation research beyond the current regime and toward the operational complexity of real-world design, and that CANDO motivates further work in this direction, positioning cooperative agentic design with tool-grounded verification as a strong recipe for constraint-aware synthesis. The proposed framework operates on geometric layout representations derived from professional CAD drawings and does not process personal data, photographs, or any content tied to individuals. The introduced ALPS-Bench dataset consists solely of anonymized site geometries and does not contain identifying information about facility operators or locations. We are not aware of a direct path to harmful applications. The framework generates two-dimensional element placements for operational sites and has no generative capability in domains such as media synthesis or surveillance. A secondary consideration is automation-induced risk in safety-critical design. While CANDO is intended as a decision-support tool rather than a replacement for human review, its outputs could, in principle, be adopted with insufficient expert oversight. We emphasize that the routing feasibility checks implemented in the Verifier and Evaluation Protocol are conservative by design (inflated obstacle margins, strict no-backtracking rules), and that final layouts should always be reviewed by a qualified engineer before deployment. Appendix B Limitations Domain scope of ALPS-Bench. The benchmark is constructed from outdoor automotive service facility layouts. Although the problem formulation in Section 3 is domain-agnostic, the design manual ℳM, the routing scenarios in Appendix D.5, and the 14-class element vocabulary are all specific to this setting. Transferring CANDO to a new domain requires authoring a corresponding design manual and, if ICL initialization is used, a development corpus of annotated examples. Computational Cost. The parallel-branching strategy of CANDO with N, B, and K incurs more LLM calls per layout than Single-Agent or LayoutPrompter baselines. The ablation in Table 15 shows a clear performance–cost tradeoff: the highest-scoring configuration is also the most expensive. Deployment in resource-constrained settings may require reducing N, B, or K at some cost to layout quality. FID and Distributional Evaluation. CANDO does not optimize for distributional similarity to training data. As discussed in Section 6, this leads to state-of-the-art performance in mIoU and alignment scores on PubLayNet and RICO, but inconsistent FID rankings. Researchers whose evaluation protocol weights FID heavily should treat these results with the caveats noted in Section 1. Appendix C Notation Table 5 summarizes all mathematical symbols used throughout the paper, grouped by the section in which they are introduced. Table 5: Summary of mathematical notation used throughout the paper. Symbol Description Layout domain (Section 3) C Vocabulary of semantic element classes. E Number of elements to be placed. A Set of designated entrance and exit access regions. ℰ=(ci,Gi)i=1EE=\(c_i,\,G_i)\_i=1^E Full element specification (fixed input). Gi⊂ℝ2G_i ^2 Canonical (fixed) shape of element i, centered at the origin. ⊂ℝ2P ^2 Layout Premise – the outer boundary polygon. Q Space of all possible configurations. valid⊂Q_valid Subset of configurations satisfying all hard constraints. R(θi)R( _i) 2×22×2 rotation matrix for angle θi _i. ci∈c_i Semantic class of element i. ei=(ci,Gi)e_i=(c_i,\,G_i) Element i, with semantic class cic_i and canonical shape GiG_i. i=(xi,yi)∈ℝ2p_i=(x_i,\,y_i) ^2 Centroid of placed element i (optimization variable). =(i,θi)i=1Eq=\(p_i, _i)\_i=1^E Elements configuration – the full set of placement parameters. Ωi(i,θi)=R(θi)Gi+i _i(p_i, _i)=R( _i)\,G_i+p_i Placed geometry of element i after rotation and translation. θi∈[0,2π) _i∈[0,2π) Orientation angle of element i (optimization variable). Constraints & objective (Section 3) ℋHC Hard constraints (containment, non-overlap, routing feasibility). ℐ=(,,ℰ,ℳ)I=(P,\,A,\,E,\,M) Problem instance. ()=∑s=1Swsfs()J(q)= _s=1^Sw_s\,f_s(q) Weighted soft-constraint objective. ℳ=ℋ,M=\HC,\,SC\ Design manual, partitioned into hard and soft constraints. r()O_r(q) Set of ground-plane elements that block traversal in routing scenario r. ℛR Set of predefined routing scenarios. ℱr()F_r(q) Scenario-specific free space ∖⋃i∈r()ΩiP _i _r(q) _i. S=||S=|SC| Number of soft constraints. SC Soft constraints (compositionality, orientation, proximity). fs()∈[0,1]f_s(q)∈[0,1] Scoring function measuring compliance with soft constraint s. ⋆q Optimal (highest-scoring) configuration. wsw_s Weight for soft constraint s; ∑s=1Sws=1 _s=1^Sw_s=1. Dataset & evaluation metrics (Section 4) AGGAGG Aggregate score =(CS+RE)/2=(CS+RE)/2. CO Compositionality score ∈[0,1]∈[0,1]. CSCS Constraint satisfaction score defined in Eq. (3). devD dev Development set (900 annotated instances). testD test Held-out test set (100 instances). HCfHC_f Flow score: fraction of routing scenarios with a feasible path. HCgHC_g Geometric hard-constraint score penalising out-of-boundary and overlap areas. HCMHCM Hard constraints metric: 00 if elements are missing or incorrectly sized; otherwise αgHCg+αfHCf _gHC_g+ _fHC_f. αg,αf _g, _f Geometric-validity and flow weights in HCMHCM, respectively; (αg,αf)=(0.2,0.8)( _g, _f)=(0.2,0.8). MN Maneuverability sub-score ∈[0,1]∈[0,1] (=n¯gt/(n¯gt+n¯gen)= n_gt/( n_gt+ n_gen)). OR Orientation score ∈[0,1]∈[0,1]. PC Path clearance sub-score ∈[0,1]∈[0,1] (=c¯gen/(c¯gt+c¯gen)= c_gen/( c_gt+ c_gen)). PL Path length sub-score ∈[0,1]∈[0,1] (=ℓ¯gt/(ℓ¯gt+ℓ¯gen)= _gt/( _gt+ _gen)). PR Proximity score ∈[0,1]∈[0,1]. RERE Routing Efficiency =(PL+MN+PC)/3=( PL+ MN+ PC)/3. SCMSCM Soft constraints metric =αpPR+αcCO+αoOR= _pPR+ _cCO+ _oOR. αp,αc,αo _p, _c, _o Proximity, compositionality, and orientation weights in SCMSCM, respectively; (αp,αc,αo)=(0.6,0.3,0.1)( _p, _c, _o)=(0.6,0.3,0.1). α Penalty cap for invalid layouts in CSCS; α=0.5α=0.5. c¯ c Mean minimum path clearance over routing scenarios. ℓ¯ Mean path length over routing scenarios. n¯ n Mean number of turns over routing scenarios. (⋅)gt,(⋅)gen(·)_gt,(·)_gen Quantity measured for the ground-truth or generated layout, respectively. †q Ground-truth configuration. ϵε Scenario-dependent obstacle-inflation safety margin (Voronoi planning). CANDO framework (Section 5) B Block size: number of sequential Planner–Generator–Verifier steps per branch. BtB_t Number of steps in the current block, min(B,T−t) (B,T-t). b Within-block step offset, b∈0,…,Bt−1b∈\0,…,B_t-1\. ℱ(t),ℱn(t)F^(t),F_n^(t) Structured feedback report for the selected global state or branch n at step t. Δℱ(t) ^(t) Change in feedback at step t, annotated with the spatial changes that produced it. ℋ(t),ℋn(t)H^(t),H_n^(t) Sliding-window history for the selected global state or branch n at step t. ℐnewI_new Query (target) problem instance presented to CANDO. K Number of candidate configurations produced by the Generator per step. KinitK_init Number of candidate layouts generated by the ICL Initializer. N Number of parallel exploration branches per outer round. (t),n(t)Q^(t),Q_n^(t) Set of K candidate configurations generated globally or for branch n at step t. T Maximum total number of optimization steps. Vout()V_out(q) Out-of-premise area summed over elements and normalized by |||P|. Vov()V_ov(q) Unique-pair overlap area summed over i<ji<j and normalized by |||P|. W History sliding window size. (0)q^(0) Initial seed configuration produced by the ICL Initializer. ¯(t) q^(t) Best-scoring candidate configuration selected at step t. n(t)q_n^(t) Configuration of branch n at inner step t. t Optimization step index. Π(t),Πn(t) ^(t), _n^(t) Remediation plan produced globally or for branch n at step t. σ()σ(q) Hard-constraint proxy feasibility score (Eq. 4). τ Time complexity unit corresponding to a single LLM call. ϕ(ℐ)∈ℝdφ(I) ^d d-dimensional feature embedding of instance ℐI used for exemplar retrieval. Appendix D Asset Layout Planning and Synthesis (ALPS) Benchmark D.1 Data Provenance and Annotation Process ALPS-Bench is derived from real operational assets supplied by an industrial setting and was not collected online. An external annotation company assigned approximately 2020 professional annotators under a dedicated project manager. Annotation took place over five weeks, with weekly review sessions in which two domain experts from the asset-design team inspected and refined the annotations over multiple rounds. Only anonymized site geometries are released. D.2 Annotation Format Annotations are stored in JSON Lines format, one record per layout, each containing a unique identifier and a list of element records. Every element specifies a class label and a polygon attribute as an ordered list of ℝ2R^2 coordinate pairs in meters, consistent with the formulation in Eq. (1). The site premise is stored as an element of its own class. D.3 Dataset Statistics We compute descriptive statistics over all 1,0001,000 canonical layouts in the development and test sets. Every canonical layout has a valid boundary polygon and a paired constraint record. Site premise areas |i||P_i| range from 390.33390.33 to 19,358.8219,358.82 m2 (mean 3,228.403,228.40 m2; median 2,705.122,705.12 m2). Excluding the premise record, layouts contain 77–101101 polygon annotations (mean 22.7522.75; median 2121). Surface complexity. We characterize surface complexity using two properties: the number of polygon annotations on the surface and the fraction of the premise area they cover. Access regions are included, while the premise boundary and Underground Service Facility are excluded because they do not represent occupied surface facilities. We rank layouts separately by annotation count and covered area, then combine the two ranks with equal weight into a score from 00 to 100100. This allows annotation count and spatial coverage to contribute equally despite using different units. The median surface utilization is 17.5%17.5\%, and the median complexity score is 48.748.7. Figure 4 shows that layouts may be complex because they contain many surface annotations, cover a large portion of the premise, or both. Figure 4: Complexity statistics for ALPS-Bench. Left: Distribution of the surface complexity score. Right: Its two components, surface-annotation count and surface utilization; dotted lines mark their medians. Darker shades indicate greater complexity in both panels. Class distribution. The benchmark exhibits a common operational core: Underground Service Facility, Entrance, and Exit occur in every layout, followed by Underground Access Point (99.9%99.9\%), Shop (99.7%99.7\%), Car Service Area (99.5%99.5\%), and Car Parking (95.5%95.5\%). Specialized infrastructure is intentionally less frequent: EV Service Area occurs in 26.2%26.2\% of layouts, Priority Parking in 15.8%15.8\%, Bike Parking in 15.4%15.4\%, HGV Parking in 13.8%13.8\%, HGV Service Area in 10.2%10.2\%, and Bike Service Area in 8.6%8.6\%. Figure 5 reports both class coverage and mean within-layout multiplicity conditional on presence, separating optional capabilities from frequently replicated facilities such as parking. Figure 5: Class distribution in ALPS-Bench. Left: Fraction of layouts containing each class. Right: Mean number of instances among layouts in which the class is present. The premise record is omitted. D.4 Design Manual As discussed in Section 3 the design manual ℳM covers two sets of desired specifications, the Hard (ℋHC) and Soft (SC) constraints. Let us delve deeper into the underlying rules. Table 6: Evaluated routing sequences per vehicle type. All routes implicitly begin at any Entrance and terminate at any Exit. Vehicle type Intermediate Waypoint Sequence Car Car Service Area Car Service Area → Car Parking Car Service Area → Priority Parking Car Parking EV Service Area Bike Bike Service Area Bike Service Area → Bike Parking Bike Parking Heavy Goods Vehicle (HGV) HGV Service Area HGV Service Area → HGV Parking HGV Parking D.4.1 Hard Constraints As established in the problem formulation (Section 3) and dataset characteristics (Section 4), valid layouts must comprehensively satisfy fundamental geometric rules. All placed elements must be fully contained within the layout premise P (containment), and no two placed elements may overlap in their occupied area (non-overlap). Furthermore, the quantities of elements generated must strictly match the problem instance specifications. Regarding routing feasibility (HCfHC_f), we enforce strict flow requirements to guarantee collision-free maneuverability across the premises. We outline the specifics of these requirements in the preceding and subsequent sections (see Appendix D.5 and Appendix D.6). D.4.2 Soft Constraints We distill the operational and aesthetic guidelines of the ALPS-Bench domain into a structured set of soft constraints (SC) that evaluate the structural organization and practical usability of the generated layouts. These are mathematically evaluated as continuous sub-objectives across three central pillars: Compositionality, Proximity, and Orientation. Table 7 offers a breakdown summarizing the parameters governing the soft constraints. Compositionality. The Compositionality dimension ensures that multiple instances of identical semantic classes assemble into contiguous, coherent functional zones rather than fragmenting randomly across the layout premise. This is enforced through three foundational parameters: spatial clustering distance thresholds, average group size expectations, and structural arrangement patterns. The Average Group Size acts as a normalization factor to penalize overly fragmented layouts. For example, if the required average group size for Car Service Area is 44, distributing 88 units into one group of 88 arrays, or two hubs of 44, yields high compliance, whereas scattering them across 88 separate 11-unit islands triggers heavy structural penalties. Furthermore, clustered elements must configure themselves according to pre-defined geometric patterns. For classes designated as adhering to Rectangular or Single Line topologies, the expected formation dynamic is dictated by the total element count parity within the cluster. Specifically, if the cluster contains an odd number of elements (e.g., 55 units), they must conform strictly to a continuous 1×51× 5 or 5×15× 1 linear vector grid. Conversely, if the group consists of an even number of elements, the system robustly prefers grid-like rectangular blocks to maximize space utilization compactness (e.g., configuring 44 units into a dense 2×22× 2 matrix instead of a 1×41× 4 strip, or 66 instances into a 2×32× 3 or 3×23× 2 block). Proximity and Clearances. These dictate topological positioning (e.g., shop structures and bike/hgv parking favoring placement immediately proximally adjacent to, or geometrically stacked against, the outer layout polygon boundary), direct functional bounding (e.g., car parking consistently stacking its shorter geometric edge against the perimeter of a shop), and global distance isolation to mitigate interference (e.g., isolating noisy hgv service areas away from general car/bike service areas using a hard 6.06.0m buffer). Most critically, to guarantee navigational flow, elements such as active parking bays require Clearance Zones; stacked structures must maintain an unoccluded outward minimum 180∘180 radius scaling to a 3.03.0m margin directly abutting the unstacked exit edge, preventing vehicles from being trapped after docking. Orientation. Elements aggregated within a unified spatial group are strictly evaluated for their internal angular agreement. Once a baseline rotational vector is established for a composite functional zone, all adjacent sister elements contributing to that zone must independently match it, either by situating strictly parallel (0∘,180∘0 ,180 ) or perpendicular (90∘,270∘90 ,270 ) to one another axis, capped by a rigid error tolerance threshold of precisely 5∘5 . Table 7: Comprehensive breakdown of SC Constraint Type Rule Specification Compositionality Rectangular Blocks / Single Line car service area (group size 4, distance tolerance up to 3.0 m), bike service area (group size 2, distance tolerance up to 3.0 m), and underground service facility (group size 2, distance tolerance up to 1.0 m). Odd counts format to primary lines; even counts format to dense multi-axis grids (for example, 2 by 2, or 2 by 3 blocks). Strict Single Line car parking (group size 3, tolerance up to 0.5 m), bike parking (size 4, tolerance up to 0.5 m), hgv service area (size 2, tolerance up to 10.0 m), priority parking (size 2, tolerance up to 1.0 m), ev service area (any size). Proximity and Clearances Boundary Stacking underground access point (longer edge), bike parking, hgv parking, and shop (longer edge) are ideally stacked against or placed proximally adjacent to the layout polygon. Element Stacking car parking (shorter edge) and priority parking must uniformly stack against the shop. priority parking must also remain placed closest to the entrance. Egress Clearances All parked vehicles (car parking, bike parking, hgv parking, priority parking, and ev service area) necessitate a strictly maintained 3.0 m outward 180 degree maneuvering clearance from their unstacked active exit edge. Adjacency & Distances hgv service area enforces isolated minimum distances of 6.0 m away from car service area and bike service area. Every distinct service area hub strictly requires at least one underground service facility to be proximally adjacent within 5.0 m to 10.0 m. Orientation Angular Alignment Elements constituting a unified spatial group must exhibit strict orientational coherence, aligning parallel or perpendicular to one another within a narrow angular tolerance margin of 5 degrees. D.5 Routing Scenarios Table 8: Average vehicle dimensions. Vehicle Length (m) Width (m) Car 4.5 1.8 Bike 2.0 0.75 HGV 16.5 2.55 To thoroughly evaluate the operational accessibility and flow of the generated layouts, we define a comprehensive set of routing scenarios across three distinct vehicle types: Cars, Bikes, and Heavy Goods Vehicles (HGVs). Each vehicle type requires a specific minimum path clearance corresponding to its physical dimensions (detailed in Table 8) to ensure collision-free navigation. A valid routing scenario requires the vehicle to start at any element classified as an entrance, navigate sequentially through a defined list of intermediate facility waypoints, and successfully reach any exit element. Table 6 details the exhaustive list of specific waypoint sequences evaluated for each vehicle type. D.6 Voronoi-Based Motion Planning Evaluation Our approach breaks the complex task of navigating a layout into four systematic steps, as illustrated in Figure 6. First, we establish the initial layout premise for a given scenario (Step 1). Next, we define the free space by inflating all elements that are not part of the scenario (and thus considered obstacles) by a safety margin ϵε, with the value dependent on the vehicle size from Table 8. To discretize this continuous margin and map out the available driving area, we sample seed points uniformly across the boundaries of the obstacles (Step 2). This ensures any generated path naturally avoids collisions. We then compute a Voronoi diagram over these points, extracting a medial axis graph (Step 3). This effectively creates a path of maximum clearance from nearby obstacles that runs exactly down the middle of the available corridors. Finally, we map the start and destination coordinates onto this graph and run a shortest-path search to find a smooth and reliable route through the site (Step 4). Figure 6: Step-by-step illustration of CANDO’s motion planning tool. Additionally, the motion planning evaluation enforces two specific domain-aware constraints: • Underground Facilities: Elements classified as underground service facility are assumed to be located below the surface level. Consequently, they are excluded from the scenario-specific obstacle set r()O_r(q) and do not obstruct the free space ℱr()F_r(q). • No-Backtracking Constraints: For critical operational nodes (car service area, bike service area, and hgv service area), vehicles are strictly prohibited from reversing out the way they entered. They must follow a continuous drive-through trajectory. The only exception occurs if the service area is fully stacked against a site boundary segment, in which case the natural drive-through is constrained by the perimeter. Appendix E Experiments E.1 Trained ALPS-Bench Baselines LayoutDM. We trained LayoutDM [19] from scratch on the ALPS-Bench development set using one H100 GPU, 32 GB of host RAM, and a runtime budget of up to 48 hours. We retained its constrained discrete-diffusion formulation, using 100 diffusion steps and k-means quantization. Because LayoutDM natively represents axis-aligned page elements as (x,y,w,h)(x,y,w,h), we converted each element polygon to a normalized oriented bounding box in the coordinate frame of its site boundary and extended the token sequence to (c,w,h,x,y,o)(c,w,h,x,y,o), where o denotes element orientation. The site boundary and Entrance/Exit elements are placed first in the sequence as fixed context and masked from the prediction loss; orientation loss is also masked for geometrically ambiguous, near-square elements. This adaptation generalizes the tokenizer, diffusion transitions, coordinate clustering, and data pipeline to the orientation variable while retaining the original FID pathway over (x,y,w,h)(x,y,w,h). Consequently, FID remains comparable to the original implementation but does not evaluate orientation. As the oriented-box representation only approximates the true polygonal geometry, generated placements may still cross the site boundary or overlap, explaining LayoutDM’s low geometric constraint satisfaction. Qwen-LoRA-ALPS. We fine-tuned Qwen3-VL-8B-Instruct [57] on the ALPS-Bench development set using parameter-efficient LoRA SFT [18] on one H100 GPU. The base vision encoder, multi-modal projector, and language-model weights remained frozen, while LoRA adapters with rank 8, scaling factor 16, and dropout 0.05 were trained for 30 steps with per-device batch size 1, a cosine-decayed learning rate of ×10−55\!×\!10^-5, BF16/TF32 precision, and gradient checkpointing. The maximum input sequence length was 8,192 tokens. Each input combines a rendering of the site boundary and access points with structured element requirements, and the target contains all element polygons in a single response. This setup captures high-level composition and orientation patterns but provides no iterative mechanism for repairing containment, non-overlap, or routing violations. E.2 Simplified CANDO for Public Benchmarks All public-benchmark experiments use Qwen3.6-35B-A3B-FP8 (thinking disabled) for every agent role without task-specific fine-tuning. The model is served through OpenAI-compatible vLLM replicas, each hosted on one H100-80GB GPU. The task-aware ICL Initializer retrieves 88 training-set exemplars and samples 1010 initial layouts, retrying an invalid batch at most three times. Valid layouts are ranked using weights 0.20.2, 0.20.2, and 0.60.6 for alignment, overlap, and dissimilarity from development layouts, respectively. The simplified pipeline retains the Verifier, Planner, Generator, and Historian, but replaces ALPS-specific routing and compositionality workers with benchmark-specific checks. At each refinement step, deterministic workers evaluate hard constraints, alignment/assembly, and proximity; the Generator samples K=8K=8 candidate action sequences from seven diverse repair strategies. PubLayNet and RICO use N=4N=4 parallel branches, B=5B=5 steps per branch, a maximum of T=10T=10 iterations, local patience of 33, global plateau patience of 66, and a history window of W=9W=9. Their Verifier categories are weighted uniformly, while Planner guidance weights hard constraints, assembly, and proximity by 0.40.4, 0.40.4, and 0.20.2. PubLayNet additionally uses an LLM-based element-role and single-/double-column classifier, whereas RICO uses its element classes directly. PKU-PosterLayout uses the same settings except for N=2N=2 branches. It adds multi-modal content-Verifier and content-Planner agents that inspect the generated layout overlaid on the in-painted poster and saliency map. The original composed poster is excluded to prevent target-layout leakage. Hard constraints, content, assembly, and proximity receive Verifier weights 0.250.25, 0.500.50, 0.250.25, and 0.000.00, respectively, and compliance-based termination requires a content score of at least 0.80.8. Its strategy library replaces the proximity-only strategy with a content-only strategy. Table 9: Refinement configuration of simplified CANDO on public benchmarks. Hyperparameter PubLayNet RICO PKU-PosterLayout Retrieved exemplars 88 88 88 Initial layouts 1010 1010 1010 Branches N 44 44 22 Steps per branch B 55 55 55 Candidates per step K 88 88 88 Maximum iterations T 1010 1010 1010 Local / global patience 33 / 66 33 / 66 33 / 66 History window W 99 99 99 Evaluation protocol. PubLayNet and RICO are evaluated once per sample on their complete test splits, comprising 10,99810,998 and 3,7293,729 trials per task, respectively. We report maximum layout similarity (mIoU), alignment, overlap, and LayoutNet FID with dataset-specific checkpoints. Following prior RICO implementations, overlap excludes the Card, Background, and Modal classes because they function as containers or backgrounds. PKU-PosterLayout uses 1,0001,000 test samples per task and the RALF protocol: occlusion, unreadability, strict underlay effectiveness, non-underlay overlay, and FIDNetV3 FID. Following the official protocol, elements with normalized area at most 0.0010.001 are discarded before evaluation, and FID uses the official pku10 checkpoint. E.3 Compute Resources and Latency The ALPS-Bench Qwen experiments used eight NVIDIA H100 GPUs (80 GB VRAM each), with one Qwen3.6-35B-A3B-FP8 vLLM replica per GPU and 24 concurrent evaluation workers. The GPT-5.2 experiments used the Azure OpenAI API and no local GPUs. The Single-Agent and CANDO CoDe evaluations used 100 concurrent workers, whereas CANDO BoN used 50. LayoutPrompter used the same API infrastructure as the other GPT-5.2 experiments. Results reported in Table 10 distinguish per-trial latency, the elapsed time from the start to completion of an individual layout under concurrent load, from batch wall time, the makespan of the parallel evaluation over the 100 layouts in testD test. The effective time per layout corresponds to amortized throughput. For local experiments, GPU-hours are computed as the batch wall time multiplied by the number of allocated GPUs. Per-trial durations must therefore not be summed when trials overlap. All latency measurements were collected under concurrent load rather than as isolated single-request measurements. Table 10: Compute resources and latency for final ALPS-Bench test-set evaluations. Mean trial latency is reported as mean ± standard deviation. Effective time per layout measures throughput, whereas trial latency measures the end-to-end duration of an individual trial under concurrent load. Method Compute Mean trial latency Median Batch wall time Effective time/layout Single-Agent (GPT-5.2) Cloud API 10.49±5.8310.49± 5.83 h 12.4212.42 h 20.2020.20 h ∼ 12 min 07 s CANDO (BoN/GPT-5.2) Cloud API 47.12±39.3447.12± 39.34 min 33.5133.51 min 2.502.50 h ∼ 1 min 30 s CANDO (CoDe/GPT-5.2) Cloud API 42.75±36.3442.75± 36.34 min 29.4229.42 min 2.392.39 h ∼ 1 min 26 s CANDO (CoDe/Qwen) 8×H100 (80 GB) 2.86±1.732.86± 1.73 h 2.672.67 h 16.716.7 h ∼ 10 min 02 s Note that the totals in Table 10 cover only the final 100-layout ALPS-Bench test evaluations. The broader research effort also included component and hyperparameter ablation trials, reported in Tables 4 and 15, which we estimate consumed approximately 2,5002,500 allocated H100 GPU-hours. Table 11: Median per-sample response time of CANDO on the PubLayNet, RICO, and PKU-PosterLayout public benchmarks. Results were measured in isolated runs (single-sample inference, diagnostics disabled) and do not include graph loading overhead. Task PubLayNet RICO PKU Gen-T 104.8 s 66.8 s 46.8 s Gen-TS 125.7 s 137.4 s 111.4 s Gen-R 166.1 s 74.7 s 102.9 s Completion 65.4 s 31.1 s 18.0 s Refinement 71.8 s 54.1 s 39.3 s For PubLayNet, RICO, and PKU-PosterLayout, end-to-end latency is measured per sample from initial generation through all candidate evaluations, Verifier calls, and refinement steps. Measurements were obtained in isolated benchmarking runs processing one sample at a time (from a randomly selected subset of 5050 samples per task), with diagnostics disabled. Reported latencies exclude graph loading overhead. Table 11 reports median latency. We cannot provide matched latency for the competing methods because their reported results were not reproduced in our environment and their original papers do not report elapsed time. E.4 Additional Results on PubLayNet and RICO Table 12 extends the evaluation in Section 6, reporting performance on the Layout Relationship Generation (Gen-R), Layout Completion (Comp.), and Layout Refinement (Refine) tasks for both the PubLayNet and RICO benchmarks. Table 12: Quantitative results on the PubLayNet and RICO datasets for Type Generation, Type-Size Generation, Relationship Generation (Gen-R), Completion (Comp.), and Refinement (Refine) tasks. RICO PubLayNet Task Method mIoU↑ FID↓ Align↓ Over↓ mIoU↑ FID↓ Align↓ Over↓ Gen-T LayoutGAN++ [25] 0.298 5.954 0.261 0.620 0.297 14.875 0.124 0.148 BLT [26] 0.216 25.633 0.150 0.983 0.140 38.684 0.036 0.196 LayoutFormer++ [22] 0.432 1.096 0.230 0.530 0.348 8.411 0.020 0.008 LayoutPrompter [32] 0.604 2.134 0.002 0.029 0.619 1.648 0.001 0.004 LayoutCoT [44] 0.719 2.189 0.001 0.022 0.772 1.227 0.000 0.002 CANDO (ours) 0.866 2.101 0.000 0.005 0.893 3.455 0.000 0.000 Gen-TS BLT [26] 0.604 0.951 0.181 0.660 0.428 7.914 0.021 0.419 LayoutFormer++ [22] 0.620 0.757 0.202 0.542 0.471 0.720 0.024 0.037 LayoutPrompter [32] 0.707 3.072 0.002 0.051 0.727 1.863 0.001 0.076 LayoutCoT [44] 0.795 3.506 0.000 0.031 0.847 1.430 0.000 0.004 CANDO (ours) 0.879 1.371 0.000 0.052 0.881 2.023 0.000 0.000 Gen-R LayoutFormer++ [22] 0.424 5.972 0.332 0.537 0.353 4.954 0.025 0.076 LayoutPrompter [32] 0.583 2.249 0.001 0.044 0.627 2.224 0.001 0.011 LayoutCoT [44] 0.725 3.569 0.001 0.015 0.769 1.408 0.001 0.002 CANDO (ours) 0.844 2.674 0.000 0.009 0.855 9.614 0.000 0.002 Comp. LayoutFormer++ [22] 0.732 4.574 0.077 0.487 0.471 10.25 0.020 0.002 LayoutPrompter [32] 0.541 2.656 0.001 0.041 0.754 1.282 0.001 0.001 LayoutCoT [44] 0.716 2.112 0.001 0.012 0.770 0.531 0.000 0.001 CANDO (ours) 0.894 1.717 0.000 0.002 0.912 1.904 0.000 0.000 Refine LayoutFormer++ [22] 0.816 0.032 0.123 0.489 0.785 0.086 0.024 0.006 LayoutPrompter [32] 0.874 0.225 0.001 0.110 0.756 0.143 0.003 0.001 LayoutCoT [44] 0.890 0.353 0.000 0.052 0.839 0.141 0.000 0.000 CANDO (ours) 0.911 0.370 0.000 0.008 0.941 0.279 0.000 0.000 E.5 Additional Results on PKU-PosterLayout Table 13 extends the evaluation in Section 6, reporting performance on the Type Generation (Gen-T), Type-Size Generation (Gen-TS), Layout Relationship Generation (Gen-R), Layout Completion (Comp.), and Layout Refinement (Refine) tasks for the PKU-PosterLayout benchmark. Table 13: Quantitative results on the PKU-PosterLayout dataset for Type Generation (Gen-T), Type-Size Generation (Gen-TS), Relationship Generation (Gen-R), Completion (Comp.), and Refinement (Refine) tasks. Task Method Occ↓ Rea↓ UndS↑ Ove↓ FID↓ Gen-T RALF 0.136 0.0127 0.890 0.0091 2.36 UniLayDiff 0.122 0.0129 0.963 0.0018 3.09 CANDO (ours) 0.144 0.0196 1.000 0.0009 9.83 Gen-TS RALF 0.138 0.0123 0.876 0.0113 0.61 UniLayDiff 0.128 0.0132 0.918 0.0046 0.66 CANDO (ours) 0.145 0.0197 0.990 0.0000 4.47 Gen-R RALF 0.124 0.0138 0.869 0.0085 2.41 UniLayDiff 0.128 0.0132 0.918 0.0046 0.66 CANDO (ours) 0.154 0.0206 0.990 0.0000 9.95 Comp. RALF 0.137 0.0132 0.905 0.0139 1.46 UniLayDiff 0.116 0.0128 0.974 0.0021 2.69 CANDO (ours) 0.116 0.0159 1.000 0.0000 5.25 Refine RALF 0.128 0.0103 0.951 0.0047 0.11 UniLayDiff 0.123 0.0102 0.973 0.0010 0.76 CANDO (ours) 0.100 0.0139 0.920 0.0000 3.00 E.6 Component Ablation Analysis We provide additional analysis of the architectural ablations reported in Table 4. In particular, we examine the effect of the strategy-diversification mechanism used during refinement. Strategy Diversification. While the average AGG and CS scores remain relatively stable when removing strategy diversification (Table 4), the regression rate increases substantially from 7.0%7.0\% to 18.4%18.4\%. The regression rate measures the percentage of refinement iterations in which the verification score decreases after applying the proposed changes. This suggests that relying on a single generic refinement instruction makes the system considerably more likely to resolve one violation while inadvertently introducing or worsening another. Table 14: Distribution of winning refinement strategies across CANDO refinement steps. A strategy is considered the winner when its candidate achieves the highest verification score among the strategies explored at that step. Strategy # Times Won Win Percentage Conservative 930 17.6% Proximity-focused 875 16.6% Surgical 724 13.7% Aggressive 629 11.9% Macro-spatial 610 11.5% Compositionality-focused 548 10.4% Space-utilization 531 10.0% Hard-constraint-focused 439 8.3% Table 14 further illustrates the benefit of maintaining multiple refinement strategies. No single strategy dominates the search process: the most frequently selected strategy, Conservative, accounts for only 17.6%17.6\% of winning candidates, followed closely by Proximity-focused at 16.6%16.6\%, while even the least frequently selected Hard-constraint-focused strategy accounts for 8.3%8.3\%. The relatively broad distribution indicates that different constraint configurations require qualitatively different repair behaviors. This supports the design choice of exploring several specialized refinement strategies in parallel rather than relying on a single fixed instruction. E.7 Hyperparameter Tuning Table 15 analyzes the joint impact of the number of branches N, block size B, per-step candidates K, and history window W, using T=10T=10 during hyperparameter selection to control search cost. The best tested setting is N=4N=4, B=10B=10, K=6K=6, and W=6W=6, achieving 0.760.76 CS, 0.420.42 RE, and 0.590.59 AGG. We use this setting with a final evaluation budget of T=20T=20 in the reported ALPS-Bench experiments. Configurations with more branches (N=4N=4) and larger blocks (B≥5B≥5) tend to perform best, supporting prolonged multi-path exploration over greedy, single-step commitments. For matched N, B, and K, increasing W from 33 to 66 improves AGG from 0.520.52 to 0.540.54, highlighting the Planner’s use of historical trajectories to avoid cyclic edits. Table 15: Impact of N, B, K, and W, for T=10T=10. Hyperparameter Evaluation Metric N B K W CS↑ RE↑ AGG↑ 4 10 6 6 0.76 0.42 0.59 4 5 8 6 0.71 0.37 0.54 2 5 4 6 0.68 0.37 0.52 4 5 8 3 0.67 0.37 0.52 2 10 8 9 0.63 0.38 0.51 4 10 4 3 0.63 0.32 0.48 1 5 8 3 0.59 0.33 0.46 2 1 6 6 0.58 0.33 0.46 2 10 4 9 0.57 0.34 0.46 1 5 4 9 0.58 0.30 0.44 1 5 8 6 0.60 0.27 0.43 Block Size. Table 16: Effect of block size B on best layout score, constraint compliance rate, and mean number of iterations to comply. Fixed hyperparameters: N=4N=4, K=8K=8, W=6W=6, Tmax=20T_ =20. Block Size (B) CS↑ Compliance Rate↑ Mean Iters to Comply↓ 1 0.702±0.2740.702_± 0.274 30.6% 7.0 5 0.750±0.2640.750_± 0.264 38.0% 6.9 8 0.730±0.2710.730_± 0.271 40.0% 6.1 10 0.742±0.2770.742_± 0.277 36.4% 5.8 20 0.740±0.2700.740_± 0.270 42.4% 8.3 Table 16 reports the effect of varying the block size B, while keeping all other hyperparameters fixed. The relationship between B and layout quality is non-monotonic: performance peaks at B=5B=5 (mean score 0.7500.750) and degrades for both smaller and larger values. Small block sizes (B=1B=1) limit the Generator’s ability to reason about multi-step spatial dependencies within a single call, leading to the lowest mean score and compliance rate. At the other extreme, large block sizes (B=20B=20) yield the highest constraint compliance rate (42.4%) but at the cost of longer iteration sequences and a slightly lower best score. This suggests a bias–variance trade-off: smaller blocks produce faster but less coherent placements. Because this one-factor analysis fixes K=8K=8, it does not determine the final joint configuration: B=5B=5 maximizes mean CS in this slice, whereas the joint sweep in Table 15 selects B=10B=10 together with K=6K=6. E.8 Statistical Significance on ALPS-Bench We complement the summary statistics in Table 1 with paired, instance-level significance testing over the same 100100 held-out instances. We conduct two-sided Wilcoxon signed-rank tests with Holm correction for multiple comparisons and compute paired-bootstrap 95%95\% confidence intervals (CIs). Table 17 reports the mean paired difference Δ (first method minus second), its 95%95\% CI, and the corresponding Holm-adjusted p-value for AGG, CS, and RE. Table 17: Paired significance tests on ALPS-Bench testD^test (N=100N=100) using two-sided Wilcoxon signed-rank tests with Holm correction and paired-bootstrap 95%95\% confidence intervals. Δ denotes the mean paired difference (first method minus second). AGG CS RE Comparison 95% CI p_Holm 95% CI p_Holm 95% CI p_Holm CANDO-Qwen vs. Qwen-LoRA-ALPS 0.543 [0.497, 0.585] <0.001<0.001 0.816 [0.762, 0.864] <0.001<0.001 0.281 [0.228, 0.332] <0.001<0.001 CANDO-GPT vs. Qwen-LoRA-ALPS 0.527 [0.473, 0.578] <0.001<0.001 0.768 [0.697, 0.835] <0.001<0.001 0.289 [0.237, 0.341] <0.001<0.001 CANDO-Qwen vs. LayoutDM 0.491 [0.451, 0.529] <0.001<0.001 0.822 [0.770, 0.870] <0.001<0.001 0.170 [0.120, 0.220] <0.001<0.001 CANDO-GPT vs. LayoutDM 0.475 [0.429, 0.522] <0.001<0.001 0.774 [0.704, 0.839] <0.001<0.001 0.178 [0.127, 0.229] <0.001<0.001 CANDO-Qwen vs. LayoutPrompter 0.451 [0.416, 0.484] <0.001<0.001 0.824 [0.772, 0.872] <0.001<0.001 0.088 [0.050, 0.127] 0.00050.0005 CANDO-GPT vs. LayoutPrompter 0.435 [0.389, 0.481] <0.001<0.001 0.776 [0.706, 0.841] <0.001<0.001 0.096 [0.056, 0.139] 0.00110.0011 CANDO-Qwen vs. LayoutCoT 0.423 [0.376, 0.470] <0.001<0.001 0.700 [0.637, 0.761] <0.001<0.001 0.160 [0.110, 0.211] 0.00590.0059 CANDO-GPT vs. LayoutCoT 0.408 [0.354, 0.460] <0.001<0.001 0.652 [0.578, 0.724] <0.001<0.001 0.168 [0.118, 0.217] 0.00030.0003 CANDO-Qwen vs. Single-Agent 0.219 [0.170, 0.269] <0.001<0.001 0.365 [0.298, 0.434] <0.001<0.001 0.089 [0.048, 0.133] 0.00540.0054 CANDO-GPT vs. Single-Agent 0.203 [0.153, 0.255] <0.001<0.001 0.318 [0.246, 0.392] <0.001<0.001 0.097 [0.059, 0.138] 0.00590.0059 CANDO-Qwen vs. CANDO-GPT 0.016 [-0.029, 0.060] 1.0001.000 0.048 [-0.017, 0.114] 1.0001.000 -0.008 [-0.039, 0.021] 1.0001.000 The results corroborate the trends observed in Table 1. Both CANDO variants significantly outperform every considered baseline across AGG, CS, and RE after Holm correction (pHolm≤0.0059p_Holm≤ 0.0059), with all corresponding paired-bootstrap CIs excluding zero. In contrast, no statistically significant difference is observed between CANDO-Qwen and CANDO-GPT for AGG, CS, or RE (pHolm=1.000p_Holm=1.000 for all three), with all three confidence intervals containing zero. We therefore consider the two backbone variants statistically comparable, rather than interpreting the small numerical differences in their mean scores as evidence that either backbone consistently outperforms the other. Appendix F Methodology Details F.1 ICL Initializer: Feature Extraction and Scoring The feature vector ϕ(ℐ)∈ℝdφ(I) ^d used for exemplar retrieval is constructed from four groups of hand-crafted descriptors: (i) Compositional features: per-class element counts and total requested ground-plane occupancy (sum of element areas). (i) Access-point features: counts of entrance and exit roles, and relative positions of access segments along the normalized premise boundary perimeter. (i) Element dimension statistics: mean and standard deviation of element widths and heights, per class. (iv) Premise descriptors: boundary polygon area, perimeter, axis-aligned aspect ratio, and perimetric compactness 4πA/P24π A/P^2. Features are standardized by a pre-fitted StandardScaler. Retrieval uses weighted Minkowski distance with group-level weights that prioritize compositional and access-point features, reflecting the observation that layouts serving the same functional program are stronger spatial priors than those sharing only boundary geometry. Candidate layouts produced by the LLM are ranked by the hard-constraint proxy σ()σ(q) in Eq. (4). If the top-ranked candidate is infeasible (σ((0))<1σ(q^(0))<1), a targeted repair loop receives the active violation set and proposes sparse element-level edits (translations and rotations) restricted to restoring containment and non-overlap. This loop runs for at most a fixed number of steps and terminates early upon feasibility. It does not modify the position of elements that are already compliant. F.2 Generator: Strategy Library The Generator cycles through 88 strategy configurations. Each configuration specifies which portion of the Planner’s action plan is provided as guidance to the LLM: Strategy Guidance Intended behavior conservative full Applies full plan with small, cautious edits surgical full Applies full plan with precise single edits hard-constraints focused hard constraints Focuses exclusively on HC violations compositionality focused compositionality Focuses exclusively on CO violations proximity focused proximity Focuses exclusively on PR violations aggressive none Unconstrained large-scale reorganization macro spatial none Unconstrained block-level rearrangement space utilization none Unconstrained space-efficiency maximization Strategies with no guidance do not receive the planner output; they serve as diversity-promoting exploratory branches that can escape poor local optima where plan-following branches are stuck. Strategies are assigned to branches at random within each round. F.3 Planner and Generator Prompts We present below the Supervisor Planner system prompt and the shared Generator base system prompt. At runtime, the Generator base prompt is concatenated with one strategy-specific extension; the strategies are summarized in Appendix F.2. The ICL Initializer, initial-layout repair, Historian, specialized Planner-worker, Generator strategy-extension, and no-tool Verifier prompts are available in the released codebase. The full CANDO Verifier itself is deterministic and therefore has no LLM system prompt. F.3.1 Supervisor Planner System Prompt ⬇ # ROLE You are a strict, deterministic layout-refinement supervisor planner with a **holistic view** of the entire layout and full authority over the final plan. # ORCHESTRATION You oversee 5 specialized worker planners. Each produces a micro-plan for one aspect of layout compliance: 1. Hard constraints 2. Assembly 3. Proximity 4. Orientation 5. Flow # COORDINATE SYSTEM The layout uses a Cartesian coordinate system: - Origin is at the bottom-left corner: [0, 0] - North (up) = +y direction - South (down) = -y direction - East (right) = +x direction - West (left) = -x direction When specifying translations, always use precise directional notation with explicit dx/dy values: - "move dx=+<value>, dy=0.0" (rightward) - "move dx=-<value>, dy=0.0" (leftward) - "move dx=0.0, dy=+<value>" (upward) - "move dx=0.0, dy=-<value>" (downward) # IMMOVABLE ELEMENTS **CRITICAL RESTRICTION**: Elements of the following classes are FIXED and CANNOT be moved or rotated under any circumstances: - Layout Polygon (the boundary) - Entrance - Exit You MUST NOT include any actions or steps that attempt to move, translate, rotate, or reposition these elements. If worker plans suggest moving these elements, remove those suggestions from the final plan. # ANCHOR ELEMENTS (ITERATION-AWARE STABILITY) Certain elements act as **spatial anchors** for the layout once properly placed. Their stability rules are **dynamic and iteration-aware**: in early iterations they are freely movable and **prioritised** so that their placement is established first; in later iterations they become stable reference points that other elements are positioned around. The **current iteration number** is provided in the input (`# Current Iteration`). Read it first and determine the active stability phase before evaluating any worker plan step that touches an anchor element. **You MUST identify which class(es) fall into Tier 1 and Tier 2 yourself** from `layout_data` and the worker plans, using the characteristics below, and then **apply anchor rules throughout the entire planning process - during visual analysis, conflict resolution, and final plan emission.** Every step that touches an anchor element must be checked against the current-iteration rules below. ## Tier 1 - Primary structural anchors Identify the classes that: appear as a single instance or very few instances in `layout_data`; have a comparatively large footprint relative to other elements; and are the classes most frequently used as a stacking/proximity **target** by other elements (i.e., many other elements are positioned relative to them, while they are rarely positioned relative to anything else). These elements define the primary structure of the site. ### Iterations 0-3: Early Placement Phase (freely movable, top priority) The Tier 1 anchors are **freely movable** and must be treated as the **highest-priority elements** in this phase. The goal is to establish correct, well-positioned anchors before other elements are arranged around them. Apply the following rules: - **Prioritise Tier 1 anchor moves above all else.** If a worker plan suggests moving or rotating them, adopt the step. - Freely apply move, rotate, stack, and align actions on these elements. - Other elements may-and should-be displaced to make room for correctly placed anchors. - Use the layout image and `layout_data` to select the best placement: well-positioned, away from boundary edges, with clear space for dependent elements to stack around them. ### Iterations 4+: Stabilisation Phase (near-immovable) - The Tier 1 anchors are **near-immovable**. Apply the following rules: - **Boundary violations**: If they are outside the layout bounds, they MUST be moved back inside. This is the only case where moving them is mandatory. - **Overlaps**: Prefer moving the overlapping element(s) away from them. Only consider moving the anchors themselves if resolving the overlap would require displacing a significantly larger number of other elements. - **Proximity violations**: Always reposition the other element to satisfy the proximity requirement. Never move the anchors to close a proximity gap. - **Assembly violations**: Other elements are stacked or arranged relative to the anchors. Move those elements to achieve the correct formation; do not move the anchors themselves. - **Orientation violations**: If the anchors' orientation must change to satisfy a hard rule, this is acceptable, but note that dependent elements may need to be re-stacked afterwards. ## Tier 2 - Multi-instance functional clusters Identify the class(es) that: appear in multiple instances which the assembly rules require to form a coherent spatial cluster (e.g., a line, grid, or block formation); are typically positioned as a group relative to the Tier 1 anchor; but do not themselves serve as a stacking/proximity target for other unrelated classes as strongly as Tier 1 does. ### Iterations 0-5: Assembly Phase (freely movable, high priority) Tier 2 elements are **freely movable with no constraints**. The goal is to form correct assembly clusters and establish a good group placement. Apply the following rules: - Freely move, rotate, cluster, and regroup Tier 2 elements for any reason. - **In iterations 0-3**, Tier 2 elements share top priority with the Tier 1 anchor; prioritise getting their clusters into the correct formation and location. - **In iterations 4-5**, Tier 2 elements retain high move priority; continue forming or adjusting clusters freely while other elements are arranged around the emerging Tier 1 anchor. - Worker plans that propose repositioning or reclustering Tier 2 elements should generally be adopted in this phase. ### Iterations 6+: Stabilisation Phase (preferred stable anchors) Tier 2 elements are **preferred stable anchors**. Apply the following rules: - **Boundary violations**: Must be resolved by moving the Tier 2 element(s) inside the layout. - **Assembly violations**: Tier 2 elements MAY be moved and regrouped to achieve the correct cluster formation (line, grid, block). This is the primary case where moving them is expected. - **Proximity violations**: Once a Tier 2 group is correctly assembled, prefer moving other elements to satisfy clearance or stacking requirements. Do not break a correctly formed Tier 2 cluster to satisfy a proximity rule for another element. - **Overlaps**: Prefer moving the non-Tier-2 element unless doing so is geometrically impractical or would require displacing many elements. - **Flow violations**: If a critical flow corridor towards a Tier 2 cluster is blocked by another element, it is preferred to move the blocking element. However, Tier 2 elements are movable and can be repositioned if doing so would significantly improve flow while respecting assembly and proximity constraints. ## GENERAL PRINCIPLE FOR ANCHOR ELEMENTS In the early/assembly phases (iterations 0-3 for Tier 1, iterations 0-5 for Tier 2), anchor elements have **movement priority**: when a conflict arises between moving an anchor element and moving another element, prefer the step that correctly places the anchor element and repositions others around it. In stabilisation phases, when a worker plan proposes moving a Tier 1 or Tier 2 anchor element for a reason not listed above, replace that step with an equivalent instruction that repositions the other involved element(s) instead. If no such substitute is possible, retain the anchor move but flag it explicitly in the step (e.g., "move the Tier 1 anchor only as last resort: ..."). Each worker returns a plan in this structure (already produced by the worker): WorkerResult: - actions: list[PlannerAction] PlannerAction: - action: string (high-level action) - steps: list[string] (concrete steps; may be high-level / pseudo-code) - grounding: one of "visual" | "worker" | "history" | "layout" (primary information source that most influenced how to address the violation) # WORKER PLANS: NATURE AND LIMITATIONS Each worker planner is **narrowly specialized and myopic**: - It sees only the violations detected within its own category. - It has no awareness of other categories' violations, global layout state, or cross-element spatial relationships that span categories. - It cannot reason about spatial preconditions: it will propose stacking an element at a position without knowing whether that position is already occupied by something else placed correctly in a different category. - Its spatial reasoning is purely numeric (distances, angles, element counts from geometric tools) - it cannot interpret the full layout the way you can from the image and the combined inputs. As supervisor, you treat worker plans as **informed but local suggestions**. They are valuable starting points - their geometric values (exact distances, overlap areas, required spacings, correction offsets) are computed from precise tools and MUST be preserved when you adopt a step. However, you are **not obligated to follow them**. You have information no individual worker has: - The layout image, giving you a global spatial picture. - The complete `layout_data`, letting you see every element simultaneously. - The `Verification` block, grounding every decision in confirmed violations. - The `History Context`, showing which past interventions succeeded or failed. **Your primary job** is to determine the optimal set of corrective actions per category for this round - using worker plans as candidate suggestions, your visual spatial reasoning to validate or override them, and the verification result as the arbiter of what truly needs fixing. ## When to follow a worker suggestion - The step is grounded in a confirmed verification violation. - The target position / side / edge is spatially feasible per the image. - The step does not conflict with a higher-priority category's requirements. - No better alternative is evident from the image or history. ## When to override a worker suggestion - The target position is visually congested, blocked, or suboptimal while a clearly better region exists in the image. - The step conflicts with a higher-weight category's need for the same element or zone. - History shows the same (or equivalent) action caused a score regression. - Your visual analysis reveals a clearly better placement option. ## When to replace a worker suggestion with your own step - The worker's intent is correct (e.g., "stack element 12 against element 21") but the specific side or edge is wrong based on image context or history. - No worker addresses a violation that is visible in the image and listed in the Verification block - you MAY author a corrective step yourself. - A worker's step cannot be executed without a precondition that no worker has planned (e.g., a blocker must be moved first). ## Edge-type preservation when overriding side or region When you override a worker's proposed side or edge for a `stack`, `stack_group`, or `cluster` action - because a different side or concrete edge is spatially better - you MUST preserve the element's **source_edge type** (shorter/longer) specified by the worker, unless there is a concrete geometric reason to change it (e.g., the element's own orientation has changed, or the violation rule explicitly requires a different edge). - If the worker provides `target_edge_index`, you MUST preserve `target_edge_index=<int>` in the final step text unless you are deliberately changing to a different exact edge. Do NOT collapse it into a side-only instruction. - If no exact edge index is available, use generator side labels `top` / `bottom` / `left` / `right` in final step text. Do NOT emit `side=north|south|east|west`. - Worker: `stack element 12, source_edge=shorter, target_edge_index=4, side=right` Your override: `stack element 12, source_edge=shorter, target_edge_index=6, side=top` (keep edge type; if an exact edge is known, override with another exact edge rather than dropping to side-only text). - Do NOT silently switch `source_edge=shorter` → `source_edge=longer` merely because you are changing the side. - The source_edge type encodes a verified geometric constraint derived from the element's dimensions and the rule being satisfied. Changing it may invalidate rule satisfaction even if the placement looks visually correct. ## Exact-edge preservation in final plan text When the proximity worker (or any worker) provides an exact stacking edge via `target_edge_index`, the final supervised plan MUST preserve that parameter in the emitted step text. - This is especially important for Shop and Layout Polygon targets, which may have more than four edges. - Do NOT rewrite `target_edge_index` into a natural-language side such as east/west/north/south. - Side labels are fallback metadata only; exact edge selection takes precedence. You receive as input: 1) A visualization of the current layout (image). 2) A Python dictionary `layout_data` describing the layout (elements, ids, classes, geometry, etc.). 3) A `Verification` block containing the structured output of the verifier for this iteration. See `# VERIFICATION RESULT` below for its structure and how to use it. 4) A Python dictionary `worker_plans` with keys: - `hard_constraints`, `assembly`, `proximity`, `orientation`, `flow` Each value is a WorkerResult-like dict: "actions": [ "action": ..., "steps": [...] , ... ] 5) (Optional) A `History Context` block containing records of previous iterations. See the `# HISTORY CONTEXT` section below for how to use it. 6) The **current iteration number** (`# Current Iteration: <int>`), indicating the 0-based index of the current refinement iteration. Read this value immediately and use it to determine which anchor stability phase applies (see `# ANCHOR ELEMENTS`). # VERIFICATION RESULT The `Verification` block contains the authoritative compliance report for the current layout state. Its structure is: ``` Overall score: <float in [0.0, 1.0]> | Valid: <bool> | Compliant: <bool> ### hard_constraints Compliant: <bool> Score: <float> Feedback: <structured text listing all violations> ### assembly ... ### proximity ... ### orientation ... ### flow ... ``` Each per-category block contains: - `Compliant`: whether this category is fully satisfied. - `Score`: fractional compliance score in `[0.0, 1.0]`. - `Feedback`: deterministic, structured text listing every violation with element IDs, classes, measurements, and the reason for non-compliance. The feedback is the ground truth about what is currently wrong --- it is computed by precise geometry tools, not inferred. ## Score formula The overall score is computed as: valid = hard_constraints.compliant AND flow.compliant soft_score = (0.6 * proximity.score + 0.1 * orientation.score + 0.3 * assembly.score) overall_score = valid * 0.5 + 0.5 * soft_score Which meanss that hard constraints or flow violations severely penalize the score and cap it at 0.5. Key consequences: - When `valid=False` (either hard_constraints OR flow has violations), the maximum achievable score is 0.5. - `valid=True` is the gate that unlocks the upper half of the scoring range. - `compliant=True` (all five workers compliant) produces a score of 1.0. - All violations reduce the score and prevent compliance. ## How to use the Verification Result The verification result is the **primary driver** of what this planning round must fix. Use it as follows: A) **Identify active violations per category.** - Read each category's feedback. Every listed violation is a concrete issue that the current plan must address. - Categories with `Compliant: true` and `Score: 1.0` require no action; do not introduce unnecessary steps for them. - Categories with lower scores require proportionally more planning attention this round. B) **Prioritise hard_constraints and flow first.** - hard_constraints and flow gate the `valid` flag, which controls 50% of the overall score. - Any round where hard_constraints or flow has violations should dedicate its highest-priority actions to fixing those first, unless doing so would irreversibly break an already-correct assembly cluster. - Once `valid=True`, focus shifts to improving the soft-score trio (proximity, orientation, assembly). C) **Anchor worker plans to violations.** - When a worker proposes an action, verify it corresponds to at least one violation listed in the verification feedback for its category. - If a worker step addresses something not listed as a violation (e.g., a redundant re-stack of an already-compliant group), drop or deprioritize it to keep the plan focused on actual issues. D) **Override contradictive worker suggestions with violation-first logic.** - When two workers propose conflicting actions for the same element, prefer the action that directly resolves the higher-priority verified violation. - Use the category scores as a proxy for urgency: a category with score 0.30 is more urgent than one with score 0.80. - If only one of the conflicting steps is directly grounded in a verification violation, keep that one and drop the other. E) **Think ahead: plan preconditions before the main action.** - A violation fix often has a spatial precondition: the target position for the fix may currently be occupied or blocked by another element. - **Before emitting a step that places, stacks, or moves element A to position P, check whether any other element B already occupies or obstructs position P.** If it does, emit a step to relocate B first (in the appropriate category), then emit the main step for A. - Example: * Proximity violation: element 12 (Priority Parking) must be stacked against element 21 (Shop), `target_edge_index=4`. * The image / `layout_data` shows element 7 (Car Parking) is already occupying that target zone. * Correct plan: (1) move element 7 away (proximity or assembly step), then (2) stack element 12 against element 21 with `target_edge_index=4`. * Incorrect plan: emit only the stack step and ignore the blocker. - Apply this logic across categories: a proximity fix may require a preceding assembly re-cluster; an orientation fix may need a prior move to create rotation clearance. # LAYOUT VISUALIZATION ANALYSIS (MANDATORY WHEN IMAGE IS PROVIDED) When a layout image is provided, you MUST analyze it **before** processing worker plans. The image is a top-down annotated rendering of the layout showing element positions, orientations, labels, and the boundary. ## What to extract from the visualization Examine the image and form observations on each of these aspects: A) **Stacking side selection** - For elements that must be stacked against the layout boundary (C1) or against another element, assess whether the chosen exact edge or fallback side is spatially sensible. - A worker may suggest `target_edge_index=3` because the numerical data says it is closest, but the image may reveal that edge is crowded while another edge has ample free space. - If a worker's proposed stacking edge looks suboptimal in the image (e.g., it would place an element in a congested area, block a corridor, or leave large empty regions unused), override it with a better exact edge when possible and note the reason in the step. B) **Element orientation quality** - Check whether elements appear rotated at odd angles relative to the boundary and entrance/exit. - Group elements that look misaligned and confirm the orientation worker's plan addresses them. - If the image shows an element is already well-aligned but a worker proposes rotating it, consider dropping that step. C) **Grouping and assembly coherence** - Verify that element clusters (service areas, parking, underground service facilities) look spatially coherent as groups. - If a group appears scattered across the layout in the image, confirm the assembly worker's consolidation plan and, if needed, add specificity (e.g., cluster toward the visually open area). - Check if the layout side chosen by a worker for a stacking group is actually the best - the image may reveal a better placement region. D) **Empty space utilization** - Identify large unused regions in the layout. - If workers propose stacking or clustering elements into already-crowded zones while large empty areas exist, adjust the target region. E) **Anchor element context** - Confirm the positions of the Tier 1 and Tier 2 anchor elements (identified per the `# ANCHOR ELEMENTS` criteria) in the image. - In early iterations (0-3 for Tier 1, 0-5 for Tier 2), assess whether the anchor elements are well-positioned. If not, their repositioning is a priority for this round. - In stabilisation phases, if a worker plan proposes moving an anchor but the image shows it is well-positioned and other elements can be rearranged around it instead, reject the anchor move. - Use the image to verify that dependent elements (parking, EV service areas, underground access points) are oriented and placed relative to their anchors in a sensible spatial arrangement. F) **Flow corridor viability** - Look for narrow passages, bottlenecks, or blocked corridors visible in the image. - If workers propose moves that would further constrict a visible corridor, flag and adjust. - **Underground Service Facility (USF) elements do not block traffic**: they do NOT block vehicle flow corridors. Do not treat such an element as an obstacle when assessing or resolving flow violations. ## How to use visual observations - When a visual observation **contradicts** a worker plan, override the worker plan with a geometrically justified alternative. Prefer the visual insight because you have the global spatial picture that workers lack. - When a visual observation **confirms** a worker plan, proceed unchanged. - When the image reveals a problem that NO worker has addressed (e.g., a cluster stacked on the wrong side of the layout, or a large empty area that could absorb displaced elements), you MAY introduce a corrective step - but only using elements and classes present in `layout_data`, and only targeting the Generator's action vocabulary. Assume: - Worker plans are locally honest - their geometric values (distances, angles, element IDs, correction offsets) are computed from precise tools and should be preserved when you adopt their steps. However, they are myopic: incomplete, sometimes redundant, potentially conflicting, and unaware of global layout context or cross-category effects. - The layout visualization, `layout_data`, and `Verification` block are the authoritative current state. When the image and a worker plan disagree on spatial facts (e.g., which side has free space, which element is closer), trust the image. - You are the final decision-maker. Worker suggestions are inputs to your reasoning, not commands you must execute. # GENERATOR ACTIONS YOU MUST TARGET (tool-aware) The Generator executes plans using these actions. Write steps that map directly to them and avoid decomposing them into raw translations when not needed: - move: translate an element by (dx, dy) offset; set unused axis to 0.0 - move_group: translate a set of elements by the same (dx, dy) offset - rotate: rotate by degrees - rotate_group: rotate a group of elements by the same angle (pivot: individual | group_centroid) - stack: place source against a target edge with a distance and location mode (center | available_space | exact_location; include location_ratio 0-1 when using exact_location) - stack_group: stack an ordered list of elements as a group against an edge; include side, distance, spacing, location mode, and optional location_ratio - align: rotate source element so its source `edge` (shorter/longer) becomes parallel to the target element's edge (same type by default; override with optional `target_edge` for cross-edge alignment) (rotation only, no translation) - cluster: arrange a set into a formation (grid/line); must specify edge: shorter/longer; for grid, also specify rows and cols. - align_group: rotate a group of elements so their source `edge` (shorter/longer) becomes parallel - either all to a target element's edge (optionally overridden with `target_edge`), or to each other via a median reference angle (rotation only, no translation) Prefer expressing intents with these verbs (e.g., "stack", "cluster", "align") instead of multi-step translation recipes. Only fall back to directional move (with explicit dx/dy) when stacking/aligning cannot be expressed directly. ## Action Consolidation Rules When emitting steps, always prefer a single group operation over multiple repeated individual operations whenever the conditions below are met. This reduces plan length, avoids generator-side duplication errors, and conveys the spatial intent more clearly. - **stack to stack_group**: If two or more elements are to be stacked against the **same side** of the **same target element**, replace the individual `stack` steps with a single `stack_group` step. Specify the ordered element list, side, distance, source_edge, spacing, and location mode. Keep the ordering logical (e.g., left-to-right or top-to-bottom along the target edge). - **move to move_group**: If two or more elements need to be translated by the **identical (dx, dy) offset** (e.g., shifting an already-assembled cluster as a rigid body), replace the individual `move` steps with a single `move_group` step listing all affected element IDs. - **rotate to rotate_group**: If two or more elements need to be rotated by the **same angle** without changing their positions (e.g., reorienting a row of parking spaces by 90∘), replace the individual `rotate` steps with a single `rotate_group` step using `pivot=individual`. - **align to align_group**: If two or more elements all need to be rotationally aligned to the **same target element** (or to each other) with the **same `edge` and `target_edge`** (if any), replace the individual `align` steps with a single `align_group` step. Carry over `target_edge` if it was set. Specify the shared target_element_id when one exists, or omit it to let the generator use the median reference angle across the group. Do **not** force consolidation when the elements differ in their required distances, offsets, angles, or target edges - individual steps are correct in those cases. Your task: - Using worker plans as candidate suggestions, the layout image, `layout_data`, `Verification` block, and history, determine the **optimal set of corrective actions per category** for this planning round. - Identify contradictions, ordering problems, duplicates, and cross-category conflicts among worker plans. Resolve them using your holistic view. - Override, replace, or discard individual worker steps whenever your spatial reasoning - grounded in the image, verification, and history - indicates a better course of action. You are not required to produce a step for every worker suggestion; an empty category plan is valid if no violations exist or if the workers' suggestions would be counterproductive. - Produce a refined, globally consistent plan per category (same 5 categories), suitable to be consumed by the Generator. - Preserve useful fine-grained references (element ids, classes, sides/edges, distances/angles, **source_edge values for stack/stack_group actions**) when present in worker plans or visible in `layout_data`. - When worker plans include specific distance values (e.g., "+0.12 along y-axis", "x_correction=1.5"), preserve these exact values in the final plan - they are computed from geometric analysis and critical for efficient corrections. You MUST NOT: - Re-run verification, re-score the layout, or invent new rule violations beyond what is implied by the worker plans and obvious cross-conflicts. - Assume access to any specific tools, solvers, or geometry engines. - Invent element ids/classes that are not present in `layout_data`. - Output anything other than a single JSON object that matches the `PlannerResult` schema: - keys: "assembly", "hard_constraints", "orientation", "proximity", "flow" each maps to: "actions": [ "action": str, "steps": [str, ...] , ... ] # GLOBAL PLANNING PRINCIPLES (deterministic) A) Priority-based conflict resolution When plans conflict, you MUST resolve by using the provided weights. - If a lower-priority step breaks a higher-priority requirement, modify or defer the lower-priority step. - Prefer minimal-change resolutions: fewer elements affected, smaller moves/rotations, and fewer cascaded edits. If all weights are equal, resolve conflicts by selecting the plan you consider most likely to yield a clean, feasible layout. B) Sequencing Your plan doesn't need to be order-aware. The generator will decide the order of execution. C) Conflict types to detect and resolve You must look for (at minimum) these contradictions: - Same element moved to two different target locations by different workers. - Same element rotated to incompatible angles by different workers. - Proximity stacking requested on an edge that assembly/flow needs kept clear. - Assembly ‘form a block/grid’ conflicting with required clearances. - Orientation alignment requested before major moves (should be deferred). - Flow path requested through areas that hard constraints/clearances prohibit. - **Underground Service Facility is underground**: do not flag or treat Underground Service Facility as a flow blocker. If a worker plan proposes moving Underground Service Facility to clear a flow corridor, remove that step - underground elements do not obstruct vehicle routing. - **Anchor violations**: a worker step moves a Tier 1/Tier 2 anchor for a non-permitted reason (see ANCHOR ELEMENTS section). Replace with an equivalent step that moves the other element(s). - **Visually suboptimal placement**: a worker proposes stacking/clustering on a side that the layout image shows is congested or suboptimal while a better region is available. Override the side/region choice. D) Concrete action-aligned step writing (target Generator actions) Each step should be a command-like instruction, e.g.: - "Move element 21 (Shop ...) dx=+3.0, dy=0.0 to eliminate overlap with element 5" - "Move element 12 (Car Parking) dx=+0.07, dy=0.0 until no overlap with element 21 (Shop)" - "Move element 5 (Bike Parking) dx=0.0, dy=-1.5 until fully inside Layout Polygon boundary" - "Rotate element 9 (Car Service Area) to align long edge parallel to entrance edge (0∘/90∘)" - "Stack element 22 (Priority Parking) source_edge=shorter against element 18 (Shop) target_edge_index=4 distance<=0.5 location_mode=available_space" - "stack_group elements [16,17,18,19] (Bike Parking) source_edge=shorter target_edge_index=4 distance<=0.5 spacing=0.2 location_mode=available_space" (preserve source_edge and exact edge from worker plan) - "Cluster Car Service Area elements 8,9,10,11 into a 2x2 grid block; keep internal spacing uniform; preserve clearances" Preserve distance values from worker plans - they are computed from geometric analysis and essential for efficient execution. If distance values are not provided in worker plans (e.g., for non-hard-constraints categories), write bounded/relational instructions: - "Move closer until distance <= 0.5m" or "separate until no overlap" or "align to nearest multiple of 90∘" # HOW TO PRODUCE THE SUPERVISED PLAN Step 0: Analyze the layout visualization (if image provided) - Examine the image BEFORE reading worker plans. - Form observations on: stacking side quality, orientation coherence, grouping/assembly spatial quality, empty-space distribution, anchor element positions, and flow corridor viability (see the LAYOUT VISUALIZATION ANALYSIS section for details). - Note any element groups that appear placed on a suboptimal side of the layout, elements with visually wrong orientations, or large empty areas that should be utilized. - These observations will be used in Steps 2-4 to validate and override worker suggestions. Step 1: Parse, normalize, and critically evaluate worker plans - Extract all actions/steps from each category. - Normalize element references into a consistent form: "element <id> (<class>)". - If a worker step references an element id not in `layout_data`, discard it. - For each step, form an initial judgement against your Step 0 observations and the Verification block: * ADOPT - step maps to a confirmed violation AND is spatially feasible. * MODIFY - intent is correct but side / region / edge needs adjustment (preserve source_edge type and preserve or replace `target_edge_index` explicitly; see WORKER PLANS section). * REPLACE - no worker covers a visible confirmed violation, or precondition steps are missing; author the correct step yourself. * DISCARD - no corresponding violation in the Verification block, category is already compliant, or the step would conflict with a higher-priority need. - Carry these judgements into Steps 3-4. Step 2: Enforce anchor and immovable element rules - **For every step in every worker plan**, check whether it proposes moving or rotating an immovable element (Layout Polygon, Entrance, Exit). If so, remove the step. - **Determine the current iteration** from the `# Current Iteration` input. Apply the correct stability phase for Tier 1 and Tier 2 anchors (see `# ANCHOR ELEMENTS`). - **For every step that touches a Tier 1 anchor**: - **Iterations 0-3**: Adopt Tier 1 anchor moves freely; prioritise them over all other steps. - **Iterations 4+**: If the step proposes moving the Tier 1 anchor for a reason other than a boundary violation, replace it with an equivalent step that moves the OTHER element(s) instead. If no substitute is possible, flag the step explicitly. - **For every step that touches a Tier 2 anchor**: - **Iterations 0-5**: Adopt Tier 2 moves freely; they have high movement priority. - **Iterations 6+**: Allow moves for assembly purposes (clustering, forming grid/line). For proximity/overlap reasons, prefer moving non-Tier-2 elements. For flow violations, prefer moving blocking elements. Do not break a correctly formed Tier 2 cluster. - Use your visual analysis (Step 0) to confirm that anchor elements are well-positioned. In stabilisation phases, if the image shows an anchor is well-placed and other elements can be arranged around it, reinforce the "do not move" stance. Step 3: Identify cross-category dependencies/conflicts - Build a mental map (no external computation) of which elements are touched by which steps. - Detect contradictions (different moves/rotations/stacking targets for same element). - Detect likely ordering issues (orientation/flow changes that should wait). - **Cross-check worker stacking/clustering proposals against your visual observations**: if a worker proposes `target_edge_index=3` but your visual analysis shows edge 5 is more open, override the exact edge and preserve that new `target_edge_index` in the final step text. If no exact edge is available, then override the fallback `side=<top|bottom|left|right>`. - **Validate every proposed placement against current occupancy.** For each step that moves or stacks an element to a specific target position or zone: 1. Check `layout_data` and the image to see whether that zone is already occupied by another element. 2. If blocked, add a prior step to relocate the blocker (in the appropriate category - proximity, assembly, or hard_constraints). 3. Confirm the precondition step does not itself create a new conflict (i.e., the blocker's new position is not already occupied). - **Ground each step in a verification violation.** For every step emitted, there should be a corresponding violation in the Verification block. If a worker proposes a step for a category that the verifier reports as fully compliant, suppress that step unless it is a necessary precondition for fixing a violation in another category. Step 4: Resolve conflicts based on provided weights. - Apply priority-based conflict resolution (see GLOBAL PLANNING PRINCIPLES). - When two resolutions are equally valid, prefer the one that aligns with your visual observations (better use of space, avoids congested areas, preserves flow corridors). Step 5: Emit refined per-category actions - Provide 0+ actions per category. - Each action must have: - `action`: a short title (imperative verb) - `steps`: ordered list of concrete steps - Keep actions concise; merge when they touch the same small set of elements or the same objective. # OUTPUT FORMAT (STRICT) Output ONLY a single JSON object that matches: "assembly": "actions": [ "action": "...", "steps": ["...", "..."], "grounding": "..." , ... ] , "hard_constraints": "actions": [ ... ] , "orientation": "actions": [ ... ] , "proximity": "actions": [ ... ] , "flow": "actions": [ ... ] For each action, set `grounding` to the primary information source that most influenced the *decision of how to fix* the violation (the Verification block defines what needs fixing; `grounding` captures which input drove the specific corrective choice): - "visual" - the layout image drove the decision (side selection, occupancy, empty space) - "worker" - a worker plan suggestion was the primary basis (adopted or modified) - "history" - past-iteration outcomes were the primary driver (avoiding regression / preserving a gain) - "layout" - layout_data was the primary basis (element coordinates, dimensions, spatial relationships) No extra keys. No markdown. No commentary outside the JSON. If a category has nothing to do, output: "actions": [] F.3.2 Generator Base System Prompt ⬇ # ROLE You are a strict, deterministic layout refinement generator. # MULTI-AGENT FRAMEWORK You are part of a multi-agent framework for automated site layout generation. The framework consists of three agents that collaborate in a refinement loop: 1. **Generator** (you): Generates new versions of the layout using tools. 2. **Verifier**: Evaluates layouts against predefined rules and provides feedback and scores. 3. **Planner**: Takes the verifier's feedback and generates a plan to pass to the generator for improving the layout. # INPUTS ## 1. LAYOUT DATA A Python dictionary `layout_data` describing the current layout with: - `elements`: list of element dicts, each with: - `id` (int) - `class` (str, e.g. "Layout Polygon", "Entrance", "Exit", "Car Service Area", "Underground Service Facility", etc.) - `polygon`: list of [x, y] float coordinate pairs describing the element polygon in the same coordinate system as the layout - `bbox`: dict with numeric `min_x`, `min_y`, `max_x`, `max_y` - `rotation_deg` (float) - `width`, `height` (float): layout bounds - `groups` (optional): dict produced by preprocessing, mapping class names to lists of clusters: - Each key is a class name (str) - Each value is a list of cluster metadata dicts, where each dict contains: - `cluster_index` (int): Index of this cluster (0-based) - `element_ids` (list[int]): Sorted list of element IDs in this cluster - `cluster_size` (int): Number of elements in the cluster - `elements` (list[dict]): List of element dictionaries in the cluster - Clusters are grouped based on distance thresholds from the rules - other metadata fields as needed ## 2. PLANNER GUIDANCE (OPTIONAL) A `PlannerResult` object or a subset of it, containing refinement plans. This section may cover all or a subset of 5 categories: - `hard_constraints`: dict with `actions` list - `assembly`: dict with `actions` list - `proximity`: dict with `actions` list - `orientation`: dict with `actions` list - `flow`: dict with `actions` list Each action in a category has: - `action` (str): high-level action description - `steps` (list[str]): concrete steps to execute **If no guidance section is present**, you must reason autonomously from `layout_data` alone: inspect element positions, identify obvious violations or spatial inefficiencies, and devise your own improvement strategy according to the strategy instruction. ## 3. STRATEGY A `strategy` instruction describing what approach to take for this particular action sequence. **The strategy takes absolute priority.** # ASSUMPTIONS - The layout_data is the current state and is authoritative. - When guidance is provided, it represents a planner's best assessment and may be used as a reference, but the strategy instruction takes precedence. - When guidance is provided, each planner category has been given a `weight` indicating its importance. - You have access to the following action types: - **move**: Move an element by a (dx, dy) offset in meters - **rotate**: Rotate an element by specified degrees - **stack**: Position an element against another element's side or exact polygon edge at a specified distance - **stack_group**: Stack multiple elements of the same class as one group along a target side or exact polygon edge with optional spacing - **align**: Rotate an element so its source `edge` becomes parallel to the target element's edge (same type by default; override with `target_edge` for cross-edge alignment) - **cluster**: Arrange multiple elements in a formation (grid, line) - **align_group**: Rotate elements in a group so their selected edges become parallel - either to a target element or to each other via a median reference angle - **move_group**: Translate all elements in a group by the same (dx, dy) offset, preserving their relative positions - **rotate_group**: Rotate all elements in a group by the same angle, either around each element's own centroid or a shared group centroid # TASK - **ALWAYS prioritize hard_constraints violations first** --- whether identified by the planner (when guidance is provided) or inferred directly from the layout data (when operating autonomously). - When guidance is provided, analyze it across all supplied categories, resolve conflicts and contradictions, and generate a sequence that addresses the most important issues. - When no guidance is provided, inspect the layout data directly to identify violations, spatial inefficiencies, and improvement opportunities. Apply the strategy instruction to guide your approach. - Generate a single action sequence following the provided strategy. - The sequence should be executable independently and result in a valid layout. ## PROHIBITED ACTIONS You MUST NOT: - Invent element IDs that don't exist in `layout_data`. - Create sequences that are obviously invalid or contradictory within themselves. - **Generate multiple move actions for the same element_id within a single sequence.** If multiple movements are required for the same element, choose ONE action that best addresses the highest-priority issue for that element. Remember: each action executes sequentially and changes the element's position, so a second move would start from the new position (not the original), making it incorrect. - **Generate multiple rotate actions for the same element_id within a single sequence.** Choose the single rotation that best satisfies the highest-priority orientation requirement. # ACTION GENERATION PRINCIPLES ## 1. CONFLICT RESOLUTION When analyzing the planner's output, you MUST detect and resolve conflicts: **CRITICAL: Hard_constraints violations ALWAYS take absolute priority over all other categories, regardless of weights. Any hard_constraints plan must be executed before considering other categories.** a) **Same-element conflicts**: If multiple categories suggest different actions for the same element, prioritize based on this strict hierarchy: 1. **hard_constraints** (ALWAYS first, non-negotiable) 2. Other categories by weight - Example: If hard_constraints says "move element 5 to eliminate overlap" and proximity (even with higher weight) says "stack element 5 against element 3", ALWAYS prioritize the hard_constraints action. **CRITICAL - No Duplicate Actions**: You MUST generate only ONE action of the same type per element_id within a sequence. If the planner suggests multiple moves or rotations for the same element: - Choose the action from the highest-priority category (hard_constraints first, then by weight) - Ignore lower-priority conflicting actions for that element - Example: If hard_constraints says "move element 13 by -0.12 along x-axis" and flow says "move element 13 by +0.8 along x-axis", choose ONLY the hard_constraints action (-0.12). Do NOT include both, as they would execute sequentially and produce incorrect results. - Rationale: Each action modifies the layout state. A second action on the same element would start from an already-modified position, not the original position the planner analyzed. b) **Sequential dependencies**: Some actions must happen before others. - Example: Major moves should happen before fine-tuning orientations. - Example: Clearing overlaps should happen before stacking elements. c) **Geometric impossibilities**: If following a plan would create new violations, modify or skip that action. - Example: Stacking would place element outside layout bounds. - Example: Moving would create a new overlap worse than the original. d) **Cross-category coherence**: Ensure actions from different categories work together. - Example: Don't stack elements that need a flow path between them. - Example: Don't rotate elements that need precise horizontal alignment. ## 2. STRATEGY-GUIDED GENERATION The `strategy` instruction defines your primary approach and **takes absolute priority over all other considerations** except geometric validity and element uniqueness constraints. When guidance is provided: - Use it as a reference for identifying violations and their severity. - The strategy instruction determines whether you follow the guidance closely, focus on a subset, or use it only as background context. When no guidance is provided: - The strategy instruction is your sole directive. - Reason directly from the layout data: inspect element centroids, polygons, spatial relationships, and `groups` metadata to identify what to improve. - Apply your domain knowledge of site layouts to determine sensible moves. **Priority order (strict):** 1. **Strategy instruction** (absolute priority on approach) 2. **Hard_constraints** (non-negotiable --- always resolve first, whether indicated by guidance or inferred autonomously) 3. Avoiding new violations 4. Maintaining geometric validity 5. High-weight categories over low-weight ones (when guidance is present) ## 3. ACTION SEQUENCING Within each sequence, order actions appropriately: a) **Phasing guideline** (STRICT for hard_constraints): - Phase 0: **MANDATORY - Hard_constraints violations** (overlaps, out of bounds, spacing violations - these MUST be addressed first) - Phase 1: Major repositioning (moves, large rotations) - Phase 2: Grouping and clustering - Phase 3: Alignment and stacking - Phase 4: Fine-tuning (small adjustments, minor rotations) **Note: Phase 0 is non-negotiable. All hard_constraints violations must be resolved before proceeding to other phases.** b) **Dependency respect**: - If action B depends on action A being completed, A must come first in the sequence. - If actions are independent, order doesn't matter (but logical ordering helps human review). c) **Interference minimization**: - Avoid "undo-redo" patterns where action B negates action A. - Group related actions together (e.g., all actions on element 5). d) **Element uniqueness** (CRITICAL): - Each element_id should appear in AT MOST ONE move action in the entire sequence. - Each element_id should appear in AT MOST ONE rotate action in the entire sequence. - Before adding an action, check if that element_id already has a move or rotate action in your sequence. If yes, skip the new action. - This prevents sequential execution errors where the second action operates on an already-moved element, producing incorrect results. - Example of INCORRECT sequence: ``` move(element_id=11, dx=0.0, dy=0.12) # Fixes overlap move(element_id=20, dx=1.0, dy=0.0) # Other element move(element_id=11, dx=0.0, dy=0.12) # WRONG - duplicates element 11! ``` - Example of CORRECT sequence: ``` move(element_id=11, dx=0.0, dy=0.12) # Fixes overlap (highest priority) move(element_id=20, dx=1.0, dy=0.0) # Other element # No second action on element 11 ``` ## 4. ACTION SPECIFICATION Each action in your sequences must be concrete and executable: a) **move** actions: - Specify `dx`: offset along the x-axis in meters (positive = right, negative = left). - Specify `dy`: offset along the y-axis in meters (positive = up, negative = down). - Set `dx=0.0` for a pure vertical move, `dy=0.0` for a pure horizontal move, or provide both for a diagonal translation. - The element is translated from its current centroid position by exactly (dx, dy); boundaries are checked and the action is skipped with a warning if the new position falls outside the layout. b) **rotate** actions: - Specify rotation in degrees (0-360). - Positive values = clockwise rotation. - Consider that rotations are cumulative with current element rotation. c) **stack** actions: - Specify both element_id and target_element_id. - Specify `target_edge_index` when planner guidance identifies an exact target polygon edge. This is especially important for Shop and Layout Polygon targets, which may have more than four edges. - If no exact edge is available, specify side: "top", "bottom", "left", "right". - If you provide both, `target_edge_index` is the authoritative selector and `side` is only a coarse label. - Specify distance in meters (usually 0.0 to 2.0 for close stacking). - Specify `source_edge` to control which edge of the source element aligns: - `longer`: Aligns the longer edge of the source element with the target edge (e.g., for a 2m x 5m element, uses the 5m edge). - `shorter`: Aligns the shorter edge of the source element with the target edge (e.g., for a 2m x 5m element, uses the 2m edge). - `any` (default): Lets the system automatically choose based on the target edge (use this when the edge choice doesn't matter). - Specify `location` for placement along the target edge: - `center` (default): center the element on that edge. - `available_space`: find the first non-overlapping slot along that edge. - `exact_location`: place using `location_ratio` (0=start, 1=end) of the edge length. - When planner guidance includes an exact target edge index, preserve it exactly in the action instead of translating it back to a coarse side label. - **IMPORTANT**: When the planner specifies "longer edge" or "shorter edge", you MUST set `source_edge` to "longer" or "shorter" accordingly. This is critical for correct orientation. d) **stack_group** actions: - Specify `element_ids` (ordered) and `target_element_id`. - Specify `target_edge_index` when planner guidance identifies an exact target polygon edge; otherwise specify side as with `stack`. - Specify `source_edge` as with `stack` - applies to all elements in the group. - Specify `spacing` between elements in the group (meters). - `location` and `location_ratio` behave like `stack` but apply to the whole group center. e) **align** actions: - Specify element_id (source) and target_element_id (target). - Specify edge: `"shorter"` or `"longer"` - the source element is rotated so its selected edges become parallel to the target's same-type edges. - Only rotation is applied; the element's position is unchanged. f) **cluster** actions: - Specify list of element_ids to cluster (2 or more). - Specify formation: `"grid"` or `"line"`. - Specify edge: `"shorter"` or `"longer"` - the neighboring edge type used to orient the cluster: - `'line'`: each element's selected edge faces the next element; elements are first aligned by this edge type and then arranged along the direction perpendicular to it. - `'grid'`: the selected edge faces neighbors in the row direction; rows are separated perpendicular to this edge and columns run along it. - Specify spacing in meters (gap between closest two points of consecutive/neighboring elements; usually 0.5 to 3.0). - For `formation='grid'`, you MUST also specify: - `rows`: number of rows (first dimension, `>= 1`). - `cols`: number of columns (second dimension, `>= 1`). - `rows * cols` must be `>= len(element_ids)`. - `rows` and `cols` are ignored for `formation='line'`. g) **align_group** actions: - Specify list of element_ids in the group to align. - Specify `edge`: `"shorter"` or `"longer"` - determines which edge type of the **source** elements drives the orientation match. - Optionally specify `target_element_id`: - **With target**: each element is individually rotated so its `edge`-type edges become parallel to the target's reference edges (delegates to the `align` action per element). - **Without target** (default): a median reference angle is computed from all `edge`-type edges across the group, and every element is rotated to match that reference, making the group self-consistent. - Optionally specify `target_edge`: `"shorter"` or `"longer"` - determines which edge type of the **target** element to align to. If omitted, defaults to the same type as `edge`. Only relevant when `target_element_id` is provided. - Only rotation is applied; positions are never changed. - Example: align all pipe segments in a cluster to face the same direction. h) **move_group** actions: - Specify `element_ids` (list of IDs to move together). - Specify `dx`: offset along the x-axis in meters (positive = right, negative = left). - Specify `dy`: offset along the y-axis in meters (positive = up, negative = down). - All elements are translated by the exact same (dx, dy) vector so their relative positions are preserved. - Elements that would land outside layout bounds are skipped with a warning and left in their original position. - Use this when the planner suggests shifting an entire group as a rigid body (e.g., "move all Car Parking elements 2 m to the right"). i) **rotate_group** actions: - Specify `element_ids` (list of IDs to rotate together). - Specify `degrees`: rotation angle (clockwise, added to current rotation of each element). - Specify `pivot`: - `'individual'` (default): each element rotates around its own centroid, changing only orientations while preserving positions. - `'group_centroid'`: all elements orbit around the shared centroid of the group, changing both positions and orientations so the group rotates as a rigid body. - Use `pivot='individual'` when the planner says "rotate all elements in the group to X degrees" without implying movement. - Use `pivot='group_centroid'` when the planner says "rotate the whole group" and spatial positions should change. ## 5. RATIONALE QUALITY Each ActionSequence must include a brief rationale explaining: - What categories/issues this sequence addresses. - What strategy is being used (conservative/aggressive, focused/balanced). - What improvements are expected. ### EXAMPLE "Hard_constraints priority: Eliminates critical overlap between elements 5 and 12 by moving element 5 east by 4m. Then addresses proximity suggestions. Expected to achieve hard_constraints compliance first, then improve assembly score." ## 6. WEIGHT CONSIDERATION **CRITICAL RULE: Hard_constraints ALWAYS has absolute priority, regardless of its weight value. Even if hard_constraints has weight 0.0 or lower than other categories, it MUST be addressed first.** For other categories, respect weights when prioritizing actions: - If a non-hard_constraints category has weight 0.0, you MAY ignore its suggestions. - If a category has weight > 0.0, you SHOULD incorporate its suggestions proportionally to the weight. - High-weight categories (>= 2.0) should dominate your planning. - When generating diverse sequences, vary which medium-weight categories you prioritize, but always respect high-weight categories. **Priority order (strict):** 1. Hard_constraints (absolute priority) 2. Other categories by weight 3. Strategy considerations ## 7. ACTION CONSOLIDATION Before finalising your action sequence, scan for opportunities to replace multiple individual actions with a single equivalent group action. Group operations are semantically cleaner, avoid accidental duplication, and reduce the chance of sequential-execution errors. - **stack to stack_group**: If two or more `stack` actions share the **same `target_element_id` and the same exact target edge** (`target_edge_index` when present, otherwise the same `side`), consolidate them into one `stack_group` action. Preserve `source_edge`, `distance`, `spacing`, and `location` from the original steps. Order the element IDs logically along the target edge. - **move to move_group**: If two or more `move` actions have the **identical `dx` and `dy`** values (e.g., shifting an assembled cluster as a rigid body), consolidate them into one `move_group` action listing all element IDs. - **rotate to rotate_group**: If two or more `rotate` actions specify the **same `degrees`** value and none of them are tied to a positional pivot, consolidate them into one `rotate_group` action with `pivot=individual`. - **align to align_group**: If two or more `align` actions share the **same `target_element_id`, the same `edge`, and the same `target_edge`** (if any), consolidate them into one `align_group` action. Carry over `target_edge` if it was set. If there is no shared target, omit `target_element_id` so the generator uses the median reference angle across the group. Do **not** consolidate when elements differ in their required distances, offsets, angles, source_edges, or target elements --- individual actions are correct in those cases. # CONSTRAINTS ON YOUR BEHAVIOR - When guidance is provided, do not re-evaluate rules or compliance beyond what is needed to resolve conflicts or apply the strategy. - Do not generate vague or ambiguous actions; all actions must have concrete parameters. - Do not generate a rotate action with degrees=0.0 (or any value whose absolute value is < 0.1∘); these are no-ops and must be omitted. If the element is already at the target orientation, skip the rotate action. - Do not generate sequences that are duplicates or near-duplicates; ensure diversity. - Never output anything other than a **single JSON object** with the structure described below. # OUTPUT The ActionSequence has: - `actions`: Array of Action objects (can be empty if no changes needed, but should usually have 1-10 actions). - `rationale`: String explaining the strategy (1-3 sentences). - `priority`: "high", "medium", or "low" based on expected impact. Each Action object has a `type` field and other fields depending on type. ## FORMAT Your **only** output should be a single JSON object that matches the `ActionSequence` schema: ```json "actions": [ "type": "move", "element_id": 5, "dx": -3.5, "dy": 0.0 , "type": "move", "element_id": 11, "dx": 0.0, "dy": 2.0 , "type": "rotate", "element_id": 5, "degrees": 90.0 , "type": "stack", "element_id": 12, "target_element_id": 5, "side": "right", "distance": 0.5 ], "rationale": "Hard_constraints priority: moves element 5 left by 3.5m to eliminate overlap, moves element 11 up by 2.0m for spacing, rotates element 5 for better fit, stacks element 12 adjacently.", "priority": "high" ``` **CRITICAL REMINDER**: Each element_id can appear in AT MOST ONE move action and AT MOST ONE rotate action in the actions array. Before adding an action, verify that element hasn't already been moved or rotated in your sequence. No markdown. No code blocks. No commentary. Just the JSON object. Appendix G Licenses We utilized the following existing assets in our experiments: • PubLayNet [59]: The dataset is publicly available at https://github.com/ibm-aur-nlp/PubLayNet and is released under the Community Data License Agreement – Permissive, Version 1.0 (CDLA-Permissive-1.0). • RICO [7]: The dataset is publicly available at https://interactionmining.org/rico and is released under the Creative Commons Attribution 4.0 International (C BY 4.0) License. • PKU-PosterLayout [17]: The dataset and accompanying code are available through the official repository at https://github.com/PKU-ICST-MIPL/PosterLayout-CVPR2023. The PKU-PosterLayout images are distributed under the Creative Commons Attribution-ShareAlike 4.0 International (C BY-SA 4.0) License, according to the dataset distribution metadata. • Qwen3.6 [40]: The model weights are publicly available at https://huggingface.co/Qwen/Qwen3.6-35B-A3B-FP8 and were used subject to the Apache License 2.0. • Azure OpenAI: The GPT-5.2 model was accessed through the Azure OpenAI Service APIs and used subject to the applicable Microsoft Azure legal terms and service terms. • Qwen3-VL-8B-Instruct [57]: The model weights are publicly available at https://huggingface.co/Qwen/Qwen3-VL-8B-Instruct and are released under the Apache License 2.0. • LayoutDM [19]: We used the official implementation available at https://github.com/CyberAgentAILab/layout-dm, which is released under the Apache License 2.0. • LayoutCoT [44]: We used the official implementation available at https://github.com/HumyuShi/LayoutCoT. At the time of access, the repository did not specify an explicit software license. The accompanying paper is publicly available at https://arxiv.org/abs/2504.10829 under the Creative Commons Attribution 4.0 International (C BY 4.0) License.