Deployment and integration
An optimizer that never reached production is a research result.
The hard part of deploying an optimization core is not the mathematics. It is entering a network that already works, proving you are better before anything is cut over, and behaving predictably when a feed drops at three in the morning. This core has been put into somebody else's live environment twenty-two times across seven countries.
The integration surface
Three ways the core is consumed.
Embedded library.
The core links into your own stack. You keep the interface, the workflow, and the customer relationship. Deterministic given the same inputs and seed, so a result is reproducible inside your own test harness.
Service API.
Solve requests over the wire against a declared latency budget. Stateless per request, with the network model versioned and pinned so any plan can be reconstructed months after it was issued.
Hosted tenant.
Full multi-tenant deployment with isolation enforced at the data layer, for operators who want the intelligence without owning the runtime.
Most of the work in any integration is not the connector. It is the semantics. What a facility identifier means in one system versus another, what a delivery event actually signifies, and which of four timestamps is the one to trust. That reconciliation is where integrations fail, and it is the part that never appears in an architecture diagram.
Shadow mode
Prove it against the incumbent before anything is cut over.
The core runs alongside the existing system on live data, producing plans that are measured but never executed. Divergence is recorded per decision, so the operator can see where the two systems disagree, by how much, and what the difference would have been worth, before committing to anything.
This is how the 8,131 shipment study was produced. Not a simulation and not a sales model, a parallel run against real movements with the incumbent as the control.
Connect.
Read-only ingestion. Nothing is written back to the host system.
Reconcile.
Entity and semantic alignment against the operator's own definitions, verified against historical data before anything runs live.
Shadow.
Parallel plans on live data, divergence measured, still no execution.
Cut over by segment.
One lane, one facility, or one customer at a time, with the shadow comparison still running behind it.
Write back.
Plans flow into the host system under the operator's own approval rules, not ours.
The operating envelope
What it does when things go wrong.
When the time budget expires.
The solver returns the best feasible plan it has found, with the optimality gap published alongside it. It does not return nothing, and it does not claim an optimum it has not proven. Anytime behavior is a requirement here, not a feature.
When a feed drops.
Estimation falls back to the lane prior rather than the last known value, and every affected decision is flagged as running on a degraded input. A stale timestamp presented as current is more dangerous than a missing one.
When the plan is refused.
Operator overrides are recorded as outcomes rather than as errors. A dispatcher who consistently rejects a recommendation on one lane is telling the model something it does not yet know, and that signal feeds calibration.
The budget is declared per decision class and the solver respects it. A method that cannot bound its own runtime cannot be put in front of a customer.
The reframe
Twenty-two integrations, not twenty-two products.
The module count elsewhere on this site is deployment evidence rather than product scope. Each one is a production integration into a live operating environment, carrying the reconciliation, acceptance testing, and support history that implies. The engine is one thing. The number worth counting is how many times it has been placed inside somebody else's network and left running.
If your network makes decisions under uncertainty, we should talk.
We work with a small number of operators at a time. Tell us what your network is optimizing for.
Start a conversation