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 BOMs that describe how things are made, the resources production consumes and how each production route loads them, the demand-order and inventory-goal categories the plan will honor, and the Solver behavior that trades off the two competing objectives: hitting demand on time versus hitting inventory targets. One planning model is reused across many scenarios — the UI’s name for a planning run. The model is the template; each scenario supplies its own 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 pick how much each one matters under Solver behavior, in the model’s Strategy section: If the model’s weights were set to values that match none of the presets, its summary reads Custom. Presets are the only weights you can set in the UI; for exact values, ask Dexter. 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 scenario 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: You don’t set these directly in the UI: each Solver behavior preset sets both decays along with the balance. To flatten a decay (every interval weighted equally) or steepen it (only the near term carries weight), ask Dexter.

​

Horizon

The horizon is a count of intervals plus an interval unit, both set in the model’s Strategy section:

• Number of intervals — how many intervals the plan covers, from 1 to 2,000.
• Interval unit — the size of one interval: Day, Week, or Month. There are no other units.

A new model starts at 12 weeks. 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, a Unit (for example hours or pieces), and an optional Kind. A kind is a label you create for a group of resources, such as “Line” or “Oven”; resources without one show as Unclassified. In results, the Order Fulfillments chart can group its rows by kind. Resources are declared on the model, but their per-interval capacity ceilings live on each scenario, 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 capacity works.

​

Bill of Resources

The Bill of Resources section says how making each BOM’s output loads your resources. You author it as production routes: for each BOM, add one route per way of making it (Add production route, each with its own Route ID), say the same output made on a fast line or a slow one. The plan is free to split production across a BOM’s routes. Each route has:

• Lead time — how many intervals after production starts the output arrives. Components are consumed when production starts.
• Resource load per offset — for the start interval (Start day) and each interval after it through the lead time (Day +1, Day +2, …), how much of each resource one unit of output uses. The editor labels these offsets as days, but they count intervals of the model’s interval unit.

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 production route is unconstrained by capacity.

​

BOMs

The Bills of Materials section lists the BOMs that define producible items in this model. The component BOMs they reference are included automatically, all the way down, so you only select the top-level recipes. A BOM that is neither selected nor a component of a selected one 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 BOM in the model 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 — a type, plus a weight on rolling tags only. 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, or a maximum output per interval for a specific SKU. 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 scenario against it.