Develop with Modeler

Most of this guide is a set of worked business problems, each applying the workflow end to end. This page describes how those pages are arranged.

Every example uses Modeler. They are grouped by where the problem comes from, not by the technique it needs:

  • Classic OR Examples — facility location, diet, workforce scheduling, portfolio, sudoku. These are the most fully worked pages; start here.

  • DevOps Engineer — assigning workloads to machines, scheduling deployments, incident response planning, testing strategy.

  • Backend Engineer — A/B testing, ad selection, e-commerce pricing, network routing.

  • Data Engineer — Kafka partition assignment, Snowflake clustering keys.

The grouping is only to help you find a problem that resembles yours. The workflow is the same on every page.

The structure of an example page

Every example page has the same three parts:

  1. The problem, in full. A short description, then a Full example scenario dropdown containing the business question with its numeric detail. This is a reference for comparison only. Giving Modeler everything in a single prompt is not how modeling normally goes: you usually start with a rough description and refine it through the conversation shown in the tabs below, and you can then compare what that conversation produced with this scenario.

  2. What an optimal solution looks like. Most pages show a concrete optimal solution near the top, to check the rest of the page against.

  3. Built with Modeler. A set of tabs walking the problem through the workflow, one step per tab.

The tabs

The tabs follow the order the work happens in:

Tab

What it shows

Pinning down the problem

Modeler asking one clarifying question at a time, most important first, with ranked candidate answers.

Bringing in your data

A real data file uploaded and read, rather than numbers retyped into the chat.

The specification

The document the conversation produces: objective, constraints, data, expected output, and test scenarios, in business language with no mathematics.

Code

The gurobipy implementation generated from the specification.

Tests

The pytest suite, one test per scenario in the specification.

Cloud solve

The code run against a real Gurobi solve in the cloud, including — on several pages — a failing run and the correction that follows.

Changing the model

Another pass round the loop: a follow-on business change goes back through the conversation, reaches the specification first, and propagates to the code and the tests, in that order.

Formulation on demand

The mathematical formulation, generated only when requested, with a toggle between the rendered view and the raw Markdown and LaTeX.

A page may omit a tab where it has nothing distinctive to show, but the order does not change.

Where to go next

Read The methodology first if you have not already. Then start with Facility or Diet under Classic OR Examples, which are the fully worked references the other examples follow. DevOps Engineer, Backend Engineer and Data Engineer apply the same workflow to problems from those roles’ day-to-day work.