> ## Documentation Index
> Fetch the complete documentation index at: https://docs.prodexlabs.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Monte Carlo

> Run repeated simulations with different random seeds to quantify the distribution of outcomes.

## Overview

A single simulation run is one random draw from your model's behavior — one path through every stochastic primitive: [distributional](/reference/distributions) processing times, probabilistic routing, sampled arrivals. Monte Carlo runs the same configuration many times with different random seeds and reports the **distribution** of outcomes: central tendency, spread, and — through the charts you author — the shape of the tail.

That's the difference between *"throughput is 847 units/day"* and *"throughput is 847 on average, and here's how often it lands below 800."* Monte Carlo is the tool for **single-configuration uncertainty quantification** — it answers *how tight is this number?* To compare different configurations, use [Experiments](/product/experiments), which answer *does this change move the metric?*

<Tip>
  **Monte Carlo varies the random seed, not your parameters.** For parameter sweeps (*what if I add a CNC machine?*), capture multiple [Snapshots](/reference/snapshots) and compare them in an [Experiment](/product/experiments) — optionally with a Monte Carlo batch per Snapshot.
</Tip>

## Before You Run

* **Stochastic content is required.** A fully deterministic model and schedule produce N identical replications — if nothing re-rolls per seed, there is no variance to measure. Add distributional processing times, probabilistic routing, or randomized arrivals first.
* **KPIs are captured at queue time.** The batch aggregates the KPIs defined on the model at the moment it's queued; there is no way to add a KPI to a completed batch. Confirm the KPIs you want distributions for exist before queueing.

## Running a Batch

Monte Carlo has its own **Monte Carlo** section in the left rail, and is also reachable from the **Monte Carlo** button in the top bar of any Run's [Results](/product/results-and-analytics) page — whether that's a plain run or a Snapshot's run inside an experiment.

The **Run Monte Carlo** modal takes an **N Runs** input — the number of seeds to sweep:

* **Default 100** — a solid starting point for central-tendency claims on most models.
* **200+** — when you care about tail percentiles (P95 and beyond); tail estimates from small batches are noisy.
* **Hard maximum 1,024 per batch** — queue multiple batches if you need more.

A batch runs against the model and, if your model uses one, its schedule — the schedule is optional, not required to launch a batch. Batches run asynchronously in the background; seeds land on the results page as they complete. Wall-clock time is typically several minutes, growing with seed count and model complexity.

## Reading Your Results

* **Per-KPI summary cards** show the **mean, standard deviation, min, max, and median (P50)** for every KPI on the model. These render from a system-seeded summary query — no authoring required. Tail percentiles like P95 and P99 are *not* on the cards; those come from distribution or CDF charts that [Dexter](/product/dexter/chat-and-tasks) authors when you ask.
* **Distribution charts** — histograms per KPI, box plots, and any Monte Carlo–scoped charts you author — render below the summary cards.
* **Per-seed rows** click through to that replication's full Run Results page — event log, per-run charts, everything — which is how you chase an outlier seed and understand what made it extreme.
* **Only successful seeds count.** If some seeds fail, they're excluded from every aggregate — the summary cards and every chart are computed over the seeds that completed. A batch with partial failures still reports as succeeded; the batch summary carries the total, successful, and failed seed counts, so check them before reading the sample size behind a statistic.

## Building Charts

Monte Carlo has its own chart-authoring view, distinct from Run charts — and in practice you build these charts by asking Dexter:

* MC charts visualize **across replications**: histograms, box plots, scatters of one KPI against another, cumulative distribution curves.
* Queries run against a **per-seed KPI view** — one row per seed and KPI — the same surface ad-hoc SQL uses. Filter by the exact KPI names from the batch summary.
* MC charts **auto-evaluate against every batch** for the model, past and future: author a chart once and it appears on the results of every batch that has already run.
* Author them through [Dexter](/product/dexter/chat-and-tasks), the same way as Run and Experiment charts: describe what you want and Dexter writes the query.

## Interpreting Results

* **Tight distributions are reassuring.** A small spread relative to the mean means the model is robust to stochastic re-rolls under this configuration.
* **Wide distributions are a signal.** Stochastic primitives are driving material variance; a number quoted from a single run is misleading without a range around it.
* **Tails matter for SLAs.** Central tendency doesn't tell you how often you miss a commitment; percentiles do.
* **Identical distributions across two batches with a change between them** mean the change doesn't move the metric under this level of noise — often a genuinely useful finding.

<Note>
  **Check convergence before quoting a tail percentile.** If a P95's rolling mean across seeds is still trending at the last seed, the number isn't stable — run more seeds or quote a less tail-sensitive metric.
</Note>

## Common Pitfalls

* **Confusing Monte Carlo with Experiments.** Many seeds under one configuration versus many configurations. Use both when both questions matter.
* **Reading P95/P99 off too few seeds.** Those percentiles come from distribution charts you author, not the summary cards — and tail estimates from 50 seeds are noisy enough to invert conclusions. Bump to 200+ and re-check convergence.
* **Adding a KPI after queueing.** The batch only aggregates KPIs that existed at queue time. Define the KPI, then queue a fresh batch.

## Related Features

* [Results](/product/results-and-analytics) — the Run-scoped surface where individual seed runs render
* [Experiments](/product/experiments) — comparing multiple Snapshots side by side, with Monte Carlo per Snapshot
* [Snapshots](/reference/snapshots) — immutable model captures for comparison cases
* [Insights](/product/insights) — durable dashboards independent of any single simulation