> ## Documentation Index
> Fetch the complete documentation index at: https://docs.prodexlabs.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Demand and Supply
> The run inputs: demand orders, supply orders, on-hand inventory, inventory goals, and resource capacity.
## Overview
This page covers the **run inputs** — the run-specific data the optimizer consumes on top of a [planning model](/product/planning-models). Every input here lives on a specific [planning run](/product/planning-runs), 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](/product/planning-runs#validating-inputs).
Like the model itself, run inputs are authored in the planning UI or by [asking Dexter](/product/dexter/chat-and-tasks) — 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](/product/planning-models#material-classification)).
| Field | Meaning |
| ------------- | ------------------------------------------------------------------------------------------------------------------------------- |
| **Name** | Human-readable label |
| **Order tag** | The [order tag](/product/planning-models#order-tags) that governs this order's weight, deadline type, buffer, and penalty shape |
| **Date** | The due date, mapped to an interval against the run's start date |
| **SKUs** | One or more lines, each with a SKU entity, a quantity, and an optional variant that pins the recipe |
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](/product/bom-overview), 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.
| Field | Meaning |
| ------------- | -------------------------------------------------------------------------- |
| **Name** | Human-readable label |
| **Date** | Arrival date; the material becomes available at the corresponding interval |
| **Materials** | One or more entity + quantity lines, each with an optional variant |
## 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](/product/planning-models#the-two-objectives).
| Field | Meaning |
| ------------------ | ---------------------------------------------------------------------------------------------------------------- |
| **Entity** | The material the goal is against |
| **Inventory tag** | The [inventory tag](/product/planning-models#inventory-tags) governing weight and rolling / non-rolling behavior |
| **Target** | The inventory quantity to aim for |
| **Margin** | The width of the no-penalty band: deviations up to the margin cost nothing |
| **Interval range** | The start and end intervals over which the goal applies |
### 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.