Adaptive Relation Library (ARL)
- Adaptive Relation Library (ARL) is a dynamic system that generates and refines symbolic topological predicates, numerical constraints, and Boolean validations for layout synthesis.
- It integrates anchoring, relative, and alignment relations into a closed-loop self-validation framework that repairs and adapts constraints in real time.
- ARL enhances AutoLayout by balancing physical plausibility with semantic consistency, reducing collisions and optimizing object placements.
Searching arXiv for the specified paper and closely related context. Adaptive Relation Library (ARL) is a component of AutoLayout that functions as a collection of symbolic topological predicates together with numerical constraint functions and Boolean validation checks for layout synthesis. In this formulation, ARL describes how objects should be positioned or aligned, but differs from static, hand-designed rule sets because its entries are generated, parameterized, and continually refined by a LLM during the layout process. Within AutoLayout, ARL is part of a closed-loop self-validation mechanism embedded in a slow-fast collaborative reasoning framework, where it supports the generation and evaluation of layouts while mitigating spatial hallucination and balancing physical stability with semantic consistency (Chen et al., 6 Jul 2025).
1. Definition and motivation
In the context of layout synthesis, ARL is defined as a collection of symbolic topological predicates, their numerical constraint functions, and Boolean validation checks. The predicates encode positional and alignment relations such as anchoring, pairwise ordering, stacking, and multi-object alignment. The associated functions evaluate whether a candidate layout satisfies these relations either softly, through a score in , or discretely, through a true/false validation (Chen et al., 6 Jul 2025).
The motivation for ARL is explicitly framed against static, hand-designed rule sets such as “object A must be left of B with at least 5 cm clearance.” ARL entries are instead generated, parameterized, and continually refined by a LLM during the layout process. Three advantages are identified. First, ARL provides flexibility across novel scenes because relations can be added or adjusted on-the-fly rather than hard-coded in advance. Second, it enables code-level self-repair: if a dynamically created constraint is too loose or too strict, the LLM can regenerate its Python implementation at runtime. Third, it supports a better semantic-physical trade-off by learning nuanced commonsense thresholds from natural-language prompts rather than relying on manual trial-and-error (Chen et al., 6 Jul 2025).
A plausible implication is that ARL shifts relational specification from a static engineering artifact to a runtime-adaptive interface between natural-language scene descriptions and executable geometric constraints. In AutoLayout, this interface is directly tied to the system’s broader objective of generating layouts that are both physically plausible and semantically faithful.
2. Internal organization and relation representation
ARL is structured into three parallel sub-libraries: Anchoring Relations, Relative Relations, and Alignment Relations. Each entry contains five elements: a symbolic name and type, a natural-language definition, a Relative Position Coordinate (RPC) template, a constraint function , and a Boolean validation function (Chen et al., 6 Jul 2025).
The three sub-libraries organize relations by arity and functional role. Anchoring relations express placement of an object with respect to a boundary or support region, exemplified by . Relative relations encode binary dependencies such as and . Alignment relations capture multi-object regularities such as (Chen et al., 6 Jul 2025).
Internally, each relation is represented as both a JSON-like record and a small Python module. At runtime, these modules are loaded and their functions are invoked by the fast optimizer for fitness evaluation and by the self-validation checker for consistency testing. This dual representation is important: the JSON-like record provides a structured symbolic description, while the Python module provides executable semantics (Chen et al., 6 Jul 2025).
The following table summarizes the sub-library structure.
| Sub-library | Example relation | Role |
|---|---|---|
| Anchoring Relations | Placement relative to a boundary or support region | |
| Relative Relations | , | Pairwise topological constraints |
| Alignment Relations | 0 | Multi-object alignment constraints |
This representation makes ARL simultaneously symbolic and operational. The symbolic portion supports interpretability and prompting, while the executable portion allows direct participation in optimization and closed-loop correction.
3. LLM-based creation, prompting, and self-repair
ARL is constructed and updated through three classes of prompts, each wrapped with special tags so that they can be parsed and re-sent to GPT-4o or another LLM. The first is the relation definition prompt, whose purpose is to transform an incomplete relation name into a well-formed dictionary entry containing type, definition, and RPC. The paper’s example asks the model to complete a relation named right_above_of using reference entries and to output strictly formatted JSON (Chen et al., 6 Jul 2025).
The second is the constraint function generation prompt. Given a relation name, its natural-language definition, and a scene snippet, the model is asked to write a Python function such as def on_top_of(objs, …): that returns a float in 1 measuring how well bounding boxes satisfy the relation. The third is the validation function generation prompt, which similarly requests a Boolean function such as def is_on_top_of(objs): … that returns True or False. These functions are enclosed within tags so that the fast system can load them on demand (Chen et al., 6 Jul 2025).
A central feature of ARL is runtime self-repair. Whenever, during layout optimization, a constraint or validation fails by raising an exception or by always returning 2 or false, the fast system traps the error and re-issues the relevant prompt to repair the Python snippet. The updated code is then reloaded into the corresponding ARL entry (Chen et al., 6 Jul 2025).
This mechanism makes ARL adaptive in a stronger sense than merely adjusting thresholds. It can also regenerate executable implementations of relations during optimization. The paper explicitly contrasts this with hard-coded rules, which would require manual re-tuning for every new scene style (Chen et al., 6 Jul 2025).
4. Mathematical formalization
ARL is formalized over a set of objects 3, a set of 3D pose parameters 4, and a set of chosen topological relations 5. A relation 6 is represented either as a discrete function
7
or, in soft form, as
8
These definitions place ARL at the interface between symbolic relation selection and continuous geometric evaluation (Chen et al., 6 Jul 2025).
During fine-grained grounding, the overall fitness of a candidate layout 9 is defined as
0
where 1 encodes collision-free (2) and in-boundary (3) metrics. The typical weights are 4 and 5 (Chen et al., 6 Jul 2025).
ARL also includes an explicit threshold-adaptation mechanism driven by closed-loop self-validation. If
6
but
7
the LLM is re-prompted to increase or decrease the threshold 8 by a small factor. The update is written as
9
with conservative learning rate 0 (Chen et al., 6 Jul 2025).
This suggests that ARL is designed not only to score layouts but also to detect mismatches between soft and hard relation semantics. The resulting closed loop links optimization, symbolic validation, and threshold revision.
5. Integration into the AutoLayout pipeline
ARL is integrated into both initialization and the two-stage layout synthesis process of AutoLayout. During initialization, default ARL entries are loaded from cache. For each user-specified new relation name, if the relation is not already present, the system prompts the LLM to create the dictionary entry, generate the constraint function, and generate the validation function (Chen et al., 6 Jul 2025).
In Stage 1, the coarse-grained generation phase, the slow system uses the Reasoning-Reflection-Generation (RRG) pipeline to produce a scene description. The fast system then generates discrete coordinates, extracts relations from the scene description using ARL, and validates those relations. If some object is never placed, the fast system updates placement iteratively until the missing set is empty (Chen et al., 6 Jul 2025).
In Stage 2, the fine-grained grounding phase, a population is initialized from the discrete coordinates. For each candidate in the population, the score begins with 1, and then for each selected relation 2, the system attempts to add 3. If an error occurs, the system prompts the LLM to repair the constraint for 4, reloads the relation, and resumes scoring. The population is then updated by selection, crossover, and mutation. The process terminates early if all constraints pass self-validation on the best candidate (Chen et al., 6 Jul 2025).
The red arrows in Figure 1 are identified as the points where any is_r failure triggers a threshold or code adjustment, thereby forming the closed loop. ARL therefore participates in both relation extraction and relation enforcement, rather than acting solely as a post hoc validation layer.
6. Relation exemplars and representational behavior
Three relation entries are described concretely. The binary relation left_of is defined as “Object A’s max X coordinate is at least 5 units less than object B’s min X.” Its RPC is 6. The associated constraint code computes a distance-based ratio bounded by delta_min=5 and delta_max=50, multiplies it by a Y-axis overlap term, and returns 7 if the ordering condition fails. Its validation function returns whether 8 (Chen et al., 6 Jul 2025).
The binary relation on_top_of is defined as “A’s bottom Z is within a small 9 above B’s top Z, and XY projections overlap by 0.” Its RPC is 1. The provided snippet returns the XY projection overlap when the vertical offset is within eps=2.0, and 2 otherwise (Chen et al., 6 Jul 2025).
The ternary relation align_x_axis is defined as “Three objects share the same Y and Z centroids within tolerance 3.” RPC is not used. The corresponding code checks whether the maximum-minus-minimum spread for these centroid coordinates remains below tol=3 (Chen et al., 6 Jul 2025).
The following table summarizes these exemplars.
| Relation | Type | Key specification |
|---|---|---|
left_of |
Binary | RPC 4; max X of A is at least 5 less than min X of B |
on_top_of |
Binary | RPC 6; bottom Z of A near top Z of B with XY overlap 7 |
align_x_axis |
Ternary | Shared Y and Z centroids within tolerance 8 |
Because these relations are generated by a LLM, ARL can produce relations such as right_above_of or near_of with scene-appropriate thresholds simply by prompting. The paper explicitly presents this as a contrast to hard-coded rules, which would require manual re-tuning for each new scene style (Chen et al., 6 Jul 2025).
7. Empirical evidence and interpretive significance
The empirical evidence reported for ARL comes from an ablation in Table 7 of the main paper. Removing ARL and replacing it with a fixed, manually written rule set causes Collision-Free (CF) to drop from 9 to 0, In-Boundary (IB) to drop from 1 to 2, PSF (overall) to drop from 3 to 4, and the average number of sampling rounds to increase from 5 to 6 (Chen et al., 6 Jul 2025).
These results are interpreted in the source along three axes. First, ARL’s adaptive thresholds substantially reduce object overlap. Second, on-the-fly code repair avoids costly manual debugging. Third, the closed-loop self-validation converges in fewer iterations when ARL entries accurately capture scene-specific spatial norms (Chen et al., 6 Jul 2025).
At the level of the full AutoLayout system, the paper reports validation across 8 distinct scenarios and a significant 7 improvement over SOTA methods in terms of physical plausibility, semantic consistency, and functional completeness (Chen et al., 6 Jul 2025). Since ARL is specifically introduced to mitigate the limitations of handcrafted rules, a plausible implication is that part of this system-level gain depends on ARL’s ability to align natural-language spatial intent with executable geometric checks.
A common misconception would be to view ARL as merely a rule database. The formulation in AutoLayout is broader: ARL is a runtime-adaptive library whose entries include symbolic definitions, numerical scoring functions, Boolean validators, and mechanisms for large-language-model-mediated regeneration and threshold adjustment. In that sense, ARL is the relational substrate through which AutoLayout operationalizes closed-loop layout synthesis under slow-fast collaborative reasoning (Chen et al., 6 Jul 2025).