Context-Aware Synthesis of Optimization Pipelines for Warehouse Optimization

# Context-Aware Synthesis of Optimization Pipelines for Warehouse Optimization
Source: [https://arxiv.org/html/2606.26852](https://arxiv.org/html/2606.26852)
Anne Meyer[https://orcid.org/0000-0001-6380-1348](https://orcid.org/0000-0001-6380-1348)Uta Mohring[https://orcid.org/0000-0001-9218-0536](https://orcid.org/0000-0001-9218-0536)Fabian Dunke[https://orcid.org/0000-0002-4805-9576](https://orcid.org/0000-0002-4805-9576)Maximilian Barlang[https://orcid.org/0009-0005-8081-4286](https://orcid.org/0009-0005-8081-4286)Özge Nur SubasHadi Kutabi[https://orcid.org/0000-0002-6023-7742](https://orcid.org/0000-0002-6023-7742)Stefan Nickel[https://orcid.org/0000-0002-8339-0117](https://orcid.org/0000-0002-8339-0117)Kai Furmans[https://orcid.org/0000-0001-6009-5564](https://orcid.org/0000-0001-6009-5564)

###### Abstract

Order fulfillment in manual picker\-to\-goods warehouses involves interconnected decisions such as item assignment, order batching, and picker routing\. While integrated models capture interactions between these decisions, practical warehouse systems often require decomposed approaches due to organizational boundaries, differing responsibilities, or limited data availability\. Existing studies primarily evaluate algorithms for isolated subproblems or fixed subproblem combinations for specific warehouse settings, but lack a general mechanism to determine applicable algorithm configurations, compose them into valid solution pipelines, and assess their performance\.

With Context\-Aware Synthesis of Optimization Pipelines \(CASOP\), we propose a framework for constructing and evaluating context\-specific optimization pipelines and apply these to order fulfillment\. The framework comprises: \(1\) a modular repository of algorithms for common order fulfillment problems; \(2\) semantic data and algorithm cards to describe warehouse context and algorithm requirements; \(3\) a taxonomy that structures order fulfillment problems into relevant subproblems; \(4\) a pipeline synthesizer that identifies applicable algorithms for a given warehouse context and composes all valid optimization pipelines; and \(5\) a pipeline evaluator that assesses all resulting pipelines\. We demonstrate the framework on 7 benchmark instance sets covering four problem classes, resulting in 1,063,044 valid pipelines\. The framework supports researchers and practitioners in designing, automatically synthesizing, and selecting valid, high\-performing algorithmic pipelines for warehouse operations\. The software is open\-source and available at[github\.com/kit\-dsm/ware\_ops\_pipes](https://github.com/kit-dsm/ware_ops_pipes)and[github\.com/kit\-dsm/ware\_ops\_algos](https://github.com/kit-dsm/ware_ops_algos)\.

###### keywords:

Warehouse optimization , Algorithm selection , Pipeline synthesis , Order fulfillment

††journal:Journal to be define\\affiliation

\[inst1\]organization=Institute for Information Management in Engineering, Karlsruhe Institute of Technology, country=Germany\\affiliation\[inst2\]organization=Department of Business Administration, University of Zurich, country=Switzerland

\\affiliation

\[inst3\]organization=Institute for Operations Research, Karlsruhe Institute of Technology, country=Germany

\\affiliation

\[inst4\]organization=Institute for Material Handling and Logistics,Karlsruhe Institute of Technology, country=Germany

## 1Introduction

Warehouse systems differ widely in their physical layout, technical equipment, IT systems, degree of automation, and operating processes\. Figure[1](https://arxiv.org/html/2606.26852#S1.F1)illustrates this variation with examples ranging from robotic fulfillment systems over manual distribution centers to block\-stacking warehouses\. These differences affect not only operational performance, but also which optimization problems arise and which solution approaches can be applied\.

![Refer to caption](https://arxiv.org/html/2606.26852v1/images/warehouse_systems_v3.png)Figure 1:Overview of different types of warehouse systems\. A robotic mobile fulfillment center of Amazon \(left,Amazon\.com, Inc\. \([2024](https://arxiv.org/html/2606.26852#bib.bib51)\), reproduced with permission\)\. The distribution center of a grocery retailer \(center, photo by Nick Saltmarsh, CC BY 2\.0, via Wikimedia Commons\)\. A block\-stacking warehouse for metal profiles \(right, courtesy of Protektorwerk Florenz Maisch GmbH & Co\. KG, reproduced with permission\)\.In the broader context of warehouse optimization, this paper focuses on order fulfillment in manual picker\-to\-goods systems, where pickers walk to storage locations to retrieve items ordered by customers, typically using carts to carry the retrieved items\. Unlike automated warehouse systems, whose fixed hardware capacity is typically dimensioned for peak loads and may therefore remain underutilized during periods of lower demand, manual picker\-to\-goods systems retain substantial operational flexibility\(Boysen and de Koster,[2025](https://arxiv.org/html/2606.26852#bib.bib52)\)\.

However, this flexibility can only be effectively exploited if the arising operational decision problems are addressed\. Order fulfillment comprises several interrelated decision problems: item assignment, order batching, picker routing, and picker scheduling\. Theitem assignment problemselects, for each requested article, the storage location\(s\) from which it is picked\. Theorder batching problemgroups customer orders into sets retrieved in a single picker tour, subject to picker capacity\. Thepicker routing problemdetermines the path for collecting items from a given pick list, typically modeled as a variant of the traveling salesperson problem \(TSP\)\. Thepicker scheduling problemassigns batches or tours to pickers and orders their execution, with objectives such as tardiness or makespan\.

Each subproblem has been extensively studied in isolation and partially integrated approaches have also been studied, combining, for example, batching and routing; we refer to\(de Kosteret al\.,[2007](https://arxiv.org/html/2606.26852#bib.bib9); Guet al\.,[2007](https://arxiv.org/html/2606.26852#bib.bib10); Boysenet al\.,[2019](https://arxiv.org/html/2606.26852#bib.bib34); Pardoet al\.,[2024](https://arxiv.org/html/2606.26852#bib.bib21); Bocket al\.,[2025](https://arxiv.org/html/2606.26852#bib.bib43)\)for comprehensive reviews\. Although integrated solution approaches for subsets of these problems in order fulfillment exist \(see e\.g\.van Gilset al\.\([2019](https://arxiv.org/html/2606.26852#bib.bib1)\)\), their applicability in practical settings is limited due to organizational boundaries, heterogeneous scopes of responsibility, or limited data availability\(Boysen and de Koster,[2025](https://arxiv.org/html/2606.26852#bib.bib52)\)\. Motivated by this,Boysen and de Koster \([2025](https://arxiv.org/html/2606.26852#bib.bib52)\)recently raised the following important research question: which planning problems in warehouse operations can be decomposed into independently solved models while still preserving substantial solution quality relative to a comprehensive model? This shifts the focus from proposing ever\-larger integrated models to understanding which decompositions are valid, practically applicable, and well\-performing in a given warehouse context\.

Existing work provides only partial answers to this question\. For example,Pardoet al\.\([2024](https://arxiv.org/html/2606.26852#bib.bib21)\)propose a taxonomy to structure variants of order batching problems into subproblems\. However, the taxonomy does not cover the full order fulfillment process considered here\. In particular, it does not consider item assignment, treats routing as a batching\-related task, and does not represent picker scheduling as a separate subproblem\. In general, benchmark studies from the warehouse literature often compare a limited set of manually selected algorithms for a specific problem setting\(Petersen and Schmenner,[1999](https://arxiv.org/html/2606.26852#bib.bib12); van Gilset al\.,[2019](https://arxiv.org/html/2606.26852#bib.bib1); Bahçeci and Öncan,[2022](https://arxiv.org/html/2606.26852#bib.bib6)\)\. This becomes limiting when a larger number of order fulfillment subproblems and possible configurations of individual algorithms are considered simultaneously\. A solution approach may solve the subproblems sequentially, or it may solve selected parts in an integrated way, for example, batching and routing\. The algorithms themselves might be configurable, and different configurations might perform better or worse depending on the warehouse context\. Furthermore, not every algorithm is applicable to a given warehouse context, and not every combination of algorithms forms a valid solution approach\. Algorithms may exploit specific layout structures such as those of parallel\-aisle warehouse layouts\(Heßler and Irnich,[2024](https://arxiv.org/html/2606.26852#bib.bib17)\)\. Other solution approaches for subproblems, such as item assignment, are only required if the warehouse follows a scattered storage policy\.

Therefore, answering the decomposition question raised byBoysen and de Koster \([2025](https://arxiv.org/html/2606.26852#bib.bib52)\)requires a framework that is able to not only select the best algorithm based on performance, but also identify applicable algorithms, compose them into valid optimization pipelines, and evaluate them in a given warehouse context\.

This connects warehouse optimization to three related research streams\. Algorithm selection provides methods for choosing among alternative solvers for a given problem instance\(Xuet al\.,[2008](https://arxiv.org/html/2606.26852#bib.bib22); Bischlet al\.,[2016](https://arxiv.org/html/2606.26852#bib.bib23)\)\. Semantic modeling provides means to describe domain knowledge and make assumptions explicit\(Negriet al\.,[2017](https://arxiv.org/html/2606.26852#bib.bib15); Knollet al\.,[2019](https://arxiv.org/html/2606.26852#bib.bib35)\)\. Type\-based synthesis approaches, such as the Combinatory Logic Synthesizer, show how repositories of typed components can be used to generate valid compositions, for example, for scheduling heuristics\(Mäckelet al\.,[2021](https://arxiv.org/html/2606.26852#bib.bib46)\)\. CLS\-Luigi extends this idea to the generation and execution of executable data pipelines from algorithm repositories\(Meyeret al\.,[2024](https://arxiv.org/html/2606.26852#bib.bib20)\)\. However, their integration for complex warehouse optimization remains largely unexplored\. None of the existing frameworks links warehouse context, algorithm requirements, pipeline construction, and performance evaluation across multiple order fulfillment problems\.

We propose CASOP, a framework for context\-aware synthesis of optimization pipelines for warehouse optimization\. As we illustrate in Figure[2](https://arxiv.org/html/2606.26852#S1.F2), we use a taxonomy to decompose problems into their subproblems and go beyond traditional algorithm selection by explicitly considering warehouse context and algorithm requirements in the form of semantic data and algorithm cards\. This allows us to compose and identify well\-performing and valid optimization pipelines from an algorithm repository tailored to a warehouse context\. CASOP comprises the following features:

1. 1\.A modular algorithm repository: Reusable algorithm implementations for key order fulfillment subproblems provided through harmonized interfaces\.
2. 2\.Semantic representation of warehouse context and algorithm requirements: A machine\-readable description of warehouse system characteristics in the form of a data card, covering layout, articles, orders, resources, and storage\. Machine\-readable description of algorithm requirements in the form of an algorithm card\.
3. 3\.Problem taxonomy and pipeline template: A taxonomy decomposing order fulfillment problems into subproblems and a corresponding pipeline template covering four problem classes\.
4. 4\.Context\-specific algorithm selection: Matching of warehouse features to algorithm requirements to identify the applicable algorithms for each subproblem\.
5. 5\.Automated pipeline synthesis: Generation of all valid pipelines from the space of applicable algorithms through combinatory logic synthesis and runtime\-efficient execution of all pipelines to identify the best\-performing configuration\.

Based on these features, CASOP supports a systematic evaluation of algorithmic design choices for a given warehouse context\. Rather than relying on manually selected algorithm combinations, the framework identifies applicable components, composes valid pipelines, and evaluates their performance\.

We apply CASOP to 7 instance sets covering four problem classes, namely the single picker routing problem with and without scattered storage \(SPRP, SPRP\-SS\), order batching and picker routing problem \(OBRP\), and the order batching, picker routing, and scheduling problem \(OBRSP\)\. To the best of our knowledge, these problems and the corresponding subproblems have not been studied jointly in the literature yet\.

![Refer to caption](https://arxiv.org/html/2606.26852v1/x1.png)Figure 2:Main contributions of the paper and delimitation from classical algorithm selection\. Unlike classical algorithm selection, CASOP explicitly considers the warehouse context and provides automated pipeline synthesis\.The remainder of this paper is organized as follows\. Section[2](https://arxiv.org/html/2606.26852#S2)reviews related work on algorithm selection, semantic modeling, and pipeline generation\. Section[3](https://arxiv.org/html/2606.26852#S3)defines the operational decision problems considered\. Section[4](https://arxiv.org/html/2606.26852#S4)presents the CASOP framework\. Section[5](https://arxiv.org/html/2606.26852#S5)reports on the experimental validation of the framework, followed by a conclusion in Section[6](https://arxiv.org/html/2606.26852#S6)\.

## 2Related Work

In this section, we review work related to ours, namely, algorithm selection approaches in warehouse optimization and related fields, semantic and information modeling for representing systems and algorithms, and automated pipeline synthesis\. These areas provide the foundation for the context\-aware and performance\-based selection of algorithms, yet there is currently no approach that achieves an integrated view to facilitate automated warehouse decision\-making\.

### 2\.1Algorithm Selection in Warehouse Order Fulfillment

Research on algorithm selection has shown that per\-instance learning approaches can significantly outperform single solvers in domains such as SAT\(Xuet al\.,[2008](https://arxiv.org/html/2606.26852#bib.bib22)\)and job\-shop scheduling\(Mülleret al\.,[2022](https://arxiv.org/html/2606.26852#bib.bib24)\)\. By contrast, in warehouse optimization, approaches for algorithm selection remain underdeveloped, although researchers have observed that for problems like picker routing and order batching, the performance of heuristics can depend highly on warehouse characteristics, such as warehouse layout, number of picks or orders, and item distributions\. Early works compared combinations of routing and storage policies\(Petersen and Schmenner,[1999](https://arxiv.org/html/2606.26852#bib.bib12)\), while later studies expanded these comparisons to include simple constructive batching approaches, zoning, and routing strategies under differing storage strategies, order sizes and batch capacities\(van Gilset al\.,[2019](https://arxiv.org/html/2606.26852#bib.bib1); Bahçeci and Öncan,[2022](https://arxiv.org/html/2606.26852#bib.bib6)\)\.

Hennet al\.\([2010](https://arxiv.org/html/2606.26852#bib.bib5)\)present a local search approach to the OBRP, which is configured with the routing policies, largest gap, and S\-shape\. The study confirms previous results on routing algorithm selection, i\.e\., selecting largest gap when the number of articles to be picked is small and S\-shape when there are more articles to be picked\.van Gilset al\.\([2019](https://arxiv.org/html/2606.26852#bib.bib1)\)evaluate the impact of varying combinations of storage, batching, zoning, and routing strategies\. The authors provide an overview of prior work on combinations of different planning problems in warehouse operations\.Lükeet al\.\([2024](https://arxiv.org/html/2606.26852#bib.bib16)\)present a novel, exact solution approach to the single picker routing problem with scattered storage, based on a dynamic programming formulation\. Well\-known routing heuristics, such as S\-shape, return, or largest gap, are formulated with a similar approach\. The authors compare different combinations of routing algorithms and storage policies with varying order sizes and find that increased scattering of C\-articles has a larger effect on tour lengths compared to only scattering A\-articles\.

Beyond these studies, research is moving toward automated or learning\-based algorithm selection for warehouse operations problems\. For example,Chenget al\.\([2024](https://arxiv.org/html/2606.26852#bib.bib26)\)introduce a deep reinforcement learning hyper\-heuristic that adaptively selects an order batching strategy from a pool of heuristics\. The learned selector significantly outperforms any single heuristic across a variety of test scenarios\.Benavides\-Robleset al\.\([2025](https://arxiv.org/html/2606.26852#bib.bib25)\)explore a hyper\-heuristic approach to the pod relocation problem in a robotic mobile fulfillment system \(RMFS\), a form of automated goods\-to\-person system, effectively treating it as an algorithm selection challenge\. They develop a portfolio of six heuristics for pod allocation and design 20 different sequence\-based hyper\-heuristics, which are allocated varying time budgets\. The two key contributions are a publicly available simulation framework for RMFS and the implementation of solution strategies\. Neither is given for problems in manual warehouse operations\.

Instead, algorithm selection is typically driven by expert knowledge and scenario\-specific assumptions, limiting reproducibility and generalization\. WhileHeßler and Irnich \([2024](https://arxiv.org/html/2606.26852#bib.bib17)\)propose a tabular mapping of routing algorithms against instance dimensions such as demand, number of blocks, and item scattering, this representation is limited to a single problem type and is not easily extendable to other decision stages\. Efforts to generalize routing models, for example, by extending the TSP formulation to unconventional layouts such as fishbone or flying\-V\(Wildtet al\.,[2025](https://arxiv.org/html/2606.26852#bib.bib13)\), demonstrate the growing diversity of applicable algorithms, but also highlight the increasing need for a structured applicability model\.

##### Gap: No systematic mapping between problem features and solver applicability

Although several studies vary the warehouse characteristics, such as storage policies, order sizes, or item scattering to compare solution approaches\(Bahçeci and Öncan,[2022](https://arxiv.org/html/2606.26852#bib.bib6); Heßler and Irnich,[2024](https://arxiv.org/html/2606.26852#bib.bib17); Lükeet al\.,[2024](https://arxiv.org/html/2606.26852#bib.bib16)\), no approach explicitly links the warehouse context to algorithm requirements\. Current practice remains largely dependent on expert knowledge, which limits reproducibility, transferability, and automation of algorithm selection\. We address this gap by introducing a mapping procedure based on warehouse features and algorithm requirements\.

### 2\.2Information Modeling

##### Data Models for Warehouse Operations

In the context of warehouse optimization, no unified modeling approach to represent warehouse data has been identified\.Oxenstiernaet al\.\([2021](https://arxiv.org/html/2606.26852#bib.bib7)\)were the first to mention the lack of standardized data formats in the context of order batching problems\. To alleviate this, they publish an instance benchmark dataset based on the TSPLIB format for TSP\. Each instance is represented as a JSON file containing information on the storage locations and obstacles of a digital warehouse model\. Although this dataset is public, the lack of documentation makes it difficult to reproduce or adopt the data model\. In particular,Heßler and Irnich \([2024](https://arxiv.org/html/2606.26852#bib.bib17)\)made a significant contribution to standardizing instance representations by converting instances from multiple previous works into a unified format\. They include instances for single picker routing and the order batching and picker routing problem fromBahçeci and Öncan \([2022](https://arxiv.org/html/2606.26852#bib.bib6)\); Žuljet al\.\([2018](https://arxiv.org/html/2606.26852#bib.bib3)\); Hennet al\.\([2010](https://arxiv.org/html/2606.26852#bib.bib5)\); Muter and Öncan \([2015](https://arxiv.org/html/2606.26852#bib.bib2)\); Heßler and Irnich \([2024](https://arxiv.org/html/2606.26852#bib.bib17)\)\. Although this serves as a starting point, the instance format ofHeßler and Irnich \([2024](https://arxiv.org/html/2606.26852#bib.bib17)\)encodes several fixed assumptions that constrain both its expressiveness and its adaptability to new problem settings\. For example, a single depot location is assumed, and, besides a generic pick capacity, no information about picker resources is modeled, such as travel or picking speed\. Further, the warehouse layout is given in a parameterized fashion, in terms of the number of aisles, number of pick locations, and fixed distances between them\. This makes it difficult to describe real\-life or unconventional layouts\.

de Assiset al\.\([2025](https://arxiv.org/html/2606.26852#bib.bib29)\)introduce a real\-world order picking dataset collected from a footwear manufacturer’s warehouse\. The dataset includes the warehouse’s CAD layout, along with the coordinates of storage locations, aisles, and depots\. Further, it contains detailed product and storage information, order lines, orders, and wave assignments\. This information is additionally modeled as a UML class diagram\.

##### Semantic modeling

Semantic information models for specific domains are essential to communicate information and standardize knowledge\. A common approach to model semantic information is through ontologies\. Formal ontologies have been proposed across various domains to standardize knowledge representation and aid complex decision processes\. In the context of algorithm selection,Kostovskaet al\.\([2021](https://arxiv.org/html/2606.26852#bib.bib32)\)propose the OPTION ontology, a semantically rich data model for benchmarking optimization algorithms\. OPTION provides core objects such as algorithms, problem instances, and performance metrics, enabling annotation and automatic integration of benchmarking data from different platforms\. In intralogistics,Negriet al\.\([2017](https://arxiv.org/html/2606.26852#bib.bib15)\)provide a comprehensive overview of existing ontology frameworks\. They extend the Manufacturing Systems Ontology by the most important entities for internal logistics processes\. These entities include, for example, transporters, operators, or such that perform storage functions\.Knollet al\.\([2019](https://arxiv.org/html/2606.26852#bib.bib35)\)extend this approach by relating the logistical process activity and information flow\.Kleinet al\.\([2021](https://arxiv.org/html/2606.26852#bib.bib50)\)propose an ontology for autonomous warehouses in the context of agile production systems\.

While such ontologies provide a powerful tool to unify existing datasets, the complexity of ontological frameworks may hinder their adoption\. For example, OPTION consists of over 300 core classes\(Kostovskaet al\.,[2021](https://arxiv.org/html/2606.26852#bib.bib32)\)\. At the same time, there does not seem to be large adoption, as the published repository shows no activity\.Knollet al\.\([2019](https://arxiv.org/html/2606.26852#bib.bib35)\)also highlight that many ontologies in the warehousing area are using different names for the same process and have varying levels of detail, highlighting a lack of standardization\.

##### Data and Model Cards

In the context of machine learning,Pushkarnaet al\.\([2022](https://arxiv.org/html/2606.26852#bib.bib33)\)propose a structured way to document datasets in the form of data cards\. This is motivated by the increasing complexity of multimodal datasets that are becoming popular and require a standardized representation of their use and intent\.Mitchellet al\.\([2019](https://arxiv.org/html/2606.26852#bib.bib31)\)propose model cards to describe meta\-information of trained machine learning models\. For example, a model card for a computer vision model might describe the model’s architecture, the training data it was developed on, its accuracy on various benchmarks, and the contexts for which the model is suited\.Yanget al\.\([2025](https://arxiv.org/html/2606.26852#bib.bib30)\)demonstrate the flexibility of model cards\. They describe trained classification models using model cards\. Based on these cards, models are selected according to the specified task\. The model card approach is widely adopted in the machine learning community and is, for example, a key part of one of the most popular machine learning platforms, HuggingFace, where open\-source models and data sets are shared\.

##### Gap: Missing semantic and data models for warehouse optimization

While ontological frameworks in logistics\(Negriet al\.,[2017](https://arxiv.org/html/2606.26852#bib.bib15); Knollet al\.,[2019](https://arxiv.org/html/2606.26852#bib.bib35)\)and in algorithm benchmarking\(Kostovskaet al\.,[2021](https://arxiv.org/html/2606.26852#bib.bib32)\)demonstrate the potential of semantic modeling, they are either too complex for practical adoption or not tailored to warehouse decision problems\. There is currently no lightweight semantic or data model that captures both the essential dimensions of warehouse instances \(e\.g\., layout, order characteristics, resources\) and the requirements of solution algorithms in a way that supports interoperability and reuse\.

### 2\.3CLS and Data Pipeline Synthesis

Software product\-line engineering studies how families of related software variants can be derived from shared reusable assets rather than implemented independently\(Clements and Northrop,[2001](https://arxiv.org/html/2606.26852#bib.bib45); Pohlet al\.,[2005](https://arxiv.org/html/2606.26852#bib.bib44)\)\. Within this broader context, the Combinatory Logic Synthesizer \(CLS\) provides a type\-based mechanism for automatically composing valid variants from repositories of typed components\(Bessaiet al\.,[2014](https://arxiv.org/html/2606.26852#bib.bib48)\)\. In CLS, each component is assigned a type that encodes both its programmatic interface and semantic properties describing its domain\-specific role\. Given a repository of components and a target specification, CLS solves the inhabitation problem by enumerating all valid component compositions that satisfy the specification, thereby generating all feasible solutions \(potentially infinitely many\)\(Bessaiet al\.,[2014](https://arxiv.org/html/2606.26852#bib.bib48)\)\.

CLS has been applied across several domains to automate the composition of domain\-specific components\.Winkelset al\.\([2024](https://arxiv.org/html/2606.26852#bib.bib47)\)use CLS to synthesize structural variants of discrete\-event simulation models for material flow systems\. Starting from a valid initial model, they represent machines, conveyors, and structural nodes as typed combinators and automatically generate alternative factory layouts that satisfy specified input–output constraints\.Mageset al\.\([2022](https://arxiv.org/html/2606.26852#bib.bib49)\)employ CLS to generate a product line of manufacturing simulation models from a master model, wrapping machine cells as components and using a graphical user interface to let non\-experts configure shop floor layouts; their proof of concept synthesized and simulated 128 configurations in under seven minutes\.Mäckelet al\.\([2021](https://arxiv.org/html/2606.26852#bib.bib46)\)build a CLS repository of constructive heuristics and dispatching rules for flow shop and job shop problems\. CLS automatically selects and composes only those algorithms whose intersection types match the given problem class, demonstrating how the framework maps problem characteristics to applicable algorithms\. However, their approach does not consider individual algorithm requirements beyond the machine environment, such as instance\-specific feature conditions or data\-dependent compatibility constraints\. These applications share a common pattern: domain components are wrapped in semantic types encoding their applicability conditions, and CLS exhaustively enumerates all valid compositions\. This pattern is directly transferable to the composition of decision pipelines for warehouse operations, where algorithms for e\.g\., order batching, picker routing, and scheduling must be combined\.

Selecting well\-performing pipelines of algorithm combinations requires building and evaluating many different pipelines\. Given a large design space, this process can quickly become tedious if done manually\. Thus, a systematic automation of pipeline synthesis, evaluation, and selection can offer many efficiency gains\.Meyeret al\.\([2024](https://arxiv.org/html/2606.26852#bib.bib20)\)proposed CLS\-Luigi, a framework for automating the generation and execution of analytics pipelines from an algorithm repository\. It combines CLS with Luigi\(Spotify,[2025](https://arxiv.org/html/2606.26852#bib.bib36)\), an open\-source workflow management system originally developed at Spotify for defining, scheduling, and executing complex dependency\-based data processing pipelines\. Unlike existing approaches to automated pipeline synthesis, CLS\-Luigi can combine algorithms from different domains, including data preprocessing, machine learning, and decision\-making\. The synthesized pipelines may be non\-linear and vary in both length \(number of nodes\) and structure \(flow of data\)\. A built\-in caching mechanism enables the reuse of intermediate results across pipeline executions\. Newly added algorithm components can be integrated seamlessly and automatically benefit from the same caching infrastructure\.

##### Gap: Lack of automated pipeline synthesis for warehouse optimization

While CLS has been successfully applied to synthesize simulation models\(Winkelset al\.,[2024](https://arxiv.org/html/2606.26852#bib.bib47); Mageset al\.,[2022](https://arxiv.org/html/2606.26852#bib.bib49)\), scheduling heuristics\(Mäckelet al\.,[2021](https://arxiv.org/html/2606.26852#bib.bib46)\), and analytics pipelines\(Meyeret al\.,[2024](https://arxiv.org/html/2606.26852#bib.bib20)\), it has not yet been used for warehouse optimization based on a contextual description\. Current studies still evaluate algorithm combinations manually or restrict to isolated decision problems, whereas the automated generation of valid, instance\-specific decision pipelines that span multiple interdependent warehouse operations has not been explored yet\.

## 3Decision Problems in Order Fulfillment

Figure[3](https://arxiv.org/html/2606.26852#S3.F3)illustrates how the subproblems of order fulfillment might be connected\. Note that this is only one possible shape; depending on the warehouse context, the problem space may be smaller or larger, and subproblems such as order batching and picker routing could also be solved in an integrated fashion\. In this section, we present a domain model that structures the data relevant for the order fulfillment subproblems, describe the subproblems in detail, and present an algorithm repository for each subproblem\.

![Refer to caption](https://arxiv.org/html/2606.26852v1/x2.png)Figure 3:Overview of decomposed decision problems in order fulfillment\.### 3\.1Domain Model

The order fulfillment process takes place within a warehouse system composed of storage locations connected by travel aisles\. To encapsulate the data relevant to solving decision problems in order fulfillment, we consider it along five domain objects:LayoutDomain,ArticlesDomain,OrdersDomain,ResourcesDomain, andStorageDomain\. Each domain object serves as a container for related data models and is annotated by a typed variablet∈Tt\\in Tto allow for meta\-description of the domain object\. Table[1](https://arxiv.org/html/2606.26852#S3.T1)summarizes the domain objects and notation used\. The domain objects and domain models are implemented as Pythondataclassobjects and are extendable based on the requirements of algorithms\.

##### ArticlesDomain

Let𝒜\\mathcal\{A\}be the set containing all articles present in the warehouse\. Each articlea∈𝒜a\\in\\mathcal\{A\}is characterized by basic physical properties such as its weightw​\(a\)∈ℝ\>0w\(a\)\\in\\mathbb\{R\}\_\{\>0\}and volumev​\(a\)∈ℝ\>0v\(a\)\\in\\mathbb\{R\}\_\{\>0\}, which define space and capacity requirements for batching\.

##### OrdersDomain

Let𝒪\\mathcal\{O\}denote the set of customer orders\. Each ordero∈𝒪o\\in\\mathcal\{O\}consists of a set of order linesℒ​\(o\)\\mathcal\{L\}\(o\)\. Each order lineℓ∈ℒ​\(o\)\\ell\\in\\mathcal\{L\}\(o\)requests a specific articlea​\(ℓ\)∈𝒜a\(\\ell\)\\in\\mathcal\{A\}in a given quantityq​\(ℓ\)∈ℕq\(\\ell\)\\in\\mathbb\{N\}\. Orders may also include temporal attributes such as an arrival timetarr​\(o\)∈ℝ≥0t^\{\\mathrm\{arr\}\}\(o\)\\in\\mathbb\{R\}\_\{\\geq 0\}, a due datetdue​\(o\)∈ℝ≥0t^\{\\mathrm\{due\}\}\(o\)\\in\\mathbb\{R\}\_\{\\geq 0\}, which are relevant for scheduling decisions, or a completion timetcomplete​\(o\)∈ℝ≥0t^\{\\mathrm\{complete\}\}\(o\)\\in\\mathbb\{R\}\_\{\\geq 0\}which can be assigned when the order is fulfilled\. The domain type indicates whether orders are splittable or non\-splittable\.

##### ResourcesDomain

Fulfillment operations are performed by a set of resourcesℛ\\mathcal\{R\}, such as human pickers or autonomous mobile robots\. The domain type categorizes the resource fleet accordingly\. Each resourcer∈ℛr\\in\\mathcal\{R\}is specified by its travel speeds​\(r\)∈ℝ\>0s\(r\)\\in\\mathbb\{R\}\_\{\>0\}, and handling time per itemτ​\(r\)∈ℝ\>0\\tau\(r\)\\in\\mathbb\{R\}\_\{\>0\}\. Resources have a load capacity through an associated pick cart, which is described byKKcapacity dimensionsδ=\(δ1,…,δK\)\\delta=\(\\delta\_\{1\},\\ldots,\\delta\_\{K\}\)\. For each resourcer∈ℛr\\in\\mathcal\{R\}and each capacity dimensionk∈\{1,…,K\}k\\in\\\{1,\\ldots,K\\\},ck​\(r\)∈ℝ\>0c\_\{k\}\(r\)\\in\\mathbb\{R\}\_\{\>0\}denotes the capacity of resourcerrin dimensionkk\. The dimension types vary across warehouse settings: for example,Hennet al\.\([2010](https://arxiv.org/html/2606.26852#bib.bib5)\)measure capacity in number of items, whilevan Gilset al\.\([2019](https://arxiv.org/html/2606.26852#bib.bib1)\)constrain boxes per cart with each box limited by item count\. The pick cart may further specify the number of available boxesnbox​\(r\)n\_\{\\mathrm\{box\}\}\(r\)and whether orders can be mixed across boxes\.

##### StorageDomain

Articles are stored at physical locations𝒮\\mathcal\{S\}, governed by a storage policy, where each locations∈𝒮s\\in\\mathcal\{S\}is characterized by coordinates\(x,y\)\(x,y\)in the warehouse layout and may hold a quantity of one or more articles\. The inventory state at a given point in time is represented by the functionI:𝒜×𝒮→ℤ≥0I:\\mathcal\{A\}\\times\\mathcal\{S\}\\rightarrow\\mathbb\{Z\}\_\{\\geq 0\}, whereI​\(a,s\)I\(a,s\)denotes the inventory level of articleaaat storage locationss\. The total inventory level of articleaais given by∑s∈𝒮I​\(a,s\)\\sum\_\{s\\in\\mathcal\{S\}\}I\(a,s\)\. The domain type distinguishes between dedicated storage, where each article is assigned to exactly one location, and scattered storage, where articles may be stored at multiple locations\.

##### LayoutDomain

The spatial structure of the warehouse can be described in two complementary forms: a parametric description and an explicit spatial representation\. The parametric description captures the regular structure of conventional parallel\-aisle warehouses through the number of aislesnan\_\{a\}, blocksnbn\_\{b\}, pick locations per aislenpn\_\{p\}, and distances between them \(dpd\_\{p\},dad\_\{a\}\), along with start and end positionspsp\_\{s\}andpep\_\{e\}\. The explicit spatial representation describes the warehouse as a layout graphG=\(V,E\)G=\(V,E\), whereVVdenotes pick nodes and depots,E⊆V×VE\\subseteq V\\times Vthe feasible connections, andd:V×V→ℝ≥0d:V\\times V\\rightarrow\\mathbb\{R\}\_\{\\geq 0\}assigns shortest\-path distances\. A predecessor functionpred:V×V→V\\textit\{pred\}:V\\times V\\rightarrow Vsupports path reconstruction to obtain the actual pick route\. The domain type distinguishes conventional parallel\-aisle layouts from unconventional designs such as fishbone or flying\-V\(Boysenet al\.,[2019](https://arxiv.org/html/2606.26852#bib.bib34)\)\.

Table 1:Summary of notation and domain objects\.SymbolDescriptionArticlesDomain— typeT∈\{standard\}T\\in\\\{\\text\{standard\}\\\}𝒜\\mathcal\{A\}Set of all articlesa∈𝒜a\\in\\mathcal\{A\}An articlew​\(a\)∈ℝ\>0w\(a\)\\in\\mathbb\{R\}\_\{\>0\}Weight of articleaav​\(a\)∈ℝ\>0v\(a\)\\in\\mathbb\{R\}\_\{\>0\}Volume of articleaaOrdersDomain— typeT∈\{standard, splittable\}T\\in\\\{\\text\{standard, splittable\}\\\}𝒪\\mathcal\{O\}Set of customer orderso∈𝒪o\\in\\mathcal\{O\}An orderℒ​\(o\)\\mathcal\{L\}\(o\)Set of order lines in orderooℓ∈ℒ​\(o\)\\ell\\in\\mathcal\{L\}\(o\)An order linea​\(ℓ\)∈𝒜a\(\\ell\)\\in\\mathcal\{A\}Article requested by order lineℓ\\ellq​\(ℓ\)∈ℕq\(\\ell\)\\in\\mathbb\{N\}Quantity requested in order lineℓ\\elltarr​\(o\),tdue​\(o\),tcomplete​\(o\)∈ℝ≥0t^\{\\mathrm\{arr\}\}\(o\),\\,t^\{\\mathrm\{due\}\}\(o\),t^\{\\mathrm\{complete\}\}\(o\)\\in\\mathbb\{R\}\_\{\\geq 0\}Arrival time, due date, and completion time of orderooResourcesDomain— typeT∈\{human, robot, mixed\}T\\in\\\{\\text\{human, robot, mixed\}\\\}ℛ\\mathcal\{R\}Set of resourcesr∈ℛr\\in\\mathcal\{R\}A resources​\(r\)∈ℝ\>0s\(r\)\\in\\mathbb\{R\}\_\{\>0\}Travel speed of resourcerrτ​\(r\)∈ℝ\>0\\tau\(r\)\\in\\mathbb\{R\}\_\{\>0\}Handling time per item for resourcerrck​\(r\)∈ℝ\>0c\_\{k\}\(r\)\\in\\mathbb\{R\}\_\{\>0\}Capacity of resourcerrin dimensionkkK∈ℕK\\in\\mathbb\{N\}Number of capacity dimensionsk∈\{1,…,K\}k\\in\\\{1,\\ldots,K\\\}Index of a capacity dimensionδ=\(δ1,…,δK\)\\delta=\(\\delta\_\{1\},\\ldots,\\delta\_\{K\}\)Capacity dimension types \(e\.g\., items, weight, volume, order lines\)nbox​\(r\)∈ℕn\_\{\\mathrm\{box\}\}\(r\)\\in\\mathbb\{N\}Number of boxes on pick cartStorageDomain— typeT∈\{dedicated, scattered\}T\\in\\\{\\text\{dedicated, scattered\}\\\}𝒮\\mathcal\{S\}Set of storage locationss∈𝒮s\\in\\mathcal\{S\}A storage location with coordinates\(x,y\)\(x,y\)I:𝒜×𝒮→ℤ≥0I:\\mathcal\{A\}\\times\\mathcal\{S\}\\rightarrow\\mathbb\{Z\}\_\{\\geq 0\}Inventory state functionI​\(a,s\)I\(a,s\)Inventory level of articleaaat locationssLayoutDomain— typeT∈\{conventional, unconventional\}T\\in\\\{\\text\{conventional, unconventional\}\\\}na,nb,np∈ℕn\_\{a\},n\_\{b\},n\_\{p\}\\in\\mathbb\{N\}Number of aisles, pick locations, blocksdp,da∈ℝ\>0d\_\{p\},d\_\{a\}\\in\\mathbb\{R\}\_\{\>0\}Distance between pick locations, aislesps,pe∈Vp\_\{s\},p\_\{e\}\\in VStart and end \(depot\) positionsG=\(V,E\)G=\(V,E\)Warehouse layout graphVVSet of vertices \(pick nodes and depots\)E⊆V×VE\\subseteq V\\times VSet of feasible connectionsd:V×V→ℝ≥0d:V\\times V\\rightarrow\\mathbb\{R\}\_\{\\geq 0\}Distance functionpred:V×V→V\\textit\{pred\}:V\\times V\\rightarrow VPredecessor function for path reconstruction

### 3\.2Subproblems of Order Fulfillment

We decompose order fulfillment into four subproblems: item assignment, order batching, picker routing, and picker scheduling\. We describe each of these subproblems in detail below\.

Item Assignment \(IA\)\.In warehouses with scattered storage policies, where articles may be stored at multiple locations simultaneously, the item assignment problem determines from which specific storage location\(s\) each requested article should be picked\. This stage resolves each order lineℓ∈ℒ​\(o\)\\ell\\in\\mathcal\{L\}\(o\)to one or more storage locationss∈𝒮s\\in\\mathcal\{S\}based on the inventory functionI​\(a​\(ℓ\),s\)I\(a\(\\ell\),s\), such that the requested quantityq​\(ℓ\)q\(\\ell\)can be fulfilled\. When a single location has insufficient inventory, the quantity may be split across multiple locations\. The output is a set of resolved pick positions𝒫\\mathcal\{P\}, where eachp∈𝒫p\\in\\mathcal\{P\}specifies a pick node, the quantity to retrieve, and its associated order line\.

Order Batching \(B\)\.To reduce travel time, multiple customer orders can be combined into batches that are retrieved in a single picker tour\. The batching problem groups orderso∈𝒪o\\in\\mathcal\{O\}into batchesb∈ℬb\\in\\mathcal\{B\}, subject to capacity constraints imposed by the picker cart capacitiesck​\(r\)c\_\{k\}\(r\),k∈\{1,…,K\}k\\in\\\{1,\\ldots,K\\\}\. Each batch forms a pick list containing all order lines from its constituent orders\. Every orderoomay have an arrival timetarr​\(o\)t^\{\\mathrm\{arr\}\}\(o\)that indicates when the order becomes known in the system, a due datetdue​\(o\)t^\{\\mathrm\{due\}\}\(o\)that specifies the time at which the picking process of the order has to be finished, and a completion timetcomplete​\(o\)t^\{\\mathrm\{complete\}\}\(o\)that captures the time at which the picking process has actually finished\.

Picker Routing \(R\)\.For each pick list, the routing problem determines the sequence in which pick locations are visited and the path through the warehouse\. This is often modeled as a variant of the TSP with the objective of finding a tourσ\\sigmathat visits all required pick locations while minimizing total travel distance\. The output specifies both the route through the warehouse layout graphG=\(V,E\)G=\(V,E\)and the sequence in which items are picked\.

Scheduling \(S\)\.Picker scheduling determines when each pick list or tour is executed and which resource handles it\. In a multi\-picker system, scheduling comprises both sequencing and resource assignment\. Sequencing determines the sequence in which the tours are executed, while assignment allocates tours to available resources\. In a single\-picker system, scheduling reduces to sequencing\. The output is a schedule consisting of an assignment functionρ:ℬ→ℛ\\rho:\\mathcal\{B\}\\rightarrow\\mathcal\{R\}, which maps each batchb∈ℬb\\in\\mathcal\{B\}to a resourcer∈ℛr\\in\\mathcal\{R\}, and a sequenceπ\\pi, which specifies the execution sequence of batches together with their start and completion times\.

### 3\.3Optimization Objectives

The choice of the overall optimization objective in the order fulfillment context depends on operational priorities and available data\. Common objectives in order fulfillment include:

- 1\.Distance: Total travel distance across all pick tours,∑b∈ℬd​\(σb\)\\sum\_\{b\\in\\mathcal\{B\}\}d\(\\sigma\_\{b\}\), whereσb\\sigma\_\{b\}denotes the tour for batchbbandd​\(σb\)d\(\\sigma\_\{b\}\)denotes the total travel distance of this tour\.
- 2\.Makespan: Time from the start of the first pick tour until completion of the last,maxr∈ℛ⁡trend\\max\_\{r\\in\\mathcal\{R\}\}t^\{\\mathrm\{end\}\}\_\{r\}, wheretrendt^\{\\mathrm\{end\}\}\_\{r\}denotes the completion time of resourcerr, accounting for travel speeds​\(r\)s\(r\)and handling timeτ​\(r\)\\tau\(r\)\.
- 3\.Tardiness: Sum of delays beyond due dates,∑o∈𝒪max⁡\(0,tcomplete​\(o\)−tdue​\(o\)\)\\sum\_\{o\\in\\mathcal\{O\}\}\\max\(0,t^\{\\mathrm\{complete\}\}\(o\)\-t^\{\\mathrm\{due\}\}\(o\)\), where orders completed before their due date contribute zero\.
- 4\.On\-Time rate: Percentage of orders completed by their due date,\|\{o∈𝒪∣tcomplete​\(o\)≤tdue​\(o\)\}\|\|𝒪\|×100%\\frac\{\|\\\{o\\in\\mathcal\{O\}\\mid t^\{\\mathrm\{complete\}\}\(o\)\\leq t^\{\\mathrm\{due\}\}\(o\)\\\}\|\}\{\|\\mathcal\{O\}\|\}\\times 100\\%\.

### 3\.4Algorithms for Order Fulfillment

To the best of our knowledge, no open\-source implementations of the algorithms reviewed in this paper exist\. We therefore provide a dedicated repository of reusable, modular implementations covering the decision problems defined in Section[3](https://arxiv.org/html/2606.26852#S3), available at[https://github\.com/kit\-dsm/ware\_ops\_algos](https://github.com/kit-dsm/ware_ops_algos)\.

The repository currently contains 22 algorithm implementations: five item assignment approaches, seven batching approaches, eight routing approaches, one integrated batching\-and\-routing approach, and one scheduling approach\. All algorithms implement a sharedAlgorithmbase class parameterized by input and output types\. Each algorithm operates on the domain objects introduced in Section[3\.1](https://arxiv.org/html/2606.26852#S3.SS1)and returns a typedSolutionObjectthat downstream algorithms can consume\. The repository is organized into dedicated modules for each decision problem, following a consistent pattern: an abstract base class defines the interface, and concrete implementations specialize it\. In Tables[2](https://arxiv.org/html/2606.26852#S3.T2)–[6](https://arxiv.org/html/2606.26852#S3.T6), indented entries denote concrete implementations of the base class listed above\. We use ’H’, ’MH’, and ’E’ to indicate whether an algorithm is heuristic, metaheuristic, or exact\. Algorithms marked with\*are used in the framework validation described in Section[5](https://arxiv.org/html/2606.26852#S5)\.

#### 3\.4\.1Item Assignment

Theitem\_assignmentmodule contains implementations of five item assignment approaches, summarized in Table[2](https://arxiv.org/html/2606.26852#S3.T2)\. The module covers both dedicated and scattered storage settings\. For dedicated storage, item assignment is fixed because each article is associated with a single storage position\. As a simple baseline solution for such cases, we implemented GIA, which greedily selects the storage location with the highest inventory level first\. For scattered storage, several storage positions may be feasible for the same requested article, and an assignment rule must select one or more of them\. For the scattered case, we implement the heuristic assignment rules MinMaxIA, MinMinIA, and SPIA based on the priority\-based approach presented inWeidinger \([2018](https://arxiv.org/html/2606.26852#bib.bib42)\)and NNIA, which is adopted fromWeidingeret al\.\([2019](https://arxiv.org/html/2606.26852#bib.bib14)\)\. GIA and NNIA are standalone constructive heuristics\. MinMaxIA, MinMinIA, and SPIA are variants ofPriorityItemAssignment, a shared base class for penalty\-based priority rules\. SPIA is parameterized by a routing algorithm that serves as a distance evaluator\.

This yields twelve executable item\-assignment configurations: four standalone configurations \(GIA, NNIA, MinMaxIA, and MinMinIA\) and eight SPIA configurations, one for each available routing algorithm\. Each algorithm returns anItemAssignmentSolutioncontaining𝒫\\mathcal\{P\}\.

Table 2:Item assignment algorithms\.AlgorithmTypeDescriptionGreedyItemAssignment\(GIA\)HAssigns items from locations with the highest inventory level first until the requested quantity is satisfied\.NearestNeighborItemAssignment\(NNIA\)\*HIteratively selects the nearest location until all demand is fulfilled\(Weidingeret al\.,[2019](https://arxiv.org/html/2606.26852#bib.bib14)\)\.PriorityItemAssignmentHBase class for item assignment based on penalty\-based priority rules\(Weidinger,[2018](https://arxiv.org/html/2606.26852#bib.bib42)\)\.MinMaxItemAssignment\(MinMaxIA\)\*Computes penalties as the maximum distance to already\-selected locations\.MinMinItemAssignment\(MinMinIA\)\*Computes penalties as the minimum distance to already\-selected locations\.SinglePosItemAssignment\(SPIA\)\*Uses the distance from a fixed reference position\.
#### 3\.4\.2Batching

Thebatchingmodule contains four batching implementations, summarized in Table[3](https://arxiv.org/html/2606.26852#S3.T3)\. We include constructive, savings\-based, seed\-based, and local\-search approaches\. Constructive and metaheuristic approaches are discussed byHennet al\.\([2010](https://arxiv.org/html/2606.26852#bib.bib5)\),Koch \([2014](https://arxiv.org/html/2606.26852#bib.bib37)\), andPintoet al\.\([2023](https://arxiv.org/html/2606.26852#bib.bib8)\)\. Learning\-based batching methods have recently been explored byBeekset al\.\([2022](https://arxiv.org/html/2606.26852#bib.bib40)\)andCalset al\.\([2021](https://arxiv.org/html/2606.26852#bib.bib39)\)\.

PriorityBatchingis a greedy constructive method parameterized by a sorting criterion\. We implement four sorting rules: OrderNrFiFo, FiFo, DueDate, and Random\.SavingsBatchingrequires a routing evaluator for computing savings and can be configured with any of the eight routing classes described in the next subsection\. This generates eight different configurations of theSavingsBatchingalgorithm\.SeedBatchingis parameterized by threeSeedCriteriaand twoSimilarityMeasureoptions as specified in Table[4](https://arxiv.org/html/2606.26852#S3.T4), resulting in six configurations\.LocalSearchBatchingrequires both a constructive batching method for initialization and a routing evaluator\. Combined with four constructive batching approaches \(FiFo, OrdNrFiFo, DueDate, RAND\) and eight routing classes, this yields 32 configurations\.

These implementations yield 50 executable batching configurations: four priority\-based configurations, eight savings\-based configurations, six seed\-based configurations, and 32 local\-search configurations\. Each algorithm returns aBatchingSolutioncontainingℬ\\mathcal\{B\}and the derived pick lists\.

Table 3:Batching algorithms\.AlgorithmTypeDescriptionPriorityBatchingHGreedy constructive batching by sorting criterion\.OrderNrFiFo\*By ascending order number\.FiFo\*By arrival datetarr​\(o\)t^\{\\mathrm\{arr\}\}\(o\)\.DueDate\*By due datetdue​\(o\)t^\{\\mathrm\{due\}\}\(o\)\.Random\*Random order with fixed seed\.SavingsBatching\*HMerges batch pairs with largest routing distance saving\(Clarke and Wright,[1964](https://arxiv.org/html/2606.26852#bib.bib38)\)\. Configurable routing evaluator \(Table[5](https://arxiv.org/html/2606.26852#S3.T5)\)\.SeedBatching\*HBuilds batches around seed orders\. Configurable seed selection and similarity measure \(Table[4](https://arxiv.org/html/2606.26852#S3.T4)\)\.LocalSearchBatching\*MHIterative improvement via SWAP/SHIFT operators\(Hennet al\.,[2010](https://arxiv.org/html/2606.26852#bib.bib5)\)\. Configurable constructive initialization; seePriorityBatching, and routing evaluator \(Table[5](https://arxiv.org/html/2606.26852#S3.T5)\)\.Table 4:Configuration options forSeedBatching\.CategoryOptionDescriptionSeed selectionRANDOMRandom seed order\.MOST\_POSITIONSOrder with the most positions\.FEWEST\_POSITIONSOrder with the fewest positions\.CLOSEST\_TO\_DEPOTOrder whose nearest pick node is closest topsp\_\{s\}\.Similarity measureSHARED\_ARTICLESOrders with more shared articles are considered more similar\.MIN\_DISTANCEMinimum pairwise pick\-node distance between orders\.
#### 3\.4\.3Routing

Theroutingmodule contains eight standalone routing implementations, summarized in Table[5](https://arxiv.org/html/2606.26852#S3.T5)\. The layout\-dependent heuristics follow established routing rules for parallel\-aisle warehouses, as evaluated byPetersen \([1997](https://arxiv.org/html/2606.26852#bib.bib11)\)\. We also implement nearest\-neighbor routing, two exact TSP\-based formulations, and the dynamic programming approach ofRatliff and Rosenthal \([1983](https://arxiv.org/html/2606.26852#bib.bib19)\)as extended byHeßler and Irnich \([2024](https://arxiv.org/html/2606.26852#bib.bib17)\)for single\-block parallel\-aisle layouts with scattered storage\. For a broader overview of TSP\-based picker\-routing models, we refer toBocket al\.\([2025](https://arxiv.org/html/2606.26852#bib.bib43)\)\.

In addition, we provide CBR, an integrated batching\-and\-routing approach\. Joint order batching and picker routing has been studied as an integrated optimization problem byValleet al\.\([2017](https://arxiv.org/html/2606.26852#bib.bib4)\); a more general column\-generation\-based approach is presented byBriantet al\.\([2020](https://arxiv.org/html/2606.26852#bib.bib27)\)\. Our implementation operates directly on𝒪\\mathcal\{O\}and jointly determines batching and routing via a capacity\-constrained TSP formulation\.

Each routing algorithm returns aRoutingSolutioncontainingσ\\sigmaandd​\(σ\)d\(\\sigma\)\. This allows for the reconstruction and visualization of the picker tours\.

Table 5:Routing algorithms\.AlgorithmTypeDescriptionHeuristicRoutingHBase class for routing heuristics\.SShapeRouting\(SShape\)\*Traverse aisles in an S\-pattern\.ReturnRouting\(RET\)\*Enter each aisle and return after the last pick\.MidpointRouting\(MP\)\*Split the warehouse at a horizontal midpoint, processing the lower and upper parts separately\.LargestGapRouting\(LG\)\*Enter each aisle only up to the largest empty gap\.NearestNeighborRouting\(NN\)\*Greedily visit the nearest unvisited pick location\.ExactRoutingEBase class for exact routing models\.ExactTSPRoutingDistance\(TSP\-D\)TSP with subtour elimination\.ExactTSPRoutingTime\(TSP\-T\)TSP including travel speed and handling time\.RatliffRosenthalRouting\(RR\)\*EDP for single\-block rectangular warehouses\.RoutingBatchingEBase class for integrated batching\-and\-routing approaches\.CombinedBatchingRouting\(CBR\)\*Capacity\-constrained TSP for integrated batching\-and\-routing\.
#### 3\.4\.4Scheduling

Batches or pick tours are usually sequenced using dispatching rules from the scheduling literature\. We implement list\-scheduling, an approach introduced byGraham \([1969](https://arxiv.org/html/2606.26852#bib.bib41)\)for multiprocessor scheduling, with four dispatching rules summarized in Table[6](https://arxiv.org/html/2606.26852#S3.T6)\.

The implementation operates on routing solutionsσ\\sigma, orders𝒪\\mathcal\{O\}with temporal attributestarr​\(o\)t^\{\\mathrm\{arr\}\}\(o\)andtdue​\(o\)t^\{\\mathrm\{due\}\}\(o\), and resourcesℛ\\mathcal\{R\}with travel speeds​\(r\)s\(r\)and handling timeτ​\(r\)\\tau\(r\)\. It maintains a priority\-ordered list of tours and repeatedly assigns the highest\-priority tour to the earliest available picker\. The dispatching rule defines the priority\.

This yields four executable scheduling configurations: shortest processing time \(SPT\), longest processing time \(LPT\), earliest due date \(EDD\), and earliest release date \(ERD\)\. Each algorithm returns aSchedulingSolutioncontaining the assignmentρ:ℬ→ℛ\\rho:\\mathcal\{B\}\\rightarrow\\mathcal\{R\}, the execution sequenceπ\\pi, and start and completion times for each tour\.

Table 6:Scheduling algorithms\.AlgorithmTypeDescriptionListSchedulingHBase class for priority\-based list scheduling\.SPTScheduling\(SPT\)\*Shortest processing time first\.LPTScheduling\(LPT\)\*Longest processing time first\.EDDScheduling\(EDD\)\*Earliest due date first\.ERDScheduling\(ERD\)Earliest release date first\.

### 3\.5Configuration Space of the Algorithm Repository

The algorithm repository described in Section[3\.4](https://arxiv.org/html/2606.26852#S3.SS4)contains both fixed and parameterized implementations\. We refer to each fully specified variant as an executable algorithm configuration, and write𝐼𝐴\\mathit\{IA\},B\\mathit\{B\},R\\mathit\{R\},𝐵𝑅\\mathit\{BR\}, andS\\mathit\{S\}for the sets of item\-assignment, batching, standalone routing, integrated batching\-and\-routing, and scheduling configurations\. Across all subproblems, the repository contains 75 executable algorithm configurations:\|𝐼𝐴\|=12\|\\mathit\{IA\}\|=12,\|B\|=50\|\\mathit\{B\}\|=50,\|R\|=8\|\\mathit\{R\}\|=8,\|𝐵𝑅\|=1\|\\mathit\{BR\}\|=1, and\|S\|=4\|\\mathit\{S\}\|=4\. This count describes the available algorithm configurations prior warehouse\-specific filtering and composition into complete optimization pipelines\. A purely sequential order batching and routing setting with item assignment already admits\|𝐼𝐴\|⋅\|B\|⋅\|R\|=12⋅50⋅8=4,800\|\\mathit\{IA\}\|\\cdot\|\\mathit\{B\}\|\\cdot\|\\mathit\{R\}\|=12\\cdot 50\\cdot 8=4\{,\}800possible combinations\. If scheduling is included, the corresponding sequential space grows to\|𝐼𝐴\|⋅\|B\|⋅\|R\|⋅\|S\|=12⋅50⋅8⋅4=19,200\|\\mathit\{IA\}\|\\cdot\|\\mathit\{B\}\|\\cdot\|\\mathit\{R\}\|\\cdot\|\\mathit\{S\}\|=12\\cdot 50\\cdot 8\\cdot 4=19\{,\}200combinations\.

However, valid pipeline construction is not a cartesian product over all stages\. Not every problem class requires every subproblem\. A pure routing problem does not require batching or scheduling, while an integrated batching\-and\-routing configuration from𝐵𝑅\\mathit\{BR\}bypasses the separate batching and routing stages, adding\|𝐼𝐴\|⋅\|𝐵𝑅\|\|\\mathit\{IA\}\|\\cdot\|\\mathit\{BR\}\|combinations rather than entering the product above\. The applicable algorithms also depend on the warehouse context and the available data\. For example, item\-assignment variants are only relevant when the storage model allows alternative pick locations, scheduling requires temporal order information and multiple resources, and some routing algorithms require a specific layout representation or layout class\.

Thus, the relevant configuration space is instance\-dependent\. Determining which algorithm configurations are applicable and composing them into valid executable pipelines is the key challenges addressed by the CASOP framework introduced in the following section\.

## 4CASOP

We present the framework coined*Context\-Aware Synthesis of Optimization Pipelines*\(CASOP\) that enables the automated mapping of warehouse characteristics to compatible algorithmic approaches, the synthesis of valid algorithm pipelines, and their systematic evaluation\.

### 4\.1CASOP Overview

The CASOP framework consists of the following five core building blocks, which are illustrated in Figure[4](https://arxiv.org/html/2606.26852#S4.F4)and discussed in detail in the following subsections:

![Refer to caption](https://arxiv.org/html/2606.26852v1/x3.png)Figure 4:Core building blocks of the CASOPframework\. Warehouse data is semantically structured into domain models described in the form of a data card \(1\)\. Requirements of algorithms from a repository are described in the form of algorithm cards \(2\)\. A taxonomy describes the problem space and which subproblems a problem consists of \(3\)\. Algorithm card, data card, and taxonomy are used by the domain\-algorithm mapping component to obtain applicable algorithms, which are then composed into context\-aware pipelines \(4\)\. Finally, all resulting pipelines are evaluated to select the best\-performing configuration \(5\)\.- \(1\)Data Cards and Domain Objects\.Warehouse information is organized into domain objects, such as layout, articles, orders, resources, and storage\. Each domain object contains contextual information, such as the layout type, and data features, such as the number of aisles or picker capacity\. A data card provides a semantic description of these domain objects and declares the available features, the problem class to be solved, and the optimization objective\.
- \(2\)Algorithm Cards and Algorithm Repository\.The algorithm repository contains implementations of item assignment, batching, routing, and scheduling algorithms, i\.e\., the algorithms presented in Section[3\.4](https://arxiv.org/html/2606.26852#S3.SS4)\. Each algorithm is described by an algorithm card that specifies the subproblem it addresses, its objective, and its requirements with respect to the warehouse data and context\.
- \(3\)Taxonomy\.The taxonomy defines the problem space considered by the framework\. It maps each problem class to the corresponding subproblems\. Depending on the warehouse setting and problem class, only a subset of subproblems may be relevant, and some subproblems may be solved sequentially or in an integrated fashion\.
- \(4\)Pipeline Synthesizer\.The pipeline synthesizer generates executable optimization pipelines subject to the context provided by the data card, algorithm cards, and taxonomy\. It comprises two parts\. First, the domain\-algorithm mapper identifies all algorithms applicable to the given warehouse setting\. It filters algorithms by problem type using the taxonomy and checks whether the required domain types, features, and feature constraints specified in the algorithm cards are satisfied by the context provided through the data card\. Second, the applicable algorithms are synthesized into context\-aware pipelines, represented as directed acyclic graphs in which nodes correspond to algorithms or data sources and edges capture data dependencies between decision stages\.
- \(5\)Pipeline Evaluator\.The pipeline evaluator evaluates the executed pipelines and assesses them according to the objective specified in the data card\. The result is a ranked set of valid pipelines and the best\-performing configuration for the given warehouse context\.

### 4\.2Data Cards and Domain Objects

A data cardℐ\\mathcal\{I\}captures the semantic description of a warehouse setting\. It is defined by:

ℐ=⟨P,Z,𝒟1,…,𝒟5⟩\\mathcal\{I\}\\;=\\;\\langle P,\\,Z,\\,\\mathcal\{D\}\_\{1\},\\ldots,\\mathcal\{D\}\_\{5\}\\ranglewherePPis the problem class,ZZis the objective, and𝒟1,…,𝒟5\\mathcal\{D\}\_\{1\},\\ldots,\\mathcal\{D\}\_\{5\}correspond to the five data domains introduced in Section[3\.1](https://arxiv.org/html/2606.26852#S3.SS1)\. Each domain object𝒟i=⟨Ti,Fi⟩\\mathcal\{D\}\_\{i\}=\\langle T\_\{i\},F\_\{i\}\\rangleexpresses the categorical typeTiT\_\{i\}\(e\.g\., conventional, scattered, human\), and featuresFiF\_\{i\}of the related domain models, as defined in Table[1](https://arxiv.org/html/2606.26852#S3.T1)\.

Data cards are structured hierarchically in YAML, mirroring the domain composition\. Features are listed by name\. When a feature carries a concrete value \(e\.g\.,n\_blocks: 2\), this value can be used for constraint evaluation in algorithm cards\. Features listed without a value signal availability only; their presence indicates that the corresponding data exists in the warehouse setting\. Figure[5](https://arxiv.org/html/2606.26852#S4.F5)\(a\) shows an example for theKrisinstance set\(Valleet al\.,[2017](https://arxiv.org/html/2606.26852#bib.bib4)\)\.

\(a\) Data card

name:example\_data\_card

problem\_class:OBRSP

objective:distance

LayoutDomain:

type:conventional

features:

\-start\_node

\-end\_node

\-n\_blocks:2

\-graph

\-distance\_matrix

ArticlesDomain:

type:standard

features:

\-article\_id

\-weight

\-volume

OrdersDomain:

type:standard

features:

\-order\_number

\-order\_date

\-amount

\-article\_id

ResourcesDomain:

type:human

features:

\-speed

\-time\_per\_pick

\-capacities

\-dimensions\_type:\[items\]

StorageDomain:

type:dedicated

features:

\-amount

\-article\_id

\(b\) Algorithm card

model\_name:RatliffRosenthal

problem\_type:routing

objective:distance

requirements:

LayoutDomain:

type:

\-conventional

features:

\-start\_node

\-end\_node

\-closest\_node\_to\_start

\-min\_aisle\_position

\-max\_aisle\_position

\-n\_pick\_locations

\-n\_aisles

\-dist\_pick\_locations

\-dist\_bottom\_to\_pick\_location

\-n\_blocks

constraints:

n\_blocks:

equals:1

ResourcesDomain:

type:

\-any

OrdersDomain:

type:

\-standard

StorageDomain:

type:

\-any

ArticlesDomain:

type:

\-any

Figure 5:Examples of a data card and an algorithm card\. The data card describes an instance from theKrisdataset, whereas the algorithm card describes the requirements of theRatliffRosenthalRoutingalgorithm\.
### 4\.3Algorithm Cards

Each algorithm in the repository introduced in Section[3\.4](https://arxiv.org/html/2606.26852#S3.SS4)is accompanied by an algorithm card\. An algorithm cardα∈𝔸\\alpha\\in\\mathbb\{A\}is defined by:

α=⟨Rα,Pα,Zα⟩\\alpha\\;=\\;\\langle R\_\{\\alpha\},\\,P\_\{\\alpha\},\\,Z\_\{\\alpha\}\\ranglewherePαP\_\{\\alpha\}is the subproblem addressed,ZαZ\_\{\\alpha\}is the optimization objective \(empty for constructive methods without an explicit objective\), andRα=⟨Tα,Fα,Cα⟩R\_\{\\alpha\}=\\langle T\_\{\\alpha\},F\_\{\\alpha\},C\_\{\\alpha\}\\ranglespecifies the algorithm requirements: the required domain types \(TαT\_\{\\alpha\}\), features \(FαF\_\{\\alpha\}\), and constraints \(CαC\_\{\\alpha\}\)\. Constraints can include comparison and set relations over features such asequals,greater\_than, orin, as well as logical combinations usingandandor\. This allows modeling requirements that go beyond feature presence\.

Algorithm requirements, subproblem, and objective are specified as YAML\-formatted algorithm cards\. Figure[5](https://arxiv.org/html/2606.26852#S4.F5)\(b\) shows an example for theRatliffRosenthalRoutingalgorithm\(Ratliff and Rosenthal,[1983](https://arxiv.org/html/2606.26852#bib.bib19); Heßler and Irnich,[2024](https://arxiv.org/html/2606.26852#bib.bib17)\)\.

### 4\.4Taxonomy

The problem taxonomyTPT\_\{P\}formalizes the mapping from each problem classPPto its constituent subproblems\. The taxonomy is given in Figure[6](https://arxiv.org/html/2606.26852#S4.F6)\. It is based on the classification of order batching problems recently proposed byPardoet al\.\([2024](https://arxiv.org/html/2606.26852#bib.bib21)\)\. To allow a broader range of problems to be covered, we extend it by the picker routing problem \(PRP\) and the IA subproblem, which are not covered in their work\.

In our taxonomy, the PRP requires only item assignment and routing; the order batching problem \(OBP\) adds batching, and the OBRP combines item assignment, order batching, and picker routing, with the option to solve batching and routing jointly through an integrated formulation \(BR\)\. The OBRSP additionally includes scheduling\.

PPRPOBPOBRPOBRSPIARIABIABRBRIABRSBRS

Figure 6:Taxonomy implemented in CASOP\. Problem \(P\); item assignment \(IA\); batching \(B\); routing \(R\); scheduling \(S\); picker routing problem \(PRP\); order batching problem \(OBP\); order batching and routing problem \(OBRP\); order batching, routing, and scheduling problem \(OBRSP\)\.
### 4\.5Pipeline Synthesizer

The pipeline synthesizer generates executable optimization pipelines for a given warehouse setting\. It uses the data cardℐ\\mathcal\{I\}, the algorithm cards𝔸\\mathbb\{A\}, and the taxonomyTPT\_\{P\}to first identify applicable algorithms, then compose them into valid context\-aware pipelines, and execute them\.

#### 4\.5\.1Domain\-Algorithm Mapping

CASOPincludes a mapping mechanism that determines which algorithms from the repository𝔸\\mathbb\{A\}are applicable to a given data cardℐ\\mathcal\{I\}\. The mapping produces the subset𝔸∗⊆𝔸\\mathbb\{A\}^\{\*\}\\subseteq\\mathbb\{A\}of applicable algorithms\. The procedure is implemented by theDomainAlgoMapperclass, which takes𝔸\\mathbb\{A\},ℐ\\mathcal\{I\}, andTPT\_\{P\}as input and returns𝔸∗\\mathbb\{A\}^\{\*\}\. It proceeds in two stages\.

- \(1\)Problem\-type filtering\.An algorithm described by algorithm cardα=⟨Rα,Pα,Zα⟩\\alpha=\\langle R\_\{\\alpha\},P\_\{\\alpha\},Z\_\{\\alpha\}\\ranglepasses the first stage if its declared subproblemPαP\_\{\\alpha\}corresponds to the problem classPPdeclared inℐ\\mathcal\{I\}, or to one of its subproblems as defined by the taxonomyTPT\_\{P\}\(see Section[4\.4](https://arxiv.org/html/2606.26852#S4.SS4)\)\. For example, ifℐ\\mathcal\{I\}declaresP=OBRPP=\\text\{OBRP\}, then algorithms for the subproblems IA, B, R, and BR are admitted, while scheduling algorithms are filtered out\.
- \(2\)Requirement matching\.Each remaining algorithm is checked against the domain objects𝒟1,…,𝒟5\\mathcal\{D\}\_\{1\},\\ldots,\\mathcal\{D\}\_\{5\}ofℐ\\mathcal\{I\}\. Specifically, for each domain𝒟i=⟨Ti,Fi⟩\\mathcal\{D\}\_\{i\}=\\langle T\_\{i\},F\_\{i\}\\ranglereferenced by the algorithm requirementsRα=⟨Tα,Fα,Cα⟩R\_\{\\alpha\}=\\langle T\_\{\\alpha\},F\_\{\\alpha\},C\_\{\\alpha\}\\rangle, the framework verifies: 1. \(a\)Type compatibility: The required domain type matches the data card’s type, i\.e\.,Ti∈TαT\_\{i\}\\in T\_\{\\alpha\}, whereanyindicates no restriction\. 2. \(b\)Feature availability: All required features are present, i\.e\.,Fα⊆FiF\_\{\\alpha\}\\subseteq F\_\{i\}\. 3. \(c\)Constraint satisfaction: All feature constraintsCαC\_\{\\alpha\}are satisfied by the concrete feature values inℐ\\mathcal\{I\}\. An algorithmα\\alphais applicable if and only if conditions \(a\)\-\(c\) hold for every referenced domain\.

#### 4\.5\.2Context\-Aware Pipelines

The synthesizer builds valid algorithm pipelines for the active problem class, executes them, and ranks their results\. It uses CLS\-Luigi, which combines CLS with Luigi\. CLS takes a repository of typed components and a target component, and searches for component combinations that can produce this target\. Luigi executes the resulting combinations as directed acyclic task graphs and caches intermediate results\.

We implement the taxonomy from Figure[6](https://arxiv.org/html/2606.26852#S4.F6)and the data flow between subproblems as a CLS\-Luigi pipeline template, shown in Figure[7](https://arxiv.org/html/2606.26852#S4.F7)\.

![Refer to caption](https://arxiv.org/html/2606.26852v1/x4.png)Figure 7:Visualization of the CASOPpipeline template\. For readability, not all concrete implementations are shown\.First, theInstanceLoaderprovides the domain objects and instance data required by the decision components\. Further, problem specific components model the data flow of the problems defined in the taxonomy:

- 1\.AbstractItemAssignmentproduces resolved pick positions\.
- 2\.AbstractBatchinghas two alternatives:MultiOrderBatching, which applies a batching algorithm, andSingleOrderBatching, which creates one batch per order\.
- 3\.AbstractPickerRoutingproduces routing solutions\. It can be instantiated by standalone routing algorithms that consume aBatchingSolution, or by an integrated batching\-and\-routing component that depends directly on item assignment\.
- 4\.AbstractSchedulingconsumes routing solutions and instance data\. It assigns tours to resources and determines their execution sequence\.

ResultAggregationis the terminal component used as synthesis target\. It collects objective values, runtimes, and the algorithm configurations used in each executed pipeline\.

The template distinguishes between abstract and concrete components\. Abstract components represent the decision subproblems and define their typed inputs and outputs\. Concrete components are the algorithm implementations that instantiate these abstract components\.

Algorithms from the repository described in Section[3\.4](https://arxiv.org/html/2606.26852#S3.SS4)are added as concrete components\. For example, batching algorithms instantiateMultiOrderBatching, routing algorithms instantiate the standalone routing alternative ofAbstractPickerRouting, and scheduling approaches instantiateAbstractScheduling\.

Before synthesis, CASOP restricts the concrete components to the algorithms returned by theDomainAlgoMapper\. Thus, only algorithms whose cards match the data card, problem class, objective, and feature constraints are available to CLS\-Luigi\.

Starting fromResultAggregation, CLS searches for all valid component combinations that can produce the requested result object\. In our implementation,ResultAggregationis specialized into objective\-specific targets such asDistanceandDueDate\. Each valid inhabitant corresponds to one executable pipeline\. The number of synthesized pipelines depends on the number of applicable algorithms per subproblem and on the structural alternatives encoded in the template\.

Figure[8](https://arxiv.org/html/2606.26852#S4.F8)shows two pipelines synthesized from the template for the OBRP problem class\. The first follows the sequential decomposition: item assignment, batching, routing, and result aggregation\. The second uses the integrated batching\-and\-routing component and therefore bypasses separate batching and standalone routing\. Both pipelines are valid because they can produce the requested aggregation target\.

![Refer to caption](https://arxiv.org/html/2606.26852v1/x5.png)Figure 8:Example pipelines resulting from the defined template for the same problem \(OBRP\)\. The upper figure visualizes the OBRP in its decomposed, fully sequential form\. The lower figure shows a partially integrated pipeline that combines batching and routing\.After execution,AbstractResultAggregationcollects the objective value, runtime, and concrete algorithm configuration of each executed pipeline\. This is specialized into two variants for pipelines with and without time\-related information\. CASOP then ranks all successfully solved pipelines according to the objective specified in the data cardℐ\\mathcal\{I\}and returns the best\-performing pipeline\.

### 4\.6Pipeline Evaluator

Based on the aggregated results, we identify the best\-performing pipeline with respect to the defined objectiveZZ, which is derived from the data cardℐ\\mathcal\{I\}\. To this end, we apply a straightforward ranking mechanism that evaluates the output ofResultAggregationacross all successfully solved pipelines and ranks them by objective value, thereby determining the overall best\-performing pipeline\.

## 5Framework Validation

We apply CASOP to seven benchmark data sets covering four problem types and warehouse settings that differ in layout, number of pickers, number of orders, storage policy, and available order information\. The purpose of the experiments is to validate the implemented algorithms by comparing their solution quality to reported benchmark results, and answer the following three validation questions\.

- \(Q1\)Framework Adaptability:Is the framework able to adapt to a wide range of warehouse and problem settings so that it can be adopted by practitioners?
- \(Q2\)Algorithm Selection Potential:Under what conditions does algorithm selection improve solution quality?
- \(Q3\)Benchmarking:How good is the performance of sequentially executed algorithms against the best known solutions?

The remainder of this section is structured around these questions\.

All experiments were conducted on a Manjaro Linux 25\.0\.10 workstation with an Intel Xeon W5\-2445 CPU \(10 cores, 20 threads\) and 125 GB RAM\. CASOP is implemented in Python 3\.13\.7, and we use Gurobi 12\.0\.3 with default solver settings for the CBR model\. For the local search batching approach and the exact solution approaches, we set a time limit of 240 seconds, configurable through CLS\-Luigi\. All other heuristics were used without time limits\. Each instance was processed by all applicable algorithm combinations\.

### 5\.1Validation Setup

In the following, we briefly detail the validation setup\. Our validation applies CASOP to seven benchmark instances across four problem classes: SPRP, SPRP\-SS, OBRP, and OBRSP\. To demonstrate the broad applicability of CASOP, we collected representative instance sets from the literature covering a wide range of warehouse settings\. The instance sets are characterized by varying levels of, e\.g\., pickers, capacities, storage policies, number of orders and orderlines, layout characteristics, and order\-level information \(due dates\)\.

Table 7:Overview of instance sets used in the experimental framework validation\.LayoutCapacityStorageOrdersResourcesProblemInstance SetReferencenbn\_\{b\} nan\_\{a\} npn\_\{p\} δ\\delta ckc\_\{k\} StorageTT \# Policies \|𝒪\|\|\\mathcal\{O\}\| \|ℒ​\(o\)\|\|\\mathcal\{L\}\(o\)\| \|ℛ\|\|\\mathcal\{R\}\| SPRPSPRPHeßler and Irnich \([2024](https://arxiv.org/html/2606.26852#bib.bib17)\)15–5030–180——Dedicated113–301SPRP\-SSHeßler and Irnich \([2024](https://arxiv.org/html/2606.26852#bib.bib17)\)15–5030–180——Scattered113–301OBRPBahceciOencanBahçeci and Öncan \([2022](https://arxiv.org/html/2606.26852#bib.bib6)\)11010\# Items5–30Dedicated58–1210–291HennWaescherHennet al\.\([2010](https://arxiv.org/html/2606.26852#bib.bib5)\)11045\# Items30–75Dedicated220–100125–4421MuterOencanMuter and Öncan \([2015](https://arxiv.org/html/2606.26852#bib.bib2)\)11010\# Items24–48Dedicated120–10062–2001Foodmartvan Gilset al\.\([2019](https://arxiv.org/html/2606.26852#bib.bib1)\)28198\# Items40Dedicated15–200059–83501OBRSPKrisBriantet al\.\([2023](https://arxiv.org/html/2606.26852#bib.bib28)\)26–1860–180\# Orderlines4–45Dedicated16–3001–452–6Sources:a[https://logistik\.bwl\.uni\-mainz\.de/forschung/benchmarks/](https://logistik.bwl.uni-mainz.de/forschung/benchmarks/)\(SPRP, SPRP\-SS, BahceciOencan, Henn, MuterOencan\);b[https://pagesperso\.g\-scop\.grenoble\-inp\.fr/~cambazah/batching/](https://pagesperso.g-scop.grenoble-inp.fr/~cambazah/batching/)\(Foodmart\);c[https://pagesperso\.g\-scop\.grenoble\-inp\.fr/~cambazah/sequencing/](https://pagesperso.g-scop.grenoble-inp.fr/~cambazah/sequencing/)\(Kris\)

##### Data Sources and Preprocessing

We evaluate CASOP on seven benchmark instance sets covering different problem classes, warehouse layouts, and operational settings\. An overview of all instance sets and their key characteristics is provided in Table[7](https://arxiv.org/html/2606.26852#S5.T7)\.

We cover one SPRP instance set presented inHeßler and Irnich \([2024](https://arxiv.org/html/2606.26852#bib.bib17)\)\. In theSPRP\-SSset, scattered storage is considered, where items may be stored in multiple storage locations\. Both instance sets have a single picker and a single\-block, parallel\-aisle layout, with varying numbers of aisles and storage locations per aisle\.

For OBRP, we evaluate four instance sets\.MuterOencan,BahceciOencan, andHenncover varying settings of single\-block parallel\-aisle layouts with varying picker capacities, number of orders, and number of articles per order\. Each of these instance sets measures picker capacity in terms of the number of items\. ForBahceciOencanandHenn, five and two storage policies are varied, respectively\.Foodmartfeatures a parallel\-aisle layout with two blocks connected by a cross\-aisle\. ForFoodmart, picker capacity is constrained by the number of boxes on a picking cart\. As boxes cannot contain mixed orders, each ordero∈Oo\\in Orequires a dedicated number of boxes calculated asbo=⌈itemso/B⌉b\_\{o\}=\\lceil\\text\{items\}\_\{o\}/B\\rceil, whereBBdenotes the box capacity\. A batch is feasible if∑o∈bbo≤K\\sum\_\{o\\in b\}b\_\{o\}\\leq K, whereKKis the number of boxes per cart as defined in the Resources domainℛ\\mathcal\{R\}\. This constraint reflects the order indivisibility requirement from the original problem formulation byValleet al\.\([2017](https://arxiv.org/html/2606.26852#bib.bib4)\), where orders from different customers cannot share baskets\.

TheKrisinstance set covers the OBRSP and was first proposed inValleet al\.\([2017](https://arxiv.org/html/2606.26852#bib.bib4)\)and further improved and published online byBriantet al\.\([2023](https://arxiv.org/html/2606.26852#bib.bib28)\), who also publish solutions for a subset of 243 instances\.Krisincludes multiple pickers, a two\-block layout, and order due dates, with all orders being released at the beginning of the planning horizon\. TheKrisinstance set is provided with large and small instances that differ in the number of orders per instance, which we treat together\.

All instance sets originate from heterogeneous sources and formats\. We therefore implement dedicated parsers andDomainLoaderto transform each instance into the unified CASOPdomain model\. The preprocessing code and parsers are publicly available in our open\-source repository to ensure reproducibility\.

##### Employed Algorithms and Configurations

We use a broad set of algorithms covering all subproblems defined in Section[3](https://arxiv.org/html/2606.26852#S3)\. The employed methods and their abbreviations are summarized in Section[3\.4](https://arxiv.org/html/2606.26852#S3.SS4)\.

Our focus is on the combination of heuristic approaches, and thus, exact routing approaches are excluded from our evaluation\. The only exceptions are the runtime efficient RR approach and CBR, which is included as an exact benchmark for routing and batching and to highlight the non\-linear template structure\. To keep experiment runtimes manageable, we evaluate CBR only onBahceciOencan, the smallest OBRP instance set\.

Batching methods that require configuration, e\.g\., with methods for initial solution construction, are evaluated using a restricted set of representative configurations\.LocalSearchBatchingis combined with three routing algorithms \(RR, NN, SShape\) for solution evaluation and two initialization strategies \(FiFo, RAND\), yielding six LS configurations\.SeedBatchingis evaluated with the seed criterionCLOSEST\_TO\_DEPOTand two similarity measures \(SHARED\_ARTICLES,MIN\_DISTANCE\)\. ForSavingsBatching, routing\-based distance evaluation is performed using RR, NN, and SShape\.

##### Performance Metrics and Objectives

Following common practice in algorithm selection literature\(Bischlet al\.,[2016](https://arxiv.org/html/2606.26852#bib.bib23)\), we compare the following:

- 1\.Single Best Solver \(SBS\): The algorithm combination that achieves the best average performance across all instances in a instance sets\.
- 2\.Virtual Best Solver \(VBS\): An oracle that always selects the best\-performing algorithm for each instance\. The VBS provides an upper bound on achievable performance through perfect algorithm selection\. Because multiple strategies may yield the same result, we will use total runtime as a tiebreaker and always report the fastest strategy\.

The relative gap between SBS and VBS quantifies the potential benefit of algorithm selection:

Relative Gap=SBS Mean−VBS MeanSBS Mean×100%\.\\text\{Relative Gap\}=\\frac\{\\text\{SBS Mean\}\-\\text\{VBS Mean\}\}\{\\text\{SBS Mean\}\}\\times 100\\%\.
We further report the gap between the best known solution \(BKS\) reported in literature and the VBS result per instance, i\.e\.,

Optimality Gap=VBS−BKSBKS×100%\.\\text\{Optimality Gap\}=\\frac\{\\text\{VBS\}\-\\text\{BKS\}\}\{\\text\{BKS\}\}\\times 100\\%\.
The runtime of the resulting pipelines is evaluated in seconds\. In terms of objectives, we compare distance, makespan, tardiness, and on\-time rate, based on the problem setting and instance features\.

### 5\.2Q1: Framework Adaptability Across Problem Classes

We first analyze the pipeline generation process in general\. We therefore evaluate the number of resulting pipelines per instance set and compare the runtimes of the three stages: instance generation, pipeline building, and execution\.

##### Pipeline Overview

Table[8](https://arxiv.org/html/2606.26852#S5.T8)summarizes the execution of CASOP, reporting the number of synthesized pipelines per instance set alongside the number of applicable algorithm components for item assignment, batching, routing, and scheduling\. The results demonstrate how the filtering mechanism identifies applicable algorithms based on problem type and instance characteristics, effectively pruning the combinatorial space of possible pipelines\. We denote the filtered algorithm configurations per subproblem by𝐼𝐴∗⊆𝐼𝐴\\mathit\{IA\}^\{\*\}\\subseteq\\mathit\{IA\},B∗⊆B\\mathit\{B\}^\{\*\}\\subseteq\\mathit\{B\},R∗⊆R\\mathit\{R\}^\{\*\}\\subseteq\\mathit\{R\},𝐵𝑅∗⊆𝐵𝑅\\mathit\{BR\}^\{\*\}\\subseteq\\mathit\{BR\}, andS∗⊆S\\mathit\{S\}^\{\*\}\\subseteq\\mathit\{S\}\.

For theSPRPandSPRP\-SSinstance sets, which consist of single\-order instances without batching capacity, no genuine order\-batching decision is present\. For consistency with the pipeline template, the table reports one single\-order batching alternative, which acts as an identity component\. The resulting number of pipelines per instance is therefore\|𝐼𝐴\|×\|B\|×\|R\|\|\\mathit\{IA\}\|\\times\|\\mathit\{B\}\|\\times\|\\mathit\{R\}\|, with\|B\|=1\|\\mathit\{B\}\|=1\.

For OBRP instance sets, batching algorithms are applicable as well\. ForBahceciOencan, the BR subproblem is applicable\. Therefore, the resulting number of pipelines for this instance set is not only the Cartesian product\|𝐼𝐴∗\|×\|B∗\|×\|R∗\|\|\\mathit\{IA\}^\{\*\}\|\\times\|\\mathit\{B\}^\{\*\}\|\\times\|\\mathit\{R\}^\{\*\}\|, but also includes the pipelines generated by the combined batching\-and\-routing approach,\|𝐼𝐴∗\|×\|𝐵𝑅∗\|\|\\mathit\{IA\}^\{\*\}\|\\times\|\\mathit\{BR\}^\{\*\}\|\.

For this instance set, the framework synthesizes both distance\-based pipelines without scheduling and time\-based pipelines with scheduling\. The resulting number of pipelines per instance is therefore

\|𝐼𝐴∗\|×\|B∗\|×\|R∗\|\+\|𝐼𝐴∗\|×\|B∗\|×\|R∗\|×\|S∗\|\.\|\\mathit\{IA\}^\{\*\}\|\\times\|\\mathit\{B\}^\{\*\}\|\\times\|\\mathit\{R\}^\{\*\}\|\+\|\\mathit\{IA\}^\{\*\}\|\\times\|\\mathit\{B\}^\{\*\}\|\\times\|\\mathit\{R\}^\{\*\}\|\\times\|\\mathit\{S\}^\{\*\}\|\.
These results demonstrate that CASOP is able to capture the domain features and algorithm requirements and successfully synthesizes valid algorithm pipelines for four different problem classes based on this information with a single CLS\-Luigi template\.

Table 8:Number of resulting pipelines per instance set\.\# Algorithms\# Instances\# PipelinesInstance Set𝐼𝐴\\mathit\{IA\}B\\mathit\{B\}R\\mathit\{R\}𝐵𝑅\\mathit\{BR\}S\\mathit\{S\}SPRP11600240014400SPRP\-SS5160014300429000BahceciOencan111610135090450HennWaescher1116005759380094MuterOencan11160027017820FoodmartData195001446480Kris113503480124800∑\\sum24,7041,063,044
##### Runtimes

Table[9](https://arxiv.org/html/2606.26852#S5.T9)reports the computational overhead of the pipeline synthesis process\.

Table 9:Detailed pipeline generation runtimes \(mean±\\pmstd, in seconds\)Instance SetLoad DomainBuild PipelinesRun PipelinesTotalSPRP1\.1717±2\.72871\.1717\\pm 2\.72870\.221±0\.1890\.221\\pm 0\.1890\.388±0\.7220\.388\\pm 0\.7221\.781±3\.4641\.781\\pm 3\.464SPRP\-SS1\.4288±3\.36601\.4288\\pm 3\.36600\.569±0\.3320\.569\\pm 0\.3320\.465±0\.8350\.465\\pm 0\.8352\.463±4\.2022\.463\\pm 4\.202BahceciOencan0\.0088±0\.00830\.0088\\pm 0\.00830\.878±0\.1250\.878\\pm 0\.125154\.078±109\.904154\.078\\pm 109\.904154\.965±109\.906154\.965\\pm 109\.906HennWaescher0\.0224±0\.02760\.0224\\pm 0\.02760\.354±0\.1670\.354\\pm 0\.16725\.956±30\.62125\.956\\pm 30\.62126\.333±30\.59026\.333\\pm 30\.590MuterOencan0\.0025±0\.00040\.0025\\pm 0\.00040\.235±0\.0110\.235\\pm 0\.01127\.489±24\.34827\.489\\pm 24\.34827\.728±24\.34727\.728\\pm 24\.347Foodmart0\.0851±0\.04310\.0851\\pm 0\.04310\.190±0\.1000\.190\\pm 0\.10019\.728±53\.56519\.728\\pm 53\.56520\.003±53\.57620\.003\\pm 53\.576Kris0\.4311±0\.56020\.4311\\pm 0\.560223\.146±22\.50023\.146\\pm 22\.500184\.554±297\.259184\.554\\pm 297\.259208\.132±284\.392208\.132\\pm 284\.392The runtimes are given for the initial domain generation \(load domain\), the pipeline build process \(build pipelines\), the sequential execution of the resulting pipelines \(run pipelines\), and the total time \(total\)\. Notably, the load domain and build pipelines phases remain negligible across all instance sets, except forKris, confirming that the framework’s overhead for algorithm filtering and pipeline construction is minimal compared to actual algorithm execution\. ForSPRP\-SS, the entire process completes in under 3 seconds per instance on average\. Across all instances, the total runtime is dominated by the run pipelines phase, which executes all synthesized algorithm pipelines using Luigi\.

The long pipeline runtimes ofKrisinstances indicate that the time limits for the LS batching configurations are exhausted, and the relative complexity of the batching phase compared to other instance sets, where solutions can be found faster\. This can also be seen inBahceciOencan, where the longer runtimes are attributable to the combined batching\-and\-routing approach\. Also, for the other instance sets, high standard deviation indicates instance\-dependent variability, likely driven by varying instance sizes and greater computational effort, e\.g\., in generating the distance matrix and graph\. At the same time, this serves as a good example of the caching mechanism of CLS\-Luigi\. When running new algorithms for the same instances, these time\-consuming preprocessing steps do not have to be repeated\.

To summarize Q1, the experiments demonstrate that CASOP successfully processes instances across multiple problem classes, varying layout representations, storage policies, and resource configurations\. The mapping approach implemented in CASOP automatically identifies applicable algorithms based on warehouse characteristics and algorithm requirements\. Through direct comparison with the best reported results from the literature, we could also verify the correctness of the instance modeling and algorithm implementations\.

### 5\.3Q2: Algorithm Selection Potential

Table[10](https://arxiv.org/html/2606.26852#S5.T10)shows the comparison of VBS vs\. SBS for all instance sets aggregated by the applicable objectives\.

Table 10:VBS overview\.ProblemInstance SetSBS StrategySBS MeanVBS MeanRelative Gap %ObjectiveSPRPSPRPGIA\+RawInput\+RR589\.83589\.830\.00distanceSPRPSPRP\-SSMinMinIA\+RawInput\+RR395\.28385\.782\.40distanceOBRPBahceciOencanGIA\+CBR168\.28168\.100\.11distanceOBRPHennWaescherGIA\+SavingsRR\+RR8114\.348083\.950\.37distanceOBRPMuterOencanGIA\+SavingsRR\+RR1293\.231279\.491\.06distanceOBRPFoodmartGIA\+SavingsNN\+NN2299\.582095\.338\.88distanceOBRSPKrisGIA\+SavingsNN\+NN\+EDD144076\.33143695\.600\.26distanceOBRSPKrisGIA\+SavingsNN\+NN\+LPT71368\.4370044\.131\.86makespanOBRSPKrisGIA\+DueDate\+NN\+EDD2153\.532037\.065\.41max\_tardinessOBRSPKrisGIA\+DueDate\+NN\+EDD96\.4997\.941\.50on\_time\_rate

We report the name of the SBS as a concatenation of the pipeline’s algorithmic components in the order of item assignment, pick list generation, picker routing, and scheduling\. We further report the mean distance of the SBS \(SBS mean\), the mean distance of the VBS \(VBS mean\), and the gain achieved by the VBS as relative gap between SBS and VBS \(Relative Gap %\)\. For most instance sets, the potential gain expected from the VBS is marginal and largely depends on the applicable solution approaches\. The largest gains can be observed for theFoodmartandSPRP\-SSinstance sets, with a gain of 8\.88 % and 2\.40 %, respectively\. For other instance sets such asSPRP,Kris, andBahceciOencan, we find a gain of around 0 % for the distance objective\. This indicates that there is a single strategy that performs best on every instance of the respective instance set\. The reason in the case ofSPRP, andBahceciOencanis the use of approaches that provide exact results\.

ForHennWaescherandMuterOencan, CBR was not used, but we can still see that the combination of SavingsRR and RR wins on almost every instance, which again is not surprising, as both approaches use the exact RR routing approach\. The LS configurations were not able to outperform the savings approach within the specified time limit\.

Foodmarthas the largest relative gap between SBS and VBS\. To investigate this, we analyze the per\-instance gap between each strategy and the VBS as a function of the number of orders\. Figure[9](https://arxiv.org/html/2606.26852#S5.F9)shows the gap to the VBS \(top\) and the mean CPU time \(bottom\) for all strategies that achieve the best result on at least one instance\. For small and medium instances \(up to 100 orders\), the local search configurations GIA\+LSOrdNrNN\+NN and GIA\+LSRANDNN\+NN consistently achieve the lowest gaps\. However, for instances with 500 or more orders, their CPU time approaches the 240\-second time limit, and the gap increases to over 80%\. The savings\- and seed\-based strategies maintain stable gaps across all instance sizes at low computational cost\. The local search configurations dominate on small instances but exhaust the 240\-second time limit on large instances, degrading their mean performance\. As the SBS is determined by the overall mean, it falls on GIA\+SavingsNN\+NN\. Figure[9](https://arxiv.org/html/2606.26852#S5.F9)indicates that this strategy actually performs worse than the LS based strategy for all instances below 200 orders\. This also highlights the drawback of the pure mean\-based determination of the SBS\.

![Refer to caption](https://arxiv.org/html/2606.26852v1/images/foodmart_strategy_vs_vbs_distance_time.png)Figure 9:Per\-strategy gap to the VBS \(top\) and mean CPU time \(bottom\) on theFoodmartinstance set, grouped by number of orders\.Since theKrisinstances allow us to solve the scheduling subproblem, we can analyze time\-related objectives\. The comparison of the SBS reveals that for different objectives, different strategies may perform better, and rankings across different objectives are not consistent, as illustrated in Figure[10](https://arxiv.org/html/2606.26852#S5.F10)\. For the distance and makespan objectives, the pipeline GIA\+SavingsNN\+NN\+LPT performs best\. However his pipeline is not in the top ten for the due\-date\-related objectives, where GIA\+DueDate\+NN\+EDD consistently performs best\. This is because the pipelines for distance and makespan ignore the due\-date constraints and can therefore find solutions that are better than those that sort by due date\.

![Refer to caption](https://arxiv.org/html/2606.26852v1/x6.png)Figure 10:Varying ranks of strategies for different objectives on theKrisinstance set\. Results are grouped by objective and objective categories\. We show the ten best performing strategies for the respective objective, ranked from best to worst\.To summarize Q2, algorithm selection improves solution quality when the best\-performing pipeline depends on instance characteristics or on the objective function\. For most distance\-based objectives, the relative gap between SBS and VBS is small, indicating that a single robust strategy often dominates across the entire instance set\. This is especially visible forSPRP,BahceciOencan,HennWaescher,MuterOencan, andKrisunder the distance objective\. However, theFoodmartresults clearly show the potential of algorithm selection: local\-search configurations perform best on small and medium instances, whereas savings\- and seed\-based strategies are more stable on larger instances where local search runs out of time\. TheKrisresults further indicate that the best pipeline depends on the objective, since distance, makespan, tardiness, and on\-time rate favor different strategy rankings\. Algorithm selection is therefore most useful in heterogeneous settings where instance size, time limits, or objective functions change the relative performance of the available pipelines\.

### 5\.4Q3: Benchmarking Against Best Known Solutions

We compare the VBS results to the BKS values from the corresponding benchmark studies, where possible\. These results contain both heuristic and optimal solutions\. ForKris, the objective values are calculated from the reported solution schedules\.

Table[11](https://arxiv.org/html/2606.26852#S5.T11)reports the number of benchmark instances \(\# Instances\), the evaluated objective \(Objective\), the mean relative gap of the VBS to the BKS \(Mean Gap to BKS \[%\]\), the ex\-post runtime of the selected VBS pipeline \(VBS Runtime \[s\]\), and the corresponding mean objective values of the VBS and the BKS \(VBS Mean and BKS Mean\)\.

Table 11:Validation results across instance sets\.Instance Set\# InstancesObjectiveMean Gap to BKS \[%\]VBS Runtime \[s\]VBS MeanBKS MeanSPRP2400distance0\.0000\.006589\.834589\.834SPRP\-SS14300distance9\.5740\.004385\.784345\.356BahceciOencan1350distance0\.01536\.333168\.102168\.074HennWaescher1440distance3\.2064\.0858090\.1717840\.128MuterOencan270distance2\.4587\.1441308\.7751278\.174Foodmart42distance6\.2960\.307850\.801799\.302Kris294distance6\.6550\.06769828\.08264261\.571Kris294on\-time rate0\.9450\.07299\.05099\.993Kris294on\-time\_distance13\.9450\.06281898\.23164261\.571

Figure[11](https://arxiv.org/html/2606.26852#S5.F11)visualizes the gap between the VBS and the optimal results as boxplots\.

![Refer to caption](https://arxiv.org/html/2606.26852v1/images/vbs_gap_to_bks_boxplot_combined.png)Figure 11:Comparison of gap between VBS and BKS on different instance sets\. Results are grouped by instance set and problem class and sorted in ascending order by average gap of the VBS\. While the instance sets for the problem classes SPRP and OBRP show the distance objective, forKris, three objectives are evaluated, which are specified in parentheses\.As expected, the framework achieves the best results for instance sets with parallel\-aisle single\-block layouts \(SPRP,BahceciOencan,MuterOencan\), where exact approaches for the subproblems are applicable\. ForSPRP, we can validate the correctness of our RR implementation and our instance representation, as it matches the reported results inHeßler and Irnich \([2024](https://arxiv.org/html/2606.26852#bib.bib17)\)\. The VBS reaches a Mean Gap to BKS of 0\.000%, with identical VBS Mean and BKS Mean values of 589\.834\.

ForSPRP\-SS, the remaining gap is mainly caused by the fact that the item assignment is solved with a heuristic component, as opposed to the integrated approach presented inHeßler and Irnich \([2024](https://arxiv.org/html/2606.26852#bib.bib17)\)\. On theBahceciOencaninstance set, the average gap to the best reported results is close to zero, indicating that the integrated CBR model is able to reproduce the optimal results reported inHeßler and Irnich \([2022](https://arxiv.org/html/2606.26852#bib.bib18)\)\. The results ofMuterOnecanandHennWaescher, for which CBR was not used, show that heuristic batching approaches combined with RR routing are strong baselines, achieving Mean Gap to BKS values of 2\.458% and 3\.206%, respectively\. ForFoodmart, we observe a Mean Gap to BKS of 6\.296%\. This instance set uses a two\-block layout, making RR routing inapplicable to the evaluated implementation\.

For theKrisinstance set, we evaluate three objectives: on\-time rate, distance objective, and the hierarchical objective of on\-time rate and distance\. For the hierarchical objective, the VBS selects the pipeline with the highest on\-time rate per instance, using distance only as a tiebreaker\. This is the fairest comparison, as using the VBS solely for the distance objective would not respect the due\-date constraints the literature model is subject to\. Although the VBS achieves a Mean Gap to BKS below 1% for the on\-time rate objective, this does not translate to the hierarchical objective where the Mean Gap to BKS is 13\.945%\. When simply selecting the pipeline with the shortest distance, we can achieve a Mean Gap to BKS of 6\.655%\.

To summarize Q3, the benchmark comparison shows that the VBS can reproduce or closely approach best reported solution values when the evaluated component portfolio matches the benchmark setting\. ForSPRP, the RR implementation exactly matches the reported results, validating both the routing implementation and the instance representation\. ForBahceciOencan, the integrated CBR model yields a Mean Gap to BKS close to zero\. For settings without CBR, the results quantify the performance of sequential batching\-and\-routing pipelines\. The VBS achieves an average gap of 3\.206% forHennWaescherand 2\.458% forMuterOencan\. Larger gaps occur, for instance, in sets where the evaluated portfolio relies on heuristic components or where specific exact components are not applicable or not yet implemented in the algorithm repository, as inSPRP\-SS,Foodmart, and the hierarchical objective onKris\.

## 6Conclusion and Future Research

This paper introduced the CASOP framework for context\-aware synthesis of optimization pipelines in warehouse optimization\. Building on the need to study decomposed planning models in warehouse operations, the framework addresses how order fulfillment problems can be decomposed into subproblems, how applicable algorithm configurations can be identified from warehouse context and algorithm requirements, and how these configurations can be composed into executable pipelines\.

CASOP combines four main components\. First, warehouse systems are described using structured, machine\-readable data cards that capture the problem class, objective, and available warehouse data across the five domain objects: layout, articles, orders, resources, and storage\. Second, optimization algorithms are represented as algorithm cards that specify the addressed subproblem, optimization objective, and requirements regarding domain types, features, and feature constraints\. Third, a context\-aware mapping procedure matches algorithm requirements against the data card and the problem taxonomy to identify algorithms applicable to a given warehouse setting\. Fourth, the resulting algorithms are composed into executable pipelines using CLS\-Luigi\. The taxonomy is translated into a pipeline template that covers both sequential decompositions and partially integrated solution paths, such as integrated batching and routing, and is instantiated using algorithms from the open\-source repository provided with the framework, which includes implementations for item assignment, order batching, picker routing, integrated batching and routing, and picker scheduling\.

The experimental evaluation shows that CASOP can be applied across heterogeneous warehouse optimization settings\. Across seven benchmark instance sets covering four problem classes, the framework generated and evaluated 1,063,044 valid pipelines on 24,704 instances\. The comparison with reported benchmark results further shows the performance range of the evaluated component portfolio\. ForBahceciOencan, the integrated CBR model yields an average gap close to zero, while sequential heuristic pipelines achieve average gaps of 3\.43% and 4\.85% forHennWaescherandMuterOencan, respectively\. Larger gaps occur in settings where the evaluated portfolio relies on heuristic components because exact\-algorithm components are not applicable, for example, in scattered\-storage instances or two\-block layouts\.

Overall, the paper demonstrates that context\-aware pipeline synthesis is a feasible approach for structuring and evaluating decomposed decision\-making approaches in warehouse optimization\. Instead of studying isolated algorithms or manually selected combinations, the proposed framework makes the relation between warehouse context, algorithm applicability, pipeline structure, and resulting performance explicit\.

Based on this, several directions for future work emerge\. First, while this paper focuses on order fulfillment, the methodology can be transferred to other warehouse optimization problems and potentially to broader supply chain planning settings\. Second, the algorithm repository should be extended to integrate additional subproblems and algorithm variants for existing ones\. Third, future work should study dynamic and online warehouse settings, where the applicable pipeline may change as orders, resources, and system states evolve\. Finally, recent developments in large language models and agentic systems may support selected parts of the framework, such as generating algorithm cards, refining pipeline templates, or integrating new algorithm components\.

## Acknowledgements

This publication was produced as part of the research project “Data\- and target\-driven sequential decision\-making for time\-dynamic logistics systems”, which was funded by the Deutsche Forschungsgemeinschaft \(DFG, German Research Foundation\) – 502552827\.

## References

- Amazon\.com, Inc\. \(2024\)Fulfillment and delivery\.Note:Image reproduced with permission\. Accessed: 2026\-05\-13External Links:[Link](https://press.aboutamazon.com/fulfillment-and-delivery)Cited by:[Figure 1](https://arxiv.org/html/2606.26852#S1.F1),[Figure 1](https://arxiv.org/html/2606.26852#S1.F1.3.2)\.
- U\. Bahçeci and T\. Öncan \(2022\)An evaluation of several combinations of routing and storage location assignment policies for the order batching problem\.International Journal of Production Research60\(19\),pp\. 5892–5911\.External Links:[Document](https://dx.doi.org/10.1080/00207543.2021.1973684)Cited by:[§1](https://arxiv.org/html/2606.26852#S1.p5.1),[§2\.1](https://arxiv.org/html/2606.26852#S2.SS1.SSS0.Px1.p1.1),[§2\.1](https://arxiv.org/html/2606.26852#S2.SS1.p1.1),[§2\.2](https://arxiv.org/html/2606.26852#S2.SS2.SSS0.Px1.p1.1),[Table 7](https://arxiv.org/html/2606.26852#S5.T7.9.9.13.3)\.
- M\. Beeks, R\. R\. Afshar, Y\. Zhang, R\. Dijkman, C\. Van Dorst, and S\. De Looijer \(2022\)Deep reinforcement learning for a multi\-objective online order batching problem\.InProceedings of the International Conference on Automated Planning and Scheduling,pp\. 435–443\.Cited by:[§3\.4\.2](https://arxiv.org/html/2606.26852#S3.SS4.SSS2.p1.1)\.
- M\. T\. Benavides\-Robles, J\. M\. Cruz\-Duarte, J\. C\. Ortiz\-Bayliss, and I\. Amaya \(2025\)Algorithm selection for allocating pods within robotic mobile fulfillment systems: a hyper\-heuristic approach\.IEEE Access13,pp\. 14010–14028\.External Links:[Document](https://dx.doi.org/10.1109/ACCESS.2025.3530842)Cited by:[§2\.1](https://arxiv.org/html/2606.26852#S2.SS1.p3.1)\.
- J\. Bessai, A\. Dudenhefner, B\. Düdder, M\. Martens, and J\. Rehof \(2014\)Combinatory logic synthesizer\.InInternational Symposium On Leveraging Applications of Formal Methods, Verification and Validation,pp\. 26–40\.External Links:[Document](https://dx.doi.org/10.1007/978-3-662-45234-9%5F3)Cited by:[§2\.3](https://arxiv.org/html/2606.26852#S2.SS3.p1.1)\.
- B\. Bischl, P\. Kerschke, L\. Kotthoff, M\. Lindauer, Y\. Malitsky, A\. Fréchette, H\. Hoos, F\. Hutter, K\. Leyton\-Brown, K\. Tierney, and J\. Vanschoren \(2016\)ASlib: a benchmark library for algorithm selection\.Artificial Intelligence237,pp\. 41–58\.External Links:[Document](https://dx.doi.org/10.1016/j.artint.2016.04.003)Cited by:[§1](https://arxiv.org/html/2606.26852#S1.p7.1),[§5\.1](https://arxiv.org/html/2606.26852#S5.SS1.SSS0.Px3.p1.1)\.
- S\. Bock, S\. Bomsdorf, N\. Boysen, and M\. Schneider \(2025\)A survey on the Traveling Salesman Problem and its variants in a warehousing context\.European Journal of Operational Research322\(1\),pp\. 1–14\.External Links:[Document](https://dx.doi.org/10.1016/j.ejor.2024.04.014)Cited by:[§1](https://arxiv.org/html/2606.26852#S1.p4.1),[§3\.4\.3](https://arxiv.org/html/2606.26852#S3.SS4.SSS3.p1.1)\.
- N\. Boysen, R\. de Koster, and F\. Weidinger \(2019\)Warehousing in the e\-commerce era: a survey\.European Journal of Operational Research277\(2\),pp\. 396–411\.External Links:[Document](https://dx.doi.org/10.1016/j.ejor.2018.08.023)Cited by:[§1](https://arxiv.org/html/2606.26852#S1.p4.1),[§3\.1](https://arxiv.org/html/2606.26852#S3.SS1.SSS0.Px5.p1.12)\.
- N\. Boysen and R\. de Koster \(2025\)50 years of warehousing research: an operations research perspective\.European Journal of Operational Research320\(3\),pp\. 449–464\.External Links:[Document](https://dx.doi.org/10.1016/j.ejor.2024.03.026)Cited by:[§1](https://arxiv.org/html/2606.26852#S1.p2.1),[§1](https://arxiv.org/html/2606.26852#S1.p4.1),[§1](https://arxiv.org/html/2606.26852#S1.p6.1)\.
- O\. Briant, H\. Cambazard, D\. Cattaruzza, N\. Catusse, A\. Ladier, and M\. Ogier \(2020\)An efficient and general approach for the joint order batching and picker routing problem\.European Journal of Operational Research285\(2\),pp\. 497–512\.External Links:[Document](https://dx.doi.org/10.1016/j.ejor.2020.01.059)Cited by:[§3\.4\.3](https://arxiv.org/html/2606.26852#S3.SS4.SSS3.p2.1)\.
- O\. Briant, H\. Cambazard, D\. Cattaruzza, N\. Catusse, A\. Ladier, and M\. Ogier \(2023\)Lower and upper bounds for the joint batching, routing and sequencing problem\.Note:arXiv preprint arXiv:2303\.17834External Links:[Link](https://arxiv.org/abs/2303.17834),2303\.17834Cited by:[§5\.1](https://arxiv.org/html/2606.26852#S5.SS1.SSS0.Px1.p4.1),[Table 7](https://arxiv.org/html/2606.26852#S5.T7.9.9.17.3)\.
- B\. Cals, Y\. Zhang, R\. Dijkman, and C\. Van Dorst \(2021\)Solving the online batching problem using deep reinforcement learning\.Computers & Industrial Engineering156,pp\. 107221\.Cited by:[§3\.4\.2](https://arxiv.org/html/2606.26852#S3.SS4.SSS2.p1.1)\.
- B\. Cheng, T\. Xie, L\. Wang, Q\. Tan, and X\. Cao \(2024\)Deep reinforcement learning driven cost minimization for batch order scheduling in robotic mobile fulfillment systems\.Expert Systems with Applications255,pp\. 124589\.External Links:[Document](https://dx.doi.org/10.1016/j.eswa.2024.124589)Cited by:[§2\.1](https://arxiv.org/html/2606.26852#S2.SS1.p3.1)\.
- G\. Clarke and J\. W\. Wright \(1964\)Scheduling of vehicles from a central depot to a number of delivery points\.Operations Research12\(4\),pp\. 568–581\.Cited by:[Table 3](https://arxiv.org/html/2606.26852#S3.T3.2.7.3.1.1)\.
- P\. C\. Clements and L\. M\. Northrop \(2001\)Software product lines: practices and patterns\.Addison\-Wesley,Boston, MA\.Cited by:[§2\.3](https://arxiv.org/html/2606.26852#S2.SS3.p1.1)\.
- R\. F\. de Assis, W\. de Paula Ferreira, and M\. Ouhimmou \(2025\)Order picking dataset from a warehouse of a footwear manufacturing company\.Data in Brief61,pp\. 111837\.External Links:[Document](https://dx.doi.org/10.1016/j.dib.2025.111837)Cited by:[§2\.2](https://arxiv.org/html/2606.26852#S2.SS2.SSS0.Px1.p2.1)\.
- R\. de Koster, T\. Le\-Duc, and K\. J\. Roodbergen \(2007\)Design and control of warehouse order picking: A literature review\.European Journal of Operational Research182\(2\),pp\. 481–501\.External Links:[Document](https://dx.doi.org/10.1016/j.ejor.2006.07.009)Cited by:[§1](https://arxiv.org/html/2606.26852#S1.p4.1)\.
- R\. L\. Graham \(1969\)Bounds on multiprocessing timing anomalies\.SIAM Journal on Applied Mathematics17\(2\),pp\. 416–429\.External Links:[Document](https://dx.doi.org/10.1137/0117039)Cited by:[§3\.4\.4](https://arxiv.org/html/2606.26852#S3.SS4.SSS4.p1.1)\.
- J\. Gu, M\. Goetschalckx, and L\. F\. McGinnis \(2007\)Research on warehouse operation: A comprehensive review\.European Journal of Operational Research177\(1\),pp\. 1–21\.External Links:[Document](https://dx.doi.org/10.1016/j.ejor.2006.02.025)Cited by:[§1](https://arxiv.org/html/2606.26852#S1.p4.1)\.
- S\. Henn, S\. Koch, K\. F\. Doerner, C\. Strauss, and G\. Wäscher \(2010\)Metaheuristics for the Order Batching Problem in Manual Order Picking Systems\.Business Research3\(1\),pp\. 82–105\.External Links:[Document](https://dx.doi.org/10.1007/BF03342717)Cited by:[§2\.1](https://arxiv.org/html/2606.26852#S2.SS1.p2.1),[§2\.2](https://arxiv.org/html/2606.26852#S2.SS2.SSS0.Px1.p1.1),[§3\.1](https://arxiv.org/html/2606.26852#S3.SS1.SSS0.Px3.p1.12),[§3\.4\.2](https://arxiv.org/html/2606.26852#S3.SS4.SSS2.p1.1),[Table 3](https://arxiv.org/html/2606.26852#S3.T3.2.9.3.1.1),[Table 7](https://arxiv.org/html/2606.26852#S5.T7.9.9.14.2)\.
- K\. Heßler and S\. Irnich \(2022\)Modeling and exact solution of picker routing and order batching problems\.Technical ReportTechnical ReportLM\-2022\-03,Chair of Logistics Management, Gutenberg School of Management and Economics, Johannes Gutenberg University Mainz,Mainz, Germany\.Cited by:[§5\.4](https://arxiv.org/html/2606.26852#S5.SS4.p5.1)\.
- K\. Heßler and S\. Irnich \(2024\)Exact solution of the single\-picker routing problem with scattered storage\.INFORMS Journal on Computing36\(6\),pp\. 1417–1435\.External Links:[Document](https://dx.doi.org/10.1287/ijoc.2023.0075)Cited by:[§1](https://arxiv.org/html/2606.26852#S1.p5.1),[§2\.1](https://arxiv.org/html/2606.26852#S2.SS1.SSS0.Px1.p1.1),[§2\.1](https://arxiv.org/html/2606.26852#S2.SS1.p4.1),[§2\.2](https://arxiv.org/html/2606.26852#S2.SS2.SSS0.Px1.p1.1),[§3\.4\.3](https://arxiv.org/html/2606.26852#S3.SS4.SSS3.p1.1),[§4\.3](https://arxiv.org/html/2606.26852#S4.SS3.p2.1),[§5\.1](https://arxiv.org/html/2606.26852#S5.SS1.SSS0.Px1.p2.1),[§5\.4](https://arxiv.org/html/2606.26852#S5.SS4.p4.1),[§5\.4](https://arxiv.org/html/2606.26852#S5.SS4.p5.1),[Table 7](https://arxiv.org/html/2606.26852#S5.T7.9.9.11.3),[Table 7](https://arxiv.org/html/2606.26852#S5.T7.9.9.12.2)\.
- J\. Klein, M\. Wurster, N\. Stricker, G\. Lanza, and K\. Furmans \(2021\)Towards ontology\-based autonomous intralogistics for agile remanufacturing production systems\.In2021 26th IEEE International Conference on Emerging Technologies and Factory Automation \(ETFA \),pp\. 01–07\.External Links:[Document](https://dx.doi.org/10.1109/ETFA45728.2021.9613486)Cited by:[§2\.2](https://arxiv.org/html/2606.26852#S2.SS2.SSS0.Px2.p1.1)\.
- D\. Knoll, J\. Waldmann, and G\. Reinhart \(2019\)Developing an internal logistics ontology for process mining\.Procedia CIRP79,pp\. 427–432\.Cited by:[§1](https://arxiv.org/html/2606.26852#S1.p7.1),[§2\.2](https://arxiv.org/html/2606.26852#S2.SS2.SSS0.Px2.p1.1),[§2\.2](https://arxiv.org/html/2606.26852#S2.SS2.SSS0.Px2.p2.1),[§2\.2](https://arxiv.org/html/2606.26852#S2.SS2.SSS0.Px4.p1.1)\.
- S\. Koch \(2014\)Genetische Algorithmen für das Order Batching\-Problem\.InGenetische Algorithmen für das Order Batching\-Problem in manuellen Kommissioniersystemen,pp\. 94–118\.Cited by:[§3\.4\.2](https://arxiv.org/html/2606.26852#S3.SS4.SSS2.p1.1)\.
- A\. Kostovska, D\. Vermetten, C\. Doerr, S\. Džeroski, P\. Panov, and T\. Eftimov \(2021\)Option: optimization algorithm benchmarking ontology\.InProceedings of the Genetic and Evolutionary Computation Conference Companion,pp\. 239–240\.Cited by:[§2\.2](https://arxiv.org/html/2606.26852#S2.SS2.SSS0.Px2.p1.1),[§2\.2](https://arxiv.org/html/2606.26852#S2.SS2.SSS0.Px2.p2.1),[§2\.2](https://arxiv.org/html/2606.26852#S2.SS2.SSS0.Px4.p1.1)\.
- L\. Lüke, K\. Heßler, and S\. Irnich \(2024\)The single picker routing problem with scattered storage: modeling and evaluation of routing and storage policies\.OR Spectrum46\(3\),pp\. 909–951\.External Links:[Document](https://dx.doi.org/10.1007/s00291-024-00760-4)Cited by:[§2\.1](https://arxiv.org/html/2606.26852#S2.SS1.SSS0.Px1.p1.1),[§2\.1](https://arxiv.org/html/2606.26852#S2.SS1.p2.1)\.
- D\. Mäckel, J\. Winkels, and C\. Schumacher \(2021\)Synthesis of scheduling heuristics by composition and recombination\.InOptimization and Learning,pp\. 283–293\.External Links:[Document](https://dx.doi.org/10.1007/978-3-030-85672-4%5F21)Cited by:[§1](https://arxiv.org/html/2606.26852#S1.p7.1),[§2\.3](https://arxiv.org/html/2606.26852#S2.SS3.SSS0.Px1.p1.1),[§2\.3](https://arxiv.org/html/2606.26852#S2.SS3.p2.1)\.
- A\. Mages, C\. Mieth, J\. Hetzler, F\. Kallat, J\. Rehof, C\. Riest, and T\. Schäfer \(2022\)Automatic component\-based synthesis of user\-configured manufacturing simulation models\.In2022 Winter Simulation Conference \(WSC\),pp\. 1841–1852\.External Links:[Document](https://dx.doi.org/10.1109/WSC57314.2022.10015425)Cited by:[§2\.3](https://arxiv.org/html/2606.26852#S2.SS3.SSS0.Px1.p1.1),[§2\.3](https://arxiv.org/html/2606.26852#S2.SS3.p2.1)\.
- A\. Meyer, H\. Kutabi, J\. Bessai, and D\. Scholtyssek \(2024\)CLS\-Luigi: analytics pipeline synthesis\.InLearning and Intelligent Optimization,pp\. 269–284\.External Links:[Document](https://dx.doi.org/10.1007/978-3-031-75623-8%5F21)Cited by:[§1](https://arxiv.org/html/2606.26852#S1.p7.1),[§2\.3](https://arxiv.org/html/2606.26852#S2.SS3.SSS0.Px1.p1.1),[§2\.3](https://arxiv.org/html/2606.26852#S2.SS3.p3.1)\.
- M\. Mitchell, S\. Wu, A\. Zaldivar, P\. Barnes, L\. Vasserman, B\. Hutchinson, E\. Spitzer, I\. D\. Raji, and T\. Gebru \(2019\)Model Cards for Model Reporting\.InProceedings of the Conference on Fairness, Accountability, and Transparency,pp\. 220–229\.External Links:[Document](https://dx.doi.org/10.1145/3287560.3287596)Cited by:[§2\.2](https://arxiv.org/html/2606.26852#S2.SS2.SSS0.Px3.p1.1)\.
- D\. Müller, M\. G\. Müller, D\. Kress, and E\. Pesch \(2022\)An algorithm selection approach for the flexible job shop scheduling problem: Choosing constraint programming solvers through machine learning\.European Journal of Operational Research302\(3\),pp\. 874–891\.External Links:[Document](https://dx.doi.org/10.1016/j.ejor.2022.01.034)Cited by:[§2\.1](https://arxiv.org/html/2606.26852#S2.SS1.p1.1)\.
- I\. Muter and T\. Öncan \(2015\)An exact solution approach for the order batching problem\.IIE Transactions47\(7\),pp\. 728–738\.External Links:[Document](https://dx.doi.org/10.1080/0740817X.2014.991478)Cited by:[§2\.2](https://arxiv.org/html/2606.26852#S2.SS2.SSS0.Px1.p1.1),[Table 7](https://arxiv.org/html/2606.26852#S5.T7.9.9.15.2)\.
- E\. Negri, S\. Perotti, L\. Fumagalli, G\. Marchet, and M\. Garetti \(2017\)Modelling internal logistics systems through ontologies\.Computers in Industry88,pp\. 19–34\.External Links:[Document](https://dx.doi.org/10.1016/j.compind.2017.03.004)Cited by:[§1](https://arxiv.org/html/2606.26852#S1.p7.1),[§2\.2](https://arxiv.org/html/2606.26852#S2.SS2.SSS0.Px2.p1.1),[§2\.2](https://arxiv.org/html/2606.26852#S2.SS2.SSS0.Px4.p1.1)\.
- J\. Oxenstierna, J\. Malec, and V\. Krueger \(2021\)Layout\-agnostic order\-batching optimization\.InInternational Conference on Computational Logistics,pp\. 115–129\.External Links:[Document](https://dx.doi.org/10.1007/978-3-030-87672-2%5F8)Cited by:[§2\.2](https://arxiv.org/html/2606.26852#S2.SS2.SSS0.Px1.p1.1)\.
- E\. G\. Pardo, S\. Gil\-Borrás, A\. Alonso\-Ayuso, and A\. Duarte \(2024\)Order batching problems: taxonomy and literature review\.European Journal of Operational Research313\(1\),pp\. 1–24\.External Links:[Document](https://dx.doi.org/10.1016/j.ejor.2023.02.019)Cited by:[§1](https://arxiv.org/html/2606.26852#S1.p4.1),[§1](https://arxiv.org/html/2606.26852#S1.p5.1),[§4\.4](https://arxiv.org/html/2606.26852#S4.SS4.p1.2)\.
- C\. G\. Petersen and R\. W\. Schmenner \(1999\)An evaluation of routing and volume\-based storage policies in an order picking operation\.Decision Sciences30\(2\),pp\. 481–501\.Cited by:[§1](https://arxiv.org/html/2606.26852#S1.p5.1),[§2\.1](https://arxiv.org/html/2606.26852#S2.SS1.p1.1)\.
- C\. G\. Petersen \(1997\)An evaluation of order picking routeing policies\.International Journal of Operations & Production Management17\(11\),pp\. 1098–1111\.External Links:[Document](https://dx.doi.org/10.1108/01443579710177860)Cited by:[§3\.4\.3](https://arxiv.org/html/2606.26852#S3.SS4.SSS3.p1.1)\.
- A\. R\. F\. Pinto, M\. S\. Nagano, and E\. Boz \(2023\)A classification approach to order picking systems and policies: Integrating automation and optimization for future research\.Results in Control and Optimization12,pp\. 100281\.External Links:[Document](https://dx.doi.org/10.1016/j.rico.2023.100281)Cited by:[§3\.4\.2](https://arxiv.org/html/2606.26852#S3.SS4.SSS2.p1.1)\.
- K\. Pohl, G\. Böckle, and F\. J\. van der Linden \(2005\)Software product line engineering: foundations, principles and techniques\.Springer,Berlin, Heidelberg\.Cited by:[§2\.3](https://arxiv.org/html/2606.26852#S2.SS3.p1.1)\.
- M\. Pushkarna, A\. Zaldivar, and O\. Kjartansson \(2022\)Data cards: purposeful and transparent dataset documentation for responsible AI\.InProceedings of the 2022 ACM Conference on Fairness, Accountability, and Transparency,pp\. 1776–1826\.Cited by:[§2\.2](https://arxiv.org/html/2606.26852#S2.SS2.SSS0.Px3.p1.1)\.
- H\. D\. Ratliff and A\. S\. Rosenthal \(1983\)Order\-Picking in a Rectangular Warehouse: A Solvable Case of the Traveling Salesman Problem\.Operations Research31\(3\),pp\. 507–521\.External Links:[Document](https://dx.doi.org/10.1287/opre.31.3.507)Cited by:[§3\.4\.3](https://arxiv.org/html/2606.26852#S3.SS4.SSS3.p1.1),[§4\.3](https://arxiv.org/html/2606.26852#S4.SS3.p2.1)\.
- Spotify \(2025\)Luigi documentation\.Note:Accessed: 2025\-09\-11External Links:[Link](https://luigi.readthedocs.io/en/stable/)Cited by:[§2\.3](https://arxiv.org/html/2606.26852#S2.SS3.p3.1)\.
- C\. A\. Valle, J\. E\. Beasley, and A\. S\. da Cunha \(2017\)Optimally solving the joint order batching and picker routing problem\.European Journal of Operational Research262\(3\),pp\. 817–834\.External Links:[Document](https://dx.doi.org/10.1016/j.ejor.2017.03.069)Cited by:[§3\.4\.3](https://arxiv.org/html/2606.26852#S3.SS4.SSS3.p2.1),[§4\.2](https://arxiv.org/html/2606.26852#S4.SS2.p2.1),[§5\.1](https://arxiv.org/html/2606.26852#S5.SS1.SSS0.Px1.p3.6),[§5\.1](https://arxiv.org/html/2606.26852#S5.SS1.SSS0.Px1.p4.1)\.
- T\. van Gils, A\. Caris, K\. Ramaekers, and K\. Braekers \(2019\)Formulating and solving the integrated batching, routing, and picker scheduling problem in a real\-life spare parts warehouse\.European Journal of Operational Research277\(3\),pp\. 814–830\.External Links:[Document](https://dx.doi.org/10.1016/j.ejor.2019.03.012)Cited by:[§1](https://arxiv.org/html/2606.26852#S1.p4.1),[§1](https://arxiv.org/html/2606.26852#S1.p5.1),[§2\.1](https://arxiv.org/html/2606.26852#S2.SS1.p1.1),[§2\.1](https://arxiv.org/html/2606.26852#S2.SS1.p2.1),[§3\.1](https://arxiv.org/html/2606.26852#S3.SS1.SSS0.Px3.p1.12),[Table 7](https://arxiv.org/html/2606.26852#S5.T7.9.9.16.2)\.
- F\. Weidinger, N\. Boysen, and M\. Schneider \(2019\)Picker routing in the mixed\-shelves warehouses of e\-commerce retailers\.European Journal of Operational Research274\(2\),pp\. 501–515\.External Links:[Document](https://dx.doi.org/10.1016/j.ejor.2018.10.021)Cited by:[§3\.4\.1](https://arxiv.org/html/2606.26852#S3.SS4.SSS1.p1.1),[Table 2](https://arxiv.org/html/2606.26852#S3.T2.4.3.3.1.1)\.
- F\. Weidinger \(2018\)Picker routing in rectangular mixed shelves warehouses\.Computers & Operations Research95,pp\. 139–150\.External Links:[Document](https://dx.doi.org/10.1016/j.cor.2018.03.012)Cited by:[§3\.4\.1](https://arxiv.org/html/2606.26852#S3.SS4.SSS1.p1.1),[Table 2](https://arxiv.org/html/2606.26852#S3.T2.4.4.3.1.1)\.
- C\. Wildt, F\. Weidinger, and N\. Boysen \(2025\)Picker routing in scattered storage warehouses: an evaluation of solution methods based on TSP transformations\.OR Spectrum47\(1\),pp\. 35–66\.External Links:[Document](https://dx.doi.org/10.1007/s00291-024-00780-0)Cited by:[§2\.1](https://arxiv.org/html/2606.26852#S2.SS1.p4.1)\.
- J\. Winkels, F\. Özkul, R\. Sutherland, J\. Löhn, S\. Wenzel, and J\. Rehof \(2024\)Component\-based synthesis of structural variants of simulation models for changeable material flow systems\.In2024 Winter Simulation Conference \(WSC\),pp\. 1657–1668\.External Links:[Document](https://dx.doi.org/10.1109/WSC63780.2024.10838927)Cited by:[§2\.3](https://arxiv.org/html/2606.26852#S2.SS3.SSS0.Px1.p1.1),[§2\.3](https://arxiv.org/html/2606.26852#S2.SS3.p2.1)\.
- L\. Xu, F\. Hutter, H\. H\. Hoos, and K\. Leyton\-Brown \(2008\)SATzilla: portfolio\-based algorithm selection for SAT\.Journal of Artificial Intelligence Research32,pp\. 565–606\.Cited by:[§1](https://arxiv.org/html/2606.26852#S1.p7.1),[§2\.1](https://arxiv.org/html/2606.26852#S2.SS1.p1.1)\.
- Z\. Yang, W\. Zeng, S\. Jin, C\. Qian, P\. Luo, and W\. Liu \(2025\)AutoMMLab: automatically generating deployable models from language instructions for computer vision tasks\.InProceedings of the AAAI Conference on Artificial Intelligence,pp\. 22056–22064\.External Links:[Document](https://dx.doi.org/10.1609/aaai.v39i21.34358)Cited by:[§2\.2](https://arxiv.org/html/2606.26852#S2.SS2.SSS0.Px3.p1.1)\.
- I\. Žulj, S\. Kramer, and M\. Schneider \(2018\)A hybrid of adaptive large neighborhood search and tabu search for the order\-batching problem\.European Journal of Operational Research264\(2\),pp\. 653–664\.External Links:[Document](https://dx.doi.org/10.1016/j.ejor.2017.06.056)Cited by:[§2\.2](https://arxiv.org/html/2606.26852#S2.SS2.SSS0.Px1.p1.1)\.