Experiments

​

Overview

A single simulation run tells you what happens with one set of inputs. An experiment tells you what happens across many. Experiments in ProDex let you compare multiple scenarios side by side — different model configurations, different schedules, different parameters — and see how your KPIs change across them. Combined with Monte Carlo simulation, experiments also answer a deeper question: not just what your expected performance is, but how confident you should be in that number.

​

What Is Monte Carlo Simulation?

In any real factory, there’s variability. Processing times fluctuate. Machines go down unexpectedly. Demand shifts. A single simulation run uses one random draw from every distribution in your model — it’s one possible version of reality. Monte Carlo simulation runs the same model dozens or hundreds of times, each with a different random seed. Every run produces slightly different results because the stochastic elements (processing time distributions, arrival patterns, failure rates) play out differently each time. The result is a distribution of outcomes rather than a single number. Instead of “throughput is 847 units/day,” you get “throughput is 847 units/day on average, with a standard deviation of 23, and a 95th percentile of 891.” That’s the difference between a point estimate and a decision you can actually trust.

​

Setting Up an Experiment

An experiment lives inside a model. Open the Experiments section in the left rail and use the experiment selector at the top to + Create new experiment. The dialog (titled “New experiment”, with the subtitle “Give this experiment a name so you can come back to it later.”) asks for two fields only — Name (required) and Description (optional) — and submits with a Create experiment button. The experiment selector also exposes inline rename (pencil) and delete (trash) icons on hover for existing experiments. Deletion is immediate, with no confirmation step. Once an experiment is selected, the sidebar has three sections — Snapshots, KPIs, Charts — plus a chevron at the top of the Snapshots header to collapse the entire sidebar to a thin vertical strip. (Before an experiment is selected, only the Snapshots header renders, with the helper text “Select an experiment to manage its snapshots, KPIs, and charts.”)

​

Adding Snapshots to Compare

The work of an experiment is comparing the results of running multiple Snapshots of a model side by side. Each row in the Snapshots sidebar section is one configuration that will be simulated when you click Run. Each row shows a small color dot, the Snapshot name, and an X to remove it. Adding a Snapshot is a single click. The Snapshots row exposes a small chevron (˅) on the right edge of the pill container — clicking it opens a popover with a search field (“Select snapshot to add…”) and the full list of Snapshots authored on the model. Each row shows the Snapshot’s color dot and name, with a checkmark on the right if it’s currently in the experiment. Clicking a row toggles that Snapshot’s membership: an unchecked row gets added to the experiment immediately (no confirm step); a checked row is removed. You can also remove a Snapshot from inside the pill container by clicking its X — also instant, no confirmation. If you need a Snapshot that doesn’t appear in the picker, create it from the Modeler’s save (disk) icon or by asking Dexter — it’ll show up in the picker as soon as it’s saved. The schedule attached to a comparison row is whatever schedule was active when the Snapshot itself was captured in the Modeler — Snapshots are immutable freezes of model + schedule, so the experiment view never re-asks for a schedule. If you want to compare the same model against multiple schedules, capture Snapshots while each schedule is active and add them as separate rows. For example, you might compare three Snapshots:

​

Selecting KPIs and Charts to Compare

The KPIs and Charts sidebar sections are visibility checklists — they toggle what surfaces in the comparison view. Each toggle saves immediately on click; there’s no separate Save button. The two lists behave differently:

• KPIs auto-fold. Every KPI authored on the underlying model appears in the experiment’s KPI checklist, ready to lay out across Snapshots. The model is the source of truth.
• Charts do not auto-fold. Model-scoped charts stay on the Results page. To render a chart in an experiment, author it directly on the experiment — the Charts checklist lists experiment-scoped charts only.

When the Charts section is empty, the sidebar reads “No charts available.” The supported authoring flow lives on the model’s Results page (for model-scoped KPIs and charts) and on the experiment itself (for experiment-scoped charts). Both paths use Dexter dialogs that take a natural-language description and write the underlying query for you.

​

Chart Types Supported in the Comparison View

The experiment comparison view renders only three chart types: Bar, Line, and Scatter. Any other type — Stacked Bar, Table, Box Plot, Histogram, Area — is silently dropped at render time and the chart simply will not appear on the dashboard. Under the hood, each experiment-scoped chart query is authored against a single Snapshot’s data, exactly like a single-run chart. The platform then pivots the query result into a multi-series chart with one series per Snapshot. Because of this pivot, the source query must produce exactly one series — multi-series source queries are also dropped. Note that model-scoped charts do not auto-fold into the experiment dashboard. KPIs on the model do auto-fold (which is why the KPIs sidebar simply lists the model’s KPIs), but charts on the model do not — to render a chart in an experiment you need an experiment-scoped chart query.

​

Running an Experiment

The top bar of the experiment view shows: a back arrow, the model name, the experiment selector, and a green Run button (play-triangle icon) on the right. The Run button is always present once an experiment is selected — the platform doesn’t gate it on Snapshot count at the UI level. With zero Snapshots the run errors at execution; a single-Snapshot experiment is technically runnable but produces no comparison. With two or more Snapshots, clicking Run fans out one simulation per Snapshot in parallel. Snapshots that already have a completed run are cached — their simulations are not re-run, but their queries are recomputed against the cached datasets, so re-running an experiment to pick up a new KPI or chart is fast. Monte Carlo at the experiment level isn’t its own subview today — to run a seed sweep on an experiment, see the Monte Carlo controls on the Results page. For a single Snapshot, MC is one click away from any Run’s Results page; the experiment Run button itself runs each Snapshot once. For most models, 100 Monte Carlo seeds per Snapshot give a good balance of statistical reliability and runtime when you do want a sweep. Push to 200+ when you care about tail metrics (P95/P99) — the tails need more samples to stabilize. Hard maximum is 1,024 seeds per batch.

​

Empty States

The main panel shows different copy depending on where you are in the flow:

• No experiment selected — “Select an experiment above, or create a new one to get started.”
• Experiment with fewer than two Snapshots — heading “Pick snapshots to compare” with subtitle “Select at least 2 snapshots on the left to compare them.”
• Experiment with Snapshots but every KPI and chart toggled off — heading “Nothing to show” with subtitle “All KPIs and charts are hidden. Re-enable at least one in the left sidebar to see results.” Re-enable at least one KPI or chart in the sidebar.

Treat these as navigation cues — each one tells you what’s missing to make the comparison view render.

​

Analyzing Experiment Results

​

Single-Snapshot Monte Carlo Results

When viewing Monte Carlo results for a single Snapshot, you see:

• Statistical summaries for each KPI — mean, standard deviation, median, and percentiles (25th, 75th, 90th, 95th, 99th)
• Histograms showing the distribution of each KPI across all seeds
• Box plots visualizing the spread (min, quartiles, max)

A tight distribution means the result is reliable regardless of variability. A wide distribution means the model’s performance depends heavily on how stochastic events play out — important to know before making decisions.

​

Cross-Snapshot Comparison

When comparing multiple Snapshots in an experiment, results are displayed side by side. Today the comparison view contains:

• KPI comparison grid — one card per visible KPI, with a horizontal bar (and the numeric value) for each Snapshot in the experiment, on a shared axis. This is the default surface and renders for every KPI you leave toggled on in the sidebar.
• Experiment charts — bar, line, or scatter charts authored on the experiment itself. Each one renders as a single multi-series chart with one series per Snapshot.

The comparison view answers questions like: does adding a machine actually improve throughput, or does the bottleneck just move? How much does the peak-season schedule stress our resources compared to baseline? Multi-series histograms, box plots, and statistical summary tables are not part of the experiment comparison view today. For per-Snapshot distributional analysis (histograms, box plots, percentiles), open the Snapshot’s individual Run on the Results page — those views support the full chart and statistical surface.

​

Comparing Scenarios

Inside the Experiments section you can:

• Add or remove Snapshots in a comparison via the Snapshots sidebar
• Toggle which KPIs and Charts surface in the comparison view via the KPIs and Charts checklists
• Re-run an experiment at any time — completed Snapshots are cached, so only newly-added Snapshots actually re-simulate

For the distributional view of any single Snapshot — full per-KPI percentiles, histograms, and box plots — open that Snapshot’s individual Run on the Results page. Experiment results are stored permanently and can be revisited at any time. To incorporate model changes, capture a new Snapshot and add it to the experiment — the prior Snapshots and their results stay available for comparison alongside the new one.

​

When to Use Experiments

Start with single runs while building and debugging your model. Once the model is stable and you’re making decisions, use experiments to compare options and Monte Carlo to quantify confidence. The combination of both is what turns a simulation from a rough estimate into a rigorous basis for operational decisions.