Tegrity.AI GroupJUBAP.Net

VEHICLE ROUTING UNDER
FULLY COMMITTED TOURISM DEMAND

Atomic passenger groups | synchronized transfers | heterogeneous multi-trip fleet | state-dependent objective pricing | bounded repair

Iván Abril Palma
Tegrity.AI Group
Research working paper v1 – July 2026

STATUS OF THIS MANUSCRIPT The system and architecture sections are code-grounded. The comparative replay protocol is preregistered research design: real historical demand days can be recovered, but no replay results are claimed in this version.

Abstract

xSeil was deployed in 2016-2017 to plan passenger transport for an integrated tourism operation in the Mexican Caribbean. A tourism sale made upstream became a transport commitment before the complete daily demand, fleet state, and network interactions were known. The resulting problem combined hard pickup promises, indivisible passenger groups, a heterogeneous owned-and-rented fleet, multiple trips per unit, direct and multi-leg service, typed transfer points, destination-capacity externalities, and a rigid planning deadline. This paper presents a single self-contained account of the operation, the vehicle-routing problem, and the deployed solution architecture.

The implementation did not solve a conventional static VRP by repeatedly constructing routes from scratch. It converted idle computation into operational latency reserve: feasible stop sequences, compatibility relations, and scenario-specific candidate structures were built and persisted offline; online planning retrieved those structures, added state-dependent scarcity and isolation prices, committed one passenger-group coalition at a time, repriced the remaining candidates, and invoked rollback or bounded search widening only on evidence of insufficiency. The code further shows that passenger groups were atomic rather than split-delivery quantities, that transfers could occur at typed non-central points, and that human scenario weights controlled both objective level and penalty curvature.

The paper makes four contributions. First, it classifies xSeil as an industrial rich-VRP with heterogeneous multi-trip routing, hard time commitments, atomic group demand, synchronized transfers, and destination resources. Second, it provides a code-auditable reconstruction while correcting earlier overstatements: the route builder is bounded level-wise enumeration rather than demonstrated dynamic programming; the allocator lacks a global optimality guarantee but does not necessarily produce a suboptimal solution; and route-library coverage is bounded by the configured topology and policies. Third, it proposes a modernization that preserves the offline-online doctrine while replacing exhaustive construction with modern candidate generation and bounded improvement. Fourth, because real demand days can be recovered, it specifies a paired historical replay comparing legacy-faithful, semantically repaired, modern, and hybrid solvers under the same time limits, scenarios, and raw KPI vectors. No superiority claim is made before that replay.

Keywords: rich vehicle routing; multi-trip VRP; time windows; synchronized transfers; passenger transport; atomic demand; route pools; human-in-the-loop optimization; historical replay; xSeil.

1. Introduction

Vehicle-routing research usually begins after the demand, locations, vehicle capacities, time windows, and objective function have already been formalised. Industrial systems begin earlier. They must decide which real-world commitments become hard constraints, which people may be grouped, which resources count as available, where transfers are legally and operationally possible, how multiple objectives are exposed to accountable humans, and how the solver behaves when the perfect plan does not exist before the deadline.

The xSeil case is valuable because the surviving evidence spans both sides of that boundary. The archive contains the production source repository, contemporary requirements and implementation documents, database models, operational workbooks, and public project descriptions. The repository snapshot contains 601 files, including 293 Python modules and approximately 26,758 lines of Python. This permits an architectural retrospective at code level rather than a narrative reconstruction alone.

The contribution is not a claim that a 2016 heuristic outperforms contemporary ALNS, hybrid genetic search, constraint programming, or branch-price-and-cut. Leading exact methods for many VRP classes use branch-price-and-cut, while high-performance metaheuristics now explore route neighborhoods with substantially greater sophistication [6-9]. The research opportunity is more specific: xSeil provides a deployed, replayable answer to how an organisation converted a highly coupled rich-VRP into an auditable offline-online decision process under a hard operational deadline.

Research questions

RQ1. Which operational commitments and entity semantics made the xSeil problem different from a textbook VRPTW?

RQ2. How did persistent feasible-route memory, state-dependent pricing, sequential commitment, and bounded repair interact in the deployed architecture?

RQ3. Which properties were algorithmic, which were architectural, and which were produced by functional and data-model completeness?

RQ4. Under matched deadlines and objective definitions, how does the legacy architecture compare with modern classical solvers and a hybrid route-pool architecture?

RQ5. Under what degree of topology and demand stability does persistent route memory continue to create value?

CENTRAL RESEARCH POSITION The paper does not ask whether old software is better than new software. It asks whether compute banking, prevalidation, human-governed objective pricing, and bounded repair create measurable operational properties that a modern solver should preserve.

2. The operation before the algorithm

The operation served visitors staying across the long Cancún-Playa del Carmen-Tulum hotel corridor and travelling to parks and tour products such as Xcaret, Xel-Há, Xplor, Xplor Fuego, Xenses, Xoximilco, and distributed experiences. Current official visitor information still illustrates the structural pattern: transportation can be purchased from a hotel or meeting point, the exact pickup time depends on the selected origin, multiple stops may occur before Transfer Central, and the service may use vans or buses depending on the operation [1-3]. These current sources orient the reader; the historical 2016-2017 configuration is reconstructed from the system of record rather than inferred from the present portfolio.

Figure 1. Schematic operating corridor. The drawing is intentionally not to scale; it shows why the problem joined a long origin corridor to several destination families and transfer resources.

2.1 A sale became an operational promise

A guest or reseller selected an experience, service date, lodging origin, and transport option. That commercial event committed the transport organisation before the complete demand and fleet situation for the day was visible. By planning time, the pickup location and service time were not optional preferences that the optimizer could freely renegotiate; they were part of the service promise.

This is the meaning of fully committed demand in the paper. It does not mean that every field detail was perfectly known. No-shows, late confirmations, vehicle availability, maintenance, boarding duration, traffic, and park-side absorption still varied. It means that the planner inherited obligations rather than choosing which requests to accept.

Figure 2. A tourism sale became a transport commitment, then an atomic passenger group, route coalition, field movement, and destination arrival.

2.2 Passenger groups, not anonymous demand units

The atomic demand object was a DestinoAgrupador: a group of compatible reservations sharing the relevant service date, pickup context, origin stop, and destination family. The production allocator did not cut such a group into arbitrary passenger fragments merely to fill a vehicle. When capacity was exceeded, it removed complete groups from the candidate coalition. A group could later travel through multiple legs, but it remained a coherent social and operational unit.

For each passenger group g: size q_g, origin o_g, destination d_g, and committed pickup context t_g.

2.3 The previous-evening deadline

The planning process had a hard previous-evening gate, reported by the project team as 18:00, because the organisation needed an executable day plan and a defensible rental decision rather than an open-ended optimization. The same system estimated final passengers from bookings confirmed by that time and historical booking curves, then translated the estimate into units by destination and vehicle type. The algorithm processing time was therefore an operational KPI, not a laboratory convenience.

2.4 Scale and evidence status

The operation ran approximately 10,000 passengers per day in high season, around 12,000 on busy days, and occasional peaks of 15,000–17,000, against a 15,000-passenger design requirement with headroom and a 17,000-passenger tested peak, and considered approximately 60 million candidate configurations in an assignment cycle. The source code demonstrates the large batch settings, memory guards, persistent route and concordance structures, and capacity-oriented design that served this scale.

3. Problem classification: an industrial rich-VRP

No single established acronym captures the entire system. The closest defensible description is a heterogeneous multi-trip vehicle-routing problem with hard time commitments, atomic passenger-group demand, direct and multi-leg service, synchronized transfers, and destination-capacity constraints. In the terminology of recent routing literature, the case belongs to rich VRP and multiple-synchronisation families because route feasibility depends on other routes, transfer timing, shared infrastructure, and vehicle reuse [4,10-12].

Figure 3. The principal routing objects and constraints. They were represented centrally even though they can be interpreted as logical actors in later agentic research.

3.1 Sets and attributes

3.2 Core constraints

Coverage: every committed group must be served, deferred under an explicit exception, or recorded as unserved; silent loss is not admissible.

Atomicity: a group may not be fractionally divided merely to fit a vehicle. Multi-leg movement preserves group identity.

Capacity: the sum of group sizes on a leg must not exceed the selected vehicle capacity; no-standing was treated as a hard feasibility rule.

Time commitments: stop sequences must respect the pickup-time logic, boarding duration, travel-time links, and route-duration limits.

Vehicle sequencing: one unit can perform multiple trips only if its resulting position and available-from time permit the next departure.

Transfer synchronization: the inbound and outbound legs, transfer point, operation, vehicle type, and connection time must be compatible.

Destination resources: arrivals should not jointly exceed the receiving capacity of bays and passenger-processing areas.

Policy compliance: authorised stops, hotel blocks, service classes, bases, and transfer policies reduce the feasible set before optimization quality is considered.

Atomic capacity constraint: sum_{g in C_r} q_g <= Q_v ; if violated, remove complete groups, not individual passengers.

3.3 Objective vector and state dependence

The objective was not one fixed distance cost. Candidate routes carried scores for direct service, policy compliance, pickup punctuality, unit savings, trip length, travel time, transfers, isolation, occupancy, and scarcity. Fuel and emissions were represented indirectly through fuller vehicles, fewer units, and travel time rather than through a direct fuel model. The same raw route could receive a different operational value as the day, remaining fleet, or chosen scenario changed.

S_r(theta, z_k) = base_r(theta) + direct_r(z_k) + isolation_r(z_k) + occupancy_r(z_k) + scarcity_r(z_k)

Here theta is the human-selected scenario and z_k is the state after k commitments. This distinction matters for replay: a modern solver must be evaluated against the same raw KPI vector and scenario semantics, not against a conveniently chosen single distance objective.

Figure 4. A locally desirable objective can become globally harmful when it interacts with destination capacity and other objectives. This is why raw KPI vectors should accompany any scalar score.

4. Evidence base and claim discipline

The paper separates what is visible in code from what is reported in contemporary documents, operational records, or retrospective testimony. This prevents a common error in software archaeology: treating the existence of a code path as proof of how often it ran, at what scale, or with what business outcome.

The raw repository must not be publicly distributed. It contains operational identifiers and historically embedded secrets. The research artifact should instead include a sanitised source bundle, hashes of the original files, a code-to-claim register, derived anonymous instances, and controlled reviewer access where required.

5. Deployed architecture

Figure 5. Compute banking: the route library and scenario structures were prepared outside the hard deadline; online planning was narrowed to retrieval, state-dependent valuation, commitment, and bounded repair.

5.1 Functional substrate before routing

The routing kernel depended on a classical functional substrate: reservation import and reconciliation, stable stop identities, hotel-operation schedules, travel-time links, vehicle types and capacities, availability states, transfer policies, destination groups, boarding-time parameters, and scenario records. These were not secondary administrative details. They defined the feasible problem. A more powerful solver cannot recover a hotel-to-stop relation or transfer policy that the data model failed to preserve.

5.2 Offline feasible-route memory

Feasible stop sequences were built level by level, extending shorter combinations by one stop while enforcing no revisit, link-time existence, pickup-time logic, boarding time, delay tolerance, and maximum route duration. The most accurate description is bounded level-wise feasible-sequence enumeration with label-setting characteristics. The surviving evidence does not establish the state recursion and optimal-substructure proof required to call it dynamic programming.

The result was a persistent column pool in the broad set-partitioning sense: a database of prevalidated route candidates available before the day was allocated. This differs from branch-and-price. xSeil did not solve a reduced-cost pricing subproblem online to generate improving columns. It generated a bounded feasible universe in advance and later consumed it.

5.3 Concordance and reusable structure

Route-stop membership and pairwise concordance structures were also materialised in bounded batches. This made shared-stop and compatibility relations queryable without reconstructing them during the planning deadline. Configuration values of one million committed records and 500,000-record batches demonstrate the intended scale of the structure, but they do not by themselves prove that the production database always contained a million routes or that every possible pair was materialised.

5.4 Human scenario pricing: level and curvature from one dial

Each named scenario stored human-set values for policy, punctuality, direct service, unit savings, short trips, and travel time. A distinctive code-level feature is that the same weight also derived a penalty exponent: exponent = weight/300 + 1. Increasing the importance of punctuality therefore did more than linearly scale its contribution; it made larger deviations increasingly expensive relative to small ones.

This was not autonomous preference discovery. The code proves the scenario substrate and scoring mechanism. The archive does not yet establish that the specified routine for learning preferred parameters from historical human choices was delivered in the surviving snapshot.

5.5 Sequential commitment and repricing

Within each time band, candidates were sorted by current total score. When a candidate had to shed passenger groups to fit a vehicle, its occupancy and total score were recomputed and written back before the next selection. Scarcity was calculated from occupancy, estimated versus total remaining capacity in a geographical zone, and a zone priority. A second-round term also used the fraction of the operating day remaining. The allocator was therefore greedy but not purely static: it committed one coalition, changed the state, and reevaluated the residual choice set.

5.6 Atomic coalition pruning – not split delivery

Earlier drafts described the capacity adjustment as split delivery. That terminology is misleading. In split-delivery VRP, one customer demand may be divided among vehicles. xSeil instead removed complete DestinoAgrupador objects. The ordering favoured groups at highly concurrent stops and smaller group size, making them more plausible candidates for service elsewhere while preserving a minimum occupancy floor. The correct description is concurrency-aware atomic coalition pruning.

5.7 Vehicle assignment and a code-level caveat

Vehicle assignment filtered units by operation, date, base, type, and available-from time. It then preferred rented units over owned units, closing the economic loop created by the previous-evening rental decision: capacity already paid for should not remain idle while owned vehicles are consumed.

The maintenance logic requires careful wording. The routine first detects whether maintenance-current units exist, but the subsequent owned/rented filters use the full unit list rather than the maintenance-current subset. The snapshot therefore does not prove a strict maintenance-current-only gate; it reveals either an implementation defect or an intentional fallback expressed unclearly. The replay should include both the exact code path and a semantically repaired variant. A second reproducibility issue is random vehicle choice, which requires a fixed seed or recorded assignment order.

5.8 Transfers as multi-leg routing resources

The data model did not assume that every transfer occurred at one central hub. It distinguished a formal centre, a temporary dynamic base, foreign and local transfer permissions, and points where transfer was forbidden. The HotelesTransbordo model connected operation, vehicle type, hotel stop, transfer stop, destination stop, destination family, and travel times. When a non-direct alternative was selected, the planner generated a transfer route type and linked the group to the route-sheet stop where it would board the receiving leg.

This makes the problem a synchronized multi-leg passenger VRP rather than a simple cross-dock variant. A transfer could reduce systemic failure at the cost of local inconvenience and connection risk. The routing paper treats it as a feasibility and utility object; the companion orchestration paper studies its role in cascade containment.

5.9 Repair, retry, and evidence-gated widening

When a time band could not be committed, the planner could roll it back, re-fetch demand, and retry. Candidate retrieval widened page by page, entering an explicitly logged advanced-search mode only after the normal page proved insufficient and stopping at a configured cap. This architecture does not guarantee that a feasible solution will be found whenever one exists. It does guarantee a bounded response policy: try the normal context, widen on evidence, and stop before the search consumes the operational deadline.

5.10 Dynamic route sheets

Ad-hoc changes were not always handled by solving a new TSP. The dynamic route-sheet component filtered active sheets by capacity, searched the persistent combination table for a compatible stop sequence, and rebuilt the affected chain from travel-time links. Failure could escalate to replanning. In modern terminology, the route library acted as a prevalidated insertion oracle.

6. Why the design was rational in 2016

The architecture deliberately traded global search flexibility for predictable operational properties. That trade should be evaluated against the actual decision environment rather than against an unconstrained benchmark.

6.1 Compute banking as latency reserve

The most reusable architectural idea is compute banking. Idle or non-critical compute was invested in reusable structural knowledge; the resulting pool reduced the amount of search required when the business deadline arrived. The banked asset was not raw computation but certified candidate structure. Its value depends on topology repetition and the half-life of that structure under change.

6.2 Auditability as a measurable property

Auditability should not be treated as a rhetorical advantage. It can be measured as the fraction of executed route legs whose complete sequence and feasibility checks existed before selection, the proportion of decisions reconstructible from stored scores and state, and the reviewer effort needed to explain an assignment. Modern replay should compare this assurance dimension alongside cost and distance.

7. Relationship to modern vehicle-routing methods

Current methods offer stronger dynamic search than the deployed planner. Branch-price-and-cut is a leading exact paradigm for many VRP classes [6]. ALNS and hybrid genetic search explore destroy-repair and route-exchange neighborhoods that can escape locally attractive commitments [7-9]. Dynamic dial-a-ride research maintains multiple plans to increase the likelihood and speed of inserting new requests [13]. OR-Tools exposes capacity, time-window, pickup-delivery, initial-route, and search-limit mechanisms useful for a reproducible baseline [14-16].

None of these references implies that a standard package can represent the full xSeil problem without custom modelling. Atomic passenger groups, multi-trip vehicle sequencing, typed transfers, destination resources, state-dependent scenario scoring, and the legacy fallback doctrine must be implemented explicitly.

7.1 Corrections to earlier comparative claims

Do not call the route builder bounded dynamic programming unless a formal state recursion, memoisation scheme, and optimal-substructure result are supplied.

Do not say the greedy allocator guarantees a suboptimal state. It provides no global optimality guarantee and may produce a suboptimal state; it can also reach an optimum on particular instances.

Do not say modern solvers universally abandon route pools. Initial routes, incumbent pools, multiple-plan approaches, warm starts, and cached structures remain active design patterns.

Do not claim that every route that can ever be driven was stored. The pool covered routes inside configured stop, policy, length, time, and topology bounds.

Do not call atomic group removal split delivery. The group remained indivisible; transfer created multiple legs, not fractional service.

Do not call the objective-pricing layer a proved market equilibrium. The code establishes state-dependent scoring and sequential repricing; a formal supply-demand equilibrium requires a separate derivation.

Do not describe the design as undominated. Its properties remain potentially valuable; comparative superiority is an empirical question for replay.

8. Historical replay protocol

Recoverable days of real demand change the publication opportunity. The system can move from an experience report to a paired empirical study in which every architecture receives the same historical commitments, fleet state, scenario, and deadline. The replay should be preregistered before comparative results are inspected.

Figure 6. Proposed replay design. The legacy-faithful and semantically repaired arms separate historical fidelity from conclusions about the intended architecture.

8.1 Data package

8.2 Experimental arms

L0 – Legacy-faithful reconstruction. Containerise the surviving dependencies and schema; preserve decision order, configured time limits, and code semantics; fix every random seed; log database order and all fallbacks.

L1 – Deterministic semantic repair. Correct documented implementation defects or ambiguities – including the maintenance-subset issue, deterministic vehicle tie-breaking, and explicit ordering – while preserving the original architecture and scoring rules.

M1 – Reproducible modern baseline. Implement the complete rich constraints in OR-Tools/CP-SAT or a custom time-bounded ALNS, with no access to the legacy route pool unless used as an explicitly labelled warm start.

M2 – High-quality search. Adapt an HGS/ALNS-style method to the rich problem and allow the same wall-clock budget. For small daily slices, use exact or branch-price models to estimate optimality gaps.

H – Hybrid architecture. Retrieve certified pool candidates first, then generate or improve routes dynamically while budget remains; fall back to the best certified feasible plan at timeout.

8.3 Matched objectives and fairness

A modern solver must not be declared superior merely because it minimises a simpler objective. Every arm should report the raw operational KPI vector. Scalar comparisons should be repeated under the same recovered scenario weights and any derived curvature. Feasibility is lexicographically prior: a plan violating atomicity, capacity, transfer connection, or hard pickup commitments cannot compensate through shorter distance.

Primary comparison: raw KPI vector K = (hard violations, unserved groups, units, rentals, passenger-minutes, transfers, occupancy, SLA, destination pressure, compute).

For multiobjective comparison, report Pareto and epsilon-dominance rather than hiding all consequences inside one score. Human-selected historical scenarios can be treated as separate decision regimes, not pooled into one average preference.

8.4 Metrics

8.5 Perturbation families

Late reservation: add groups after the historical planning cut and measure insertion or replanning behaviour.

Vehicle outage: remove a vehicle after planning, preserving its position and committed groups as the disruption state.

Travel-time inflation: multiply selected links or inject corridor-specific delay distributions.

Transfer-point closure: disable one formal or exceptional transfer resource.

Destination-capacity reduction: lower bay or passenger-absorption limits to reveal synchronized-arrival externalities.

Topology drift: add, remove, or reclassify stops to measure the half-life and refresh cost of the persistent pool.

8.6 Statistical plan

Use paired comparisons by day and scenario. Predefine random seeds and repeat stochastic arms. Report median and tail latency, paired effect sizes, bootstrap confidence intervals, and the full distribution rather than only means. For every claim of architectural advantage, identify the corresponding measurable quantity. For example, warm-start advantage means lower time to first feasible plan; graceful degradation means a shallower loss curve under injected pressure; auditability means a higher reconstructible-decision fraction.

8.7 Proposed hypotheses

9. Reference modernization

Figure 7. Proposed modernization: preserve stable semantics, route memory, bounded governance, and human authority while replacing the complete search universe with modern generation and improvement.

The likely modern architecture is not a binary replacement. Keep the domain schema, atomic group semantics, transfer model, scenario governance, route-history store, and bounded fallback. Replace exhaustive enumeration as the sole candidate source with dynamic generation and improvement. The persistent pool becomes a selective memory: certified recurring patterns, previous incumbents, transfer motifs, and high-value route fragments.

9.1 Retrieve-improve-fallback policy

Retrieve the best certified candidates and historical plans matching the current day and scenario.

Construct an immediate feasible incumbent from the pool or the legacy allocator.

Run dynamic ALNS/HGS/CP-SAT improvement within a strict budget, allowing new routes when the pool is insufficient.

Validate every proposed route against the same rule engine and transfer semantics.

At timeout, return the best feasible incumbent; if dynamic search fails, fall back to the certified plan.

9.2 New research metrics enabled by the case

Route-memory half-life: how long a stored candidate remains useful after changes in topology, travel times, policies, and demand composition.

Compute-bank return: online time saved per unit of offline computation, storage, and refresh cost.

Prevalidation coverage: proportion of executed route legs whose complete feasibility was certified before the day.

Time-to-first-feasible versus time-to-best: separates operational survivability from optimization quality.

Human scenario regret: hindsight distance between the selected scenario and the best realised KPI vector, without assuming the human objective was wrong.

Semantic defect sensitivity: outcome difference between faithful code replay and a corrected implementation of the intended rule.

10. Threats to validity and limitations

Single-system retrospective. The architecture may be strongly adapted to a stable tourism corridor and should not be universalised without comparative cases.

Originating-group bias. Code verification reduces but does not eliminate hindsight and selection bias.

Incomplete operational record. Exact production cardinalities, scale figures, and some business outcomes require reconstruction from demand days, logs, database extracts, or acceptance evidence.

Code is not execution history. A branch in the repository proves capability, not frequency of use or operational success.

Snapshot defects. The repository may contain dead code, incomplete features, and bugs. The maintenance-selection issue is one concrete example.

Retrospective terminology. Terms such as rich-VRP, route pool, market clearing, compute banking, and coalition pruning are modern analytical labels rather than necessarily the vocabulary used by the original team.

Baseline implementation risk. A weak modern baseline would make the replay uninformative; rich constraints and equal time budgets must be implemented by experienced OR researchers.

Utility model risk. No single scalar objective captures all stakeholders. Raw KPIs and scenario-specific comparisons are mandatory.

Privacy and intellectual property. Only anonymised demand, sanitised code, and authorised artifacts may enter the reproducibility package.

11. Conclusion

xSeil deserves study as more than a legacy routing heuristic. It is a code-preserved industrial rich-VRP architecture in which commercial commitments became atomic demand groups, feasible stop sequences were banked before the deadline, human scenarios altered both objective level and curvature, scarce capacity was repriced as allocations were committed, transfers created synchronized multi-leg service, and bounded repair protected operational time.

The design should not be romanticised. It did not contain a column-generation pricing problem, did not guarantee global optimality, carried static-memory and topology-change costs, and includes implementation ambiguities that the replay must expose. Those limitations make the case more useful, not less: they permit a disciplined separation between historical code, intended architecture, and modern alternatives.

The recoverability of real demand days creates the decisive next step. A paired historical replay can measure whether the apparent edge lay in solution quality, time to feasibility, prevalidation, tail latency, graceful degradation, human-governed utility, or some combination. The strongest likely outcome is not that the 2016 system defeats a 2026 solver. It is that a hybrid architecture – persistent decision memory beneath bounded modern search – may preserve the properties that made xSeil operationally credible while removing the limitations of exhaustive preparation and greedy commitment.

Annex A. Technical code artefacts

The excerpts below are lightly shortened from the production repository snapshot dated 2018-04-21. They are included to make the architectural claims auditable. Line numbers may differ after sanitisation. The raw repository is not a public research artifact.

A1 – Feasibility pruning during bounded level-wise route construction [C].

# crear_combinaciones_pd.py - extension of a stored stop sequence if parada_destino in row["c_paradas_ids"]:     return                                      # no revisits  enlace = row["tiempo_enlace"] if not enlace:     raise Exception("missing link time")  hora_llegada_seconds = time_to_seconds(hora_salida_last_punto) + enlace _retraso = hora_llegada_seconds - time_to_seconds(row["hora_pup"])  tiempo_embarque = row["embarque_med"].total_seconds() if row["embarque_med"] else 0 if abs(_retraso) > self.retraso_tolerable:     if _retraso >= 0:         return                                  # late beyond tolerance     elif abs(_retraso) > self.retraso_tolerable + abs(tiempo_embarque):         return                                  # too early even after boarding allowance

Reading: the builder creates only sequences that survive link, repetition, pickup-time, boarding, and delay checks. This is prevalidation, not proof that the pool contains every physically imaginable route.

A2 – Bounded-batch persistence of route concordance structures [C].

# crear_combinaciones_concordantes.py MAX_LIMIT = 1000000 BATCH_SIZE = 500000 ... CombinacionesConcordantes.objects.bulk_create(     self.list_combinaciones_concordantes_pending,     batch_size=BATCH_SIZE)

Reading: the settings establish million-scale intended processing and a persistent compatibility relation. Actual production cardinality must be recovered from database artifacts.

A3 – Human scenario values control both objective level and penalty curvature [C].

valor_politicas        = self.__escenario.valor_politicas valor_puntualidad      = self.__escenario.valor_puntualidad valor_directos         = self.__escenario.valor_directos valor_ahorro_unidades  = self.__escenario.valor_ahorro_unidades valor_viajes_cortos    = self.__escenario.valor_viajes_cortos valor_tiempo_recorrido = self.__escenario.valor_tiempo_recorrido  exp_valor_puntualidad      = (valor_puntualidad / 300) + 1 exp_valor_ahorro_unidades  = (valor_ahorro_unidades / 300) + 1  df_pickups['puntuacion_puntualidad'] = (     ((avg - df_pickups['puntuacion_puntualidad']).abs()      ** exp_valor_puntualidad) * valor_puntualidad     / (2 * std)) + valor_puntualidad

A4 – State-dependent scarcity, phase pricing, and in-loop repricing [C].

df.loc[idx, "puntuacion_escasez_unidades"] = (     df[idx]["porcentaje_lleno"]     * (eu["plazas_estimadas"] / eu["plazas_totales"])     * zona.prioridad_escasez)  df.loc[idx_gp, 'puntuacion_directos_final'] = (     (eu["plazas_estimadas"] / eu["plazas_totales"])     * porcentaje_franja     * zona.prioridad_segundas_vueltas)  # inside the assignment loop after atomic-group trimming row["porcentaje_lleno"] = min(row['pax'] / tipo_unidad_plazas, 1) row["puntuacion_lleno"] = row["porcentaje_lleno"] * self.__escenario.valor_ocupacion row['puntuacion_total_final'] = (     row['puntuacion_total'] + row['puntuacion_directos_final']     + row['puntuacion_aislamiento'] + row['puntuacion_lleno']     + row['puntuacion_escasez_unidades'])

A5 – Concurrency-aware removal of complete passenger groups [C].

# planeacion.py - asignar_pasajeros pasajeros_sobrantes = row["pax"] - tipo_unidad_plazas ... SELECT count(*) AS concurrencia, q.* FROM query q ORDER BY 1 DESC, q.tot_pax ... if temp_porcentaje_lleno >= self.__pargeneral.minimo_ocupacion:     pasajeros_sobrantes -= destino_agrupador.tot_pax     agrupadores_ids_quitados.append(destino_agrupador.id_agrupador) ... row["agrupadores_ids"] = list(agrupadores_restantes) row["pax"] = row["pax"] - agrupadores_quitados

Reading: the code removes complete groups, preserving atomicity. It is coalition pruning, not fractional split delivery.

A6 – Availability filtering, rented-unit-first selection, and the maintenance-subset caveat [C].

estimaciones_parada = UnidadesParadas.objects.filter(     operacion_id=self.__operacion_id,     fecha=self.__fecha,     disponible_desde__lte=combinacion_paradas[0].hora_salida,     parada_id=parada_base_id,     unidad__id_tipo_unidad_id=tipo_unidad.pk)  unidades = list(Unidades.objects.filter(pk__in=unidades_ids)) unidades_al_dia = [u for u in unidades if u.status_mantto == MANTENIMIENTO_AL_DIA] if unidades_al_dia:     unidades_al_dia = [u for u in unidades if u.propia is True]     unidades_al_dia_rentadas = [u for u in unidades if u.propia is False]     if unidades_al_dia_rentadas:         unidad = random.choice(unidades_al_dia_rentadas)

Code-audit caveat: after detecting maintenance-current units, the subsequent filters use the complete unidades list. The replay must preserve this in L0 and correct it explicitly in L1 rather than silently rewriting history.

A7 – Typed transfer policy vocabulary [C].

CENTRO_SALIDAD = 'CT' BASE_DINAMICA = 'DIN' PERMITE_TRANSBORDOS_FORANEOS = 'FO' PERMITE_TRANSBORDOS_LOCALES = 'LO' NO_PERMITE_TRANSBORDOS = 'NT'  POLITICA_TRANSBORDOS_CHOICES = (     (CENTRO_SALIDAD, 'Centro de Salida'),     (BASE_DINAMICA, 'Base de Salida y Transferencia Temporal Dinamica'),     (PERMITE_TRANSBORDOS_FORANEOS, 'Permite transbordos foraneos'),     (PERMITE_TRANSBORDOS_LOCALES, 'Permite transbordos locales'),     (NO_PERMITE_TRANSBORDOS, 'No permite transbordos de pasajeros entre unidades'))

A8 – Hotel-transfer-destination feasibility object [C].

class HotelesTransbordo(models.Model):     id_operacion = models.ForeignKey('Operaciones', ...)     id_tipo_unidad = models.ForeignKey('TipoUnidades', ...)     id_hotel = models.ForeignKey('Hoteles', ...)     id_parada_hotel = models.ForeignKey('PuntosParada', related_name='rel_id_parada_hotel', ...)     id_parada_transbordo = models.ForeignKey('PuntosParada', related_name='rel_id_parada_transbordo', ...)     id_parada_destino = models.ForeignKey('PuntosParada', related_name='rel_id_parada_destino', ...)     id_grupo_parques = models.ForeignKey('NombreGruposParques', ...)     tiempo_recorrido = models.PositiveIntegerField(...)     tiempo_hotel_transbordo = models.PositiveIntegerField(...)

A9 – Transfer feasibility depends on point, operation, unit type, and both travel legs [C].

JOIN x_cat_puntos_parada pp   ON pp.activo IS TRUE  AND pp.politica_transbordos IN ('CT','DIN','FO') LEFT JOIN x_det_politica_transferencias pt ON      pt.id_parada_id      = pp.id  AND pt.id_operacion_id   = so.id_operacion_id  AND pt.id_tipo_unidad_id = tu.id  AND pt.politica IS TRUE LEFT JOIN x_det_tiempo_enlace enlace_hotel_CT   ON enlace_hotel_CT.id_parada_1_id = h.id_parada_id  AND enlace_hotel_CT.id_parada_2_id = pp.id LEFT JOIN x_det_tiempo_enlace enlace_CT_destino   ON enlace_CT_destino.id_parada_1_id = pp.id  AND enlace_CT_destino.id_parada_2_id = g.id_bahia_id

A10 – A selected non-direct alternative becomes an executable transfer route binding [C].

if row["puntuacion_directos"] < 0:     hruta.tipo_hruta = PICK_UP_DE_TRANSFERENCIA ... if hruta.tipo_hruta == PICK_UP_DE_TRANSFERENCIA:     agrupador.id_parada_hruta_transbordo_id = paradas_hruta.pk

A11 – Band-level retry and bounded evidence-gated search widening [C].

CONST_REINTENTAR = 0 ret = CONST_REINTENTAR while ret == CONST_REINTENTAR:     destinos = DestinoAgrupadores().get_destinos_planeacion(...)     for index in range(self.__pargeneral.limite_paginacion_planeacion):         page = index         if page == 1:             self.logger.warn("Modalidad: busqueda avanzada")         ...

A12 – Dynamic route-sheet insertion using the persistent route library as an oracle [C/R].

def insert_adhoc(group):     sheets = active_route_sheets(group.date)     sheets = [h for h in sheets if h.available_seats >= group.size]     for h in rank_by_added_time(sheets, group):         sequence = search_persistent_combination(stops(h) + [group.stop])         if sequence is None:             continue         delete_old_stop_chain(h)         rebuild_stop_chain(h, sequence, static_link_times)         return h     return None  # escalate to broader replanning

The pseudocode is faithful to apps/hojadinamica/admin.py; the production routine is longer because it reconstructs route-sheet records and related passenger bindings.

A13 – Previous-evening booking-curve extrapolation and vehicle sizing [C].

pax_promedio_hora[destino_id] = historical_booked_by_now pax_promedio_totales[destino_id] = historical_final_total pax_actuales_sum = today_confirmed_by_now  pax_estimados_x_destinos[destino_id] = (     pax_actuales_sum     * pax_promedio_totales[destino_id]     / pax_promedio_hora[destino_id])  calc = (pax_estimados * porcentaje_ocupacion_destino) / stats.tipo_unidad.plazas num_unidades_x_escenarios[escenario_id]["tipo_unidad"][tipo] += calc

Annex B. Minimum reproducibility and replay package

B1. Suggested canonical instance JSON

B1 – Illustrative canonical interchange format. The final schema should preserve the original semantics without personal identifiers.

{   "day_id": "anon-2017-08-XX",   "cutoff_time": "18:00:00",   "groups": [{"id":"g1","pax":4,"origin":"s12","destination":"d3","pickup":"07:20:00"}],   "vehicles": [{"id":"v8","type":"bus-45","capacity":45,"base":"b1","available_from":"05:30:00","rented":true}],   "stops": [{"id":"s12","kind":"hotel","transfer_policy":"NT"}],   "links": [{"from":"s12","to":"p2","seconds":1260}],   "transfer_rules": [{"point":"p2","operation":"op1","vehicle_type":"bus-45","allowed":true}],   "destination_resources": [{"destination":"d3","band":"08:40-08:45","bays":4,"pax_capacity":180}],   "scenario": {"punctuality":300,"direct":220,"occupancy":180,"travel_time":150},   "limits": {"planning_seconds":900,"max_search_pages":4,"minimum_occupancy":0.65} }

Annex C. Claim-status ledger

References

[1] Grupo Xcaret. How to get to Xcaret? Transportation options and maps. Official visitor information, accessed July 2026.

[2] Grupo Xcaret. FAQS: transportation pickup, hotel and meeting-point selection, and vehicle type. Official site, accessed July 2026.

[3] Grupo Xcaret. Location / How to Get to Xcaret Park and current parks-and-tours portfolio. Official site, accessed July 2026.

[4] Soares, R., Marques, A., Amorim, P., and Parragh, S. N. (2024). Synchronisation in vehicle routing: Classification schema, modelling framework and literature review. European Journal of Operational Research, 313(3), 817-840. doi:10.1016/j.ejor.2023.04.007.

[5] Vidal, T., Laporte, G., and Matl, P. (2020). A concise guide to existing and emerging vehicle routing problem variants. European Journal of Operational Research, 286(2), 401-416.

[6] Costa, L., Contardo, C., and Desaulniers, G. (2019). Exact Branch-Price-and-Cut Algorithms for Vehicle Routing. Transportation Science, 53(4). doi:10.1287/trsc.2018.0878.

[7] Ropke, S., and Pisinger, D. (2006). An adaptive large neighborhood search heuristic for the pickup and delivery problem with time windows. Transportation Science, 40(4), 455-472. doi:10.1287/trsc.1050.0135.

[8] Vidal, T. (2022). Hybrid genetic search for the CVRP: Open-source implementation and SWAP* neighborhood. Computers & Operations Research, 140, 105643. doi:10.1016/j.cor.2021.105643.

[9] Kool, W., Olde Juninck, J., Roos, E., Cornelissen, K., Agterberg, P., van Hoorn, J., and Visser, T. (2022). Hybrid Genetic Search for the Vehicle Routing Problem with Time Windows: A High-Performance Implementation. 12th DIMACS Implementation Challenge technical paper.

[10] Cattaruzza, D., Absi, N., and Feillet, D. (2016). The Multi-Trip Vehicle Routing Problem with Time Windows and Release Dates. Transportation Science, 50(2), 676-693. doi:10.1287/trsc.2015.0608.

[11] Cattaruzza, D., Absi, N., and Feillet, D. (2018). Vehicle routing problems with multiple trips. Annals of Operations Research, 271(1), 127-159.

[12] Huang, N., Li, J., Zhu, W., and Qin, H. (2021). The multi-trip vehicle routing problem with time windows and unloading queue at depot. Transportation Research Part E, 152, 102370.

[13] Ackermann, C., and Rieck, J. (2025). Multiple plan approach for a dynamic dial-a-ride problem. OR Spectrum, 47, 781-815. doi:10.1007/s00291-025-00809-y.

[14] Google OR-Tools. Vehicle Routing Problem, Capacity Constraints, Time Windows, Pickup and Delivery, and Common Routing Tasks documentation. Accessed July 2026.

[15] Pillac, V., Gendreau, M., Guéret, C., and Medaglia, A. L. (2013). A review of dynamic vehicle routing problems. European Journal of Operational Research, 225(1), 1-11.

[16] Ritzinger, U., Puchinger, J., and Hartl, R. F. (2016). A survey on dynamic and stochastic vehicle routing problems. International Journal of Production Research, 54(1), 215-231.

[17] JUBAP.Net. xSeil whitepaper and public case-study material. Accessed July 2026.

[18] xSeil production repository snapshot (2018-04-21), contractual functional inventories, implementation manuals, and operational artifacts. Private system of record; sanitised excerpts reproduced with permission.

[19] Abril Palma, I. (2026). Centralized Multi-Actor Orchestration Under Conflicting Objectives: The xSeil Logistics System. Technical working paper.

Selected official and technical sources: Xcaret transport information | Xcaret FAQ | Exact branch-price-and-cut survey | HGS-CVRP | Synchronisation survey

p.