Orla: Multi-Domain Policy Systems

• Orla is a multifaceted term denoting distinct systems that integrate high-level policy decisions with specialized execution engines across various research domains.
• In mobile manipulation, ORLA* employs a lazy A* search with dynamic buffer allocation and stability checks to achieve up to 25% travel reduction during object rearrangement.
• In LLM workflows, inventory allocation, and wireless coexistence, ORLA frameworks formalize explicit policy layers to enhance system throughput, efficiency, and fairness.

Orla, or ORLA in uppercase, is a homonymous label used for several distinct research systems rather than a single unified concept. In the literature represented here, it denotes: ORLA*, an A*–based algorithm for mobile manipulator object rearrangement; Orla, a library and serving layer for LLM-based multi-agent systems; ORLA, an OR-guided LLM for Allocation in multi-warehouse inventory allocation; and ORLA, an optimal transmission policy for Licensed-Assisted Access coexistence with WiFi in unlicensed spectrum (Gao et al., 2023, Shahout et al., 13 Mar 2026, Xu et al., 28 Jun 2026, Garcia-Saavedra et al., 2018). The shared name masks substantial domain divergence across robotics, LLM systems, operations research, and wireless networking.

1. Nomenclature and domain-specific meanings

The term appears in four technically separate contexts.

Name	Domain	Stated purpose
ORLA*	Mobile manipulation	Compute time-optimal multi-object rearrangement plans for a mobile manipulator
Orla	LLM systems	Construct and run LLM-based agentic systems
ORLA	Inventory allocation	Generate, verify, and select OR formulations for multi-warehouse allocation
ORLA / OLAA	Wireless coexistence	Maximize LAA throughput under a strict fairness constraint with WiFi

ORLA* is explicitly defined as “Object Rearrangement with Lazy A*,” and targets the Mobile Robot Tabletop Rearrangement problem. Orla, by contrast, is presented as a serving layer above existing LLM inference engines, with stage mapping, workflow orchestration, and workflow-level cache management. The allocation-oriented ORLA expands to “OR-guided LLM for Allocation” and integrates formulation generation, solver verification, and aggregation. In wireless networking, ORLA and OLAA are transmission policies derived for asynchronous and synchronous coexistence modes, respectively (Gao et al., 2023, Shahout et al., 13 Mar 2026, Xu et al., 28 Jun 2026, Garcia-Saavedra et al., 2018).

A common misconception is that these works instantiate a single acronym family with shared semantics. The record here does not support that view. The name is reused across unrelated problem classes, and each usage is anchored in a different optimization object: rearrangement cost, workflow execution policy, allocation accuracy, or coexistence throughput.

2. ORLA* in mobile manipulator rearrangement

ORLA* addresses the Mobile Robot Tabletop Rearrangement (MoTaR) problem: given an initial, collision-free arrangement $\mathcal{A}_I$ and a goal arrangement $\mathcal{A}_G$ of $n$ objects on a planar table, allowing stacks, it computes a sequence of over-hand pick-and-place actions $\Pi=\langle a_1,\dots,a_k\rangle$ that moves each object from its start pose to its goal pose while minimizing

$J(\Pi)=dist(\Pi)+C\cdot |\Pi|.$

Here, $dist(\Pi)$ is the total travel distance of the end-effector or mobile base, depending on the reachability model, and $C$ is a constant weight per pick-and-place (Gao et al., 2023).

The method is formulated under two scenarios. In the EE scenario, a compact workspace is reachable from a fixed base, so $dist(\Pi)$ measures end-effector travel. In the MB scenario, a large table requires the base to traverse a closed-loop track, so $dist(\Pi)$ is the base’s path length. The central planning difficulty is joint optimization of manipulation order and robot travel under object–object dependencies, temporary buffering, and, in multi-layer settings, pile stability.

ORLA* represents search states as arrangements of all $n$ objects. A Deterministic State (DS) assigns a fixed pose to every object. A Non-Deterministic State (NDS) arises when one or more objects have been sent to a buffer but their exact buffer poses have not yet been committed. From any state, the planner may pick any graspable object, meaning an object with no object above it, and place it either directly at its goal pose if that pose is collision-free and dependencies have been met, or at an as-yet-unallocated buffer.

Its A* structure uses exact path cost $\mathcal{A}_G$0, admissible and consistent heuristic $\mathcal{A}_G$1, and score

$\mathcal{A}_G$2

with

$\mathcal{A}_G$3

The heuristic assumes one pick-and-place per unplaced object plus shortest straight-line or cyclic-track distance, ignoring buffer detours, and therefore never overestimates.

The distinguishing mechanism is lazy evaluation of buffer placements. When an action uses a buffer, ORLA* does not immediately compute where in the workspace the displaced object will sit. Instead, the search introduces an NDS carrying a symbolic buffer placeholder, and the travel cost to and from that buffer is deferred until the NDS is expanded or the next DS is reached. This prunes large swaths of the continuous buffer-pose space while preserving optimality at the DS level. The paper states that if the heuristic sampling-based buffer-allocation procedure is replaced with an exact solver, such as a mixed-integer nonlinear program, and stability checks are perfect, then ORLA* guarantees global optimality.

For stackable tasks, ORLA* supports multi-layered rearrangement subject to stability constraints. A learned model, StabilNet, implemented as a ResNeSt-based CNN, takes two $\mathcal{A}_G$4 depth images—the top view of the environment and the underside of the held object—and outputs the probability that a candidate placement will not topple. Unstable buffer or final placements are rejected.

The reported empirical picture combines ablation and cross-benchmark comparison. On disc instances at density $\mathcal{A}_G$5 with $\mathcal{A}_G$6 up to $\mathcal{A}_G$7, ORLA*–Full reduces travel by $\mathcal{A}_G$8–$\mathcal{A}_G$9 versus a variant optimizing only action count, without more picks. Lazy buffer allocation outperforms immediate greedy sampling, cutting both picks and travel and solving more instances within time limits. On general-shaped objects using $n$0–$n$1 YCB models, ORLA* achieves $n$2 lower end-effector travel in small tables and $n$3 lower base travel in large tables, uses no more pick-and-places than state-of-the-art MCTS or TRLB, and maintains high success rates at moderate planning times. StabilNet generalizes to unseen shapes such as bananas and tea-boxes, correctly rejecting unstable placements with $n$4 accuracy. The worst-case time complexity remains exponential in $n$5, as with complete combinatorial rearrangement search (Gao et al., 2023).

3. Orla as a serving layer for LLM-based multi-agent systems

Orla is introduced as an open-source library and serving layer for LLM-based agentic systems. Its defining abstraction is a separation between request execution and workflow-level policy. Rather than manually composing orchestration code with LLM serving engines and tool execution logic, developers define workflows composed of stages, while Orla manages how those stages are mapped, executed, and coordinated across models and backends (Shahout et al., 13 Mar 2026).

The three user-visible abstractions are Stage, Workflow, and Backend. A Stage is the unit of work that executes an LLM call and may include iterative tool loops; it specifies a target backend and model, inference parameters, and an optional set of tools. A Workflow is a directed acyclic graph of stages whose edges encode dependencies, with prompts built from upstream outputs via a user-supplied builder function. A Backend is any LLM serving endpoint accessed via an OpenAI-compatible HTTP API, and Orla treats backends such as vLLM, SGLang, Ollama, or a simulated latency-model backend identically.

Above that abstraction layer, Orla introduces a three-part workflow-level control plane. The Stage Mapper assigns each stage to a model and backend, either by explicit mapping or through a pluggable policy. The paper describes a ThresholdStageMapper, for example routing by prompt length, and a OneBitStageMapper, which makes a quick LLM call on a tiny router model to classify a request as simple or complex and route it to a light or heavy model. The Workflow Orchestrator enforces dependencies, schedules ready stages, carries context and resources across the workflow lifetime, overlaps tool waits with other in-flight stages, and dynamically reroutes under backend load. Its scheduling is two-level: each backend maintains per-stage sub-queues keyed by stage UUID, a StageScheduler chooses across stage queues, and a RequestScheduler chooses within a stage queue. The Memory Manager operates at workflow granularity rather than per-request granularity, coordinating KV-cache preservation and eviction via lifecycle signals such as stage start, stage finish, and workflow completion.

Three built-in memory policies are specified. Preserve on Small Increments retains the existing KV cache when consecutive stages on the same model and backend differ by at most a threshold in context length,

$n$6

Flush at Workflow Boundaries proactively flushes cache when a workflow completes or transitions to a different backend or model. Flush Under Pressure polls backend cache utilization and, if utilization exceeds a threshold $n$7, greedily evicts the oldest idle workflow’s cache. The text states that these workflow-aware policies jointly reduce time-to-first-token and avoid mid-workflow evictions that plague request-level LRU schemes.

The architecture is organized as four layers: hardware runtime; LLM serving engines such as vLLM, SGLang, and Ollama; Orla itself, consisting of StageMapper, Orchestrator, and MemoryManager; and application code defining stages, tools, and workflows.

Evaluation is reported on a single 96 GB GPU server. On SWE-bench Lite, comprising 2 294 bug-fix requests, the baseline sends all requests to Qwen3-8B on vLLM, while Orla uses OneBitStageMapper to route $n$8 of requests to Qwen3-4B and the rest to Qwen3-8B on vLLM backends. Reported gains are wall-clock time down $n$9, mean per-request completion time down $\Pi=\langle a_1,\dots,a_k\rangle$0, and estimated inference cost down $\Pi=\langle a_1,\dots,a_k\rangle$1. In the cache-management experiment on DAG-MATH-Formatted-CoT, consisting of 5 multi-stage math problems and 2 894 requests on SGLang plus Qwen3-8B, workflow-level caching reduces time-to-first-token relative to flush-per-request, and the entire CDF shifts left.

The stated limitations are architectural rather than conceptual. Memory management currently relies on SGLang’s Cache API; vLLM and Ollama lack a standard cache-control interface, so Orla falls back to backend-level eviction in those cases. Built-in scheduling policies such as FCFS, priority, and threshold routing are described as a proof of concept. Distributed or multi-GPU orchestration is not yet explored (Shahout et al., 13 Mar 2026).

4. ORLA for multi-warehouse inventory allocation

In supply-chain optimization, ORLA denotes an OR-guided LLM for Allocation aimed at balance-oriented multi-warehouse inventory allocation. The setting considers a single SKU distributed across $\Pi=\langle a_1,\dots,a_k\rangle$2 warehouses indexed by $\Pi=\langle a_1,\dots,a_k\rangle$3, with on-hand inventory $\Pi=\langle a_1,\dots,a_k\rangle$4, forecast daily demand $\Pi=\langle a_1,\dots,a_k\rangle$5, total replenishment quantity $\Pi=\langle a_1,\dots,a_k\rangle$6, and allocation decision variables $\Pi=\langle a_1,\dots,a_k\rangle$7. The hard-budget constraint is

$\Pi=\langle a_1,\dots,a_k\rangle$8

The core balance quantity is the post-allocation Target Inventory Days

$\Pi=\langle a_1,\dots,a_k\rangle$9

and the system-level benchmark

$J(\Pi)=dist(\Pi)+C\cdot |\Pi|.$0

which is constant given $J(\Pi)=dist(\Pi)+C\cdot |\Pi|.$1 (Xu et al., 28 Jun 2026).

Given band parameters $J(\Pi)=dist(\Pi)+C\cdot |\Pi|.$2, warehouse $J(\Pi)=dist(\Pi)+C\cdot |\Pi|.$3 is accurately allocated if

$J(\Pi)=dist(\Pi)+C\cdot |\Pi|.$4

Allocation accuracy, also called balance rate, is defined as

$J(\Pi)=dist(\Pi)+C\cdot |\Pi|.$5

The objective is to satisfy side constraints while maximizing balance, typically by minimizing deviations from $J(\Pi)=dist(\Pi)+C\cdot |\Pi|.$6 or maximizing $J(\Pi)=dist(\Pi)+C\cdot |\Pi|.$7.

The framework develops three complementary MILP formulation families. The Sum-of-Deviations formulation minimizes total absolute deviation of warehouse TID from $J(\Pi)=dist(\Pi)+C\cdot |\Pi|.$8 and admits a linearized form using auxiliary $J(\Pi)=dist(\Pi)+C\cdot |\Pi|.$9. The Soft Band Compliance formulation introduces slacks $dist(\Pi)$0 and $dist(\Pi)$1 to allow controlled violations of the target band and penalizes under- and over-shoot. The Knapsack-Inspired Allocation formulation introduces binary $dist(\Pi)$2 indicating whether warehouse $dist(\Pi)$3 is within band, reward variables $dist(\Pi)$4 to count compliant allocations, and deviation penalties $dist(\Pi)$5, with objective

$dist(\Pi)$6

The system also provides a modular side-constraint library, labeled OC1–OC9, covering ratio bounds, case-pack sizes, group-level shares, served-warehouse limits, and related requirements. When hard constraints conflict, a penalty-based relaxation introduces nonnegative slack variables and modifies the objective to restore feasibility with minimal violation.

A distinctive contribution is the PMC pipeline: Problem–Model–Code. Each instance is represented as a triple consisting of a textual or semi-structured problem specification $dist(\Pi)$7, an exact OR model $dist(\Pi)$8, and executable solver code $dist(\Pi)$9. Given $C$0, the LLM is prompted to output $C$1 and $C$2. During SFT plus preference-optimization using KTO, the model learns to avoid non-linear hallucinations, missing constraints, and type errors. Solver-in-the-loop verification then checks executability, feasibility, and solution quality. If a candidate is infeasible, automated feasibility restoration triggers penalty-based relaxation and re-solves.

To address instance heterogeneity, ORLA generates $C$3 candidate formulations and codes, executes them, predicts realized quality with LightGBM regressors on instance features, selects the top $C$4 experts, and aggregates their outputs using score-aware softmax weights

$C$5

Because the fused plan may be fractional or violate side rules, a repair MILP is solved:

$C$6

subject to the original constraints, $C$7, and $C$8.

The empirical evaluation uses 29 production batches from JD.com, with allocation accuracy $C$9 as the metric. The best single OR formulation, identified as KI, improves allocation accuracy by 3.4 percentage points over the incumbent approach and improves 26 of 29 batches. The full ORLA framework, including formulation selection and aggregation, yields a 4.5 percentage-point overall improvement and also improves allocation accuracy in 26 of the 29 evaluation batches. The post-training regime achieves 100% code syntax accuracy and reduces solver-execution failure to 0.1%. A plausible implication is that the framework’s main gain does not come from LLM text generation alone, but from coupling generation to solver verification and downstream selection (Xu et al., 28 Jun 2026).

5. ORLA and OLAA in unlicensed-spectrum coexistence

In unlicensed wireless networking, ORLA and OLAA are optimal transmission policies derived for coexistence between Licensed-Assisted Access and WiFi under a strict fairness requirement. The design goal is twofold: first, the presence of an LBT node should not hurt any incumbent WiFi station more than the addition of one extra fully-backlogged WiFi station; second, the LBT node should maximize its own long-term throughput or airtime fraction subject to that fairness constraint (Garcia-Saavedra et al., 2018).

The key mechanism is orthogonal Listen-Before-Talk via LIFS. ETSI allows an LBT device to seize the channel after sensing the medium idle for 20 $dist(\Pi)$0s of energy detection, called LIFS. WiFi stations defer until an AIFS or DIFS of at least 34 $dist(\Pi)$1s has elapsed. By transmitting after LIFS, the LBT node captures idle periods that WiFi stations will not contend for. The consequence is collision-free coexistence: WiFi-to-LBT collisions are eliminated because WiFi does not start transmission before 34 $dist(\Pi)$2s, and LBT-to-WiFi collisions are impossible because after an LBT burst the channel is busy, and when it becomes idle again WiFi still waits at least 34 $dist(\Pi)$3s.

Under saturated homogeneous WiFi, the paper defines attempt, success, idle, and transmission probabilities and derives a closed-form upper bound $dist(\Pi)$4 on the fraction of would-be idle slots that may be converted into LBT bursts while satisfying fairness. The ORLA transmission rule is then Bernoulli: at each LIFS opportunity, the LBT node transmits a burst of length $dist(\Pi)$5 with probability

$dist(\Pi)$6

using $dist(\Pi)$7 to exhaust the fairness bound. The text states that this policy is airtime- and throughput-optimal among random access policies satisfying the fairness constraint.

The framework is extended to non-saturated and heterogeneous WiFi through a renewal-reward analysis of station attempt probabilities and a new bound on $dist(\Pi)$8 based on aggregate airtime. Under light load, when $dist(\Pi)$9 and LIFS opportunities become scarce, the LBT node may transmit up to

$dist(\Pi)$0

back-to-back bursts, shortening the last burst if needed.

OLAA is the synchronous counterpart. It handles frame-aligned operation, where the LBT node must start transmission on a fixed boundary such as the next 1 ms LTE TTI. After a LIFS opportunity, the node may reserve the channel and wait for the next boundary or skip and try again. The decision is posed as an optimal stopping problem with maximal-rate-of-return fixed point, and the policy transmits if

$dist(\Pi)$1

The paper states that this rule preserves the fairness bound and is throughput-optimal among synchronous policies.

Performance evaluation is extensive. When aggregating packets, IEEE 802.11ac WiFi can be more efficient than 3GPP LAA, whereas ORLA and OLAA can attain 100% higher throughput without harming WiFi. Long U-LTE frames can incur up to 92% throughput losses on WiFi when using 3GPP LAA, whilst ORLA and OLAA sustain $dist(\Pi)$2 gains at no cost, including in the presence of non-saturated WiFi and multi-rate scenarios. In saturated homogeneous WiFi with MPDU = 1500 B and $dist(\Pi)$3 ms, 3GPP LAA can consume up to 6× more airtime than a WiFi node and slash WiFi throughput by 50%, whereas ORLA doubles LTE throughput and keeps WiFi unchanged. Under standard contention-window settings, ORLA and OLAA achieve 100–200% throughput gains and never degrade WiFi; with $dist(\Pi)$4 ms, 3GPP LAA may temporarily boost LTE by 800+% but at the cost of 90% WiFi loss, while ORLA still delivers $dist(\Pi)$5 LTE gain with zero WiFi loss (Garcia-Saavedra et al., 2018).

6. Comparative interpretation and research significance

Across these distinct literatures, the recurrent role of “Orla” is not semantic unity but a repeated emphasis on policy layers that sit above a lower-level execution substrate. In ORLA*, lazy A* search operates above concrete buffer-pose allocation and learned stability checking. In the LLM-serving Orla, workflow-level policy is separated from backend execution. In the allocation framework, natural-language problem descriptions are transformed into solver-ready formulations whose quality is verified and selected through optimization feedback. In wireless coexistence, ORLA imposes a fairness-constrained channel-access policy above the incumbent WiFi MAC. This suggests that the repeated naming aligns with a common architectural instinct: make discrete control decisions explicit, then couple them to a lower-level engine with measurable guarantees.

The guarantees, however, are domain-specific and often conditional. ORLA* is globally optimal only if buffer allocation is solved optimally and stability checks are perfect. Orla’s workflow-level cache management currently depends on SGLang’s Cache API for direct cache control. Inventory-allocation ORLA restores infeasible instances through penalty-based relaxation, which preserves executability but changes the effective objective. ORLA and OLAA in wireless networking guarantee fairness relative to the benchmark of adding one extra fully-backlogged WiFi station, not arbitrary fairness notions. These distinctions are important because the shared label can obscure materially different notions of optimality, feasibility, and system scope.

For researchers, the principal significance of the name lies less in cross-domain transfer than in a pattern of methodological composition. Each Orla variant combines a high-level planner or selector with a subordinate mechanism that resolves continuous, infrastructural, or solver-level detail. That pattern is explicit in lazy search plus buffer optimization, stage mapping plus orchestration plus memory management, PMC generation plus solver verification plus aggregation, and fairness-bound derivation plus orthogonal LIFS access. A plausible implication is that the reuse of the label reflects a broader design vocabulary in contemporary systems research: move policy into an explicit layer, formalize its objective, and then expose interfaces to heterogeneous execution backends (Gao et al., 2023, Shahout et al., 13 Mar 2026, Xu et al., 28 Jun 2026, Garcia-Saavedra et al., 2018).