Nextmv is a decision modeling and simulation framework built for developers. It helps you automate and evaluate decisions like routing, scheduling, and assignment.
We believe that algorithms should be like any other software. You shouldn't need a wizard to automate delivery routes or a scientist to build a shift scheduler. We give developers the legos to make and experiment with decision models without a PhD.
This documentation should get you working with the Nextmv Decision Stack quickly. Reading it will help you understand its design, and how to go from business requirements and operational data to deployed models in production.
Our tools are intended to scale up and down to meet different business needs. This guide is not exhaustive. We recommend reading through the package documentation to get to know individual components.
Our platform
The Nextmv Decision Stack is an opinionated set of developer tools for rapidly building optimization and simulation models in production environments. The Nextmv Decision Stack includes the following components:
- Solvers (Hop) and simulators (Dash)
- Engines
- Runners
- Extensions
Solvers and simulators
Hop and Dash modules are divided into three top-level packages.
- Models: Something to make a decision about (e.g., a route for a vehicle, an assignment of compute jobs to machines on a network, or the price to bid in an auction).
- Runners: The glue between input data, the model, and its environment. It reads data into a state structure defined by the modeler, runs a solver or simulator, and provides decisions as data. We provide several prebuilt runners for use with Nextmv (see runners for more information).
- Solvers (Hop) / Simulators (dash): State-based representations of a system of actors and actor decisionsSolvers search the space of feasible decisions and recommend a solution and simulators are event-based simulations of actor decisions.
While Hop, the decision modeling and optimization system, and Dash, the discrete event simulator, provide different functionality, they share common designs and behaviors. Modelers can customize solvers and simulators by creating their own actors and decision logic according to their use-case.
Hop
Hop is a decision modeling and optimization tool built for developers. It helps you solve optimization problems and automate decisions like routing, scheduling, and assignment.
Hop helps you put automation in place quickly, iterate on it easily as your requirements change, and automatically gather evidence along the way so you know if it's working the way you want. This minimizes time spent on infrastructure and maximizes modeler impact.
Dash
Dash is a fast discrete event simulator built for the cloud. It helps you predict and compare the outcomes of complex systems. Dash makes it easy to model user behavior and quickly estimate outcomes using real data to ensure you're taking the best approach, no matter what conditions come your way.
Engines
Engines are standardized, reusable, high-performance algorithms. Engines leverage many of the same fundamentals as Hop, but are already structured and tuned for high-volume use cases.
Each of these engines follow modern layered architecture techniques such that each component can be combined, interchanged, or modified as needed for a particular use case. For example, a capacitated vehicle routing problem with time windows (cvrptw) engine will build and extend a capacitated vehicle routing problem (cvrp) engine.
Design goals
Both Hop and Dash are modular packages that easily integrate with the modern, cloud-based development environment, which minimizes time spent on infrastructure and maximizes modeler impact.
Hop and Dash are unique in that they encourage users to follow decision engineering best practices.
At Nextmv, decision models and simulations mirror the same principles:
- Repeatable
- Testable
- Interpretable
Repeatable models and simulations are easy to create and deploy to different environments. They are configured the same way in research and development, testing, and deployment. They can share business logic so you don't violate the DRY principle (don't repeat yourself).
Testable models are easy to validate and configure in CI/CD. Recoding decision logic into an unfamiliar language (e.g. linear inequality systems) or coding an entire discrete event-based simulator from scratch introduces layers of potential errors and maintenance. Hop models and Dash actors are built from state. This makes testing models or sims like testing other software.
Interpretable models and simulations have outputs that don't require complex data transformation. Hop decisions and Dash measures can be stored and queried directly just like any other data. They can be picked up and re-created from their inputs for debugging. The modeler owns the model and the actor definitions. It's not a black box behind a REST API.