A practical logistics system can calculate thousands or millions of technical possibilities while still leaving the most important decision to people: which competing operational objectives deserve priority. xSeil combined a reusable library of feasible route structures, scenario-dependent mathematical scoring, human selection of acceptable trade-offs, and iterative allocation that recalculated the consequences of each commitment. The result was an operational decision architecture connecting planning, vehicle resources, passengers and real-world execution.

Abstract

Developed for Experiencias Xcaret/Xtours in the Mexican Caribbean during 2016–2017, xSeil addressed passenger transport in which reservations became binding service commitments before the final demand and available fleet were fully known. The problem joined hard pickup times, indivisible passenger groups, a heterogeneous fleet, direct and multi-leg service, transfer rules, service-specific policies, destination capacity and changing field conditions. Its practical solution was not a single static route optimization. It prepared and stored feasible combinations, used named planning scenarios to express competing operational priorities, ranked scenario-specific pickup candidates, and committed resources sequentially while repricing the remaining opportunities. Human planners could compare alternatives and govern the balance among punctuality, policy compliance, occupancy, direct trips, vehicle use and journey time. Dynamic route sheets, field telemetry, exception handling and bounded repair kept computation connected to execution. This article reconstructs those capabilities from original functional requirements, preserved source-code analyses and recovered operational evidence, and explains their architectural value for contemporary adaptive systems. [1–7]

Keywords: xSeil; scenario-based planning; multi-objective optimization; Pareto-oriented trade-offs; human-in-the-loop decision support; committed demand; rich vehicle routing; persistent route memory; computational steering; operational orchestration.

1. The operating problem: every pickup was already a promise

The fundamental difficulty was the order in which commercial commitments and transport information became available. Tickets were sold through a distributed network of hotels, resellers and other channels. A sale fixed the pickup location and time as part of the promised service. The transport operation then had to reconcile these commitments with fleet capacity, vehicle availability, transfer policies and the evolving day. It could not treat excess demand as ordinary uncommitted demand or routinely defer passengers to the next scheduled bus. [2,3]

The network covered a long Cancún–Riviera Maya corridor with hundreds of hotels and pickup points and multiple parks and destinations. Vehicles differed in capacity, operating role, availability and ownership or rental status. One physical vehicle could serve successive trips if the sequence was feasible. Passenger groups had to remain operationally intact. Transfers could occur through several permitted types of points, but required connection and policy compatibility. A locally attractive assignment could consume seats, time or future positioning needed to honour another commitment. [2,3]

The planning problem was therefore a constrained, state-changing system rather than an isolated shortest-path calculation. The business objective was to maintain a feasible and acceptable day of service under changing demand while using expensive transport capacity responsibly.

1.1 Hard constraints and competing objectives

• Hard service conditions: seating capacity, non-standing passengers, pickup-time logic, valid travel links, indivisible passenger groups, vehicle sequencing, permitted transfers and route-duration bounds.
• Operational preferences: high punctuality, direct service, occupancy, fewer vehicles, fewer or shorter journeys, travel-time reduction and adherence to more detailed service policies.
• System-level effects: arrival congestion at destinations, rental requirements, vehicle scarcity by zone, maintenance/readiness states, traffic deviation and later reservations.

These dimensions interact. Using fewer vehicles can increase occupancy but extend passenger journeys. Maximizing direct service can consume capacity that a transfer-based solution would share. A punctual arrival can still overload the receiving area when many vehicles arrive together. The planner had to keep the distinction between admissible operations and desirable outcomes explicit. [3,4]

2. An integrated operational architecture

xSeil was built as an end-to-end logistics intelligence platform. The route planner was one component of an architecture that acquired and normalized reservations, maintained an operational world model, calculated and compared plans, generated executable route sheets, followed field operations, and supported reassignment. The principal historical stack combined Linux/POSIX, Python, Django and PostgreSQL with central web-based control interfaces and Android/iOS field clients. SOX supplied reservation and operational records; GeoTab and mobile records supported positioning, geofence events and execution state. [2,5]

2.1 Information and application layers

• Integration and normalization: imports from SOX and other systems, reference mapping, validity checks, inconsistent-record filtering and changing API/data-source boundaries.
• Operational model: passengers and reservation groups; hotels, stops, parks and service types; vehicle capacity, status, base and role; time links; pickup and boarding parameters; transfer permissions; route-sheet objects.
• Planning and simulation: route-combination creation, pickup construction, scenario parameters, score transformations, candidate retrieval, allocation and rental forecasts.
• Execution and control: generated route sheets; mobile guide/driver interactions; geofence and passenger events; deviation propagation; dynamic route changes; destination pacing.
• Management intelligence: punctuality, occupancy, direct versus transfer movements, unit utilization, reassignment history and other planning/actual comparisons.

Data quality was a computational prerequisite. A mathematically feasible route would not be executable if a reservation referenced an invalid stop, vehicle status was stale or a transfer policy was lost in integration. The middleware therefore formed part of the operational decision system, not merely a surrounding data feed. [2,5]

3. Persistent computation before the planning deadline

A major engineering decision was to separate expensive structural feasibility work from time-critical operating decisions. xSeil constructed feasible stop sequences level by level, applying time-link, duration, repetition, pickup and delay checks before persisting accepted combinations. It also stored relations among routes sharing stops and generated candidate pickup/service structures. Online planning could retrieve these prepared objects instead of rebuilding every route from an empty state. [3,5]

The persistent route library was bounded by configured topology and policies. Its strength was reusable, prevalidated structure. The architecture invested machine time ahead of the operational decision window and thereby converted preparation into faster candidate retrieval, scoring and local repair.

# Readable reconstruction of the stored-route generation
pool = feasible_single_stop_sequences()
for depth in configured_stop_depths:
    for sequence in pool[depth - 1]:
        for stop in compatible_extensions(sequence):
            route = append(sequence, stop)
            if valid_links_times_policies(route):
                persist_route_with_stops_times_and_parent(route)
                pool[depth].add(route)
    if not pool[depth]:
        break

The source objects include crear_combinaciones.py, crear_combinaciones_pd.py, Combinaciones, CombinacionParadas and crear_combinaciones_concordantes.py. The latter materialized shared-stop route-pair relations in bounded batches. The resulting substrate supported both planned allocation and later reconstruction of an active route when a new passenger group needed insertion. [3,5]

3.1 How this reduced live computation

• Structural feasibility could be computed and validated before the daily decision window.
• Scenario-specific candidate scoring reused persistent combinations rather than constructing the full route universe for every weighting choice.
• Indexed and materialized candidate structures supported retrieval within operation and time bands.
• Dynamic insertion could consult an existing feasible combination to rebuild an affected route sheet.
• Search widened only when the normal candidate scope was insufficient, subject to configured limits.

This approach can be described as computational preparation or persistent route memory. The term “compute banking” is a useful later name for the principle: reserve expensive computations for reusable structure, and spend limited online time on state-specific decisions. [3]

4. Scenarios as a human–machine planning interface

The scenario mechanism addressed two problems at once. Operationally, no single mathematical objective captured every acceptable trade-off. Computationally, evaluating all feasible combinations under every possible priority balance during the active planning window was impractical. xSeil gave the control centre a shared decision surface: named objective configurations that could be calculated, compared, accepted and then used to guide the continuing allocation process. [4,7]

The June 2016 functional proposal described statistical estimation and an AI planning algorithm producing alternative combinations and selecting three planning scenarios for presentation. The February 2017 Technical Annex subsequently described distinct planning scenarios, planning parameters, planning indicators and learning from scenarios selected as better. These are historical features of the design, rather than concepts added by later AI research. [4,7]

4.1 A finite budget of operational priorities

In the preserved data model, ParGenerales and Escenarios defined named values for punctuality, policy compliance, vehicle savings, occupancy, direct journeys, short trips and travel time. Configurations were stored in x_par_escenarios. The administrative formset enforced a combined priority ceiling of 100; client-side controls showed the remaining budget as values were assigned. The interface made the tension among priorities visible. [5,8]

Figure 2 illustrates the operational priority profiles and the trade-offs evaluated by the control centre.

Different weight configurations could favor different feasible plans. A punctuality-oriented configuration could use additional vehicle capacity to protect a pickup promise. A utilization-oriented configuration might improve occupancy through more shared movements. A direct-service configuration might prioritize fewer transfers at a cost elsewhere in the KPI vector. The decision was about the operating policy embodied by the plan, not merely a preferred route drawing.

4.2 What makes the trade-off Pareto-oriented

In multi-objective optimization, a plan is nondominated within a feasible candidate set when no other candidate improves one measured objective without worsening at least one other. xSeil’s design exposed alternative operational compromises of this kind to people, while its implemented computation used explicit scenario weights, nonlinear scoring and state-dependent sequential choice. The practical objective was to present high-quality, interpretable alternatives near useful trade-off regions and then produce an executable plan under the chosen priorities.

The historically implemented planning mechanism is best characterized as multi-objective scenario-based optimization with heuristic allocation. A formal nondominance test can be applied to the final raw KPI vectors when running the historical replay; the scenario comparison and scoring mechanism itself is directly visible in the retained software. [3,5]

4.3 The priority dial also changed penalty curvature

One distinctive implementation detail is that a human-set priority affected not only the amount assigned to a criterion but, for several criteria, the shape of its penalty. The scoring routine derived an exponent from the selected value. In simplified notation:

eᵢ = 1 + wᵢ / 300

Here wᵢ is the scenario value for objective i. A higher priority could make large deviations more costly relative to small deviations. This is particularly relevant for punctuality and policy penalties, where an operator may care disproportionately about serious breaches rather than small variation. The public code evidence shows the expressions in calcular_puntuaciones_pickups_pd.py. [5]

# Short code-grounded examples of scenario 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

4.4 Scenarios were computational steering

The scenario selection also influenced where live computational work was spent. Persistent structures had already reduced expensive route-generation work. Historical/statistical estimates and the planning-parameter layer narrowed plausible operating conditions. Scenario-specific weights then valued candidates under an accepted operational perspective. Once an operator selected the scenario, online planning concentrated on retrieval, scoring, committing and repairing solutions within that frame rather than exploring every possible objective balance afresh. [7,9]

This is an important distinction from a simple explanatory dashboard. The scenarios were part of the planning computation and its allocation of search effort. They represented the meeting point between human judgment about what matters and the machine’s capacity to evaluate combinatorial consequences.

5. Sequential commitment: the engine continued after human choice

Selecting a scenario did not conclude planning. It established the trade-off frame within which the allocation engine had to construct an executable operating plan. The planner then processed candidate pickups by operation and time band, calculated dynamic scores, selected feasible high-ranked candidates and committed passenger groups and vehicle resources. Each commitment changed the remaining problem. [3,5]

5.1 The state-dependent score

The public technical reconstruction expresses a candidate’s total value as a function of the selected scenario and current state:

Sᵣ(θ, zₖ) = Bᵣ(θ) + Dᵣ(zₖ) + Iᵣ(zₖ) + Oᵣ(zₖ) + Eᵣ(zₖ)

Here θ denotes the human-selected scenario and zₖ the system after k commitments. The base term reflects scenario priorities; additional terms capture directness, isolation of passenger groups, occupancy and scarcity. As seats, vehicles, routes and times are consumed, the valuation of remaining candidates changes. A route that was attractive before one commitment may be less valuable afterward. [3]

The planning code assembled a final candidate score from scenario-derived scoring and dynamic contributions such as direct-trip adjustment, isolation, fullness and unit scarcity. This structure was recalculated for affected rows inside the allocation process.

5.2 A readable reconstruction of the planning loop

scenario = load_selected_scenario()
state = load_demand_fleet_and_time_bands()
for band in operating_bands:
    candidates = retrieve_scenario_scored_pickups(band, scenario)
    while unassigned_groups_remain(band):
        update_occupancy_isolation_and_scarcity(candidates, state)
        choice = select_high_scoring_feasible_candidate(candidates)
        commit_complete_passenger_groups_and_vehicle(choice, state)
        update_seats_times_vehicle_positions_and_compatibility(state)
        reprice_affected_remaining_candidates(candidates, state)
        if normal_candidate_scope_is_insufficient():
            retry_or_widen_search_within_configured_bounds()
    persist_route_sheets_and_scenario_results()

This pseudocode expresses the retained planning sequence in readable form. The key code paths are apps/xplanner/algorithms/planeacion.py, calcular_puntuaciones_pickups_pd.py, the candidate builders and scenario models. [3,5]

5.3 Passenger groups were atomic

When a proposed vehicle allocation exceeded available capacity, the algorithm could remove complete compatible groups from that coalition, recalculate occupancy and evaluate the revised candidate. The passenger group itself was not fractionally divided simply to fit seats. Multi-leg transfers preserved group identity while joining compatible vehicle movements. This distinction mattered operationally and mathematically because the planning unit was a service commitment, not a divisible commodity. [3]

5.4 Resource decisions were economically connected

Fleet assignment considered operation, date, base, vehicle type and available-from time. The system also estimated rental requirements from reservation progress and historical booking curves. The code reconstruction shows a preference to use rented vehicles already acquired before consuming owned capacity when compatible. A rental decision from the previous evening therefore influenced the next day’s marginal allocation, preventing committed capacity from unnecessarily remaining idle. [3,5]

6. Simulation, comparison and learning

The scenario mechanism was connected to planning and simulation workflows. Forms required an escenario_id; batch planning commands could accept repeated scenario identifiers; and an administrative estimation interface compared selected scenarios against expected vehicle requirements. The platform therefore supported comparison of planning frames, not merely storage of alternative configuration names. [7,8]

The functional inventory also contained A193, “Diferentes escenarios de planeación,” and A194, “Aprendizaje automático para ir determinando parámetros de la planeación (en base a los escenarios que seleccionaron como mejores).” This established the intended continuity from scenario selection to improved planning parameters. The retained reconstruction gives direct access to scenario weights, results and historical estimation; the precise learning model is a separate source-code trace within that functional design. [4,7]

6.1 Two different feedback horizons

• Within a planning run: every allocation updates the residual state and causes the remaining choices to be re-evaluated.
• Across planning scenarios and operating days: preferred configurations, stored KPIs and historical demand patterns supply the basis for parameter refinement and future estimation.

These horizons should remain distinct. The first is an observable, stateful allocation loop. The second concerns historical learning and parameter selection across experiences. Together they explain how a human choice could guide an immediate computation and also inform the architecture’s longer-term improvement path.

7. Bounded repair and live replanning

A complete operating plan could encounter insufficient compatible capacity, last-minute reservations or disruption. xSeil treated those as explicit planning conditions. When the normal candidate page did not supply an acceptable allocation, the planner could widen retrieval through configured pages, enter an advanced-search path and retry a time band. Failures could trigger rollback and reconstruction. Search width and escalation remained bounded by operational limits, rather than consuming indefinite computation. [3,5]

The dynamic-route subsystem could also handle a new passenger group by inspecting active route sheets with available seats, consulting the persistent combination library for a compatible stop sequence, and rebuilding the affected route chain. This reuse connected the offline route memory directly to field change management. [3]

7.1 Why bounded computation mattered

The requirement was not simply to achieve a mathematically impressive result. The transport organization needed a route sheet by the planning deadline, plus a coherent way to respond when that sheet no longer matched reality. Bounded search, fallback and local reconstruction gave the algorithm an operational discipline: obtain a feasible incumbent, update its consequences as commitments are made, and escalate in a controlled way when ordinary candidates are insufficient.

8. Closing the loop with physical execution

xSeil extended beyond overnight planning into operating control. Mobile users recorded vehicle and passenger events. Geofence and positioning information supported comparison of actual movement against planned stops and promised times. When real delay was detected, the system could propagate its effect to downstream route timing, updating the expected operating state. [2,6]

A destination pacing process aggregated expected arrivals by destination and time band, compared unit and passenger pressure with receiving capacity, and iteratively adjusted selected vehicle arrival expectations. The process recalculated the board after each proposed adjustment and issued bounded speed-up or slow-down status directives through the operational route-sheet mechanism. This was centralized, narrow operational actuation connected to an observable control loop. [6]

8.1 The recurring decision pattern

The recurring structure matters: local decisions were evaluated in terms of their effects on the rest of the system. It allowed an operational team to plan in advance without assuming that the physical day would remain unchanged.

9. Explainability as operational governance

The historical explainability mechanism was practical rather than conversational. Operators could work with named objectives, explicit priorities, constraints, scenarios and resulting operational KPIs. They could ask what happened to punctuality, occupancy, direct service or required fleet capacity when a priority changed. The platform computed consequences that could not reasonably be enumerated by a human planning team, while people retained authority over acceptable operational compromises. [7,9]

This transparency had a second effect. Experienced planners often carried tacit knowledge about exceptions: which apparently absolute rules were genuinely hard, which had conditional tolerances and which could be relaxed under a particular circumstance. Computational planning required those distinctions to become represented. An exception that previously occurred informally became a visible choice among service, policy and resource consequences.

The human contribution therefore extended beyond approving a proposed plan. Operators supplied the contextual meaning of constraints and could challenge the assumptions behind a scenario. Making tacit compromises explicit also made those decisions more consistent, comparable and accountable. This was an organizational as well as computational capability.

10. Operational scale and preserved evidence

The recovered archive connects the conceptual architecture to a substantial operating environment. Preserved SOX exports for 4 and 6 July 2017 contain 3,328 and 3,605 reservations respectively, corresponding to 10,679 and 11,954 booked passengers. In those two samples, approximately 7–10% of reservations were created on the day of service itself. This confirms that planning and execution had to absorb demand arriving after the advance-planning horizon. [6]

Executed route sheets from 1–8 August 2017 document the movement structures produced by the operating system. The recovered operation families account for approximately 6,100–9,000 pickup passengers per day in those sheets, representing the recovered subset of the operation rather than a complete daily total. The artifacts also show multi-destination movements and sequential trips performed by the same vehicle. [6]

The wider preserved technical record includes a 2016 process and architecture baseline, intensive 2017 development and validation, a 2018 handover trail, registered code archives and later code-grounded reconstruction. The provenance inventory identifies 1,373 distinct GitLab commits across references, six branches and 242 issues, with the root commit dated 13 March 2017. These anchors support technical traceability from requirement to source mechanism and operating artifact. [1]

10.1 Performance in its proper operating context

Performance should be understood across several dimensions: ability to produce feasible committed-demand plans; reuse of prevalidated structures within deadlines; need for additional rented vehicles; punctuality and passenger journey quality; capacity and transfer effects; replanning effort; and continuity of field execution. The recovered repository establishes the mechanisms that supported those outcomes, while the reservation and route-sheet artifacts establish operational scale.

The code also exposes substantial computational engineering: batched route generation, persistent SQL structures, scenario-specific scoring, in-memory candidate valuation and partial recomputation after state changes. Its functional efficiency came from carefully representing the problem, reusing its structure and governing the search process.

11. Code and functional traceability

The following implementation map identifies the main retained source objects relevant to scenario-oriented computation. Names reflect the preserved xSeil repository and the 2026 technical/code review. [3–5,8]

• apps/xsail/models/pargenerales.py — named scenario values, general parameters, and the Escenarios model backed by x_par_escenarios.
• apps/xsail/admin/pargeneralesadmin.py and apps/xsail/src/pargenerales/js/parGenerales.js — operator editing and finite priority-budget validation.
• apps/xplanner/algorithms/crear_combinaciones.py and crear_combinaciones_pd.py — persistent level-wise construction of feasible stop sequences.
• apps/xplanner/algorithms/crear_combinaciones_concordantes.py — shared-stop compatibility relation over stored routes.
• apps/xplanner/algorithms/crear_pickups.py — pickup candidates and base metrics for service, policy, timing, directness and route structure.
• apps/xplanner/algorithms/calcular_puntuaciones_pickups_pd.py — scenario-dependent score components and nonlinear penalty exponents.
• apps/xplanner/algorithms/planeacion.py — time-band candidate retrieval, dynamic scoring, sequential allocation, repricing, retry and bounded widening.
• apps/xplanner/forms.py and range-planning commands — scenario identifiers in planning and comparative simulation.
• apps/xplanner/algorithms/estimar_rentas.py — estimated remaining demand and vehicle-rental requirements.
• apps/hojadinamica/admin.py — capacity-aware insertion and reconstruction of active route sheets.
• apps/xlogistics/daemon.py — destination-arrival pacing, saturation assessment and bounded operational directives.

11.1 Historical requirements that established scenario governance

• A042 (2016): planning indicator summary, including units, passengers by route, occupancy, direct service, punctuality SLA and algorithm processing time.
• A146–A147 (2016): alternative schedule-optimization scenarios and their presentation.
• A191 (2017): additional optimization parameters for stops, transfers, journey time and selected vehicle use.
• A192–A193 (2017): parameters by service type and multiple planning scenarios.
• A194 (2017): machine learning for determining planning parameters from scenarios selected as better.
• A195 (2017): updated planning for confirmed cruise reservations communicated through dynamic route sheets.

Together, the code paths and historical functions demonstrate that scenario choice was embedded in the application data model, calculation functions, operational interface and ongoing execution workflow—not a later retrospective label added to a conventional route solver. [4,8]

12. What the xSeil architecture contributes beyond mobility

The historical xSeil implementation coordinated operations centrally through a shared application and database. Its enduring value lies in the decision structure that it forced the engineering team to develop: a world model with reliable semantics; distinct hard commitments and negotiable preferences; reusable feasible structures; human-governed scenario choices; incremental allocation; awareness of residual capacity and cascading effects; and a feedback path between computation and the physical world.

A later 2023 Car Evolution concept explored transferring orchestration patterns to shared urban mobility, integrating individual agendas, vehicles, public objectives and changing conditions. Subsequent Ecosystem Awareness, Minimum Sufficient Control Architecture and Regime Awareness research examine broader questions about observation, authority, interdependence, system validity and control under changing context. These lines reuse architectural lessons from xSeil while addressing different problem domains and maturity levels. [9,10]

The distinction is fruitful. xSeil demonstrated how a centralized application can maintain operational feasibility and trade-off choice in a bounded physical network. The later research asks how a heterogeneous ecosystem can know when its current information, dependencies, authority and control assumptions remain sufficient to support a decision.

13. An engineering pattern: human authority over meaning, machine authority over search

xSeil’s most transferable contribution is the separation—and productive coupling—of two responsibilities. People determined which service and policy compromises were legitimate in context. Software performed structured combinatorial work, estimated consequences, committed resources and revised the remaining option space as the situation evolved.

The practical pattern can be expressed in six steps: represent the operational world; prevalidate reusable structure; calculate competing scenario outcomes; obtain a human choice of acceptable priorities; allocate and reprice sequentially; and reconnect field evidence to the next decision. This is a form of human-governed adaptive computation with an explicit operational contract.

Its business value was concrete: fulfil commitments already made to passengers, improve visibility of capacity/resource trade-offs, make exception decisions auditable, concentrate expensive computation where useful, and keep the planning result connected to live execution. The architectural lesson reaches beyond transport wherever resource commitments, policies, human judgment and uncertain downstream consequences must coexist.

References and evidence sources

[1] xSeil 2016–2018: Provenance, Delivery & Code Evidence v1.1 (public evidence record and original GitLab/registered-artifact anchors). https://docs.google.com/document/d/1TsUwtFBmdVX4zoxuRyqR6xYYRXORwZvTYvrTm1p8C-Q/edit

[2] JubAp.NET — xSeil Whitepaper: operating context, functional architecture and integrations. https://jubap.net/jubap-net-xseil-whitepaper/

[3] Vehicle Routing Under Fully Committed Tourism Demand, working paper v1, July 2026. https://jubap.net/xseil-vrp/

[4] xSeil Functionality Analysis: original functional inventory and code mapping, including A042 and A191–A195. https://jubap.net/xseil-functionality-analisis/

[5] The xSeil Problem, Deployed Architecture, Functional Substrate and Quantum Research Boundary, Companion Paper I v2.1. https://jubap.net/xseil-quantum-formulation-companion-paper-2/

[6] Pre-Agentic Orchestration: Closed-Loop Logistics Control Before the Agent Era. https://jubap.net/xseil-orchestration/

[7] xSeil 2017 — Scenario-Based Planning Technical Article, internal working manuscript, 5 September 2026. https://docs.google.com/document/d/1U0kJdR2sRzp37C-NvEZ3_nR5Zb7EzQ7DuQ_KO7iwX-Q/edit

[8] Agent Sync — xSeil Control Centre Weighting Code Review, 9 August 2026. https://drive.google.com/file/d/1Ev9Bb3rEU_lcvP8XlHnocCsYa5NyFoZn/view

[9] xSeil Evolution 2017–2026 — Working Master: Car Evolution, MCA and FG-TIDA, September 2026. https://docs.google.com/document/d/1Ac0RDJLCbDoDCmRcYYQqQ5qoGdpV5RimnSVneY3ODhU/edit

[10] From Field Practice to Pre-Standardization: An Extensible Case-Study Framework, Tegrity.AI. https://tegrity.ai/from-field-practice-to-pre-standardization-an-extensible-case-study-framework/

[11] xSeil Technical Papers — Series index. https://jubap.net/series/xseil_technical/