Tegrity.AI GroupJUBAP.Net

Large Problems Without Large Hardware

A contract-to-code study of business functions in a mission-critical logistics platform (2016-2017), reassessed in 2026

Ivan Abril Palma
Tegrity.AI Group
Working paper v2 – July 2026

Central question Did xSeil obtain a durable systems-engineering edge by allocating computation, data structures and human authority more efficiently – rather than by relying on exceptional hardware?

Abstract

This paper examines whether a large operational problem can be solved with a durable efficiency advantage even when the implementation has no exclusive hardware advantage. The case is xSeil, a mission-critical logistics platform deployed in 2016-2017. The evidence combines a contractual component taxonomy, a costed inventory of 178 line items, a 2017 delivery tracker, a surviving repository of 601 files (293 Python modules; 26,758 Python lines), and the published system description. Only 38 of the 178 costed items (21.3%) were classified contractually as internal logic or algorithm-analysis components; together they represented 37.9% of the historical estimated cost, while 62.1% concerned data structures, integration, screens, reports, architecture, inherited components, business analysis and related work. This composition does not prove comparative value, but it demonstrates that the computationally difficult planner was only one layer of the delivered system.

The code evidence shows a recurrent design pattern: use the smallest mechanism that fully closes a business function. Availability was a controlled state and a filter; rental sizing was a booking-curve ratio and a capacity division; passenger reality was closed through boarding/no-show state; SLA control was timestamp accounting; reassignment governance was a typed reason catalogue; congestion pacing was a bounded feedback loop; and expensive combinatorial work was precomputed, persisted and widened only when evidence required it. We call this functional efficiency: minimizing resource intensity per completed business function while meeting its correctness, deadline, auditability and safety conditions.

The paper concludes that xSeil’s durable edge is plausible but not yet demonstrated quantitatively against a modern 2026 implementation. The strongest candidate advantage is not raw execution speed; it is the avoidance of unnecessary computation, data movement and coordination through explicit semantics, closed loops, persistent decision memory and bounded adaptation. We propose a functional-unit benchmark and a replay programme capable of testing that proposition. A complete annex maps the system’s functional inventory to implementation mechanisms, code anchors and the relevance – or irrelevance – of advanced computation.

Keywords: functional efficiency; enterprise systems; logistics; software architecture; business functions; computational efficiency; contract-to-code traceability; closed-loop control; xSeil

Changes in version 2. This version adds material only; no claim of version 1 is removed. Additions: five recovered primary sources (S6–S10 in Section 2.2); repository provenance and an audit of a later third-party containerization port (Section 2.4); the measured production hardware envelope (Section 2.5); recovered operational scale evidence with explicit evidence classes (Section 2.6); an empirical note on the booking curve (Section 6.2); two additional limitations (Section 10); and references [P6]–[P10].

1. Research question and contribution

Modern discussions of computational advantage tend to compare processors, accelerators, FLOPs, model sizes or asymptotic algorithms. Operational systems are bought and judged differently: they must complete business functions under deadlines, imperfect data, legal constraints, human authority and field uncertainty. A system may therefore be computationally efficient in a business sense even when none of its individual algorithms is state of the art and none of its hardware is unique.

The question studied here is narrower than whether xSeil was technically sophisticated. It asks whether the system converted ordinary computing resources into operational capability unusually well. The paper contributes four things:

a contract-to-code empirical method that maps required functions to their actual mechanisms;

a distinction between hardware, algorithmic, architectural, operational and functional efficiency;

a cautious assessment of which xSeil mechanisms may still constitute an edge in 2026;

a functional-unit measurement protocol for testing the edge rather than asserting it.

The central claim is deliberately conditional: xSeil provides strong evidence of architectural economy and high functional leverage, but not yet a controlled proof of superior total efficiency against modern alternatives.

2. Case, sources and method

2.1 The case

xSeil was designed as an integrated logistics operating platform rather than a standalone vehicle-routing solver. It covered data acquisition and normalization, operational master data, fleet readiness, planning, rental estimation, field execution, live monitoring, route-sheet changes, transfer coordination, pacing and managerial reporting. The public system record describes a fully committed demand model: pickup time and location were committed at sale, capacities were hard, and operational changes could propagate through the remaining plan.

2.2 Primary evidence

2.3 Method

Each requirement is classified by contractual component type, functional family, core implementation mechanism and advanced-compute relevance. Code claims are anchored to surviving models, algorithms, SQL or workflow modules. Historical cost figures are used only to describe the structure of the contracted work. They are not treated as realized cost, profit, value or effort measures.

Evidence discipline: contract evidence establishes that a function was required; tracker evidence establishes reported delivery state; repository evidence establishes an implementation mechanism; public material establishes context; retrospective interpretation is labelled as such.

2.4 Repository provenance and the 2023 port

Two archives of the production repository survive. Snapshot A (S4, dated 21 April 2018; 601 files; SHA-256 77bc819ae8746ec72216d00d2544a672ebc7114283459d3d58b189de586ce786) is the production-era snapshot; every code claim and line reference in this paper is anchored to it. Snapshot B (S6, dated 28 January 2023; 671 files; SHA-256 c2de31a8f8de2ed146c9c1ee40dce870ee088ada9c460ce17df7c9a2be54edd2) is a later containerization of Snapshot A by a third-party developer, adding a Dockerfile, docker-compose configuration, pinned dependency locks and supervisor configuration.

A file-level audit establishes that the core planner modules cited by this research programme (planeacion.py, simular_planeacion.py, crear_combinaciones_concordantes.py, combinaciones.py, estimar_rentas.py, daemon.py, the constants module, motivoreasignacion.py and the dynamic route-sheet module) are byte-identical across both snapshots. The port nevertheless introduces at least three semantic divergences: (i) a mechanical schema rename corrupted a dataframe reference in the concurrency computation (pickups.pickup_id became public.pickup_id, an unconditional runtime error on that path); (ii) an exception-propagation change (raise replaced by logging) that silently alters failure and retry semantics; and (iii) a rewritten transfer-admissibility inequality in the hotel-transfer construction routine, changing which transfer triples are generated.

Three consequences follow. First, Snapshot A is the sole evidentiary and replay baseline; Snapshot B must not be executed as historical evidence without a defect audit. Second, the third divergence is itself analytically useful: it is a concrete instance of the difference between code history and intended rule, and a natural candidate for the semantic-repair arm of the replay programme described in the companion routing paper. Third, the existence of the port is weak but genuine evidence of revivability: an external developer could containerize the 26,758-line system with localized changes, most of which are mechanical (a Python reserved-word rename and a schema rename). The port additionally embeds new secrets (an API key and personal contact data) that reinforce the existing non-distribution rule for the raw repository.

2.5 The measured hardware envelope

The recovered benchmark workbook (S10) documents the hardware class on which the system actually ran: a production server with 20 CPUs and 252 GB of RAM, and a development server with 8 CPUs and 62 GB. It also records PostgreSQL pgbench measurements on ten-million-row tables of 121-byte rows over one million transactions: a read-only test at approximately 536 transactions per second (1.86 ms average latency) on production and approximately 1,105 transactions per second (0.90 ms) on development, with a corresponding write-and-read test. The development machine outperforming production on a read microbenchmark is a useful caution: these figures document the envelope and the team’s measurement practice, not a comparative hardware claim.

This sharpens the meaning of the title. “Without large hardware” does not mean under-provisioned hardware; it means a single well-provisioned commodity multi-core database server. There was no cluster, no distributed computing framework, no GPU and no accelerator. The million-scale route and concordance structures and the daily planning loads described in this paper ran, and were benchmarked by the team at ten-million-row scale, on one conventional machine. The claim defended in this paper is therefore precise: the leverage came from allocation of computation, data structures and human authority on ordinary infrastructure, not from exceptional or distributed infrastructure.

2.6 Recovered operational scale evidence

Planning was not one national computation. It executed per geographic operation (the Cancún operation, the Riviera Maya operations and the Xenses operation) and per time slot (morning and afternoon), so a daily passenger total is the sum over several planning instances [C for the operation and time-band structures, which are visible in code and configuration; O for the per-operation sheets]. Any comparison with published scale figures must respect this decomposition: a per-instance load and a daily total are different quantities.

The recovered artifacts establish the following. Booked demand (S9, class O): 10,679 passengers across 3,328 reservations for 4 July 2017, and 11,954 passengers across 3,605 reservations for 6 July 2017, spanning roughly 35 park and service codes and four geographic zones. Booking dynamics (S9, class O): 31–37% of final demand was captured two or more days before service, 56–59% on the day before, and 7–10% on the service day itself; because capture resolution is date-level, the fraction visible at the 18:00 planning cut is bounded between 31–37% and 90–93% rather than measured exactly. Executed volumes (S8, class O): the recovered pickup sheets for 1–8 August 2017 total approximately 6,100–9,000 passengers per day across the three recovered operation families, pickup direction only; one day (2 August) contains near-duplicate sheet versions that must be deduplicated, and the sheets do not cover the complete daily operation.

The operation’s daily scale was on the order of 10,000 passengers per day in high season, approximately 12,000 on busy days, and up to 15,000–17,000 on occasional peak days; a single planning instance — the Cancún morning slot — could alone reach 10,000–12,000 passengers on a peak day. The recovered artifacts are consistent with this scale: the 6 July 2017 booked total of 11,954 passengers directly matches the ~12,000-passenger figure.

The recovered demand days (July 2017) and the recovered executed days (August 2017) do not overlap, so no complete demand-to-plan pair exists yet. Recovering a SOX export for any day between 1 and 8 August 2017 would create the first fully matched instance for the replay programme.

3. Five meanings of efficiency

The distinction matters because hardware gains do not automatically become business gains. SPEC’s server benchmark reports large improvements in operations per watt over time, and algorithmic progress can multiply hardware progress. Yet data movement can cost orders of magnitude more energy than arithmetic, and tail latency can dominate the performance of large services. These findings point toward architecture and workload placement, not only faster chips. The Software Carbon Intensity standard is especially relevant because it measures emissions per functional unit. This paper generalizes the same denominator: compare resources per completed operational function, not merely per instruction or server transaction [1-6].

4. What the contractual inventory shows

The costed inventory contains 178 line items. The original taxonomy distinguishes screens (PA), reports (RE), catalogues/data structures (CAT), normalization and ETL (NO), business analysis (NEG), architecture and technology (TEC), visual design (DI), internal logic (LOG), analysis of alternative internal processes (AN), and inherited components (HER). LOG and AN together account for 38 items (21.3%) and 287.5 of 759.5 thousand historical MXN-equivalent estimate units (37.9%).

Figure 1. Historical estimated cost by contractual component type. Figures describe the 2016 proposal structure, not realized expenditure or value.

Two conclusions are justified. First, the platform was functionally broad: most requirements were not optimizer internals. Second, the contract explicitly treated data, interfaces, reports, architecture and operational design as deliverables in their own right. A stronger conclusion – that these items produced more economic value than the algorithms – requires usage, error, cost and outcome data and is not claimed here.

5. Mechanisms of functional efficiency

P1. Let the data model do the work

Controlled vocabularies, status machines and mandatory relations turn ambiguity into queryable state. Availability, reassignment reasons and maintenance governance are examples.

P2. Derive instead of synchronizing manually

A derived answer can eliminate a recurring reconciliation meeting. Unit availability and end-of-service position are examples.

P3. Close the loop before improving the estimator

Boarding and no-show capture make the state truthful. A simple forecast on closed-loop data can be more useful than a sophisticated model on stale data.

P4. Bank expensive computation

Feasible route structures and concordances were persisted offline so that online work became retrieval, scoring and bounded repair.

P5. Widen search only on evidence

The planner began with a narrow candidate page and entered advanced search only if no sufficiently full candidate existed, under a hard page cap.

P6. Keep accountable trade-offs human

The machine priced alternatives; a controller selected the scenario. Human authority prevented sensitivity in scalarization from becoming silent automation risk.

P7. Use attribution joins as management instruments

A report becomes actionable when it attaches cost or deviation to a reason, owner, unit, route or maintenance event.

P8. Prefer lightweight actuators

The pacing controller changed route-sheet status and audio cues rather than attempting direct vehicle control.

6. Representative code evidence

The examples below are intentionally small. Their purpose is not to imply that production delivery consisted only of these lines; integration, error handling, deployment and user work remain substantial. They show that the core business mechanism was often compact because the state model was explicit.

6.1 Availability as an enumerated state

apps/xsail/const/__init__.py; apps/xsail/models/unidades.py

STATUS_DISPONIBLE_CHOICES = (
    ('DIS', 'Disponible para Programacion de Transporte'),
    ('NDI', 'No disponible para programacion de transporte'),
    ('PRI', 'En Servicio Privado'),
    ('ACC', 'Accidente'),
    ('COR', 'Corralon')
)

status_disponible = models.CharField(
    max_length=3, choices=STATUS_DISPONIBLE_CHOICES, default='DIS')

The computational work is a filter. The systems-engineering work is the controlled state vocabulary, its writers and its history.

6.2 Rental estimation as a booking-curve ratio

apps/xplanner/algorithms/estimar_rentas.py

pax_promedio_hora[destino_id] = pax_promedio_df[mask].tot_pax.sum()
pax_promedio_totales[destino_id] = pax_promedio_df.tot_pax.sum()
pax_actuales_sum = pax_actuales[mask_actual].tot_pax.sum()

pax_estimados = (pax_actuales_sum * pax_promedio_totales[destino_id]
                  / pax_promedio_hora[destino_id])
units_needed = (pax_estimados * occupancy) / unit_type.seats

A modern forecast may improve accuracy, but it must be compared with this baseline per daily decision, including pipeline cost, deadline compliance and explainability.

Empirical note (2026 recovery). The recovered reservation exports (S9, Section 2.6) show why this estimator existed: only 31–37% of final demand was certain to be visible at the planning cut, and 7–10% of reservations arrived on the service day itself. The booking-curve ratio was not a convenience; it was the mechanism that made a defensible previous-evening rental decision possible at all, and the same-day arrival rate quantifies the real workload absorbed by the dynamic route-sheet function (Section 6.9).

6.3 Operational reality and care in the reservation model

apps/xsail/models/reservas.py

noshow = models.NullBooleanField(default=None, null=True)
goshow = models.NullBooleanField(default=None, null=True)
abordo = models.BooleanField(default=False)

discapacitados = models.PositiveSmallIntegerField(default=0)
# wheelchair reservation imported as two occupied seats

The same model closes the plan-reality loop and carries an accessibility rule into capacity feasibility.

6.4 Governance as a typed reason catalogue

apps/xsail/models/motivoreasignacion.py

class MotivoReasignacion(models.Model):
    class Meta:
        unique_together = [["tipo", "motivo"]]

    tipo = models.CharField(
        max_length=10,
        choices=CHOICES_TIPO_MOTIVOS_REASIGNACIONES,
        null=False)
    motivo = models.CharField(max_length=128, null=False)

The schema makes each deviation attributable. Reporting is subsequently a join and a group-by rather than a reconstruction exercise.

6.5 Topological isolation as a database operator

apps/xsail/models/pickups.py::get_concurrencias

WITH query_agrupadores AS (
    SELECT ARRAY_AGG(DAP.id_destino_agrupadores_id) agrupadores,
           DAP.id_pickup_id
    FROM xsail_PickUpsPlaneacion P
    JOIN xsail_DestinoAgrupadoresPlaneacion DAP
      ON P.id_pickup_id = DAP.id_pickup_id
    WHERE P.posible_lleno IS TRUE
    GROUP BY DAP.id_pickup_id
)
SELECT A.id_pickup_id, count(*) - 1 AS num_concurrencias
FROM query_agrupadores A
JOIN query_agrupadores B ON B.agrupadores <@ A.agrupadores
GROUP BY A.id_pickup_id;

The architectural idea is more important than the syntax: use the database’s set containment to expose whether a candidate is well connected or liable to become stranded.

6.6 Scenario dials set both price and curvature

apps/xplanner/algorithms/calcular_puntuaciones_pickups_pd.py

valor_puntualidad = escenario.valor_puntualidad
exp_valor_puntualidad = (valor_puntualidad / 300) + 1

df['puntuacion_puntualidad'] = (
    (abs(avg - df['puntuacion_puntualidad']) ** exp_valor_puntualidad)
    * valor_puntualidad / (2 * std)
) + valor_puntualidad

This is one of the genuinely algorithmic layers. A human-set scenario parameter affects both price level and nonlinear sensitivity.

6.7 Evidence-gated widening

apps/xplanner/algorithms/planeacion.py

for page in range(pargeneral.limite_paginacion_planeacion):
    candidates = get_better_pickups(..., page=page)
    if page == 1:
        logger.warn('Modalidad: busqueda avanzada')
    if any(candidates.porcentaje_lleno >= minimo_ocupacion):
        break

The system does not pay the broad-search cost unless the narrow search fails to produce a sufficiently occupied candidate.

6.8 Incremental ETA correction

apps/xlogistics/daemon.py

diferencia = retraso_real - retraso_estimado
ParadasHruta.objects.filter(
    id_hruta_id=hoja.pk,
    orden__gt=parada_actual.orden
).update(
    retraso_estimado=Q('retraso_estimado') + diferencia,
    hora_llegada_estimada=Q('hora_llegada_estimada') + diferencia,
    hora_salida_estimada=Q('hora_salida_estimada') + diferencia
)

The system updates only the remaining chain. This is architectural efficiency through incremental recomputation.

6.9 Dynamic route change through stored structure

apps/hojadinamica/admin.py::api_search_combination

if (hoja.pax_previstos + pax.tot_pax) > plazas:
    return SUPERA_PAX

paradas_ids.append(pax.id_parada_origen_id)
qs = Combinaciones.objects
for orden in range(len(set(paradas_ids))):
    qs = qs.filter(
        rel_combinaciones_paradas__id_parada_id__in=paradas_ids,
        rel_combinaciones_paradas__orden=orden)

best = DataFrame(list(qs.values())).drop_duplicates().sort_values('tiempo').iloc[0]

A live change is first checked against capacity and then resolved by searching the stored route substrate rather than rebuilding the entire planning problem.

6.10 Bounded pacing rather than direct autonomy

apps/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)

if row.velocidad == up_speed:
    hoja.status_hruta = INCREMENTAR_VELOCIDAD
else:
    hoja.status_hruta = DISMINUIR_VELOCIDAD

The controller moves one planned arrival at a time and emits a field-facing directive. It does not establish direct mechanical vehicle control.

7. Do these mechanisms constitute a real edge in 2026?

7.1 What is not an edge

The original Python/Django/PostgreSQL stack is not, by itself, a contemporary performance advantage.

Simple code is not automatically efficient; a short function may depend on expensive data preparation or a complex schema.

The surviving archive does not contain controlled energy, compute-cost or modern-baseline measurements.

Functional breadth does not prove that every function was heavily used or economically decisive.

7.2 What may be a durable edge

Semantic compression: business distinctions are encoded once in state machines and relations, reducing later computational and coordination work.

Computation placement: expensive enumeration is moved offline; online work is retrieval, incremental update and bounded repair.

Selective sophistication: advanced logic is reserved for the residual problems that actually need it, while ordinary functions use ordinary mechanisms.

Closed-loop truth: actual boarding, movement and status data prevent downstream models from optimizing a fictional state.

Deadline-aware sufficiency: the system optimizes within a fixed operational gate and stops widening once an acceptable candidate exists.

Controlled machine authority: high-sensitivity trade-offs remain visible to accountable operators.

These mechanisms remain relevant because modern hardware improvement and modern software complexity grow together. Faster hardware can mask inefficient architecture, but it does not remove integration, state definition, auditability or the cost of data movement. The likely xSeil edge is therefore a systems property: business utility obtained by refusing unnecessary computation and by using persistent semantics to make the necessary computation cheaper.

7.3 Provisional answer

Provisional answer: yes, xSeil shows a credible architectural-efficiency edge; no, the archive does not yet prove a quantitative total-resource advantage over a modern implementation. The edge should be treated as a testable hypothesis, not a historical superlative.

8. A functional-unit benchmark for testing the edge

A fair comparison must hold the business result constant. Inspired by functional-unit measurement in the Software Carbon Intensity standard, each benchmark should define one completed operational unit R and measure the resources required to deliver it.

8.1 Proposed metrics

8.2 Candidate functional units

8.3 Replay programme

Reconstruct three to ten historical operating days from surviving route sheets and demand records.

Instrument the original system or a faithful containerized reconstruction for CPU, memory, I/O, data movement and latency.

Build modern comparators: cloud-native implementation, modern OR solver, modern forecast, and where relevant an ML-enhanced version.

Hold functional units and acceptance criteria constant; do not compare raw throughput alone.

Report Pareto frontiers rather than a single weighted score: accuracy, deadline, energy, cost, auditability and human intervention.

Publish negative findings. If a modern system wins on every dimension, that is still a useful result.

9. Other research papers enabled by the evidence

1. Contract-to-code traceability as an empirical method

Study how contractual requirements become schemas, queries, algorithms and interfaces; propose a reproducible coding scheme for enterprise-system research.

2. The Minimum Sufficient Mechanism principle

For each business function, compare the simplest valid mechanism with progressively more sophisticated alternatives and identify the point of diminishing return.

3. Functional-unit benchmarking for enterprise software

Extend performance-per-watt and carbon-per-functional-unit concepts to operational decisions, including integration and human coordination.

4. Compute banking and deadline-aware architectures

Formalize when offline precomputation plus online retrieval dominates cold optimization under hard issue times.

5. Human authority as a computational resource

Examine whether scenario selection by accountable operators reduces unsafe search, specification risk and the need for expensive automated discrimination.

6. Semantic complexity versus computational complexity

Separate problems whose difficulty lies in defining state and meaning from those that genuinely require large search or estimation budgets.

7. Attribution joins as organizational control

Study how cause-linked data models change managerial action even when the underlying analytics are simple.

8. Functional completeness as a prerequisite for AI or quantum advantage

Show that advanced computation is valuable only after the classical system has produced coherent inputs, constraints, utility and action semantics.

The strongest immediate paper after this one is likely the Minimum Sufficient Mechanism study. It can be tested experimentally on rental estimation, availability, ETA propagation and dynamic route insertion, each of which has a clear simple baseline and a plausible modern alternative.

10. Limitations

Single principal deployment and an originating-group retrospective.

Historical proposal cost estimates are not realized costs and cannot measure value-per-line or return on investment.

The delivery tracker uses project-status conventions that require source interpretation.

The code snapshot post-dates initial deployment and may include later changes or incomplete modules.

Several published conceptual interpretations are broader than the code evidence; this paper relies on code for implementation claims.

No direct 2026 benchmark has yet been run, so present-day advantage remains a hypothesis.

The 2023 repository port (S6) is not semantically faithful to the production snapshot; it must not be used as an evidentiary or replay baseline without the defect audit of Section 2.4. Documents and artifacts recovered from inside it are evaluated on their own provenance.

Recovered booked-demand days (July 2017) and recovered executed-plan days (August 2017) do not overlap, and executed sheets cover only part of each day’s operation; a fully matched demand-to-plan instance therefore remains to be assembled for the replay programme.

11. Conclusion

xSeil demonstrates that a large problem does not require every function to be computationally large. Its architecture concentrated sophisticated computation in a limited planning core and used schemas, joins, ratios, incremental updates, persistent libraries and bounded control for much of the remaining platform. The practical intelligence of the system was therefore distributed across the functional inventory, not concentrated in one optimizer.

The case supports a more useful definition of software efficiency: the resources consumed per verified business function under the real operational envelope. Under that definition, xSeil may retain a genuine edge today because it reduced the amount of computation that had to occur at all. The evidence is strong enough to justify the hypothesis and a rigorous benchmark, but not strong enough to declare victory before the benchmark is performed.

References and primary sources

[P1] Technical Annex 1: Component Types and Deliverables, October 2016.

[P2] xSeil Costed Functional Inventory / Technical Annex 2, 2016.

[P3] xSeil Delivery Tracker, February 2017.

[P4] xSeil production repository snapshot, 21 April 2018.

[P5] JUBAP.Net, xSeil Whitepaper: Operating Context and Technical Solution Architecture.

[P6] Second xSeil repository archive (containerization port), 28 January 2023. Provenance and divergence audit in Section 2.4.

[P7] xSeil contemporary design-document corpus, 2016–2017 (62 files recovered within [P6]): function specifications, implementation manuals and process descriptions.

[P8] Executed operation route sheets, Cancún and Riviera Maya operations, 1–8 August 2017.

[P9] SOX reservation exports for service days 4 and 6 July 2017 (legacy system of record; personal data, anonymization required).

[P10] xSeil production benchmark workbook (“test performance”): server envelopes and PostgreSQL pgbench measurements, 2016–2017.

[1] Green Software Foundation, Software Carbon Intensity Specification, ISO/IEC 21031:2024.

[2] Standard Performance Evaluation Corporation, SPECpower_ssj2008 benchmark and Power History.

[3] L. A. Barroso and U. Holzle, The Case for Energy-Proportional Computing, IEEE Computer, 2007.

[4] J. Dean and L. A. Barroso, The Tail at Scale, Communications of the ACM, 2013.

[5] M. Horowitz, Computing’s Energy Problem (and What We Can Do About It), ISSCC, 2014.

[6] D. Hernandez and T. B. Brown, Measuring the Algorithmic Efficiency of Neural Networks, 2020.

[7] F. P. Brooks, No Silver Bullet: Essence and Accidents of Software Engineering, IEEE Computer, 1987.

Annex A. Complete functionality-to-mechanism matrix

The matrix contains the 178 costed 2016 line items plus 52 non-duplicate extensions or clarifications from the February 2017 tracker. Implementation mechanisms are concise research classifications, not claims that the cited snippet alone delivered the complete function. ‘Advanced compute relevance’ indicates whether additional search, statistical or optimization capability could plausibly improve the core mechanism; it does not imply quantum relevance or advantage.

Annex B. Expanded code and architecture evidence

This annex preserves the most useful code-level examples in one place. Excerpts are lightly shortened for readability; deployed identifiers are retained. The complete repository remains the system of record.

B1. Unit and maintenance states

apps/xsail/const/__init__.py

STATUS_MANTTO_CHOICES = (
    ('MNO', 'No Establecido'),
    ('MAN', 'Realizando Mantenimiento'),
    ('DIA', 'Mantenimiento al dia'),
    ('REA', 'Esperando Reagendar Mantenimiento'),
    ('MPR', 'Cita Mantenimiento Proxima')
)
STATUS_DISPONIBLE_CHOICES = (
    ('DIS', 'Disponible para Programacion de Transporte'),
    ('NDI', 'No disponible para programacion de transporte'),
    ('PRI', 'En Servicio Privado'),
    ('ACC', 'Accidente'),
    ('COR', 'Corralon')
)

Availability and fleet stewardship are represented as controlled state, enabling filters, security rules and histories.

B2. Boarding and accessibility

apps/xsail/models/reservas.py

noshow = models.NullBooleanField(default=None, null=True)
goshow = models.NullBooleanField(default=None, null=True)
abordo = models.BooleanField(default=False)
gestionada = models.BooleanField(default=True)

discapacitados = models.PositiveSmallIntegerField(default=0)
# imported wheelchair flag reserves two seats

A few fields close the actual-demand loop and carry a care constraint into capacity arithmetic.

B3. Boarding-time constants

apps/xsail/models/tiemposembarque.py

class TiemposEmbarque(models.Model):
    id_punto_carga = models.ForeignKey('PuntosParada', ...)
    embarque_med = models.DurationField(null=False)
    pax_med = models.PositiveIntegerField()
    tiempo_pax = models.DurationField(
        help_text='Tiempo promedio adicional por pasajero')

A physical act – boarding and wristband handling – becomes a route-time parameter rather than an informal assumption.

B4. Rental estimation

apps/xplanner/algorithms/estimar_rentas.py

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

The core estimator is compact and auditable; production complexity is mainly integration, grouping and resilience.

B5. Reassignment vocabulary

apps/xsail/models/motivoreasignacion.py

class Meta:
    unique_together = [["tipo", "motivo"]]

tipo = models.CharField(
    max_length=10,
    choices=CHOICES_TIPO_MOTIVOS_REASIGNACIONES,
    null=False)
motivo = models.CharField(max_length=128, null=False)

A schema constraint turns deviations into attributable, reportable management events.

B6. Isolation query

apps/xsail/models/pickups.py::get_concurrencias

SELECT A.id_pickup_id,
       count(*) - 1 AS num_concurrencias,
       ARRAY_AGG(B.id_pickup_id) AS pickups_concurrentes
FROM query_agrupadores A
JOIN query_agrupadores B
  ON B.agrupadores <@ A.agrupadores
GROUP BY A.id_pickup_id

PostgreSQL set containment supplies a topological signal without a separate graph-processing stack.

B7. Scenario curvature

apps/xplanner/algorithms/calcular_puntuaciones_pickups_pd.py

exp_valor_puntualidad = (valor_puntualidad / 300) + 1
exp_valor_ahorro_unidades = (valor_ahorro_unidades / 300) + 1

df['puntuacion_puntualidad'] = (
    abs(avg - df['puntuacion_puntualidad']) ** exp_valor_puntualidad
) * valor_puntualidad / (2 * std) + valor_puntualidad

The planner’s more sophisticated layer transforms human scenario choices into nonlinear objective prices.

B8. Master price and in-loop repricing

apps/xplanner/algorithms/planeacion.py

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'])

Scores are not merely computed once; state-dependent components are updated as the allocation consumes resources.

B9. Bounded search escalation

apps/xplanner/algorithms/planeacion.py

ret = CONST_REINTENTAR
while ret == CONST_REINTENTAR:
    for page in range(limite_paginacion_planeacion):
        candidates = get_better_pickups(..., page=page)
        if page == 1:
            logger.warn('busqueda avanzada')
        if any(candidates.porcentaje_lleno >= minimo_ocupacion):
            break

The normal path remains narrow; search expands only on evidence and remains capped.

B10. ETA correction from a real event

apps/xlogistics/daemon.py

diferencia = paradahruta.retraso_real - paradahruta.retraso_estimado
ParadasHruta.objects.filter(
    id_hruta_id=h.pk,
    orden__gt=paradahruta.orden
).update(
    retraso_estimado=Q('retraso_estimado') + diferencia,
    hora_llegada_estimada=Q('hora_llegada_estimada') + diferencia,
    hora_salida_estimada=Q('hora_salida_estimada') + diferencia)

A detected delay is propagated only over the remaining route, avoiding full recomputation.

B11. Dynamic route insertion

apps/hojadinamica/admin.py::api_search_combination

if (hoja.pax_previstos + paxs.tot_pax) > plazas:
    return SUPERA_PAX

paradas_ids.append(paxs.id_parada_origen_id)
qs = Combinaciones.objects
for orden in range(len(set(paradas_ids))):
    qs = qs.filter(
        rel_combinaciones_paradas__id_parada_id__in=paradas_ids,
        rel_combinaciones_paradas__orden=orden)

best = DataFrame(list(qs.values()))        .drop_duplicates().sort_values(['tiempo']).iloc[0]

The route library acts as an insertion oracle for a live operational change.

B12. Pacing indices and field directive

apps/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)

hoja.status_hruta = (INCREMENTAR_VELOCIDAD
    if row.velocidad == up_speed else DISMINUIR_VELOCIDAD)

The controller changes a route-sheet state consumed by the field interface; the evidence does not establish direct mechanical actuation.

Annex C. Recommended empirical study design