Decision platform

Nextmv is a decision platform built for developers. It helps you automate, optimize, and operate decisions like routing, scheduling, and matching.

We knew decision automation was the missing link between the modern data stack and the operation, but we didn't feel like we had the tools - workflow or infrastructure - to make it a part of the typical dev workflow. So we built them.

We wanted a platform that we could use with a variety of decision-making paradigms, let us go from local dev to remote deployment with confidence, and felt like other modern tools.

We think about decisions as code, meaning we use our platform to create decision services. But what is a decision service? It looks a little something like this.

Decision services sit between the data stack and the operation and operate at scale to provide ops with the best plan in the time they have to run.

These services take in structured operational data (we prefer JSON), generate possible plans that assign and sequence tasks, compare those plans based on a value function that is important to the business (KPI = on time deliveries), and return the best one.

This plan is then sent as structured output downstream to ops tooling (who doesn't love a good dashboard) or consumer applications (they show us ads, promos, ETAs, or prices). A plan is a snapshot in time of what the decision service thinks the operation should take action on based on current information.

Things change. That's why we have a decision service! We can re-plan as often as we want, triggered on new events or scheduled cadences.

We understand that collaborating on decision models is how you impact your business in a real way. Our platform is a set of opinionated tools for building, testing, deploying, and operating decision models.

We created 3 ways to interact with the Nextmv Platform:

1. CLI - workflow management tools
2. SDK - modeling and optimization tools
3. Console - management UI tools

The Nextmv command line interface (CLI) provides a guided workflow for decision optimization. It allows you to focus your efforts on the art of modeling rather than finding and assembling all the infrastructure you need to get up and running.

The CLI is convenient for local development, testing, and publishing to remote instances.

For more detail on CLI, check out the CLI reference.

The Nextmv software development kit (SDK) provides a set of APIs to build decision models. Our SDK is used to construct decision models and applications.

Our lowest level API is the Store API. You can use this API for creating custom decision models. We also have higher level APIs for specific spaces, like our Router API.

These APIs are used to create models and templates.

A model is a problem space someone needs to represent and reason about. It consists of operational data (e.g., vehicles and stops), constraints (e.g., time windows, capacity), an objective or value function (e.g., minimize, maximize, satisfy), and domain logic for type definitions and state generation.

Templates serve as starting points for solving a domain-specific optimization problem. Templates can be the foundation for building a custom decision model or used on their own.

For more detail on SDK, check out the SDK reference.

We designed our platform with the modern, cloud-based development environment in mind to minimize time spent on infrastructure and maximize decision engineer impact.

Our APIs are unique in that they encourage users to follow software engineering best practices applied to decision automation.

At Nextmv, decision models are built to be:

• Repeatable
• Testable
• Interpretable

Repeatable models are easy to create and deploy to different environments. They are configured the same way in research and development (local), testing, and deployment (remote). 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 optimization solver from scratch introduces layers of potential errors and maintenance. Models built with Store API are built from state. This makes testing models like testing other software.

Interpretable models output plans that don't require complex data transformation for the operation to act on them. Decisions 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, business logic, and value function for the decision. It's not a black box behind a REST API.