> ## 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.

# Simulation Overview

> How models, schedules, runs, snapshots, experiments, and Monte Carlo fit together in ProDex.

## Overview

Simulation in ProDex is discrete-event simulation, and it's a set of connected artifacts rather than a single feature. You build a **model** of your process on the [Modeler](/product/simulation-modeling) canvas, optionally drive it with a **schedule** of real production events, and execute it as a **run**. A run produces data you interpret through **KPIs** and **charts**. To compare scenarios, you capture **snapshots** of the model and pit them against each other in an **experiment**. To quantify the variability inside a single scenario, you replay it across many random seeds as a **Monte Carlo** batch.

This page is the map. Each artifact has its own page for the details, and [Your First Simulation](/getting-started/your-first-simulation) walks the whole loop once, hands-on.

## The Building Blocks

### Models

The model is the core artifact: the process graph plus the supporting data it references. It lives on the [Modeler](/product/simulation-modeling) canvas, where you drag in sources, processes, buffers, combiners, separators, transformers, routers, and sinks and wire the flow between them. Stations aren't flow nodes — they're a grouping construct that wraps processes, combiners, separators, transformers, and routers into a physical space. Attached to the model are the [entities](/reference/entities) that move through it, the resources (workers, machines, tooling) it consumes, and the [constants and lookup tables](/reference/constants-and-lookups) that parameterize it, plus any nested sub-models ([Model Nodes](/reference/model-nodes)). The [distributions](/reference/distributions) its stochastic logic draws from live inline in component fields rather than as a separate artifact.

A model is a living object: you edit it in place, revalidate, and re-run as your understanding of the process evolves. [Validation](/reference/validation) catches structural problems before you run.

### Schedules

A [schedule](/reference/schedules) is the operational layer on top of a model. Where the model describes *how* the process works, a schedule describes *when* specific things happen, anchored to real calendar time: **material releases** inject specific entities at specific times, and **scheduled actions** fire variable assignments or events at specific moments. A model can have many schedules — a baseline week, a high-demand scenario, a maintenance window — and you pick the active one in the Modeler's top bar. Swapping the schedule swaps the operational scenario without touching the model itself.

<Warning>
  At a Source, material releases **coexist** with the Source's own arrival logic: both fire, and scheduled releases fire even when the Source is paused. If you want schedule-only arrivals, use an event-only Source with no arrival logic. See [Schedules](/reference/schedules).
</Warning>

### Runs

A run is one execution of one model against one schedule (or against the model's plain duration when no schedule is active). It produces a complete record of what happened — entity lifecycles, process activity, resource activity — which the [Results](/product/results-and-analytics) view reads. Runs are stored under their parent model, and each one traces back to the configuration it executed.

After the simulation itself finishes, ProDex computes the run's KPIs and charts in a second pass: a run shows as *pending* while that pass is working and *ready* once its numbers are populated.

### KPIs and Charts

**KPIs** are single numbers: throughput, average WIP, utilization. **Charts** are visualizations: throughput over time, utilization by resource, a queue-length histogram. Both are authored on the model — describe what you want and [Dexter](/product/dexter/chat-and-tasks) writes the underlying query — so every subsequent run computes them automatically. They are the interpretation layer that turns a run's raw data into an answer. See [Results and Analytics](/product/results-and-analytics).

### Snapshots

A [Snapshot](/reference/snapshots) is a frozen, self-contained copy of the model **and** its active schedule at a point in time — the full recursive bundle, including the entities, constants, lookup tables, and sub-models the model references. The live model keeps changing as you edit; snapshots don't. That immutability is what makes results reproducible: you can reload a snapshot onto the canvas, hand it to a teammate, or compare it against others in an experiment, and the configuration won't have drifted.

Capture one from the disk icon in the Modeler's top bar whenever you reach a configuration worth keeping: a calibrated baseline, a candidate change, a scenario you'll want to compare later.

### Experiments

An [Experiment](/product/experiments) is the comparison harness: point it at two or more snapshots — baseline, extra capacity, alternate schedule — and run them side by side. KPIs lay out across snapshots on a shared axis so you can see which option wins and by how much. The model's existing KPIs fold into the comparison automatically, but its charts do not — a chart in an experiment needs an experiment-scoped query authored for it.

### Monte Carlo

A [Monte Carlo](/product/monte-carlo) batch answers a different question: not *which option is better* but *how much does this option's outcome vary from randomness alone?* It re-runs one configuration across many random seeds and reports the distribution — mean, percentiles, histograms, box plots — instead of a point estimate. Two things have to be in place first: the configuration needs genuine stochastic content (a fully deterministic model produces identical replications with no spread to measure), and the KPIs you want distributed have to already exist on the model when the batch is queued.

<Tip>
  Experiments vary the **scenario**; Monte Carlo varies the **randomness**. Use experiments to pick between options and Monte Carlo to know how much to trust the numbers. To get both, run a Monte Carlo batch against each candidate configuration separately.
</Tip>

## How the Pieces Fit Together

The typical arc:

1. **Build** the model on the canvas: wire the flow, define entities, set the distributions your timing and routing logic draw from, add constants, get [validation](/reference/validation) green.
2. **Attach a schedule** if the scenario needs real operational timing; otherwise the model's duration field is enough.
3. **Run it.** The simulation executes, then the results pass computes your KPIs and charts.
4. **Analyze** in [Results](/product/results-and-analytics): read the KPIs, inspect the charts and event log, iterate on the model, run again.
5. **Compare scenarios.** Capture a snapshot per candidate configuration and assemble them into an [experiment](/product/experiments).
6. **Quantify variability** with [Monte Carlo](/product/monte-carlo) before trusting a scenario with a real decision.

| Artifact      | Where it lives                                                                                         |
| ------------- | ------------------------------------------------------------------------------------------------------ |
| Model         | The Modeler canvas; every model belongs to a factory                                                   |
| Schedule      | Defined per model; selected in the Modeler top bar                                                     |
| Run           | Stored under its model; opened from Results                                                            |
| KPIs & charts | Authored on the model; values computed per run                                                         |
| Snapshot      | Captured from the Modeler top bar; listed in the snapshot picker and experiment sidebar                |
| Experiment    | The Experiments section in the left rail                                                               |
| Monte Carlo   | Its own batch artifact, triggered against a model and schedule; results open from the Monte Carlo view |

<Info>
  You don't have to drive any of this by hand. [Dexter](/product/dexter/chat-and-tasks) can build models, capture snapshots, trigger runs, author KPIs and charts, and assemble experiments from chat — and a full improvement study can run as a multi-session project. See [Simulation Studies](/product/simulation-studies).
</Info>

## Limits and Caveats

* **You can't experiment on the live model.** Every comparison row in an experiment is a snapshot. To compare "baseline vs. change," capture both first.
* **Model edits don't propagate to snapshots.** A snapshot is a freeze, not a reference. To pick up changes in an experiment, capture a new snapshot and add it alongside the old one.
* **Deleting a snapshot that an experiment references breaks that experiment.** Remove it from the experiment's snapshot list first. See [Snapshots](/reference/snapshots) for the safe order of operations.
* **Results arrive in two stages.** A run whose KPIs haven't populated yet is *pending*, not broken — the simulation finished and the results pass is still computing. If the results pass fails, it can be retried without re-simulating.
* **Monte Carlo reports only completed seeds.** Failed seeds are dropped from the pooled statistics — check the completed-seed count before quoting tail percentiles from a small batch.
* **The UI follows one active selection.** Results, chart authoring, and the run picker read the currently active model, run, and schedule, so confirm you're looking at the run you think you are before comparing numbers.

## Where to Go Next

* [Your First Simulation](/getting-started/your-first-simulation) — build and run the loop once
* [Modeler](/product/simulation-modeling) — the canvas, every component type, and the run controls
* [Simulation Studies](/product/simulation-studies) — running a full improvement study as a multi-session project
* [Results and Analytics](/product/results-and-analytics), [Experiments](/product/experiments), [Monte Carlo](/product/monte-carlo) — the analysis surfaces
* Reference: [Entities](/reference/entities), [Schedules](/reference/schedules), [Events](/reference/events), [Distributions](/reference/distributions), [Expressions](/reference/expressions), [Constants & Lookup Tables](/reference/constants-and-lookups), [Validation](/reference/validation), [Snapshots](/reference/snapshots), [Model Nodes](/reference/model-nodes), [Combiners, Separators & Transformers](/reference/batching)