Skip to main content

​
Overview

This page covers the run inputs — the run-specific data the optimizer consumes on top of a planning model. Every input here lives on a specific planning run, not on the model, so the same model can plan against many demand and supply scenarios. A run is made up of:
  1. Start date — the calendar date interval 0 maps to
  2. On-hand inventory — what is on the shelf on the start date
  3. Demand orders — what the plan must fulfill, and by when
  4. Supply orders — externally procured raw materials and when they arrive
  5. Inventory goals — target stock levels the plan should hold
  6. Resource capacity — per-interval capacity ceilings for each resource on the model
Every dated input maps to an interval by counting interval units from the run’s start date. Because the horizon is a count of intervals, the last valid interval index is n − 1; dates that fall past the horizon are rejected during validation.
Like the model itself, run inputs are authored in the planning UI or by asking Dexter — often by handing Dexter an order export or spreadsheet and letting him load it into the run.

​
Demand Orders

A demand order is a customer-facing commitment the plan tries to fulfill. Only SKU-classified entities are valid — intermediates and raws cannot be demanded directly (see material classification). The optimizer chooses the interval in which to fulfill each order. A buffer on the tag pulls the effective due date earlier — it is finish-early margin, not extra slack after the deadline. If the order’s tag is soft, the plan may miss the deadline and pay a penalty (which stays zero as long as the order finishes by the deadline minus its buffer); if the tag is hard, the plan must fulfill by the deadline minus any buffer intervals, or the run is infeasible.

​
Variants on Demand Lines

If a SKU has more than one BOM, a demand line’s variant selects the recipe. Matching is by subset: for every attribute the BOM’s condition mentions, the demand line must carry a compatible value. Extra attributes on the demand line — ones the BOM doesn’t condition on — are ignored. A demand line with no variant matches only a BOM whose variant condition is empty (a wildcard that matches any line); if every BOM for the entity conditions on some attribute, the demand line must carry those attributes to match.

​
Supply Orders

A supply order is a scheduled arrival of raw material from outside the plant. Only RAW-classified entities are valid — intermediates and SKUs are produced internally by the plan, never procured.

​
On-Hand Inventory

On-hand inventory is what is physically on the shelf on the run’s start date. Each entry is an entity + quantity pair with an optional variant. Any classification is valid — you can seed the run with raws, intermediates, or finished SKUs. The start date and on-hand inventory together form the run’s initial conditions: they anchor interval 0 in calendar time and in stock position.

​
Inventory Goals

An inventory goal expresses a target stock position for an entity over an interval range. The optimizer pays a loss to deviate from it — this is the second term of the objective.

​
How the Loss Curve Works

The penalty depends on how far actual inventory strays from the target, measured against the margin. As long as inventory stays within the margin of the target — above or below — there is no penalty at all. Once it drifts past the margin, the penalty grows faster and faster the further it goes: a small overshoot or undershoot is cheap, a large one is expensive. The margin is your knob for how tolerant the plan should be around each target.
Under the hood the solver approximates this smooth curve with a series of straight-line segments, so tiny kinks in the penalty are expected. The mental model — no penalty inside the margin, a steeply growing penalty beyond it — is the one to plan with.
A non-rolling inventory tag changes how stock behaves across the goal’s window: at each interval the goal covers, the entity’s inventory resets to zero at the start of the interval — nothing carries in from the interval before, and no penalty is charged for the reset. Use it for spoilage-bounded materials or one-off builds where stock can’t physically carry from one interval to the next.

​
Resource Capacity

Resource capacity — set per resource, per interval, on the run — is how many units of that resource (hours, pieces, whatever the resource’s unit is) are available in that interval.
Missing intervals default to zero, not unlimited. There is no implicit baseline. If a resource should run at a steady level across the horizon, every interval needs an entry at that level — a single missing row silently zeros out the resource for that interval, and “why is nothing being produced?” is almost always a missing capacity row, not a solver bug.
The zero default has three practical consequences:
  • Modeling downtime — omit the interval, or set it to zero
  • Modeling a surge — raise the ceiling for just those intervals
  • Diagnosing an empty plan — check the capacity rows for the affected intervals first
Parts of the product refer to run-level capacity entries as resource replenishments — the capacity that becomes available in that interval. Same concept, same numbers.