Skip to main content

​
Overview

A completed planning run carries three kinds of output:
  1. The production plan — the interval-by-interval schedule the optimizer chose
  2. Order fulfillment status — which demand orders the plan covers
  3. Solve KPIs — how the solver did, and how much to trust the answer
Reading a plan is rarely a one-shot exercise. You look at what the optimizer chose, spot where it made a trade-off you don’t like, adjust the model or the run’s inputs, and re-run. This page covers what each output means and the adjust-and-re-run loop that turns a first-cut plan into one you can commit to.

​
The Production Plan

The production plan is the primary output — a list of entries answering what to produce, when, and how much: The plan respects flow balance across the horizon for every material:
and inventory never goes negative. The plan reports the resulting end-of-interval inventory for each material alongside the production entries, so you can read how stock rises and falls across the horizon, not just when production happens. Intermediates needed for a SKU appear as their own production entries in the intervals leading up to the SKU that consumes them — the lead-up chain is part of the plan, not an implementation detail.

​
Order Fulfillment

Every demand order carries a fulfilled flag that flips to true when the plan covers the order in full. The flag is boolean — there is no partial-fulfillment state. Either the plan produces at least the ordered quantity by the order’s fulfillment interval, or the order is unfulfilled. An order ends up unfulfilled in two ways:
  • A soft-deadline order the optimizer chose to drop. The lateness penalty was cheaper than what fulfilling would have cost elsewhere — usually a competing higher-weight order on the same constrained resource. Reading the plan against the run’s resource capacities makes the trade-off visible.
  • A hard-deadline order. Hard orders cannot be dropped — if a hard order cannot be fulfilled, the whole run reports infeasible rather than returning a plan with the order missing.

​
Solve KPIs

Beyond the four KPIs above, the solver keeps internal progress diagnostics — its dual bound (the proven lower bound on the objective) and MIP nodes explored. These are not part of the standard results view; they matter mostly when a hard instance times out and you want to gauge how stuck the solver got.
Status and gap together are how you sanity-check a plan before acting on it: an optimal result at a tight gap is a plan you can commit to; a feasible result at a wide gap is a plan worth eyeballing — valid, but the solver couldn’t prove it was close to the best.

​
The Adjust-and-Re-Run Loop

First-cut plans are rarely the plan you ship — they are the plan that surfaces where the model’s assumptions don’t match your judgment. The knobs, in the order you typically reach for them:
  • Rebalance the two objectives. Shifting the balance toward inventory protects stock targets at the expense of demand timing; shifting it toward demand does the reverse. Plan hits every due date but lets inventory drift? Shift toward inventory. Holds inventory beautifully but misses orders you cared about? Shift toward demand.
  • Re-tune per-tag weights. A class of orders being dropped too readily deserves a higher order-tag weight; an inventory goal being over-protected at others’ expense deserves a lower one.
  • Update demand or supply as new information arrives. New orders, a supply delay, a start-date shift — put the changed inputs on a new run rather than editing the old one, so before and after stay comparable.
  • Adjust or add custom constraints. If the plan does something operationally impossible that the base model doesn’t capture (a batching rule, a changeover limit), encode it as a custom constraint.
  • Extend the horizon or add capacity. A perpetually tight or infeasible plan usually means the horizon is too short for the lead-up chain, or the declared capacity doesn’t match what the floor can run.
Change one thing per iteration. Runs are cheap and persistent — a chain of single-change runs tells you exactly which adjustment moved the plan, while a batch of simultaneous edits leaves you guessing.

​
Comparing Runs

Every completed run remains available with its inputs and outputs intact. There is no dedicated side-by-side comparison view for planning runs today — the fastest way to compare two runs is to ask Dexter: which orders changed fulfillment state, which intervals shifted production, how the objective moved, and where the trade-off landed. Dexter can also chart both plans for a specific SKU or resource so the difference is visible at a glance.