Thank you for the valuable comments and the recognition of our contributions. Below we address specific questions.

1. Design Choice of AEOS-Former

We appreciate your suggestion to better articulate the motivations behind our design choices. At its core, the AEOS scheduling problem asks: "Which satellite should service which task, subject to constraints?" We frame this as a matching problem under constraints, where satellites and tasks are two sets of “tokens” whose pairwise affinities must respect feasibility.

This formulation naturally leads to the choice of Transformer, which can ingest variable-sized inputs and excel at reasoning through the attention mechanism. That said, a vanilla Transformer is essentially a black box. Learning to perform task assignments while conforming to all constraints would require massive datasets and prohibitively large compute budgets.

To avoid this, we introduce an internal constraint module that explicitly predicts the feasibility of every satellite–task pair. This separation lets the Transformer focus on high-level reasoning, while the lightweight constraint checker guarantees that only physically possible assignments are considered.

Alternative design choices were also considered. A simple MLP would fail to handle dynamic input sizes without padding or truncating the inputs. Graph neural networks (GNN) over a bipartite satellite-task graph could capture pairwise interactions, but the message-passing schemes would complicate both model design and training, and still leave constraint learning implicit.

By contrast, our matching-based Transformer, augmented with an internal constraint module, strikes the right balance. It naturally accommodates any number of satellites and tasks, leverages powerful attention-driven reasoning, and enforces real-world operational constraints without inflating the training cost. We will include a concise discussion of these design alternatives and our rationale in the revised manuscript.

2. Detailed Comparison with Baselines

Among all baseline methods, MSCPO-SHCS performs closest to our approach. On the val-unseen split, it outperforms AEOS-Former on $15$ out of $64$ scenarios. To better understand this, we conducted a statistical analysis comparing the scenarios where each method performs best.

The key differentiating factor appears to be task volume. In scenarios where MSCPO-SHCS outperforms AEOS-Former, the average number of tasks is $168.8$. In contrast, for the remaining scenarios where AEOS-Former performs better, the average number of tasks is $191.3$. This suggests that MSCPO-SHCS is more competitive in smaller-scale settings, likely due to its local search nature being more effective when the solution space is limited. On the other hand, AEOS-Former scales more robustly to high-task-density scenarios, where optimization-based methods tend to struggle with increasing combinatorial complexity.

We will include this analysis in the revised manuscript to provide a clearer understanding of which instances favor which method.

3. Limitations

Due to page limits of the manuscript, we included the limitations section in Sec. 1 of the supplementary materials. In the final manuscript, we will move the limitations section back to the main text.

4. Clarification on the Problem Setting

We appreciate your meticulous review of our manuscript. All of the dynamics mentioned in the introduction (including tasks, satellites, and batteries) are governed by the simulator, instead of the scheduling algorithm. However, not all of these factors are equally uncertain. Some properties, such as satellite positions and battery levels, evolve according to physical laws and are therefore predictable given the current state. In contrast, the emergence of new tasks represents true external uncertainty. For example, a task may request observation of a region affected by a sudden natural disaster, something that cannot be predicted in advance. The scheduling algorithm has no prior knowledge of when or where such tasks will be released. A central goal of AEOS-Former is to handle this mix of predictable dynamics and unpredictable events in a unified framework. Traditional methods often require re-optimization when the environment changes, which introduces latency. AEOS-Former, by contrast, adapts to all changes without retraining.

5. The Data Generation Process

All tasks in AEOS-Bench are randomly sampled from predefined ranges, as detailed in Tab. 2 of the supplemental material. Each scenario comprises a randomly sampled constellation and task set. Scheduling annotations are then generated using the pipeline described in Fig. 3 of the manuscript: an iterative algorithm proposes candidate schedules, and human reviewers verify their correctness. Only annotations that pass the verification are included in AEOS-Bench.

There are two key stages in our data generation process that involve human oversight. First, during satellite asset generation (illustrated in Fig. 2 of the manuscript), human reviewers filter out satellites with unstable or inefficient attitude control. Only satellites with smooth and reliable pointing behavior are retained as valid assets. Second, during the data annotation phase (as shown in Fig. 3 of the manuscript), human reviewers check for irrational scheduling behavior, such as observations of the same task by multiple satellites.

This pipeline allows us to curate a high-quality dataset of realistic task assignments, while minimizing the burden on human annotators by delegating most of the heavy lifting to automated methods.

6. Paper Formatting Concerns

We appreciate your careful reading and constructive feedback. We will correct the label in Fig. 5 to “Constraint Model.” As for the spacing problem of separators, we have reviewed all mathematical expressions and will address any inconsistent spacing between symbols and numbers during final typesetting. Finally, “w.r.t.” is an abbreviation for “with respect to”, which is widely used in mathematical contexts. We will spell it out to improve readability.

Thank you for your detailed review and insightful questions about our work. Below we address specific questions.

1. Concept Clarification

We apologize for the ambiguity around these terms and appreciate the opportunity to clarify. In our work, a scenario refers to a scheduling problem instance at timestep $0$, which comprises the constellation state (positions, attitudes, remaining resources) and a set of tasks (target coordinates, time windows). During inference, the AEOS-Bench simulator first loads the scenario to initialize the constellation, then steps through time. At each subsequent timestep, the simulator applies the high‑level scheduling commands from AEOS‑Former, updates the constellation state via the MRP controller, and records task progress until the scenario concludes.

An asset denotes a satellite eligible for inclusion in AEOS-Bench. As shown in Fig. 2 of the manuscript, we generate a large pool of assets by sampling satellite properties, computing corresponding MRP parameters via an empirical formula, and then filtering through a completion rate check and a human quality check. The surviving satellites become part of the asset pool. When constructing scenarios for AEOS-Bench, constellations are formed by random sampling from the asset pool.

We will incorporate these definitions of "scenario" and "asset" into the revised manuscript to eliminate any remaining confusion.

2. Power Consumption

We presume the "energy" is referring to the onboard power consumption of satellites during task execution. As shown in Tab. 2 of the manuscript, AEOS-Former achieves a significant reduction in power usage compared to baseline methods. For example, on the val-unseen split of AEOS-Bench, our method reduces power consumption from 140.83 Wh (MSCPO-SHCS) to 68.99 Wh, representing an approximate 50% reduction.

Although satellites are typically equipped with solar panels for recharging, minimizing power consumption has clear benefits: it enables more flexible maneuver and reduces wear on high-power components—ultimately helping to extend satellite lifespan without requiring additional hardware robustness.

3. Ablation Study on Loss Weights

The loss weights $(w_s, w_t, w_a)$ in Eq. (9) are designed to balance the contributions of feasibility loss, timing loss, and task assignment loss. We selected $ws=wt=wa=1$ based on preliminary experiments, where an ablation study (summarized in the table) showed that AEOS-Former is robust to the loss weights and setting $w_s = w_t = w_a = 1$ achieves better performance, which is shown below:

We did not perform an extensive hyperparameter sweep over the three loss weights. Thus, in future work, we plan to conduct more systematic hyperparameter searches to determine whether alternative weight combinations can yield further improvements.

4. Rationale of the CS Definition

We define CS as a comprehensive metric that balances completion rate metrics (CR, PCR, WCR) with efficiency metrics (TAT, PC). To do so, we first aggregate the three completion rate metrics into a single completion ratio, and then combine this with normalized versions of TAT and PC.

Specifically, we compute the completion ratio as a weighted average of CR, PCR, and WCR. The weights ($w_\text{CR} = 0.6, w_\text{PCR} = 0.2, w_\text{WCR} = 0.2$) reflect our prioritization of CR over PCR and WCR. This aggregated ratio naturally lies in $[0, 1]$, where higher is better. In contrast, TAT and PC are unbounded positive quantities that we wish to minimize. To align all components, we take the reciprocal of the completion ratio, mapping it to $[1, \infty)$.

Then we normalize TAT and PC with their respective normalization weights. To choose the values for $w_\text{TAT}$ and $w_\text{PC}$, we examined the typical ranges of these metrics. We observed that TAT hovers around $7$ hours and PC around $100$ Wh. Setting $w_\text{TAT} = 1/7$ and $w_\text{PC} = 1/100$ therefore brings these terms into the same order of magnitude (around $1$), so that no single metric overwhelms the overall score. Random, HAAL, and REDA were omitted from this calibration because their completion rate metrics were anomalously low and would skew the normalization.

This formulation ensures that CS accounts fairly for both coverage performance and resource efficiency, with no undue bias toward any single metric.

5. Performance of Prior Works

Thank you for pointing out the need for concrete evidence behind these two claims.

First, regarding "While effective on simplified benchmarks, their performance degrades sharply in realistic scenarios," Tab. 2 of our manuscript shows that REDA achieves 21.54 CS on the val‑unseen split, whereas AEOS‑Former achieves 4.43 CS. On the original REDA benchmark (which ignores attitude control, sensor FOV, etc.), REDA and AEOS‑Former score $11,094$ and $17,325$ in total return, respectively. Although REDA still falls short there, the performance gap shrinks on the simplified benchmark. This contrast confirms that the performance of REDA degrades much more severely when faced with the realistic dynamics and constraints embedded in AEOS‑Bench.

Second, for "While these methods offer faster runtimes, their performance diminishes with large‑scale or dynamic scenarios," we performed a scenario‑level analysis comparing MSCPO‑SHCS and AEOS‑Former. We found that MSCPO‑SHCS outperforms AEOS‑Former only on scenarios with an average of 168.8 tasks, whereas AEOS‑Former takes the lead on scenarios averaging 191.3 tasks. This pattern demonstrates that while MSCPO‑SHCS may be competitive on smaller task sets, AEOS‑Former’s learning‑based approach scales gracefully to higher task densities.

6. Task Definition

Tasks in AEOS-Bench are defined as satellite observation missions, each characterized by key parameters: minimum continuous observation duration, release time, due time, and target coordinates. In AEOS-Bench, these parameters are sampled independently and uniformly from predefined ranges, as fully specified in Tab. 2 of the supplemental material.

7. Typos

Thank you very much for pointing out our typo. We will strive for excellence and correct all typos in the revised manuscript.

8. Data Annotation

Annotating ground‑truth schedules by hand is laborious. Annotating a single scenario with $10$ satellites and $50$ tasks can take an expert nearly $40$ minutes. To streamline this, we developed the pipeline in Fig. 3 of the manuscript: an iterative algorithm proposes candidate schedules, and human reviewers simply verify them rather than building them from scratch. Because reviewers only need to confirm rationality, this task requires minimal specialized astronautics knowledge.

All human validation was performed by the paper’s authors. In future work, we plan to expand our annotation effort via crowdsourcing to scale AEOS‑Bench even further while maintaining high quality.

9. Limitations and Broader Impacts

Due to page limits of the manuscript, we provide detailed discussions of limitations (Sec. 1) and broader impacts (Sec. 2) in our supplementary materials.

Our work is designed with socially beneficial applications in mind, such as ecological monitoring and disaster response of AEOS constellations. While it is possible that the scheduling technology could be applied in surveillance contexts, we strongly oppose any misuse. Importantly, the Outer Space Treaty adopted by the United Nations prohibits harmful interference and hostile activities in space, including unlawful surveillance, providing a legal framework that governs responsible use of space technologies worldwide.

To further mitigate risks, our source code is licensed under Apache 2.0, but we plan to introduce additional restrictions, including provisions that explicitly limit downstream misuse. For AEOS-Bench, access will require submission of an application form and approval by the authors. Redistribution of the dataset will be strictly prohibited without explicit permission.

We take the potential for negative societal impact seriously and are actively incorporating safeguards into both our licensing and data access policies to ensure that our work is used ethically and in accordance with international norms.

We appreciate your detailed review and constructive feedback very much. We provide our response to your review as follows.

1. Computation Cost and Deployment

Although our model requires $6$ hours for training completion (with $8$ RTX4090 GPUs), the training cost is incurred only once. Upon training completion, the model can directly perform inference on new scenarios. Consequently, deployment in real-world applications does not necessitate substantial computational resources for retraining, but rather enables deployment through invocation of the pre-trained model. Moreover, this training cost can be further reduced. Our $6$-hour training duration is implemented to achieve superior performance. As demonstrated in the table below, the model exhibits satisfactory convergence after $2$ hours of training on $8$ RTX4090 GPUs, achieving a CS score of $4.67$.

Regarding deployment challenges under resource-constrained conditions, as illustrated in the table below, the model's required FLOPS do not operate at an excessively high level. Taking the RK3568, a commonly employed Commercial Off-The-Shelf (COTS) platform for satellite deployment, as an example, its FP32 computational capacity approximates $500$ GFLOPS, which is sufficient to achieve second-level task allocation for the majority of scenarios presented in the table. Since constellation scheduling constitutes a high-level task, frequent execution at millisecond granularity does not impact allocation outcomes but with higher power consumption. Therefore, second-level allocation is entirely adequate for constellation mission planning applications. That said, we agree that model compression techniques can further boost the performance. In future work, we will implement model quantization and pruning to better accommodate the demands of larger-scale constellation planning over the coming decades.

2. Scalability to Large-Scale Constellations

As mentioned in the table below, this model can be applied to larger-scale constellations without additional training and can essentially cover larger-scale real-world constellations. Regarding satellite internet constellations such as Starlink, although they contain massive constellations (typically thousands of satellites in different orbits), they differ fundamentally from the remote sensing satellites targeted in this paper: internet constellations focus on providing continuous services to broader regions and generally do not concern themselves with signal directionality, meaning they only need to consider satellite coverage of ground areas. In contrast, remote sensing satellites face extensive remote sensing demands across various regions and require specialized scheduling for specific locations. Moreover, due to the difficulty in miniaturizing the optical equipment they carry, it is challenging to launch multiple satellites simultaneously. This indirectly results in remote sensing constellations being at most in the hundreds scale, even when not small in size. Most remote sensing constellations planned for the next decade are around the scale of $100$ satellites. Therefore, this model possesses good scalability for constellations that require constellation planning of this type.

3. Accuracy and Timeliness of Low-Level Attitude Control

We appreciate your insight regarding the low‑level attitude control. In our framework, AEOS‑Former outputs only the high-level task assignments (specifying which satellite observes which target) at each timestep, while the AEOS-Bench simulation handles low-level attitude control for each satellite. As detailed in Fig. 1 of the supplemental materials, the simulator first computes the attitude tracking error (the angular separation between the satellite's current attitude and the task's line of sight). Then, the Modified Rodrigues Parameters (MRP) feedback control algorithm [1] adjusts the angular velocities of reaction wheels to control the attitude. MRP, much like a PID controller but tailored for spacecraft attitude, is carefully tuned to optimize operational accuracy and timeliness. As long as the high‑level commands generated by AEOS‑Former respect the constraints of the satellite, the MRP controller can execute these commands without introducing additional latency or inaccuracy.

This decoupled architecture, where a task planner issues high-level commands and a specialized controller executes them, is widely used in Embodied AI and robotics [2, 3]. This separation allows the planner to operate at a lower frequency that is sufficient for strategic scheduling, while the low‑level controller runs at high rates to ensure stable and precise attitude control. By delegating low-level control to MRP, AEOS‑Former can focus on optimizing task assignments, which leads to better scheduling performance and more accurate evaluation.

We agree that an end‑to‑end co‑optimization of scheduling and control could yield further gains, as the model would have direct influence over reaction wheels. Investigating such integrated approaches, potentially via a hierarchical design, is an exciting direction for future work.

[1] Analytical Mechanics of Space Systems. AIAA. DOI: 10.2514/4.102400.

[2] Helix: A Vision-Language-Action Model for Generalist Humanoid Control. Figure.

[3] Agent as cerebrum, controller as cerebellum: Implementing an embodied lmm-based agent on drones. arXiv: 2311.15033.

4. Choice of Track

We carefully considered submitting to the dataset/benchmark track before deciding on the main track. Our primary goal was to present a complete solution to the realistic AEOS constellation scheduling problem, one that not only provides a realistic benchmark but also introduces a novel constraint‑aware Transformer architecture and training pipeline.

Existing benchmarks either focus on toy scenarios or omit critical constraints, failing to support the training and rigorous evaluation of scheduling models for real-world deployment. Therefore, we develop AEOS-Bench as an essential component for solving the realistic AEOS constellation scheduling problem, though it is not an end in itself. While we believe AEOS‑Bench will be a valuable resource for the community, our contribution also lies in the methodological innovations of AEOS-Former.

Submitting to the main track allows us to present the full narrative: from problem formulation to network design and training. We believe this integrated presentation better reflects the breadth and depth of our contributions and will more effectively inspire future work.

5. Completion Rate on the Test Split

The reduced CR metric on the test split is primarily driven by its internal constraint module $\mathcal{C}$, which filters out satellite-task pairs deemed infeasible. On both the val-seen and val-unseen splits, the PC metric remains around $70$ Wh, but on the test split, PC falls to $40.91$ Wh, indicating that $\mathcal{C}$ rejects a substantially larger fraction of assignments. The underlying cause is a sim-to-real gap. The satellite parameters in AEOS-Bench are uniformly sampled (Tab. 1 of the supplemental material), while real-world satellite parameters often follow different distributions. As a result, the feasibility checks of $\mathcal{C}$ are overly conservative on the test split.

An immediate remedy is to adjust the feasibility threshold $\tau$ of $\mathcal{C}$. In Tab. 3 of the supplemental material, lowering $\tau$ from $1 \times 10^{-3}$ to $5 \times 10^{-4}$ increases test-split CR from $19.25$ to $20.37$, surpassing the MSCPO-SHCS baseline ($19.44$ CR) and reduces CS from $6.35$ to $6.18$. This simple tuning recovers much of the lost performance.

6. Temporal Granularity

In astronautics, the orbital dynamics of a satellite are affected by the orbital altitude. Our research focuses on AEOS satellites, which typically operate in Low-Earth Orbit (LEO), with altitudes ranging from $200$ km to $2000$ km. At these altitudes, LEO satellites travel at approximately 7.9 km/s and complete an orbit around the Earth in merely $90$-$120$ minutes. As a result, their orbital state evolves significantly in the order of seconds. This temporal granularity aligns closely with that of attitude control.

At each timestep, we feed the full satellite state (including both orbital parameters and attitude parameters) into AEOS-Former to make task assignments.

Thank you for your meticulous review and constructive comments. Below we address specific questions.

1. Experiments on Previous Benchmarks

We agree that testing AEOS-Former on external benchmarks is important to demonstrate its broader applicability. To that end, we directly evaluated our pretrained AEOS-Former on the REDA benchmark, which comprises a single scenario with $324$ satellites and $450$ tasks. Unlike AEOS-Bench, REDA does not simulate attitude dynamics. Instead, it measures reward solely based on the proximity between satellites and task locations. Since AEOS-Former relies on attitude information as part of its input, we use the AEOS-Bench simulator to generate the necessary attitude information for each REDA satellite.

Introducing these attitude constraints naturally prevents AEOS-Former from selecting some task assignments that would maximize the reward metric. Nevertheless, even under this more restrictive regime, AEOS-Former achieved a total reward of $17,325$, outperforming REDA’s score of $11,094$ by a wide margin.

This result shows that AEOS-Former is not over-fitted to AEOS-Bench but can also generalize to much larger constellations and different evaluation criteria. We will include these cross-benchmark results in the revised manuscript to underscore the versatility and robustness of our approach.

2. Context on Baselines

The baselines presented in our paper include both optimization-based and learning-based methods. Specifically, HAAL and MSCPO-SHCS are optimization-based approaches. HAAL formulates the scheduling problem as an integer-constrained optimization task, solving it using traditional planning solvers. MSCPO-SHCS adopts a stochastic hill-climbing strategy to iteratively refine scheduling decisions in a time-efficient manner. In contrast, REDA is a neural network-based method that combines multi-agent reinforcement learning with polynomial-time greedy solvers to strike a balance between solution quality and computational speed.

As shown in Table 2 of the manuscript, we evaluated all of these methods on AEOS-Bench. Our AEOS-Former demonstrates consistent improvements over both optimization-based and learning-based baselines. We will expand the background and clarify the distinctions between baseline methods in the revised version to improve readability and context.

3. Uniqueness of Scenarios

Every scenario in AEOS-Bench is guaranteed to be unique. Even across different splits, no two scenarios share the same constellation or task set. During simulation, the AEOS-Bench simulator first loads the scenario to initialize the constellation, then steps through time. At each subsequent timestep, the simulator applies the high‑level scheduling commands, updates the constellation state, and records task progress until the scenario concludes. When gathering training data and when running evaluations, the simulator is indeed the same, but the scenarios are always different. As the simulator steps through time, it produces a distinct trajectory of constellation states and task progress for each scenario.

Since the train, val-seen, val-unseen, and test splits are disjoint pools of scenarios, no exact sequences from data collection appear during evaluation. This prevents the model from memorizing specific simulation runs, forcing it to learn scheduling strategies that generalize to entirely new constellations and task sets.

4. The Limitations Section

A dedicated limitations section in the main text is omitted due to page limits. The discussion is included in Sec. 1 of the supplemental material. In the final manuscript, we will move the limitations section back to the main text.

Thank you for your thoughtful feedback and the recognition of our work. Below we address specific questions.

1. Computation Cost for Training

While AEOS‑Former requires approximately 48 GPU-hours to train ($6$ hours on $8$ RTX 4090 GPUs), we believe this cost is justified given the complexity of the AEOS constellation scheduling task and the significant generalization benefits it enables. Following the scaling law of Transformers [1], model performance improves with increased model size, dataset size, and training cost. In the AEOS constellation scheduling problem, inference latency is strictly constrained, thus limiting the model size. Therefore, we scale up the dataset size to cover a wide diversity of scenarios and prolong the training process to better optimize the model.

While the training cost is more expensive than some heuristic or optimization-based methods, it is a one-time cost. The resulting model exhibits robust generalization to unseen or changing scenarios (e.g., a satellite malfunctions) without retraining, enabling real-time scheduling (latency in milliseconds). In contrast, prior methods are often tailored to fixed scenarios; when the scenario changes, re-running the optimization procedures (taking minutes to hours) is required, which severely hinders real-time responsiveness.

To further investigate the trade-off between training cost and performance, we conducted a small-scale ablation. As summarized in the table below, AEOS‑Former retains high performance even under reduced training budgets:

To lower the computational barrier for the community, we will release both the AEOS-Bench dataset and the pretrained AEOS-Former model. This allows researchers to finetune or directly deploy the model, mitigating the need for expensive pretraining.

[1] Scaling laws for neural language models. arXiv: 2001.08361.

2. Scalability to More Complex Scenarios

Since AEOS‑Former formulates scheduling as a matching problem between satellites and tasks, it extends seamlessly to arbitrary new constellations and task sets. Currently, each scenario in AEOS-Bench contains $1$-$50$ satellites and $50$-$300$ tasks. To test the scalability of AEOS-Former, we evaluate the pretrained model on more complex scenarios that lie outside the original range of AEOS-Bench. The results are summarized below:

When we increase the number of satellites to $50$-$100$, CR jumps from $35.42$ to $64.71$, indicating that AEOS‑Former effectively leverages additional resources without retraining. With more tasks ($100$-$600$), CR drops to $24.30$ since the task load exceeds the satellite resources. These experiments demonstrate that AEOS-Former retains strong generalization when facing complex scenarios beyond its training distribution.

3. Computation Cost for Inference

We sincerely appreciate you for emphasizing this critical concern about computational scalability. We have quantified the computational cost through two key metrics: arithmetic complexity (GFLOPS) and inference latency (to directly reflect real-time feasibility).

We use the calflops tool to measure the GFLOPS across varying scenario sizes (the number of satellites and tasks). While Transformer modules theoretically exhibit quadratic complexity, it contributes only $10$ in the total GFLOPS of AEOS-Former. The remaining $90$ stems from our constraint module, which scales linearly with the scenario size. As shown below, the GFLOPS of AEOS-Former grows linearly with the scenario size:

We benchmark the inference latency over $1,000$ runs on an RTX 4090 GPU to assess real-world performance. Even at the largest scale ($1,000$ satellites + $300$ tasks), AEOS‑Former completes in $11.58$ ms. For smaller scenarios (e.g., $100$ satellites + $100$ tasks), latency drops to under $3$ ms. Since our scheduling system operates at a $1$ Hz update rate, these latencies leave ample margin for real‐time operation.

4. Interpretability of AEOS-Former

Traditional heuristic or optimization-based schedulers provide full transparency by applying explicit decision rules or optimizing known objective functions at each step. In contrast, neural network (NN) models, including AEOS-Former, are inherently "black boxes". It is challenging to trace exactly how individual scheduling decisions arise. This lack of transparency is a general limitation of NN-based methods.

To improve interpretability, we introduce an internal constraint module that explicitly predicts the feasibility of each satellite-task pairing. By exposing these feasibility scores, users can observe which assignments are permitted or filtered out. While this does not fully reveal the model’s internal reasoning, it introduces a verifiable layer that partially bridges the interpretability gap between AEOS-Former and traditional heuristic or optimization-based approaches.

5. Convergence of AEOS-Former

Optimization-based methods perform iterative optimization for specific scenarios, attempting to find optimal solutions. As the number of iterations increases, the probability of finding the optimal solution becomes higher. Our method directly takes scenario information as input and outputs task assignment without any iterative process. Therefore, the performance of our method primarily depends on the degree of fitting to the training set and the generalization error. Quantitative research on the fitting degree and generalization error of deep neural networks is still in a relatively foundational stage. Some studies have achieved global convergence of encoder-only shallow transformers [1]. However, we acknowledge that the performance of deep neural networks, compared to optimization-based methods, lacks theoretical guarantees and mainly relies on statistical results on test data to qualitatively demonstrate effectiveness. In future work, we will attempt to integrate deep neural networks with optimization-based methods to achieve stronger theoretical guarantees.

[1] On the convergence of encoder-only shallow transformers. NeurIPS.