Supply chain software has accumulated an enormous amount of operational data over the past decade. ERP systems record every transaction. WMS systems log every pick and pack event. TMS systems capture every shipment milestone. Visibility platforms aggregate carrier data from hundreds of sources. The data infrastructure has been built. What hasn't been built is the intelligence infrastructure that turns that data into better decisions at the moment decisions need to be made.
This gap is what decision science tries to address. It's a term that covers a range of approaches — mathematical optimization, simulation, reinforcement learning, constraint programming — all applied to the problem of making better choices under uncertainty in operational settings. It's not new as an academic discipline. What's new is that the computational costs have fallen enough and the data infrastructure has matured enough that decision science can now be embedded in real-time operational systems rather than reserved for monthly planning cycles.
Why point-solution ML models aren't enough
The last five years of supply chain software investment has produced a lot of point-solution ML models. A demand forecasting model for the demand planning team. A route optimization model for the transportation team. A slotting optimization model for the warehouse team. A carrier selection model for the freight procurement team. Each of these models, in isolation, does a reasonable job of improving the decision it was built for.
The problem is that supply chain decisions are not independent. The decision to hold more safety stock (made by the demand planner to reduce stockout risk) interacts with the decision about warehouse slotting (made by the operations team to maximize throughput) interacts with the decision about carrier selection (made by the transportation team to minimize cost). Optimize each of these individually, and you can easily end up with locally optimal decisions that are globally suboptimal. You've reduced stockout risk while simultaneously creating warehouse congestion that reduces throughput by more than the stockout reduction was worth.
Decision science infrastructure attempts to model these interdependencies explicitly. Rather than three separate optimization models running on separate data, you build a framework that can represent the constraints and objectives of multiple decision types simultaneously, and can reason about how a decision in one domain affects the feasible space in another. This is harder to build than a point-solution model. It's also harder to sell because the value is systemic rather than attributable to a single metric improvement. But it creates a more defensible position once deployed, because the system becomes a core component of operational planning rather than an add-on that addresses one metric.
What Nextmv is building
When we diligenced Nextmv in late 2024, the framing that resonated with us was their description of the problem as "optimization infrastructure." Not an optimization product for a specific supply chain domain, but infrastructure for building, testing, and deploying optimization applications in any domain. The analogy they used was Stripe for payments: Stripe didn't build a payments product, they built infrastructure that makes it easy for developers to build payments applications. Nextmv is building infrastructure that makes it easy for logistics software teams to build decision-optimization applications without starting from scratch every time.
The practical value of this architecture: a logistics software company that builds on Nextmv's infrastructure can focus its engineering resources on the domain-specific logic — what are the constraints in a last-mile routing problem, what are the objectives in an inventory positioning problem — without rebuilding the solver infrastructure, the experiment framework, or the deployment and monitoring tooling that goes around a production optimization model. The time from "we want to add an optimization capability" to "the model is running in production" compresses from six months to six weeks.
What made us comfortable backing this at seed: the founding team came out of operations research and distributed systems backgrounds, had already been running the product with real logistics customers (not just a demo), and had a clear empirical answer to the question of whether their infrastructure abstraction actually accelerated development cycles — they'd measured it with their design partners. That measurement discipline is a proxy for the kind of operational rigor that makes infrastructure products trustworthy over time.
The composability argument
The deeper argument for decision science infrastructure over point-solution models is composability. When optimization models are built as composable modules with standardized interfaces, you can combine them in ways that point solutions don't allow. A route optimization module that exposes a standard constraint interface can be connected to an inventory positioning module that exposes a standard demand interface. The combined system can answer questions neither could answer alone — "given my current inventory distribution and expected demand for the next 72 hours, what is the optimal combination of replenishment decisions and routing decisions to minimize total cost while maintaining service level targets?"
This is not a question you can answer with two separate point-solution models running on separate pipelines. It requires a shared problem representation, a solver that understands the interactions, and a common interface for defining the objectives and constraints. That shared infrastructure is what the supply chain software stack is currently missing.
We're not saying this is a problem that's easy to productize. The challenge with selling composable infrastructure is that customers want to buy solutions to specific problems, not building blocks for future solutions. A VP of Operations wants to know "can you reduce our carrier cost?" not "can you give us a platform for building optimization applications?" The companies that get this right tend to lead with a specific, high-value optimization application — a route optimizer, a carrier selection tool, a warehouse slotting module — while building on composable infrastructure underneath. The platform value becomes apparent to the customer over time as they see how the components connect.
The horizon problem in supply chain optimization
One specific challenge in decision science for supply chains that's worth addressing directly: the time horizon problem. Supply chain decisions operate at very different timescales. A routing decision needs to be made in minutes. An inventory positioning decision operates on a daily or weekly cycle. A network design decision — where to locate distribution nodes — operates on a multi-year horizon. Most optimization models are built for one timescale, and the decisions at different timescales are handled by different teams with different tools that don't share information.
The interesting companies are building decision infrastructure that can handle multiple timescales in a connected way — where the long-horizon network design decision creates the constraint space within which the medium-horizon inventory decision operates, which in turn creates the constraint space for the short-horizon routing decision. This is how the system actually works in practice; the software stack should reflect that reality rather than fragmenting the decision process into timescale silos that can't communicate. Building that coherence is hard. It's also the direction that the most technically ambitious supply chain software companies are moving.