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 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 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 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 that move through it, the resources (workers, machines, tooling) it consumes, and the constants and lookup tables that parameterize it, plus any nested sub-models (Model Nodes). The 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 catches structural problems before you run.Schedules
A schedule 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.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 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 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.Snapshots
A Snapshot 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 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 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.How the Pieces Fit Together
The typical arc:- 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 green.
- Attach a schedule if the scenario needs real operational timing; otherwise the model’s duration field is enough.
- Run it. The simulation executes, then the results pass computes your KPIs and charts.
- Analyze in Results: read the KPIs, inspect the charts and event log, iterate on the model, run again.
- Compare scenarios. Capture a snapshot per candidate configuration and assemble them into an experiment.
- Quantify variability with Monte Carlo before trusting a scenario with a real decision.
You don’t have to drive any of this by hand. Dexter 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.
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 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 — build and run the loop once
- Modeler — the canvas, every component type, and the run controls
- Simulation Studies — running a full improvement study as a multi-session project
- Results and Analytics, Experiments, Monte Carlo — the analysis surfaces
- Reference: Entities, Schedules, Events, Distributions, Expressions, Constants & Lookup Tables, Validation, Snapshots, Model Nodes, Combiners, Separators & Transformers