Monte Carlo Forecasts: Test Assumptions Before Percentiles

A Monte Carlo forecast repeatedly samples uncertain inputs and runs a model to show a range of possible outputs under those assumptions. More simulations can reduce sampling noise, but they do not repair a wrong business model or unsupported input distribution. Review the assumptions before presenting a precise percentile.

NumPy's random Generator documentation describes supported sampling tools, while NIST's uncertainty guidance provides broader context for careful uncertainty treatment. This article uses invented business examples for education, not personalized financial advice or a claim of measured future probabilities.

Start with a deterministic model

Build a calculation that works for fixed known inputs before adding randomness. For example, a delivery model might calculate total work time from setup time, number of jobs, and processing time per job. Test those relationships using simple cases you can calculate by hand.

Keep units and periods consistent. Sampling weekly sales while applying a monthly cost without conversion creates a logical error that additional iterations will reproduce efficiently. Label each input's unit, timing, and source.

Test impossible and boundary states explicitly. Negative job counts, an invalid capacity, or a missing price should not silently become plausible results. Necessary input validation belongs in the model rather than being hidden by a blanket error-to-zero formula.

Explain each uncertain input

For every distribution, record why it was chosen and what evidence supports its range and shape. Historical observations, contractual limits, expert estimates, and pure scenarios provide different kinds of support. Do not present an invented distribution as an observed market pattern.

An equally weighted range is a modelling choice, not a statement that all values are naturally equally likely. A bell-shaped distribution can generate implausible negative values for some quantities unless the model handles its domain appropriately. Choose a supported representation that respects the variable's meaning.

Keep uncertain estimates separate from known constants. A fixed signed fee need not be randomized simply to make the simulation look sophisticated. Conversely, uncertainty about a major assumption should not disappear because the current spreadsheet contains only one convenient number.

Model dependencies deliberately

Sales, support workload, refunds, and infrastructure usage may move together. Sampling them independently can create combinations that do not represent the business. Record dependencies and test whether the model preserves the relationships that matter.

For an invented example, each accepted order creates one delivery and an associated variable cost. Sample the order volume, then derive the delivery cost from that volume under the stated cost rule. Independently sampling total cost from an unrelated range can break that relationship.

Where dependence is genuinely uncertain, compare clearly labelled assumptions rather than pretending it is known. Do not infer a stable correlation from a handful of observations without appropriate analysis. Sensitivity to the dependency can be a useful finding in itself.

Make the run reproducible

Record the code or workbook revision, input definitions, sampling procedure, random seed where applicable, library version, and number of iterations. A seed can help reproduce a run under the same supported environment; it is not a universal guarantee across every algorithm and version.

Keep the original input set with the output. If a reviewer sees only a histogram, they cannot tell whether a wider result came from new evidence, a changed formula, or a different distribution assumption. Version the explanation and calculation together.

Use approved synthetic or properly protected operational data. A forecasting script does not need unrestricted access to customer records merely to sample a volume distribution. Preserve the same data-minimization standards used in ordinary analytics.

Interpret percentiles accurately

If a simulated completion-time result has a 90th percentile of 12 days, describe it as a percentile of the modelled output under the stated assumptions. Do not automatically promise a 90% real-world on-time guarantee. Calibration requires evidence comparing forecasts with later outcomes.

Also check which direction represents risk. A low cash-balance percentile and a high completion-time percentile can be concerning in different ways. Label the quantity and tail instead of calling every 90th-percentile number the “safe case.”

Report enough of the distribution to show relevant downside and uncertainty. An average can conceal a meaningful tail, while a single extreme simulated value may be unstable. Choose summaries suited to the decision and explain the modelling limits plainly.

Test convergence and sensitivity separately

Repeat runs or increase iterations to see whether the reported summaries stabilize sufficiently for the intended use. That checks sampling noise. Then vary major assumptions to inspect model sensitivity, which answers a different question.

Do not treat a stable percentile as proof that the assumptions are correct. A model can converge tightly to a misleading result. Compare with simpler scenarios, historical outcomes where available, and the domain review appropriate to the decision.

JSON Diff can compare redacted simulation configurations and CSV Viewer can inspect exported summaries. Neither runs Monte Carlo simulations. Our runway scenario guide covers deterministic cash scenarios, which remain useful alongside simulation.

Conclusion

Monte Carlo methods expose consequences of uncertainty only as well as the underlying model represents it. Verify deterministic logic, distributions, dependencies, reproducibility, and percentile meaning. More iterations improve numerical stability, not the truth of an unsupported forecast.