Guide
Assumptions & Validation
Every constraint in your model is an assumption about the real world. The assumptions ledger tracks where each number came from, how confident you are, and what happens if it's wrong.
Assumptions ledger
The ledger is a table of every constraint in your model with metadata about its quality. For each constraint, you can record:
The current number used in the model.
Plausible bounds for sensitivity and Monte Carlo analysis.
Where the number came from (report, measurement, estimate).
Who is accountable for this assumption.
High, Medium, Low, or Unspecified.
Measured, Estimated, Placeholder, or Imported.
Free-text context about the assumption.
When this assumption was last reviewed.
The ledger also computes an impact score (0-100) for each constraint based on its sensitivity (pressure score) — how strongly the result depends on that limit. Confidence, source, and value type are shown separately and used to flag validation priorities.
Source and owner
Recording the source matters because it tells anyone reviewing the model whether a number is grounded in data or a rough guess. Common sources include:
- -Vendor spec sheet or contract
- -Historical production data (last 6 months average)
- -Engineering estimate from team lead
- -Placeholder — needs validation before decision
The owner field tracks accountability. When validation is needed, the owner is the person to ask.
Confidence
Each constraint can be tagged with a confidence level:
Based on recent measurement or confirmed data. You'd bet on this number.
Based on a credible estimate or slightly dated data. Reasonable but could shift.
A rough guess, analogy from a different context, or an unverified assumption.
Not yet assessed. The ledger flags these for review.
The overall model confidence is derived from the individual constraint confidences, weighted by impact. A single low-confidence, high-impact constraint can pull the overall confidence down.
Low / base / high ranges
For each constraint, you can set a low and high estimate alongside the base value. These ranges feed into sensitivity analysis. Stochastic feasibility uses a separate uncertainty control:
Set an uncertainty percentage on each constraint to enable Monte Carlo sampling. The solver draws random offsets within that percentage (triangular or uniform distribution) and checks whether the plan stays feasible. The result is a feasibility rate (e.g., "87% of samples are feasible") and failure attribution.
You can also set an uncertainty percentage (0-40%) per constraint, which automatically creates a symmetric range around the base value. This is faster than manually setting low/high for every constraint.
Caveats
The assumption summary generates caveats — plain-language warnings about model quality. These appear in the decision brief and flag issues like:
- -"3 constraints have no source — the model rests on unverified numbers"
- -"The top bottleneck uses a placeholder value"
- -"2 high-impact constraints have no confidence rating"
- -"Low/high ranges are missing for 4 constraints — stochastic analysis is incomplete"
Caveats are not errors — they're transparency markers. They ensure that anyone reading the decision brief can see which inputs are sourced and which need review.
Validation checks
Before solving, SSPLAX runs structural validation on the model and flags issues:
A node with no edges — it can't participate in the optimization.
The model needs at least one entry and exit point.
An edge where min > max, or a constraint where the default is out of bounds.
No path from any source to this sink — flow can't get there.
Yield must be between 0 and 1 (exclusive).
Cost segment breakpoints must be increasing and rates must be non-negative.
For more validation details, see the Reference page.