Five of us from [Universidad del Valle de Guatemala](https://noticias.uvg.edu.gt/eficiencia-en-el-puerto-de-singapur-el-desafio-que-llevo-a-team-uvg-al-segundo-lugar-del-2025-winter-simulation-challenge/) walked into the [Winter Simulation Conference Simulation Challenge](https://meetings.informs.org/wordpress/wsc2025/simulation-challenge/) in Seattle. None of us had built a discrete-event simulation (a model that ticks forward each time something happens, like a ship arriving or an AGV moving a container) before the year started. We came home with the silver medal. The problem was to minimize the average total time vessels spend in a fully automated container terminal modeled on Tuas Port, Singapore, the largest fully automated terminal in the world. Our solution, the one that took second place, is an adaptive policy that selects the right heuristic for the scenario instead of trying to find the one heuristic that handles everything. ## What broke our first solution The competition gives every team the same hardware. It asks four questions on every container that arrives. Which vessel should berth first? Which berth should it use? Which AGV should move each container? Which yard block should each container land in? Most teams, us included for the first three rounds, build fixed scoring functions for each of those four decisions. You weight waiting time, distance, congestion, and distribution balance, then pick the highest-scoring option each time. It worked, until it didn't. The further into the competition we got, the more obvious it became that a single set of weights handled some scenarios well and others poorly. A heuristic tuned for a peak-load schedule was the wrong tool for a sparse one. We were trying to find *the* best weights. The actual problem was that no single weight set could be right everywhere, and we were going to keep losing points until we admitted it. Each heuristic is one page of a book. The bandit reads the scenario and turns to the right page. Top-down schematic of the modeled container terminal: 4 berths with quay cranes at top, AGV transit lanes in the middle, 16 yard blocks at the bottom with stacked containers.

Top-down schematic of the modeled container terminal: 4 berths with quay cranes at top, AGV transit lanes in the middle, 16 yard blocks at the bottom with stacked containers.

## How we got there The whole thing started as a recommendation. Two of our professors at UVG, Mgtr. Dulce Chacón and Mgtr. Ingrid de León, suggested the team apply for the Simulation Challenge. The five of us (Rafael O'Meany, Juan Fernando Zúñiga, Kenneth Monterroso, Ángel Esquit, and me) agreed before any of us had a clear idea what we were committing to. The first round ran in August 2025. Most of what we did that round was learn what *vessel arrival distribution* and *berth allocation* actually meant in code. For rounds one through three, our solution was a stack of fixed scoring functions, one for each of the four decision problems. Vessel selection scored each waiting vessel on urgency, queueing fairness, service-time estimate, feasibility flags, and a top-down filter that capped the number of vessels we even evaluated. Berth allocation scored each available berth on proximity, yard-side congestion, and a forward-looking reservation for big vessels arriving soon. AGV dispatching scored each available vehicle on distance, ETA, idle time, and how concentrated the AGVs were already in one zone, with congestion-adaptive weights that made distance more important when the system was busy. Yard block assignment scored each candidate block on transport time, the wait time at the yard crane, the block's current utilization, and a sigmoid distribution penalty that prevented us from dumping every container from one vessel into the same block. By round three we knew the hidden round (the final scenario the judges had not released) was almost certainly going to be different from anything we had tuned for. The fixed-rule version was going to lose points there. So we changed approach. We built a contextual bandit using LinUCB. The mental model: imagine a slot machine with seven arms, where pulling each arm runs the simulation with a different strategy. The bandit reads the situation, places its bet on the arm it expects to score highest, and updates its odds based on the outcome. Seven arms, each arm a parameter set tuned for a specific group of scenarios. A 28-feature context vector summarized the scenario at simulation start: six features for vessel arrival patterns, eleven for weekday load distribution, four for berth and asset concurrency, seven for flow and load variability. The bandit predicted the expected performance of each arm given the context, picked the highest one, and loaded that parameter set into the four scoring functions before the simulation ran. The hard part was not the bandit. It was the scenario grouping that made the seven arms meaningful in the first place. We computed two 25-by-25 Euclidean-distance matrices, one on vessel arrival data and one on transhipment data, then merged them and grouped scenarios by similarity. Some groups were tightly clustered, which let us specialize their parameter sets aggressively. Other groups were diffuse, which forced their parameter sets to be more generalist. Once the groups were stable, we used Bayesian optimization (a smart search that learns from each trial where to try next, instead of brute-forcing every combination) to develop the parameter sets, focusing on the five most influential parameters (all yard-block scoring weights, since yard placement is what encodes future congestion in the system). Each parameter set took four to five days to optimize on the hardware we had, which was the binding constraint on how aggressively we could iterate. The simulation begins and calls the bandit for a parameter set. Loads vessel arrival data, transhipment data, and yard state into a feature pipeline. A 28-feature context vector is built and passed to the LinUCB model. LinUCB predicts the expected total time for each of the seven parameter sets given this context. The arm with the highest predicted score is chosen for this scenario. The selected arm's parameter set is loaded into the four scoring functions, and the simulation runs as a heuristic system for the rest of the scenario. A team member at a podium in Seattle presenting the Optimization of the scoring functions slide. Two judges sit at a table to the right, listening.

A team member at a podium in Seattle presenting the Optimization of the scoring functions slide. Two judges sit at a table to the right, listening.

Rounds one through three we tuned the four scoring functions manually for each scenario group. It worked on familiar patterns and fell apart on unfamiliar ones. For the hidden round we switched to LinUCB with seven arms. The problem turned from "find the best parameters" to "select the right parameters at runtime," and that reframing was the entire shift. The four scoring functions had dozens of tunables. Optimizing all of them per scenario group was beyond our compute budget. We committed to optimizing the five yard-block scoring parameters because yard placement encodes future congestion: where you put a container now constrains where the next one can go. Highest leverage per CPU-hour, by a wide margin. With twenty-five scenarios per round, "let us just guess which ones are alike" was the failure mode we wanted to avoid. The 25-by-25 Euclidean-distance matrices on vessel arrival and transhipment data forced the grouping to be data-driven. Some groups specialized; others generalized. We could see which was which before tuning a single parameter. After round one, the pattern was clear: our scoring was reactive when it needed to be predictive. A berth that looks optimal right now is the wrong choice if a large vessel is arriving in thirty minutes. We added forward-looking penalties (vessel reservation, future-load weighting on yard blocks) and the scoring started seeing the next move instead of just the current one. We also tried to ground the work outside the simulation. One of us interviewed port operators in Guatemala about how container handling actually runs in practice. The interviews were useful for understanding what we didn't know. The operations described were too different from a fully automated terminal to map cleanly onto the model. The honest version is that we learned the simulation by failing inside it, round by round, and let each failure tell us which signal we'd been ignoring. ## What the bandit got us In round one we were trying to find *the best heuristic*. By the time we were preparing for the hidden round, we had given up on that goal and were instead trying to find *the right heuristic for this scenario*. That reframing is why the silver-medal architecture is a structurally different kind of system than a single tuned policy. The bandit gave us a three to four percent average improvement over our best fixed-rule submission, with up to seven and a half to ten percent improvement under specific high-congestion scenarios. In a port operations context, anything above one percent is operationally meaningful. Three percent on a system handling thirty-seven million containers a year is real money. ## What I took away A simpler model you can reason about and run a thousand times is more useful than a faithful one you can run twice. Modeling realism is a trade-off, and the right level of abstraction depends on what you're optimizing for, not on what the system "really" looks like. The bigger lesson generalizes well past port logistics. A tuning problem that will not converge often becomes a selection problem that solves cleanly. The biggest engineering judgment in this project was not in the bandit's math. It was in the moment we stopped searching for one perfect policy and started searching for the right one to use right now. Team UVG and accompanying advisors standing together in front of the WSC 2025 Simulation Challenge banner at the Seattle conference venue, after the competition ended.