Guide
Build a Model
Start with the shape of the decision, then add only the mechanics it needs. Every Form uses the same validated linear or mixed-integer model contract, but authoring stays in the language of routing, blending, selecting, or assigning.
Choose the Form
Move quantity through stages and routes.
Choose input amounts for one blend and its property limits.
Select candidates into windows under shared limits.
Place items into eligible destinations under shared limits.
Form changes the canvas, section headings, and solved visual. It does not switch to a different solver. A Portfolio or Assignment may still contain supporting flows, and those technical fields remain available in Model data.
Set the model's depth
Model setup groups optional mechanics under Structure, Time, Limits, Uncertainty, Data, and Measures. Turn on planning periods, soft limits, scenarios, spreadsheet input, carbon, or other depth only when the decision needs it. Mechanics that are off stay out of authoring and Results.
A capability already used by the model is either locked by its Form or removed with its authored data after confirmation. Enabling a capability exposes its controls but does not invent model data.
Network stages and routes
Nodes represent stages in your system: sources, processes, queues, and outputs. Every model has at least one source (where material enters) and one sink (where it exits).
Entry point for raw material, inbound demand, or an input stage.
Exit point for delivered output or a final destination.
A service, tool, or machine that transforms flow.
A buffer or inventory point between stages. Supports holding cost and max storage for inventory economics.
In the Model Editor, you add nodes, rename them, and connect them with flows. Drag nodes on the canvas to arrange them. Layout does not affect the solve, but a clear topology makes the system easier to reason about.
Flows and paths
A flow connects two nodes and carries exactly one named product in one direction. Each product has its own quantity unit, and each flow has a minimum and maximum defining the feasible range.
The solver decides how much moves along each flow to meet the objective while respecting all limits. A path from source to sink may pass through multiple intermediate nodes, and the solver optimizes the entire network simultaneously.
If a stage loses material (e.g., 72% yield in a manufacturing step), set the yield ratio on its outbound flow. Output = input × yield. The solver accounts for this when computing end-to-end output, so yields compound across consecutive stages. Flow bounds and resource rates apply to the flow's input side; the next node receives the yielded output.
Flow is conserved separately for every node, product, and period, so merged branches cannot exchange product identity. Ordinary flows only route the selected product. To transform one product into another, add an explicit conversion with input and output amounts, such as one bulk batch producing 900 finished vials. Conversion activity can be continuous, whole-number for full batches, or a yes/no decision, and can consume shared resources at rates per activity unit.
Mark a flow as reversible to allow movement in either direction. Useful for modeling transfers between work centers or bidirectional material movement.
Set a flow's decision type to "yes/no" when the decision is on/off rather than how-much. The solver treats these as 0/1 decisions, so the flow is either active or inactive. You can also force a yes/no flow on or off to test specific configurations.
Capacities and limits
Flow bounds (min/max) define what's physically possible for each flow path. The min is typically 0; the max is the stage's capacity. When you adjust these on the Constraints screen, you're telling the solver the feasible range for each path.
If the solver returns a flow at its maximum, that flow is capacity-constrained. Check the constraint shadow prices in the results to understand which limits are most worth relaxing.
Costs, demand, and resources
Each flow can carry multiple cost and resource overlays:
USD per unit of flow. When minimizing cost, the solver routes flow through the cheapest available paths. Cost rates also appear in budget constraints.
Define breakpoints where the cost rate changes. For example, the first 100 units cost $5/unit, the next 50 cost $8/unit. The solver picks the optimal volume on each segment.
Tonnes of CO₂ per unit of flow. Feeds into carbon cap constraints and the carbon minimization objective.
Define any resource (FTEs, GPU hours, water, energy) and attach consumption rates to flows. Enter its quantity unit only (for example, hours). Flow rates are hours per unit of flow, while availability limits are hours per planning period. Changing units relabels values; it does not numerically convert them.
Constraints
Constraints are the real-world limits the solver must respect. On the Constraints screen, you set each constraint's value within its allowed range using sliders.
Total cost across all paths cannot exceed this amount (USD).
Total CO₂ emissions across the network cannot exceed this limit.
Throughput through a specific stage or path is capped at this rate.
Total consumption of a custom resource (FTEs, GPU hours, etc.) is capped.
A minimum delivery requirement at a specific output point.
For details on each type, see the Reference page.
How firm is each limit?
Constraints differ in kind. A shared QC pool and a regulatory release requirement are both limits, but only one is a reasonable thing to propose relaxing. Each constraint carries a Decision interpretation that says which it is.
A normal operating limit. Eligible to appear in recommendations and repair suggestions. This is the default.
Remains visible in binding analysis, so its influence on the plan is clear, but is never proposed for relaxation and cannot be softened. Use it for commitments that are not available to trade away.
Can be relaxed, but any result that does so is labeled as policy relief, so a recommendation depending on a relaxed commitment is never presented as routine.
Alongside that, each constraint can be enforced two ways:
The plan must satisfy it. If it can't, the model is infeasible.
The solver may exceed the limit, but pays your Penalty / violation unit for every unit it does, up to an optional Maximum violation. This turns a preference into an explicit price rather than a hard wall.
Two more fields shape what happens when things go wrong. Implementation cost / unit records what relaxing this limit would actually cost in practice, and Repair priority makes a constraint progressively more expensive to change when SSPLAX assembles a combined repair for an infeasible model. Each priority level raises its cost by roughly an order of magnitude.
Soft enforcement asks whether violating a limit is worth its penalty during normal operation. Combined repair asks for the smallest change package that makes an infeasible model work. Decision interpretation determines which limits may appear in that answer at all. The three are independent, and are set independently.
Choices that aren't flows
Some decisions have no natural reading as a quantity moving along a path: which supplier to qualify, whether to add a shift, which sites to open. Model those as decision alternatives rather than inventing flows to stand in for them. A decision option can carry its own costs, consume resources, add capacity, enable or disable flows, or deliver output directly.
See Decisions & Targets for the full set of controls, including requires/excludes rules and target seeking.
Objectives
The objective is what you're optimizing for. Each template defines one or more:
Push as much flow as possible from sources to sinks. The most common objective.
Find the lowest-cost plan that still meets all minimum delivery requirements.
Minimize total consumption of a specific resource (carbon, FTEs, energy) while meeting delivery requirements.
On the Objective screen, if the template has minimum delivery requirements, you'll also set the required delivery levels before proceeding.
Common modeling patterns
Most real-world models fall into a few recurring shapes:
One source feeding multiple parallel paths (e.g., demand split across suppliers). The solver decides how much flows through each.
Stages in series with yield losses at each step. The binding constraint is usually the tightest stage, not the last one.
Two parallel paths that merge before the sink. Useful for comparing routes (e.g., build in-house vs. outsource) under a shared budget.
The same network solved across multiple time periods with demand growth, constraint schedules (flat, growth, step, ramp), ramp rates, carry-over, backlog, and inventory economics between periods. Set this up on the Constraints screen.
A set of options where only some can be chosen, such as suppliers, sites, or upgrades. Model it as a decision group with selection bounds rather than as parallel flows, so the choice carries its own costs, effects, and dependency rules.
For step-by-step walkthroughs, see Modeling Playbooks.