PaperlayerView exact revision on arXiv

Source-linked AI summary

ALAS: A Stateful Multi-LLM Agent Framework for Disruption-Aware Planning

Edward Y. Chang, Longling Geng

arXiv:2505.12501v1cs.AI

TL;DR

LLMs can produce inconsistent plans and struggle to adapt when disruptions require long-range coordination. ALAS uses specialized agents and persistent memory for structured planning and local compensation, with reported improvements over standalone LLMs and classical operations research solutions.

  • Problem

    Standalone LLMs often produce incomplete or invalid plans and struggle with long-range consistency, coordination, and adaptive behavior, especially when disruptions arise.

    Source: §1 · p. 1

  • Method

    ALAS decomposes planning across specialized agents and uses persistent memory to track state and support localized corrections after runtime disruptions.

    Source: §1 · pp. 1–2

  • Results

    Across static and dynamic job-shop benchmarks, ALAS reports improvements over baselines; on TA, its mean gap was 0.86%, versus DRL-Chen (25%), DRL-Zhang (18%), and SeEvo-GPT3.5 (15%).

    Source: §4.3.1 · p. 8, §5 · p. 9

  • Takeaways & Limitations

    The reported results support ALAS’s use for structured planning and disruption handling through modular agents, persistent state tracking, and localized compensation.

    Source: §1 · p. 2, §5 · p. 9

    Standalone LLMs lack persistent state and may fail to revalidate a previously valid plan after a disruption without rollback.

    Source: §2.1 · p. 3

Abstract

from arXiv · show

Large language models (LLMs) excel at rapid generation of text and multimodal content, yet they falter on transaction-style planning that demands ACID-like guarantees and real-time disruption recovery. We present Adaptive LLM Agent System (ALAS), a framework that tackles four fundamental LLM deficits: (i) absence of self-verification, (ii) context erosion, (iii) next-token myopia, and (iv) lack of persistent state. ALAS decomposes each plan into role-specialized agents, equips them with automatic state tracking, and coordinates them through a lightweight protocol. When disruptions arise, agents apply history-aware local compensation, avoiding costly global replanning and containing cascade effects. On real-world, large-scale job-shop scheduling benchmarks, ALAS sets new best results for static sequential planning and excels in dynamic reactive scenarios with unexpected disruptions. These gains show that principled modularization plus targeted compensation can unlock scalable and resilient planning with LLMs.

1 Introduction

ALAS addresses LLM planning weaknesses with specialized agents and persistent memory, aiming to support consistent planning and local recovery when disruptions occur.

1 Introduction

  • Dynamic disruptions can make global replanning costly and disruptive, while stateless LLMs may respond invalidly to changing plans.The introduction identifies last-minute cancellations, emergent constraints, and failures as examples.Source: §1 · p. 1
  • ALAS coordinates lightweight agents specialized for validation, domain exploration, context retention, monitoring, and persistent memory.Memory modules track state transitions and dependencies to support rollback and consistency.Source: §1 · pp. 1–2
  • Urban Ride Sharing illustrates the need to coordinate concurrent trips and adapt to disturbances through persistent state tracking and local rescheduling.The running example includes traffic delays and last-minute passenger requests.Source: §1 · p. 2
  • ALAS emphasizes localized corrections and persistent state to avoid costly global recomputation and support cross-domain adaptive planning.The paper also highlights transparent reasoning and audit trails for real-time decisions and post-mortem analysis.Source: §1 · p. 2

2 Related Work

Related work frames planning with LLMs as limited by verification, memory, context, and recovery gaps, motivating ALAS’s persistent state and localized compensation.

2.1 Structural Limitations of LLMs

  • LLMs lack self-validation, favor high-probability completions, degrade over long contexts, and can propagate reasoning errors without persistent state.These limitations are linked to constraint violations and difficulty recovering when disruptions invalidate a plan.Source: §2.1 · pp. 2–3
  • ALAS responds to these structural limitations with specialized agents, persistent memory, and runtime monitoring.The paper presents this architecture as a response to the state and consistency gaps.Source: §2.1 · p. 3

2.2 Multi-Agent Planning Systems

  • Prior LLM multi-agent systems are described as lacking persistent memory, formal validation, and disruption recovery; ALAS emphasizes state tracking and local error containment.The cited independent evaluation found no reliable improvement over single-agent systems across 150+ tasks [12].Source: §2.2 · p. 3

2.3 LLM-Based Planning and Benchmarks

  • LLM planning frameworks use decomposition, search, or orchestration, but LLMs are not competitive with classical combinatorial solvers on globally optimal static plans.Classical methods can falter in dynamic settings requiring real-time adjustment and context-aware reasoning.Source: §2.3 · p. 3
  • Existing benchmarks rarely include disruptions, revalidation, or compensation, while this study evaluates disruption-aware planning on large-scale Demirkol-DMU and TA benchmarks.The experiments also report that basic planning tasks expose LLM limitations in validation, memory persistence, and execution consistency.Source: §2.3 · pp. 3–4

3 The ALAS Three-Layer Architecture for Adaptive and Reactive Planning

ALAS converts planning specifications into executable workflows through blueprinting, agent construction, and runtime execution with persistent memory and reactive compensation.

3 The ALAS Three-Layer Architecture for Adaptive and Reactive Planning

  • ALAS uses a three-layer architecture—workflow blueprint, agent factory, and runtime monitor—with persistent memory to build verifiable execution workflows.The architecture targets planning and coordination under dynamic, stateful conditions.Source: §3 · p. 4

3.1 Workflow Blueprinting Layer: Template Construction

  • The blueprinting layer turns a planning input into a dependency graph of roles, assigns execution and compensation profiles, then validates and refines the workflow.An independent validator checks graph soundness, temporal consistency, and compensation coverage before the template is finalized.Source: §3.1 · pp. 4–5

3.2 Agent Factory Layer: Agent Sourcing and Compensation Logic

  • The agent factory instantiates executable role agents from capability, context, logging, and compensation specifications.A primary-agent signature records dependencies and protocol, capabilities, context, efficiency constraints, and trace logging; compensators add recovery protocol and exception history.Source: §3.2 · p. 5

3.3 Runtime Layer: Execution and Reactive Adaptation

  • At runtime, agents execute in dependency order, log state, and use LRCP for localized compensation or queue reordering, stopping when recovery is infeasible or too costly.Persistent memory records transitions, dependencies, logs, and compensation actions to support rollback and post-hoc diagnostics.Source: §3.3 · pp. 5–6

4 Experimental Evaluation

The evaluation spans transportation, event coordination, and job-shop scheduling, testing static planning and responses to disruptions. Across these settings, ALAS is assessed for feasibility, efficiency, scalability, and reactive schedule repair.

4.1 Case Study 1: Transportation Scheduling

  • 95.1 km (SD 13.04 km) versus 118.9 km (SD 16.6 km): Alas reduced average travel distance by 20% over baseline LLMs, and replanned successfully in all trials after a cancellation and new request.All models met deadlines in sequential planning; reactive baselines often lost vehicle locations, duplicated assignments, or ignored updated deadlines.Source: §4.1 · p. 7

4.2 Case Study 2: Event Coordination

  • Across ten reunion trials, Alas produced a feasible schedule every time, while standalone LLM baselines violated hard constraints and often needed retries.The reported baseline errors include travel-time miscalculations and common-sense violations; the paper attributes them primarily to context loss in long prompts.Source: §4.2 · p. 7
  • With James’s flight delayed, Alas succeeded in all ten reunion trials, while DeepSeek and Claude failed in 7/10; LRCP updates state, detects conflicts, and validates alternatives.Persistent state history supports targeted undo/redo of affected scheduled tasks.Source: §4.2 · p. 7

4.3.1 Experimental Results

  • 36%, 53%, and 21%: on Demirkol-DMU, Alas+LRCP on Claude-3.7 had the lowest mean gap to theoretical optimum, outperforming SPT, LPT, and DRL-Liu, respectively.Figure 3 compares mean gap to upper bound across the two benchmark datasets.Source: Figure 3 · p. 8, §4.3.1 · p. 8

4.3 Case Study 3: Job Shop Scheduling with Disruptions

  • The job-shop evaluation uses Demirkol-DMU and Taillard benchmarks and adds machine breakdowns requiring schedule adjustments that minimize makespan and work-in-progress movement.Demirkol-DMU instances range from 20×15 to 50×20 job-machine configurations; Taillard includes instances up to 100×20.Source: §4.3 · p. 8

4.3.1 Experimental Results

  • 0.86%: on seven real-world industrial TA instances, Alas+LRCP’s mean gap was below DRL-Chen (25%), DRL-Zhang (18%), and SeEvo-GPT3.5 (15%).Classical heuristic LSO had gaps of up to 34%.Source: §4.3.1 · p. 8
  • 19.8%: under 20 random DMU machine failures, LRCP maintained the lowest average gap among the compared SeEvo-GPT3.5/GLM3, GP, and DRL variants.The evaluation compares LRCP, ALAS’s reactive planner, with those baselines.Source: §4.3.1 · p. 8

4.3.2 LRCP Mechanism: A White Box Analysis

  • After breakdowns, LRCP propagates local delays across machines, then reorders queues to trade makespan gains against WIP penalties.In the illustrated example, the final makespan is 22 units with one unit of WIP movement.Source: §4.3.2 · p. 9, Figure 5 · p. 9

5 Conclusion

ALAS decomposes planning into memory-augmented agents coordinated through modular templates, using localized compensation and persistent state tracking to respond to runtime disturbances. The authors report gains in constraint satisfaction and disruption handling, while identifying deployment and modeling limits.

5 Conclusion

  • ALAS combines memory-augmented agents and modular templates with LRCP for localized compensation and disruption response.The framework is designed to adapt to runtime disturbances with minimal messaging overhead.Source: §5 · p. 9
  • The authors report empirical improvements over standalone LLMs and classical operations research solutions in constraint satisfaction and disruption handling.Source: §5 · p. 9
  • Real-world job-shop deployment remains unvalidated; the agent factory assumes reliable prompt-based code generation, and current statistical models use static operation times and tWIP.The authors note complex or high-risk domains may require human oversight and real-world deployments may need dynamic adjustment.Source: §5 · p. 9

Appendices

The appendices list supplementary architecture, algorithm proofs, and extended experimental materials. The meta-planner workflow constructs, specifies, validates, and refines a workflow template.

Appendices

  • The appendices cover ALAS architecture, LCSR proofs, extended urban ride and family reunion results, and additional case studies.Supplementary benchmark datasets, code, and extended analyses are slated for upload to the Open Review submission site.Source: Appendices · p. 15

A Supplemental Information for Section 3

  • ALAS has three architectural layers; its appendix describes the first layer’s three phases, ending with instantiated agents running as real-time processes.Agent specifications are prepared for implementation in phase two, and phase three instantiates those agents.Source: A Supplemental Information for Section 3 · p. 15

A.1 Complete Meta-Planner Algorithm for Workflow Generation

  • The meta-planner extracts roles, maps them to nodes and dependencies, specifies agents, and validates and refines the workflow template.The algorithm organizes these steps as network construction, agent specification, and validation and refinement.Source: §A.1 · p. 15

A.2 ALAS Architecture

ALAS uses layered architecture and persistent memory to support state tracking, constraint validation, and recovery. Its Agent Factory discovers or generates implementations, including compensation agents, and its efficiency strategies reduce generation overhead.

A.2 ALAS Architecture

  • Persistent memory supports all ALAS layers by storing state, validating constraints, and enabling recovery.The meta-planner algorithm specifies agent and compensation-agent components before workflow validation and refinement.Source: Figure 6 · p. 15, §A.2 · p. 15

A.4.2 Agent Discovery Process

  • The Agent Factory searches for implementations matching agent specifications, evaluates capability, protocol, efficiency, context, and logging fit, then verifies suitable matches.It uses exact matching or approximate capability matching with adaptation mechanisms.Source: §A.4.2 · pp. 16–17, §A.4.1 · p. 16

A.4.3 Agent Coding Mechanism

  • When discovery fails, the Factory uses an LLM to generate and validate custom implementations, with iterative refinement available for complex agents.Generated code incorporates logging, protocol handling, efficiency and context constraints, and compensation integration.Source: §A.4.3 · p. 17

A.4.4 Compensation Agent Generation

  • Compensation-agent generation analyzes primary-agent state changes and dependencies, selects recovery strategies, and defines a sequence for restoring consistency.The Factory pairs each state-modifying operation with a reversal mechanism.Source: §A.4.4 · p. 17

A.4.5 Deployment Artifact Production

  • Factory outputs are deployable artifacts, including code, prompt templates, API configurations, and hybrid implementations, with metadata for execution, persistence, monitoring, and recovery.The Factory translates formal agent specifications into executable implementations through discovery or custom generation.Source: §A.4.5 · p. 18

A.4.6 Factory Design Pattern Implementation

  • The Factory pattern decouples agent specifications from implementations, supports heterogeneous technologies and runtime substitution, and lets ALAS evolve without changing meta-planning or runtime components.It also supports a growing repository of reusable components.Source: §A.4.6 · p. 18

A.4.7 Implementation Efficiency Considerations

  • Agent-generation optimizations significantly reduce computational overhead, especially for recurring workflows and scenarios requiring multiple similar agents.The Factory uses caching, component reuse, incremental refinement, and resource scaling.Source: §A.4.7 · p. 18

A.4.8 Theoretical Foundations

  • The Factory draws on program synthesis, component-based software engineering, LLM prompt engineering, and agent-oriented software engineering to turn specifications into executable implementations.These frameworks are presented as the theoretical basis for the approach.Source: §A.4.8 · pp. 18–19

B LCSR Specifications and Lemma Proofs

LCSR updates execution state after disruptions, propagates delays, optimizes local queues, and handles cascading delays. The appendix also describes the urban ride assignment problem and its workflow-template walkthrough.

B LCSR Specifications and Lemma Proofs

  • LCSR updates the execution tracker and machine queues after a disruption, then applies cascading repair and queue reordering.Its input includes the tracker, queues, disruption time, and a machine outage duration.Source: B LCSR Specifications and Lemma Proofs · p. 19
  • LCSR marks operations completed, in progress, or waiting; in-progress operations are rescheduled to the disruption end before delays are propagated downstream.The tracker and affected queue are updated, and the next machine receives a delay notification.Source: B LCSR Specifications and Lemma Proofs · p. 19
  • Local queue optimization swaps an earlier operation with a later terminal operation only when the swap improves makespan, while cascading notifications delay dependent operations.Non-terminal operations are skipped as less flexible; the algorithm returns updated tracker and queues.Source: B LCSR Specifications and Lemma Proofs · p. 19
  • The stated complexity is quadratic in job count; machine count appears in both delay propagation and parallelization, and swap heuristics can improve practical bounds.The generalized lemma assumes at most Omax operations per job.Source: B LCSR Specifications and Lemma Proofs · pp. 19–20

C Urban Ride Assignment Problem

  • Urban ride assignment aims to assign ride requests to vehicles while satisfying constraints and objectives, using locations, roads, travel times, time windows, and vehicle attributes.The described vehicle attributes include current location, battery or fuel level, and passenger capacity.Source: C Urban Ride Assignment Problem · p. 20

C.1 A Simplified URS Problem Statement

  • The simplified walkthrough uses a ride-assignment instance with three drivers and four passengers to show how ALAS works.The appendix identifies the instance in Table 1 of the main text.Source: §C.1 · p. 20

C.2 Generating Planner W* Walkthrough

  • Given the urban ride assignment problem statement, ALAS generates a planning template Wtemplate.The accompanying table is titled “Agent Specifications and Protocols.”Source: §C.2 · p. 21, Table 3 · p. 21

C.2.1 State-Space Analysis

This section analyzes ALAS planning scenarios and workflows by specifying roles, dependencies, resources, timing, constraints, and scheduling requirements. It describes how specialized agents construct, validate, monitor, and coordinate executable plans, including workflows for adapting to changing conditions and disruptions.

C.2.1 State-Space Analysis

  • The URS state space tracks four airport-bound passengers, three two-seat vehicles, seven locations, travel-time constraints, and objectives of on-time arrivals and minimizing distance.Urban segments are 10 km at 60 km/h, while airport routes are 31–36 km at 100 km/h; the framework also specifies vehicle capacity and execution protocols.Source: §C.2.1 · p. 21

C.2.2 Phase 1: Network Construction

  • The URS network represents passenger, vehicle, and location nodes, links them through temporal, spatial, and capacity dependencies, and assigns specialized agents to routing, scheduling, capacity, and shared constraints.Pickup windows are derived backward from airport deadlines; agents also manage temporal constraints, resource allocation, distance optimization, and passenger grouping.Source: §C.2.2 · p. 22, §C.2.3 · p. 22

C.2.4 Phase 3: Validation and Refinement

  • Validation checks deadline feasibility, vehicle capacity, passenger service, and resource allocation, then refines compatible shared rides and vehicle assignments while preserving service guarantees.The final plan specifies pickup times, assignments, routes, delay buffers, and contingency protocols; the output also lists required agents and their placement in the network.Source: §C.2.4 · p. 22, §C.2.5 · p. 23, Table 4 · p. 23

C.3 From Workflow Template to Execution Workflow

  • ALAS transforms Wtemplate, which defines abstract roles and interactions, into Wexec by resolving roles to real-world instances and adapting tasks to real-time constraints.Wexec is a directed graph of concrete actions and dependencies that incorporates real-time data and updates as conditions evolve.Source: §C.3 · p. 23

C.3.1 Observation on Sequential Planning

  • The agent architecture is presented as supporting independent responses to changing conditions, parallel specialized decisions, modular upgrades, and fallback-based resilience.Examples include route adjustments for traffic, parallel scheduling and vehicle allocation, adding new agents without changing core routing, and refinement when an agent fails.Source: §C.3.1 · p. 24

C.4 Reactive Planning under Disruptions

  • For a road closure, ALAS enables route, schedule, and vehicle-allocation agents to adapt concurrently; in a case study, it handles a cancellation and new request while preserving deadlines, unlike baseline LLMs that lose state consistency.The case introduces r2’s cancellation at 8:05 and a new request r5 at location F at 8:10.Source: §C.4 · p. 24

D. Family Reunion Planning Problem

  • The family-reunion workflow specifies qualified cooking, driving, and supervision roles alongside timing, location, and safety dependencies, then assigns role and dependency monitors.The constraints include completing the turkey and side dishes by 6:00 PM, aligning airport pickups with landings, matching drivers to passengers, and maintaining oven supervision; monitors track cooking, drivers, resources, timing, locations, and safety.Source: §D.1.1 · pp. 24–25, Table 5 · p. 25, §D.1.2 · p. 25

D.2.4 Common Sense Constraint Analysis and Verification (Human in the Loop)

  • The family-planning workflow separates constraints needing agent-collected data from social or personal factors requiring human input, and uses standardized agent protocols and monitoring thresholds to support dynamic adjustments.Agent-required checks include airport operations, weather and traffic, and task dependencies; human verification covers family dynamics and personal capabilities, while temporal monitoring classifies deviations as normal, warning, or violation.Source: §D.2.4 · pp. 27–28, §D.3 · p. 28, §D.4 · p. 28

D.4 Monitoring Protocols and Dynamic Adjustments

  • When disruptions arise, the meta-planner coordinates specialist agents’ responses while maintaining global constraint satisfaction.For a delayed flight, the spatial agent detects the arrival-time change, the temporal agent calculates ripple effects, role agents consider reassignment, and the safety agent checks supervision coverage.Source: §D.4 · p. 28

D.5 Integrated Workflow Network

  • The workflow network assigns cooking, driving, and supervision roles, with temporal, spatial, and safety dependencies monitored by corresponding agents.Assignments include Sarah or Grandma cooking, James or Michael driving, and a supervisor present while the turkey cooks; monitoring covers verified buffer times, routes, and supervision-role coverage.Source: §D.5 · pp. 28–29

D.6 Agent Interaction Specifications

  • Table 8 presents agent interaction protocols and state transitions.Source: Table 8 · p. 29

D.7 Augmented Problem Statement Revised with W*

  • The revised problem specifies a 6:00 PM Boston dinner, family arrival and pickup assumptions, cooking preferences, and a strict schedule completion deadline.Tasks and dependencies must be observed, individual idle time accounted for, and the schedule must list time, task, and assigned people; traffic congestion is not factored into current planning.Source: §D.7 · p. 29

D.8 Experiment #1: Sequential Planner with Common Sense

In the Family Reunion test, ALAS and Gemini consistently produced feasible schedules, while other standalone LLMs had difficulty. ALAS was feasible in every run and the standalone models’ plans differed in iteration count and scheduling quality.

D.8 Experiment #1: Sequential Planner with Common Sense

  • Both ALAS and Gemini consistently generated feasible schedules, while the other standalone LLMs encountered significant challenges.The experiment used an augmented specification that included constraints such as luggage-claim and rental-car pickup time.Source: §D.8 · p. 30
  • DeepSeek outperformed GPT-4o and Claude on slack time, total driving distance, and load balance, despite needing two iterations to converge.Claude also needed two iterations, while GPT-4o needed three; the schedules are shown in Tables 9–11.Source: §D.8 · p. 30, Table 10 · p. 30, Table 11 · p. 30

D.8.1 Observations of Errors in Standalone LLMs

Standalone LLM plans contained incorrect travel-time estimates and implausible decisions, including in their initial attempts. The discussion connects these errors to context loss and constraint-tracking challenges, contrasting them with ALAS’s consistently feasible and efficient schedules.

D.8.1 Observations of Errors in Standalone LLMs

  • DeepSeek and Claude eventually produced feasible plans in their second iterations, but their initial attempts contained critical errors.The initial errors are documented in Tables 12 and 13.Source: §D.8.1 · p. 30, Table 12 · p. 31, Table 13 · p. 31
  • Standalone plans misestimated 60-minute trips as 45 or 30 minutes and included implausible decisions, such as starting turkey preparation at 10 AM.Another example was James departing the airport without Emily.Source: §D.8.1 · p. 31
  • Context erosion and information loss are linked to constraint violations, while ALAS uses domain-specialized agents and independent validation.The discussion also identifies cascading errors and difficulty tracking overlapping dependencies as challenges for single-pass reasoning.Source: §D.8.1 · p. 31
  • The proposed response to overlapping dependencies is to enumerate atomic dependencies and verify global constraints; iterative revisions also need clean-state resets.The discussion identifies incomplete constraint resets as a risk for propagating errors across iterations.Source: §D.8.1 · p. 31
  • ALAS consistently generated feasible and efficient plans in all test runs, unlike the inconsistent standalone LLM schedules.The schedules are synthesized in Table 14.Source: Table 14 · p. 31, §D.8.1 · p. 32

D.9 Experiment #2: Reactive Planner for Flight Delay

In the flight-delay test, ALAS produced feasible reactive plans while DeepSeek and Claude failed, with ALAS using state-aware local compensation. The appendix also describes its validation and replanning workflow for job-shop scheduling, from initial templates to converged makespan examples.

D.9 Experiment #2: Reactive Planner for Flight Delay

  • ALAS generated a feasible reactive plan, whereas DeepSeek and Claude 3.7 failed; the latter models failed in seven of ten runs through constraint violations or missed pickups and deadlines.The disruption delayed James’s flight until 4:00 PM; the failed schedule is shown in Table 15.Source: §D.9 · p. 32, Table 15 · p. 32

P OST 6:00 PM

  • With James delayed and Michael occupied with Emily’s pickup, Grandma could not be picked up and returned by the 6:00 PM dinner deadline.ALAS generated feasible plans in all runs by updating persistent state, detecting conflicts, evaluating alternatives, and validating constraints; this took 12.1s versus 4.8s, or 2.5× the computation time.Source: P OST 6:00 PM · p. 32

D.10 ALAS’s Reactive Plan and Stateful Explanation

  • ALAS’s reactive plan reroutes Michael directly to the airport, then to Grandma’s home, trimming roughly 30 minutes of travel.The passage attributes the adjustment to state-aware reasoning and continuous tracking of participant state and history; the schedule appears in Table 16.Source: §D.10 · p. 33, Table 16 · p. 33

E Additional JSSP Results and Analysis

  • The additional JSSP appendix section supplies full prompt specifications, failure-rate statistics, and pointers to supplementary visualizations.The passage frames these as additions to the core experimental findings.Source: E Additional JSSP Results and Analysis · p. 33

E.1 LLM Prompt Design

  • Standalone LLMs may produce a workflow template, but ALAS validates and refines it before instantiating and running agents with runtime local repair.The appendix distinguishes template generation from the executable, disruption-aware workflow.Source: §E.1 · p. 33

E.2 LLM Heuristic Baselines (sampled)

  • For each JSSP benchmark, standalone LLMs were asked to select an optimization method and report expected makespan; this yields only an initial static template, not an executable disruption-aware plan.The sampled prompts and heuristics are described in Table 17 and Table 18.Source: §E.2 · p. 33, Table 17 · p. 34, Table 18 · p. 34

E.3 ALAS’s Validation Replan Iterations

  • ALAS’s validation-replan cycle typically converged within up to five iterations across all benchmark datasets.The iteration pattern is depicted in Figure 8.Source: §E.3 · p. 33

E.4 Examples of Makespan at Convergence

  • After plan generation, validation, and local replanning, the paper presents four representative Gantt charts of JSSP instances with different sizes and complexity.The charts show makespan results at convergence in Figure 9.Source: §E.4 · p. 34

E.5 Additional Experimental Results and Analysis

ALAS and ALAS+LRCP outperform competing methods in virtually all DMU and TA benchmark instances. LRCP improves schedules through viable local job exchanges, while the figures also show convergence gaps and representative schedules.

E.5 Additional Experimental Results and Analysis

  • Across virtually all DMU and TA JSSP instances, ALAS and ALAS+LRCP outperform competing methods; LRCP guarantees makespan improvements when viable local exchanges exist.Figure 10 presents the benchmark comparisons.Source: §E.5 · p. 34, Figure 10 · p. 36
  • Convergence gaps are 19.09% on DMU, 0.86% on TA, and 0% on ABZ, SWZ, and YN.Figure 8 reports the gap percentages across five benchmark datasets.Source: Figure 8 · p. 35
  • Gantt charts show ALAS schedules across representative JSSP instances with varying job and machine counts; the larger TA72 instance is in the supplementary materials.TA72 has 100 jobs and 20 machines.Source: Figure 9 · p. 35
Loading 2505.12501v1…