Planning Models

​

Overview

A planning model is the reusable setup the optimizer plans against. It defines the horizon (how far out, and in what interval size), the resources production consumes, the BOMs that describe how things are made, the demand-order and inventory-goal categories the plan will honor, and the weights that trade off the two competing objectives: hitting demand on time versus hitting inventory targets. One planning model is reused across many planning runs. The model is the template; each run supplies the run-specific inputs — demand, supply, on-hand inventory, resource capacities — described in Demand and Supply. For how the pieces fit together, start with the Planning Overview.

​

The Two Objectives

The optimizer balances two competing goals: hitting demand on time and holding inventory at its targets. You decide how much each one matters with a single balance setting.

• All the way toward demand — the plan ignores inventory targets to hit due dates.
• All the way toward inventory — the plan lets demand slip to hold inventory at goal.
• Balanced — the default, weighing the two evenly.

There is no third goal for resource utilization. Resource capacity is a hard limit, never traded off. If the plan cannot fit inside the capacity you give it, the run is infeasible — you either add capacity or slacken deadlines.

​

Time Decay

Both goals are discounted the further into the future they fall, so near-term commitments count for more than distant ones. Two separate decay settings control this — one for demand lateness, one for inventory: By default both apply a gentle decay. Flatten a decay to weight every interval equally, or steepen it so that only the near term carries weight.

​

Horizon

The horizon is a count of intervals plus an interval unit:

• Number of intervals — how many intervals the plan covers.
• Interval unit — the size of one interval. Typical values: day, week, month.

The interval count is exactly that — a count — so the horizon end is exclusive. A 4-interval weekly horizon starting 2026-06-01 covers 2026-06-01 through 2026-06-28, with interval indexes 0 through 3.

​

Resources

Resources are the constrained capacities production consumes — production lines, machines, labor pools, tanks, ovens. Each resource has a name and a unit (for example hours or pieces). Resources are declared on the model, but their per-interval capacity ceilings live on each run, not on the model — the same model can be run against a light week or a peak week without redefinition. See resource capacity for how run-level capacity works. The model also carries a bill of resources — the mapping from a BOM to the resources its production consumes and how much of each one unit of output requires. A single BOM can carry more than one bill-of-resources entry: each is an alternative production route (say, the same output made on a fast line or a slow one), and the plan is free to split production across them. These requirements live with the planning model, not on the BOM itself, so the same BOM can carry different resource usage under different models. A BOM with no bill-of-resources entry is unconstrained by capacity.

​

BOMs

The model carries an explicit list of the BOMs the optimizer sees. A BOM not attached to the model is invisible to the optimizer, even if it exists in the factory. This lets one factory carry several planning models with different scopes without cross-contamination.

​

Material Classification

Every attached BOM is classified automatically from its position in the BOM graph: Classification follows from the graph — you do not set it by hand.

​

Variants

Variants let one entity carry many recipes. A BOM can attach a variant condition — a set of attribute rules, all of which must hold — and the optimizer routes a demand line to a BOM when the BOM’s condition is a subset of the demand’s variant. A condition can test a yes/no flag, a value drawn from a fixed set of text options or numbers, or a numeric range. A BOM with no condition is the default recipe and matches any order for that entity. See BOMs for the full variant-condition syntax.

​

Order Tags

An order tag classifies demand orders and carries the objective parameters for that class. Every demand order references one tag. Note that the buffer is a pre-deadline margin, not post-deadline slack: it moves the zero-penalty point earlier — to the due date minus the buffer — so it pressures the optimizer to finish early, useful for orders that need packing or QA time between production and shipment. On a hard-deadline tag, the same buffer also tightens the hard constraint: the order must be fulfilled by the due date minus the buffer, not merely by the due date. For a soft deadline, leaving an order entirely unfulfilled is not free — its cost equals the lateness penalty evaluated at the end of the horizon (the maximum lateness). The optimizer therefore weighs “ship it late” against “don’t ship it at all” rather than treating non-fulfillment as costless.

​

Inventory Tags

An inventory tag classifies inventory goals. It is simpler than an order tag — just a type and a weight. An entity with no inventory goal behaves as rolling with zero weight — the optimizer holds whatever inventory the demand plan implies.

​

Custom Constraints

A planning model can carry optional custom constraints on top of the standard structure — for example minimum production quantities per interval, maximum daily output for a specific SKU, or sequencing rules. It can also carry custom objective terms — extra goals folded into what the optimizer balances, beyond the two built-in ones. Both are authored per model and apply to every run against it.