xSeil 2016 to 2018 Provenance Delivery and Code Evidence

How a contracted logistics intelligence system became working software operational practice and a durable technical record

Evidence assembled 8 September 2026 · Public version 1.1

Private correspondence is cited through stable Gmail message and thread IDs. The linked public evidence files provide the supporting repository identifiers, hashes and registration records.

From operational challenge to working system

At Jubap.Net, we built xSeil as an expert logistics-intelligence system for a real tourism-transport operation. The evidence joins a 2016 process and architecture baseline, intensive development throughout 2017, formal validation and handover correspondence, operating artifacts, and registered code and project archives from 2018.

Together, these records show how the system moved from requirements and operating rules into software, planning scenarios, route construction, live logistics control and a structured delivery process grounded in operational data.

A connected evidence trail

The public evidence trail connects the contractual and requirements records, the dated functional presentation, Gmail-ID delivery and validation correspondence, GitLab issues and commits, source-code mechanisms, route and test artifacts, registration records and the later code-grounded reconstruction.

Requirements define the scope. Correspondence dates review and delivery. Issues and commits reveal the engineering sequence. Code exposes the mechanisms. Operational artifacts show how the work was organized. Registration records preserve the existence and date of the principal artifact classes.

The operational system

The historical architecture was broader than a route solver. It covered service parameters, scenario-dependent planning, multiple competing indicators, reservation and fleet integration, transfer points, route-sheet generation, morning and runtime replanning, geofences, mobile execution, plan-versus-actual monitoring, no-show state, rental-capacity estimation, park-entry saturation and speed recommendations.

A simple trilemma helps explain the pressure among service commitments, asset utilization and policy compliance, but it is not the full model. The surviving sources also address punctuality, occupancy, direct-service share, waiting, travel time, stops, rental reduction, maintenance, personnel roles, transfer rules and service-specific conditions.

Contractual and delivery baseline

The February 2017 Technical Annex and adjacent requirements form the contractual technical baseline. The repository provides the complementary implementation layer, allowing readers to trace selected functions from the agreed scope into surviving code, issues and commits.

A May 2017 validation sequence established the governing requirements document, formal review steps, change-control treatment for additional items and a delivery-reception process. Later correspondence records progress review, operational-data testing and a structured handover that included environments, dependencies, Git history, modules, database, interfaces and logistics-planning workflow.

Development history recovered from GitLab

The GitLab project preserves 1,373 distinct commits across all references, 6 branches and 242 issues. The root commit is dated 13 March 2017. Of the distinct commits, 1,354 are dated 2017; later maintenance continues through January 2023. The current master tree contains 671 files.

The issue record provides direct mechanism-level traceability. Examples cover route construction, pickup construction, unit-type scoring, the travel assistant, logistics-control demonstration, dynamic route sheets and rental estimation. Review, paid and closed labels preserve the work progression, while four open issues retain the remaining development trail.

Mechanisms visible in source code

Data intake and normalization. SOX and GeoTab connectors import catalogues, reservations, vehicles, operation state and transported-passenger events. A normalization boundary handles incomplete and changing upstream records.

Candidate construction and scoring. The planner builds combinations and pickups, then scores them under scenario parameters for factors such as occupancy, directness, isolation, scarcity, delay and resource use.

Sequential allocation and repair. Planning consumes residual capacity and time-dependent feasibility; later allocations therefore depend on earlier choices. Simulation, reassignment and bounded repair routines search for an executable plan inside the accepted policy frame.

Rental estimation. The surviving implementation estimates demand with the documented relation pax_current × average_total_pax ÷ average_hourly_pax and converts it into vehicle demand using capacity and historical occupancy.

Closed-loop logistics control. A five-minute cycle recalculates platform and passenger saturation and recommends increasing or decreasing average speed within operating constraints. Dynamic route-sheet logic supports passenger reassignment, remaining capacity, itinerary change and additional delay.

Operational validation and data quality

The validation chain describes a concrete method: ingest and filter real reservation data; compare it with executed route sheets; run planning against historical operating periods; inspect rejected records; and reconcile differences between API data and visible operating systems.

The surviving July reservation exports and August executed route sheets provide complementary windows into demand structure and executed operations. Together with the validation correspondence, they show how the planning team compared reservation feeds, historical operating periods and route-sheet outcomes.

The surrounding modernization programme meant that xSeil could not assume a clean, stable master source. The implementation therefore used a rule-based translation and filtering boundary instead of waiting for a future replacement system. Vendor comparisons, where needed, use only the phrase top international technology and consultancy companies.

Registered artifacts and custody

Four Safe Creative records preserve the project history: two process and architecture artifacts registered in 2016 and two software archives registered in 2018. Their titles, dates, artifact classes and rights regimes are reproduced in the public evidence register.

The 2018 Git commit that introduced the registered document package and the registrations created on the same day form a strong temporal anchor between repository history and the preserved registration record.

The public evidence files expose aggregate counts, stable Gmail IDs, repository identifiers, hashes and mechanism descriptions. The underlying repository, wiki, correspondence and operating records remain under controlled custody.

What the record reveals

The record reveals a complete expert-logistics architecture with source code, documentation and issue management; intensive development in 2017; integration with operational sources; scenario-based planning and simulation; route-sheet construction; transfers; live logistics control; rental estimation; saturation logic; speed recommendations; and dynamic reassignment mechanisms.

How this article anchors the series

I use this article as the evidence gateway for the technical series. The functional-analysis paper explains the deployed problem and architecture. The vehicle-routing paper formalizes fully committed demand and state-dependent feasibility. The orchestration paper reconstructs the closed loop before the current agent era. Companion papers extend the work into scenario selection, computational formulations and new research questions.

The series reconstructs a deployed system from its original technical and operational record so that each later paper can build on a shared, traceable foundation.

Gmail evidence ledger

The IDs below are stable retrieval anchors in the authenticated mailbox. Each one connects the public summary to its preserved source record.

Contractual baseline and formal validation — 15be9b38938e8d4a; thread 15be8de6ccce61a5. Formal delivery is tied to the governing requirements baseline; out-of-baseline items enter change control.
Baseline reset — 15be9b95725cda5b; thread 15be8dd6326c2431. The supplied requirements document becomes the sole validation baseline and supports a delivery-reception process.
Official meeting follow-up — 15c30aedce05dd79. An executive operations role circulates the agreements from the May review meeting.
Functionality and progress review — 15c3c9a4797ce9a2; 15c3cb4a068a385e. The project team supplies the requested functionality/progress record and a client role confirms technical review.
Advance and deliverable review — 15d569eff0ff1617. A client role requests dates to review advances and deliverables under the previous agreement.
Project plan — 15d9ff01d7b69cc8. A client project-management role circulates the planning and logistics-control work plan.
Operational-data validation — 15da53c735aada42; 15da913789f69ff8; 15dc42fd24c8fd00; 15dc4868e5b2fb37; 15dc7383c590929f; 15dc90f1acbb6969; 15dcc8d8692d9ca7; 15dd33e5b49d3a19; 15dd369b63f87f12; 15de23acd170e123. The chain covers changing reservation feeds, test scheduling, comparison with executed route sheets, filtered records, source differences, status semantics and the normalization boundary.
Handover scope — 162d15c6b29e29ab; thread 162d98667f01df3f. The delivery transition asks for working material and GitLab access; the walkthrough scope includes environments, history, modules, database, APIs and operating process.
Development workflow — 15b44aa6869431db; 15b44c76dd8b9f76; thread 15b730c3946654f7; 15b7de3fca0bd5be. The record connects code exchange, issue completion, commit upload and the daily GitLab issue/review/validation workflow.
Historical presentation — thread 15537aa4b39c6c1b; 1553ce323ce5045f; 1554707b8b4c4eef. The chain dates the functional presentation and records slide-level review and confidentiality concerns.
Infrastructure performance — 15ee8d3ae6086b00; 15f08c49926b7636. The record preserves the project benchmark comparison and infrastructure conference that guided deployment choices.

Safe Creative register

1804216635327 — 2018-04-21, Git Project, Git project archive, CC BY-NC-SA 4.0.
1804216635334 — 2018-04-21, Source Code, Source-code archive, CC BY-NC-SA 4.0.

Integrity anchors

Git history — 1,373 distinct commits across all references — root 19781f7b3cadb83de6a96ff1df00ffd48f7d7007; master 7af5ff8acd55df878668488cc054cc5d7ad4c13c
GitLab project — Project ID 2877383; 6 branches; 242 issues — 238 closed; 4 open
Registered document package — 62 files — C9878A9DED6FCCC4CCA5A65F861A5B570FD3B9CA8201CD6A3520BC8E1763F4BB
Private Git object pack — 39,684,364 bytes — E0259CE19B1FBC31944215BFD1A9C95B45DDE68499E52AE5900D057DD2A59133
Private Git index — 402,480 bytes — 46757D3663060A2B94E490C378496B0259F8EE38A0FCF32257BDCF5AFB130397
Evidence review — Controlled internal review — ACD805ECC7665CC1131DF377173BEA0132FD37565D4F914FE41A1112785FD28D
Integrity manifest — Controlled internal manifest — 8EA5DA3156C24625CF5F8297D9BEC13EF4F71E05AE5BAE2A31F9FBAC12D3C314

Public evidence files

Public evidence register
Public integrity manifest