Skip to main content

​
Overview

A planning run is one execution of the optimizer against a planning model. The model is the reusable setup — horizon, resources, BOMs, tags, weights. The run is where you supply the inputs the plan will actually see: the start date, demand, supply, on-hand inventory, inventory goals, and resource capacities for this specific horizon. Every run is persistent. You can re-open a run, inspect its inputs and its output plan, adjust something, and run again — usually in a new run so you can compare before and after. See Demand and Supply for the inputs a run carries and Planning Results for what the optimizer returns.

​
Creating a Run

You create runs in the planning UI or by asking Dexter. The typical chat pattern:
“Create a run on the weekly model, start date next Monday, using the demand from the June order book and the on-hand inventory from yesterday’s ERP export. Cap the packaging line at 80 hours per week.”
Dexter builds the run, wires the inputs back to their source data so the derivation stays auditable, and hands it back for review before anything is solved. Every input a run needs is attached to that run, not shared across runs — one model can drive many runs against different scenarios without them interfering with each other.

​
Validating Inputs

Before you optimize, validate. Validation checks the run against the model without invoking the solver, catching the setup mistakes that would otherwise fail a solve — or worse, silently produce a wrong plan. Validation runs a fixed sequence of checks; later checks are skipped if an earlier structural check fails:
Check 3 also rejects two BOMs for the same entity whose conditions use completely disjoint attribute sets — an order could satisfy both, which is ambiguous. If you split an entity’s recipes by size, every one of its conditioned BOMs must condition on size.
Validation errors are always data setup issues, not solver issues. Fix the inputs and validate again — there is no point invoking the solver on a run that doesn’t validate.
Deleting and re-creating a BOM breaks saved models. A planning model saved before the re-creation still points at the old BOM record, and validation fails with a “BOMs not found” error. Re-save the model so its BOM list re-resolves — re-creating the BOM alone is not enough.

​
Optimizing

Once validation passes, run the optimizer. The solver takes the model plus the run’s inputs and finds the production plan that minimizes total loss, subject to hard resource-capacity limits, BOM flow balance, supply timing, and any hard-deadline orders. Short plans return promptly. Longer plans keep running in the background — you can navigate away, and the results appear on the run when the solve finishes. A run moves through queued (accepted, not yet picked up), processing (the solver is working), and then a terminal succeeded or failed — where an infeasible run counts as failed.

​
Solver Defaults

The optimality gap is a proof, not an accuracy estimate: a 2% gap certifies that no plan more than 2% better exists. Solves that hit the time limit report whatever gap they reached.

​
Solver Outcomes

Separate from the run’s job status, every solve carries a solution-quality outcome describing the plan it produced:

​
When a Run Is Infeasible

Infeasibility is not a solver bug — it is the optimizer telling you the inputs cannot all be satisfied at once. The common causes, roughly in order of frequency:
  • A hard-deadline order that cannot be met given resource capacity and the BOM lead-up chain. Relax the tag to soft, add capacity in the constrained intervals, or extend the horizon.
  • A resource with no capacity in the intervals a demanded SKU needs — remember that missing capacity rows default to zero.
  • Missing raw-material supply for a demanded SKU. Add supply orders for the raws the BOM chain needs, or seed on-hand inventory.
  • Over-constrained custom constraints — for example a minimum-production floor stacked against a maximum-output cap that together exclude every schedule. Loosen whichever constraint is over-restrictive.
Recovery is almost always one of five moves: relax a hard tag, add capacity in the pinch intervals, extend the horizon, add supply, or loosen a custom constraint. Change one thing at a time and re-run so you can see which move unlocked the plan.