Tegrity.AI GroupJUBAP.Net

The xSeil Problem, Deployed Architecture, Functional Substrate, and Quantum Research Boundary

Iván Abril Palma · IMSV.org / tegrity.ai working group

Abstract. This paper reconstructs the problem structure and architecture of xSeil, a logistics planning and execution platform deployed in 2016-2017 for passenger transport in the Riviera Maya. The operating regime combined demand committed before fleet planning, fixed pickup obligations, heterogeneous vehicles, transfer options, hard seating constraints, time windows, and dense propagation effects. The surviving repository shows that xSeil did not rely on a single monolithic optimizer. It integrated data normalization and fleet readiness with an offline persistent library of feasible stop sequences, a stored route-compatibility relation, human-configured scenario scoring, state-dependent online allocation, bounded search widening, rollback and retry, dynamic route reconstruction, and destination-arrival pacing. The contribution is a code-grounded architectural account designed to support a separate quantum-formulation paper. Quantum interest arises from the system’s structured discrete spaces, native offline-online boundary, simulation and event surfaces, and explicit separation between reusable decision memory and adaptive real-time control. No quantum advantage is claimed. The paper instead identifies the conditions that any later quantum object must satisfy: a fixed instance, a precise output requirement, coherent data access, a reversible or Hamiltonian representation, and comparison against strong classical baselines.

Keywords: vehicle routing; committed demand; persistent route library; online allocation; repair and retry; hybrid architecture; quantum resource accounting

1. Introduction

Vehicle-routing research typically begins with a fleet, a customer set, demands, and an objective such as distance or cost. xSeil began from a less forgiving operational reality: transportation commitments had already been sold through a distributed commercial network before planning, and the planning system received the resulting obligations as fixed inputs. Pickup place and time, passenger quantities, destination commitments, vehicle capacities, transfer policies, and operating windows had to be reconciled after the demand had become non-negotiable. This places the case within the wider family of vehicle-routing problems with time windows, heterogeneous capacity, transfers, multiple trips, and dynamic execution, while adding a strong asymmetry between commercial commitment and operational control [1,2].

The system is relevant to quantum computing for a narrower reason than the generic claim that routing is combinatorial. Its repository preserves several different computational objects: a reusable feasible-route library, a route-pair relation, scenario-dependent score surfaces, sequential allocation under changing state, a simulation mode, and event-producing control loops. These objects have different data-access patterns and different output requirements. Some may admit meaningful quantum formulations; others are intrinsically adaptive and should remain classical. The architecture therefore provides a useful test case for deciding where an ideal query-complexity improvement could survive full resource accounting.

This paper has four objectives. First, it defines the operational problem without relying on later conceptual reinterpretations. Second, it reconstructs the deployed architecture from the public project record and a surviving source-code snapshot. Third, it identifies the classical functional substrate that made the optimization problem operationally well-defined. Fourth, it identifies architectural research surfaces for a companion paper that will define the actual quantum objects, oracles, Hamiltonians, error targets, and classical benchmarks. The present paper deliberately stops before those technical formulations.

2. Operational problem

The public project record describes a major integrated tourism operation serving a large daily passenger volume through a network of hotels, resellers, parks, vehicles, drivers, guides, and transfer points. Demand could be sold without live knowledge of fleet capacity, so the transportation obligation reached the planner after the customer-facing commitment had already been made. The operation ran around 10,000 passenger movements per day in high season, approximately 12,000 on busy days, with occasional peaks of 15,000–17,000, and tens of millions of candidate evaluations in major assignment cycles [6].

Scale corroboration (v2.1). Recovered per-reservation exports from the legacy system of record establish booked totals of 10,679 and 11,954 passengers for 4 and 6 July 2017, matching this order of magnitude from primary artifacts; daily totals decompose over planning instances (geographic operation by time slot). Capture dates additionally show 7-10% of reservations arriving on the service day itself, an empirically calibrated rate for the late-demand perturbation families used in Companion Paper II. Peak and per-instance figures reflect operational scale: around 10,000 passengers per day in season, approximately 12,000 on busy days, and occasional peaks of 15,000–17,000.

Table 1. Problem properties and computational consequences.

A useful retrospective classification is a multi-trip, heterogeneous vehicle-routing problem with transfers and time windows. This is not a claim that one standard mathematical formulation captures every deployed rule. The repository contains business semantics, operational statuses, fleet-readiness conditions, transfer logic, time-band processing, and execution updates that extend beyond a static VRP instance. It is therefore more accurate to describe xSeil as a logistics operating architecture containing several routing, assignment, scheduling, and control subproblems.

The central difficulty was propagation. If a passenger group was assigned to a route, seats disappeared, the route timing changed, a vehicle became unavailable for a period, and the value of alternative assignments changed. A solution evaluated at the beginning of a band could therefore become stale after the first few allocations. The system needed to preserve global operational coherence while still making decisions sequentially and under a deadline.

3. Evidence base and reconstruction method

The reconstruction uses two evidence classes. The first is the public xSeil whitepaper, which describes the operating context, end-to-end platform scope, integrations, planning functions, field execution, and managerial reporting [6]. The second is a surviving repository snapshot dated 21 April 2018. The archive contains 601 files, including 293 Python modules and approximately 26,758 lines of Python (exact cat-based count over the 293 modules) across planning, logistics, dynamic route sheets, import, reporting, GeoTab integration, APIs, and supporting applications. The archive hash used for this review is SHA-256 77bc819ae8746ec72216d00d2544a672ebc7114283459d3d58b189de586ce786 [7].

Provenance addendum (v2.1). A second archive of the repository exists: a third-party containerization dated 28 January 2023 (671 files; SHA-256 c2de31a8f8de2ed146c9c1ee40dce870ee088ada9c460ce17df7c9a2be54edd2). Every module cited in Table 2 is byte-identical across both archives, so all evidence in this paper is unaffected. The 2023 port nevertheless introduces at least three semantic divergences (a schema-rename defect breaking the concurrency computation at runtime; an exception-propagation change altering retry semantics; a reversed transfer-admissibility inequality in the hotel-transfer builder) and embeds additional secrets. The 2018 snapshot is therefore the sole evidentiary anchor and the required source for any kernel extraction in Companion Paper II; the 2023 archive is used only as corroboration and as the container in which contemporary design documents and executed August 2017 route sheets were preserved.

Claims in this paper are intentionally narrower than the broad conceptual interpretation on the latter part of the public whitepaper. A mechanism is treated as code-established only when a corresponding source object can be identified. Later descriptions such as formal market equilibrium, low-propagation clusters, probability-of-anomaly multiplied by propagation probability, or pre-armed catastrophic scenarios are not required for the architecture presented here and are not asserted as deployed code facts.

Table 2. Principal code evidence used in the architectural reconstruction.

4. Deployed architecture

xSeil was not organized as a single optimization call. It was an end-to-end platform connecting operational data, reusable decision structures, online planning, execution, and feedback. Figure 1 summarizes the architecture and shows the boundary relevant to later quantum work.

Figure 1. xSeil computational architecture. The dashed boundary marks the offline or frozen-state region after the classical functional substrate has produced a coherent operational state in which later quantum formulations may be considered; it does not imply that every enclosed function is quantum-suitable.

4.1 Integration, functional completeness, and operational state

The planning engine depended on reservations, hotel and park structures, pickup schedules, vehicle data, operation definitions, travel times, transfer policies, maintenance and availability. The public documentation describes ingestion from SOX and other sources, together with validation of inconsistent hotel, vehicle, reservation, and manual-planning data [6]. The contractual component taxonomy separately recognized screens, reports, catalogues, normalization/ETL, business analysis, architecture, design, internal logic, process analysis, and inherited components [13]. Algorithmic logic was therefore one deliverable class inside a wider information system, not the entire product.

Architecturally, this layer is not peripheral. A mathematically valid route computed over inconsistent identifiers or stale fleet status is not executable. Fleet readiness, boarding state, SLA definitions, accessibility rules, maintenance, reassignment reasons, and rental decisions established the state, constraints, and utility on which later computation depended. These functions were frequently implemented through controlled vocabularies, filters, joins, and arithmetic rather than advanced algorithms [14,15].

Code evidence 1 - operational states define feasible input (apps/xsail/const/__init__.py)

STATUS_MANTTO_CHOICES = (
    ('MNO','No Establecido'), ('MAN','Realizando Mantenimiento'),
    ('DIA','Mantenimiento al día'), ('REA','Esperando Reagendar'),
    ('MPR','Cita Mantenimiento Próxima'))
STATUS_DISPONIBLE_CHOICES = (
    ('DIS','Disponible para Programación de Transporte'),
    ('NDI','No disponible'), ('PRI','En Servicio Privado'))

Code evidence 2 - rental sizing baseline (estimar_rentas.py)

pax_estimados = pax_actuales_sum * pax_promedio_totales[destino_id]                  / pax_promedio_hora[destino_id]
calc = (pax_estimados * porcentaje_ocupacion_destino)        / stats.tipo_unidad.plazas

Table 3. Functional substrate and its role in quantum formulation.

4.2 Offline feasible-route library

The route builder constructed feasible stop sequences level by level. Starting from valid base-to-stop structures, it extended each stored sequence by one stop until a configured maximum number of stops was reached. Candidate extensions were rejected when a travel-time link was missing, a stop was repeated, total pickup duration exceeded its limit, or arrival deviation exceeded the configured tolerance. Accepted sequences were persisted in PostgreSQL with their ordered stops, times, duration, delay and parent relation [8].

Code evidence 3 - level-wise persistent route construction (crear_combinaciones_pd.py)

iterator = start_num_paradas
while True:
    obj_len = Combinaciones.objects.filter(num_paradas=iterator).count()
    if obj_len == 0: break
    for offset in range(0, obj_len, BATCH_SIZE_SELECT):
        self.__pool_main.add_task(self.make_combinaciones_by_batch, ...)
    self.__pool_main.wait_completion()
    iterator += 1
    if iterator > NUM_PARADAS_COMBINACIONES: break
...
if _fecha_b < _fecha_a: return
if _combinacion.tiempo > self.TIEMPO_MAXIMO_PICKUP: return
pending_combinaciones['base'].append(_combinacion)

This is best understood as a materialized, bounded column pool. It resembles the route-column substrate used by set-partitioning and column-generation methods, but xSeil did not generate new columns through a reduced-cost pricing subproblem at each planning epoch. It invested computation earlier, during available capacity, and stored reusable feasible structures. A dominance eliminator capable of removing the slower of two routes covering the same stop set exists in the code, but the relevant calls are disabled in the observed build. The resulting design preferred storage and reuse over aggressive compression of the library.

4.3 Concordance: a stored relation over routes

A second offline process built a relation between stored routes. Routes sharing stop structure were grouped, paired, deduplicated and annotated before insertion into a persistent concordance table. The implementation used bounded staging parameters of 500,000 rows and a one-million-row operational limit per commit phase [9]. These constants demonstrate intended batch scale, not the final production cardinality of the full relation.

Code evidence 4 – shared-stop grouping and pair materialization

SELECT ARRAY_AGG(id_combinacion_id ORDER BY id_combinacion_id),
       id_parada_id, p.politica_transbordos
FROM xsail_combinacionparadas
JOIN x_cat_puntos_parada p ON p.id = id_parada_id
WHERE orden > 0
GROUP BY id_parada_id, p.politica_transbordos;

for c1, c2 in combinations(group['combinaciones_concordantes'], 2):
    key = (c1, c2)
    obj = pair_cache.get(key) or CombinacionesConcordantesTmp(...)
    obj.paradas_coincidentes.append(group['id_parada_id'])

The important architectural point is that xSeil contained both explicit route objects and a second-order relation over route pairs. That relation is more structured than an unindexed Cartesian product: pairs arise from shared-stop incidence and may carry additional classifications. For later quantum research, the distinction between a materialized relation and an implicit relation that must be generated coherently will be decisive.

4.4 Scenario scoring and human authority

Planning scenarios stored explicit values for objectives including punctuality, direct service, unit savings, occupancy, policy compliance, short trips and travel time. The scoring routine read these scenario values and, for several objectives, derived a nonlinear exponent using the form value/300 + 1. A scenario value therefore influenced both the level of an objective contribution and the curvature applied to deviations [10].

The online planner added further state-dependent terms. Occupancy depended on current passengers and vehicle capacity; scarcity depended on remaining estimated seats and zone priority; isolation depended on the concurrent alternatives available for unresolved passenger groups. The total candidate score was not a timeless route coefficient. It was a function of the scenario and the current planning state.

Code evidence 5 – one human dial changes level and curvature

valor_puntualidad = self.__escenario.valor_puntualidad
valor_politicas   = self.__escenario.valor_politicas
exp_valor_puntualidad = (valor_puntualidad / 300) + 1
exp_valor_politicas   = (valor_politicas / 300) + 1
# transformed component: |x-mean|**exp * value / (2*std)

The repository supports human-configured scenario selection, not autonomous discovery of the correct objective weights. This allocation of authority is important: the system computed complete operational consequences under declared priorities, while accountable operators retained control of the scenario definition. The later technical companion should therefore avoid treating the human preference vector as an unknown automatically optimized quantum variable unless a separate governance model is specified.

4.5 Online allocation, bounded widening, and repair

Online planning was organized by operating time bands. For each band the planner retrieved candidate pickups, calculated scarcity and isolation, assembled the final score, sorted candidates, and allocated them sequentially. After a passenger assignment, occupancy and the total score of affected rows were recalculated before later decisions. This is a key property: the online process was adaptive and stateful, not a one-shot selection over fixed coefficients [11].

Code evidence 6 – state-dependent score and bounded escalation

row['puntuacion_total_final'] = (row['puntuacion_total']
    + row['puntuacion_directos_final'] + row['puntuacion_aislamiento']
    + row['puntuacion_lleno'] + row['puntuacion_escasez_unidades'])
pickups_franjas.set_value(Index, 'puntuacion_total_final',
                          row['puntuacion_total_final'])

for page in range(self.__pargeneral.limite_paginacion_planeacion):
    if page == 1: self.logger.warn('Modalidad: busqueda avanzada')
    ...
if len_llenos == 0: return CONST_REINTENTAR

When the normal candidate page was insufficient, the planner widened retrieval page by page up to a configured limit. Entering the second page was explicitly logged as advanced-search mode. Constraint failures could return a retry status or raise rollback-related exceptions, leading to band-level reconstruction. The search width was therefore governed and bounded; it did not expand without limit under operational pressure.

4.6 Dynamic route sheets and destination pacing

After initial planning, new or displaced passenger groups could be inserted into an active route only after a capacity check. If the origin stop was not already present, the dynamic-route module queried the persistent combination table for a route containing the required stop set, selected a short valid combination, and rebuilt the route sheet. The library thus acted as an operational oracle for local reconstruction, avoiding a new general route search on the live path [12].

Code evidence 7 - field-facing bounded pacing directive (xlogistics/daemon.py)

track['indice_saturacion_unidades'] = track.num_unidades / track.andenes_max
track['indice_saturacion_pasajeros'] = track.pax_franja / track.pax_max
track['indice'] = (track['indice_saturacion_pasajeros']
                   * track['indice_saturacion_unidades']
                   * track['indice_franja'])
mask = (track.indice_saturacion_unidades > 1)        | (track.indice_saturacion_pasajeros > 1)
...
hoja.status_hruta = (INCREMENTAR_VELOCIDAD if row.velocidad == up_speed
                      else DISMINUIR_VELOCIDAD)

A separate logistics daemon aggregated estimated arrivals by destination and time band. It calculated unit saturation, passenger saturation and a within-band position term, multiplied them into a composite index, moved one offending route to an adjacent band, and recomputed the board. When the procedure settled, it updated estimated arrival times and set route-sheet statuses instructing an increase or decrease of average speed with safety. The code establishes a field-facing control directive; it does not by itself establish direct mechanical actuation of vehicle controls [12].

5. Functional dependency and the quantum exclusion map

The functional inventory changes the quantum interpretation in an important way. The quantum candidate is not the enterprise system; it is a bounded residual kernel inside a functionally complete classical architecture. Better computation cannot repair inconsistent hotel identities, missing boarding events, an unavailable vehicle marked as ready, an undefined SLA, or an ungoverned reassignment. Those are semantic and organizational failures, not search-complexity failures.

Table 4. Problems excluded from direct quantum treatment and the residual surfaces that remain.

This boundary supplies three elements missing from generic quantum-logistics proposals: a coherent state z0, a defensible classical baseline, and an operational utility for the output. It also raises the evidentiary standard: a quantum method must outperform the cheapest adequate production method, including data preparation and integration cost, not an artificial brute-force baseline.

6. Architectural rationale

The design can be interpreted as a response to four simultaneous constraints.

Bounded latency. The hard value of a plan fell sharply after the operational issue time. Pre-validating route structures and retrieving them later converted part of the daily computation into an offline storage problem.

Auditability. Every stored route had passed the configured feasibility gates before allocation. Operators could inspect the structures and the business criteria that contributed to candidate scores.

Adaptive state. Because each assignment changed occupancy, scarcity and availability, the online loop needed to recompute local values rather than rely on a single static optimization model.

Controlled degradation. Bounded page widening, retry and rollback provided explicit responses when the normal candidate set was insufficient. Under pressure the system widened or reconstructed in governed steps rather than silently returning an infeasible plan.

These properties involve trade-offs. A persistent route library consumes storage and adapts less naturally to topology changes than dynamic generation. Sequential greedy allocation need not deliver the best static objective value. The architecture should therefore not be presented as universally superior to branch-and-price, adaptive large-neighborhood search, or modern mixed-integer approaches [3]. Its contribution lies in the way it combined precomputation, interpretability, human control, repair and field execution for a specific mission-critical regime.

7. Why this architecture is relevant to quantum research

The quantum relevance of xSeil does not follow merely from the fact that vehicle routing is hard. Quantum algorithms accelerate particular mathematical access models: finding marked states, estimating expectations, or exploring a specified Hamiltonian. A complete enterprise application cannot be placed in superposition as an undifferentiated object. The architecture is useful because it separates several candidate objects and makes their boundaries visible.

Table 5. Architectural features that motivate – but do not establish – later quantum formulations.

7.1 Native hybrid boundary

The offline route pool, concordance construction and scenario artefacts were created before the live allocation loop. This provides a natural location for batch experiments and avoids placing quantum turnaround time directly on the field-execution path. It does not solve state preparation. Any later quantum procedure must still account for the cost of preparing the relevant route, pair or perturbation distribution and, where required, implementing the inverse preparation operation [4,5].

7.2 Structured spaces rather than unstructured size

The route pool and concordance relation are highly structured. Routes are built by feasibility-pruned extension, while concordant pairs arise from shared-stop incidence. A quantum formulation that ignores this structure and searches the raw Cartesian space would compare poorly with classical indexing. The technical companion must therefore define a coherent index that preserves the useful classical structure rather than discarding it.

7.3 Fixed-instance extraction from adaptive control

The online planner recalculates scores after allocations and can widen, retry or roll back. These feedback loops violate the fixed-oracle assumption required by standard amplitude amplification and estimation. A valid quantum study must freeze an operational snapshot, a scenario, a candidate subset, a perturbation distribution and an event definition. The quantum object would then evaluate that fixed instance offline; the adaptive outer loop would remain classical.

7.4 End-to-end resource accounting

Grover-type amplitude amplification and quantum amplitude estimation offer ideal quadratic improvements in query complexity under suitable oracle access [4,5]. Those results do not price database extraction, state preparation, reversible arithmetic, error correction, repeated measurements, queueing, or the classical work needed to interpret the output. xSeil is useful precisely because these costs can be tied to concrete source objects. The companion paper should report end-to-end resources and allow a negative conclusion when overhead dominates.

8. Research handoff to the technical companion

The architecture supports four distinct technical work packages, which should not be forced into one generic quantum-advantage equation:

1. Candidate expectation estimation. Define a bounded stochastic score for a regime or planning candidate, with an explicit uncertainty distribution, and compare classical sampling with ideal amplitude-estimation resources.

2. Implicit rare-structure search. Define a new predicate over a coherently indexable route or route-pair space that is not already materialized in PostgreSQL.

3. Cascade-event probability estimation. Extract a deterministic, finite, side-effect-free event kernel from a frozen xSeil snapshot and estimate rollback or escalation probability under declared perturbations.

4. Frozen-state optimization benchmark. Construct a deliberately simplified route-selection or fleet-assignment instance and benchmark quantum-inspired, annealing, variational and strong classical methods without calling it the exact xSeil planner.

For each work package the technical paper must specify the input encoding, output requirement, classical baseline, hardness variable, state-preparation model, oracle or Hamiltonian, logical and fault-tolerant resources, and decision utility. This is the point at which claims about quantum advantage may be tested. The present paper supplies only the system substrate.

9. Limitations and claim boundaries

This is a retrospective of one industrial deployment written from the originating programme. The surviving repository strongly supports the architectural mechanisms, but it does not independently prove every historical throughput or business-impact claim. Reported passenger and candidate-volume figures are retained as project-record context rather than reproduced performance measurements. A future empirical paper should reconstruct database cardinalities and replay anonymized historical days.

The repository is a snapshot, not a complete software-lifecycle record. Some functions may represent intended, experimental, replaced or partially deployed behaviour. Code existence is therefore distinguished from observed operational use. The public whitepaper contains later conceptual language that is useful for interpretation but should not be back-projected into the 2016 code without a direct mapping.

No comparison with a modern branch-and-price, ALNS, mixed-integer or learning-based solver has yet been executed. No quantum advantage is claimed. The architecture supports research questions because it makes candidate objects concrete, not because its historical scale automatically defeats classical computing.

10. Conclusion

xSeil addressed a mission-critical logistics regime in which commercial demand was committed before planning, feasibility was non-negotiable, and local decisions changed the value and feasibility of later decisions. Its response was architectural: normalize operational data; precompute and persist feasible route structures; store relations between them; expose human-configured scenarios; allocate sequentially with state-dependent re-pricing; widen search only within governed bounds; repair or roll back when needed; and connect planning to dynamic route sheets and arrival pacing.

For quantum research, the value of the case is not a promise that a quantum computer should solve the whole application. It is the existence of a code-preserved system whose discrete spaces, stochastic questions, adaptive boundaries and output requirements can be separated and priced. The correct next step is a technical companion that turns selected surfaces into explicit objects and computes whether any ideal quadratic query improvement survives the cost of accessing and representing the deployed data structure.

References

[1] G. B. Dantzig and J. H. Ramser, “The Truck Dispatching Problem,” Management Science, vol. 6, no. 1, pp. 80-91, 1959. DOI: 10.1287/mnsc.6.1.80. https://pubsonline.informs.org/doi/10.1287/mnsc.6.1.80

[2] M. M. Solomon, “Algorithms for the Vehicle Routing and Scheduling Problems with Time Window Constraints,” Operations Research, vol. 35, no. 2, pp. 254-265, 1987. DOI: 10.1287/opre.35.2.254. https://pubsonline.informs.org/doi/10.1287/opre.35.2.254

[3] S. Ropke and D. Pisinger, “An Adaptive Large Neighborhood Search Heuristic for the Pickup and Delivery Problem with Time Windows,” Transportation Science, vol. 40, no. 4, pp. 455-472, 2006. DOI: 10.1287/trsc.1050.0135. https://pubsonline.informs.org/doi/10.1287/trsc.1050.0135

[4] G. Brassard, P. Høyer, M. Mosca and A. Tapp, “Quantum Amplitude Amplification and Estimation,” Contemporary Mathematics, vol. 305, pp. 53-74, 2002; preprint quant-ph/0005055. https://arxiv.org/abs/quant-ph/0005055

[5] A. Montanaro, “Quantum Speedup of Monte Carlo Methods,” Proceedings of the Royal Society A, vol. 471, 2015. arXiv:1504.06987. https://arxiv.org/abs/1504.06987

[6] JUBAP.Net, “xSeil Whitepaper: Operating Context, Architecture and Retrospective Interpretation,” public project record, accessed July 2026. https://jubap.net/jubap-net-xseil-whitepaper/

[7] xSeil source repository snapshot, archive dated 21 April 2018, controlled research copy; SHA-256 77bc819ae8746ec72216d00d2544a672ebc7114283459d3d58b189de586ce786.

[8] xSeil source evidence: apps/xplanner/algorithms/crear_combinaciones.py and crear_combinaciones_pd.py, feasible-route construction and optional dominance logic.

[9] xSeil source evidence: apps/xplanner/algorithms/crear_combinaciones_concordantes.py and apps/xsail/models/combinaciones.py, concordance construction and shared-stop grouping.

[10] xSeil source evidence: apps/xplanner/algorithms/calcular_puntuaciones_pickups_pd.py and apps/xsail/models/pargenerales.py, scenario values and nonlinear score exponents.

[11] xSeil source evidence: apps/xplanner/algorithms/planeacion.py and simular_planeacion.py, banded candidate retrieval, scoring, allocation, retry and simulation-related paths.

[12] xSeil source evidence: apps/hojadinamica/admin.py and apps/xlogistics/daemon.py, dynamic route reconstruction, saturation processing and route-sheet control statuses.

[13] Anexo Técnico 1, Descripción de tipo de componentes del sistema y sus entregables, October 2016; contractual taxonomy of screens, reports, catalogues, normalization, business analysis, architecture, design, internal logic, process analysis, and inherited components.

[14] Functionally Rich, Technologically Minimal: How Real Large-Scale Logistics Problems Were Solved With Simple Code, Paper IV draft v0.2.

[15] Paper IV Technical Code Annex: Verbatim Evidence for Functional Minimalism, v1; availability, rental estimation, isolation, reassignment governance, and fleet-stewardship code evidence.

Companion Paper I v2 – the technical quantum objects and resource models are intentionally reserved for Companion Paper II.

Companion Paper I v2 |