Show IH: GSL now accepts XLSX and XLSX-in-ZIP through the runtime
A small-looking milestone that actually closes an important gap in the Geo Strategy Logistic (GSL) Solver.
I started with benchmark files such as .vrp / .txt, then built a unified converter and runtime layer so the same problems can be represented as CSV and now XLSX.
The validation pipeline is:
Original Benchmark → Converter → XLSX → ZIP → GSL Runtime → Optimization → Audit
I tested the XLSX path on representative instances from different VRP families:
X-n979-k58 — Uchoa et al., CVRPLIB Set-X
C2_2_4 — Homberger
pr10 — Cordeau
pr13b — Vidal et al. (2013)
Specifying the vehicle count (k) alongside the cost is crucial here, as the problem formulation explicitly minimizes both the total distance and the fleet size simultaneously.
The resulting optimizations were:
X-n979-k58 → Cost: 126087.33 | Vehicles: 58
C2_2_4 → Cost: 3178.01| Vehicles: 6
pr10 → Cost: 3002.00 | Vehicles: 23
pr13b → Cost: 9058.30 | Vehicles: 43
I also tested the corresponding .xlsx.zip inputs directly through the GSL runtime. The runtime extracts the XLSX file and passes it into the same optimization pipeline.
The important part for me is not just that Excel files can be parsed. GSL is deterministic, so I can use the engine itself as an audit mechanism: convert an original benchmark instance into another data format, feed it back into GSL, and verify that it still represents the same problem and produces consistent optimization results.
I initially considered supporting both .xls and .xlsx, but eventually kept XLSX as the sole Excel format. It is the more practical modern format and avoids adding unnecessary legacy-format complexity.
So the current architecture is becoming:
Benchmark data → Converter → CSV/XLSX → ZIP Runtime → GSL Engine → Audited Solution
The optimization core stays untouched while the data interface becomes much closer to how operational data actually exists.
The part I find more interesting than the XLSX support itself is the separation between the data interface and the optimization core.
That seems like the right architectural direction for something that eventually has to deal with messy real-world inputs.
Users don't really care whether the underlying benchmark started as .vrp, .txt, CSV or XLSX. They care that the system can take what they already have and produce a result they can trust.
And the audit loop makes this more than a format conversion problem. You're effectively using the deterministic solver to ask, “Did this transformation preserve the meaning of the original problem?”
That's a much stronger validation criterion than simply checking whether the file parsed successfully.
I think that's the interesting product story here: making operational data easier to enter without weakening confidence in the output.
Exactly. That separation is becoming one of the most important architectural principles in GSL.
The input layer can evolve as new data formats and real-world workflows appear, while the optimization core remains unchanged.
And for me, the audit loop is what makes that separation meaningful. It allows me to verify that the transformation changes the representation, not the underlying optimization problem.
The long-term goal is exactly that: make real-world data easier to bring into GSL while maintaining confidence in the optimization results.
The technical architecture is clear, but I think there’s an even stronger product story hiding underneath it.
“XLSX support” sounds like a format update. What you’ve actually built is a way for someone to bring messy, familiar operational data into a deterministic optimization system without losing confidence in what the data means.
That distinction matters because the buyer/user probably isn’t thinking:
“Great, the runtime now accepts XLSX.”
They’re thinking:
“Can I give this system the data my team already uses, and can I trust the result?”
I’d almost make that question the headline of the feature. The converter, ZIP runtime, and audit loop then become evidence supporting the promise rather than the story itself.
That shift could make this milestone much easier to understand outside the optimization/VRP crowd.
I agree. That is actually closer to what I was trying to achieve with this milestone.
XLSX is only the visible part of the change. The more important part is building an input layer that can adapt to the data people already have, while keeping the optimization core and the validation logic stable.
The converter, ZIP runtime, and audit loop are therefore not really the product story by themselves. They are the mechanisms I use to make that transition verifiable.
I think your framing is useful:
“Can I give GSL the data my team already uses, and can I trust the result?”
That is a much better way to explain where GSL is heading beyond the benchmark/VRP context.