Guide
Assumptions & Validation
Model input values represent assumptions about the real world. Input documentation records the evidence behind them: where each number came from, who owns it, how confident you are in it, and what still needs review.
Input documentation
Input documentation is metadata about the model inputs. It does not change the baseline solve. The solver still uses the constraint value you set on the Constraints screen; these fields explain how trustworthy and review-ready that value is.
The current number used in the model.
Where the number came from (report, measurement, estimate).
Who is accountable for this assumption.
Your confidence in this input value: High, Medium, Low, or Unspecified.
Measured, Estimated, Placeholder, or Imported.
Optional review bounds for documenting what range still needs validation.
Free-text context about the assumption.
When this assumption was last reviewed.
Results use this documentation to flag validation priorities: high-impact inputs with missing sources, low input confidence, placeholder values, or missing review bounds deserve attention before the answer is shared.
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.
Input confidence
Confidence means your confidence in the input value, not the solver's confidence in the answer. It is a documentation signal used for review and reporting.
Based on recent measurement or confirmed data.
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. Input documentation flags these for review.
A low-confidence, high-impact input does not make the optimization mathematically invalid. It means the decision depends on a number that should be validated.
Review bounds and uncertainty
There are two different ideas that both look like ranges:
Documentation bounds for the input. They help reviewers see what range still needs validation, but they do not change the baseline solve or stochastic sampling.
A solver control for robustness analysis. When it is non-zero, stochastic feasibility samples around the constraint value and reports how often sampled scenarios remain feasible.
Caveats
The input documentation summary generates caveats — plain-language warnings about documentation 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"
- -"Review bounds are missing for 4 high-impact inputs"
Caveats are not solver errors. They flag which inputs are well documented and which still need review, so nobody reading the brief has to guess.
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.