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

# Runs

> A run is one execution of a simulation model: the model, an optional schedule, and the full dataset of results the simulation produced.

## Overview

A **run** is one execution of a [simulation model](/product/simulation-overview) — the model, an optional [schedule](/reference/schedules), and the full dataset of results the simulation produced. Runs are how you turn a model into numbers you can read: throughput, cycle times, utilizations, WIP, queues, resource activity, and every other measure the model is instrumented for.

## Where Runs Live

Runs belong to a **simulation model**. Open a model and its runs are listed alongside it; selecting a run makes it the active run and loads its KPIs and charts. The last several runs across your models are also surfaced in the workspace so you can jump back to recent work without opening each model.

<Note>
  **There is no separate top-level "Runs" surface.** A run is always a run *of* a specific model. Runs are also not a Data concept — pipelines don't execute, so there are no "pipeline runs" (see the last section of this page).
</Note>

## What a Run Contains

* **The inputs it was executed against**: the model as it was configured when the run executed, and the schedule that drove it, if one did (arrivals, shifts, changeovers, or whatever the schedule carries for that model). A run names its schedule when one drove it, so the conditions behind the numbers are unambiguous.
* **The raw simulation dataset**: the low-level events the simulation emitted — entity lifecycles, process activity, resource activity, and related tables. This is the source of truth for anything derived from the run.
* **Derived KPIs and charts**: the KPI queries and chart queries defined on the model, computed against the run's dataset. These are what render on the model's [Results](/product/results-and-analytics) view.

## Statuses

A run executes asynchronously in the background. Its raw dataset lands when the simulation finishes, and Dexter surfaces the run once the dataset has landed and its derived results are computed.

Once a run has landed, its raw dataset stays valid. What can vary is the **derived-results state** — the KPI and chart computations layered on top:

* **Pending**: KPIs and charts are still computing after a fresh run or after query edits. Wait, then reload.
* **Ready**: KPIs and charts are computed and ready to read.
* **Failed**: the derived computation hit an error while the run and its dataset stayed valid. Ask [Dexter](/product/dexter/chat-and-tasks) to recompute; the simulation itself does not need to re-run.

## Triggering a Run

Runs are created from a model. There are two entry points:

* **Ask Dexter.** *"Run the baseline schedule on the Line A model"*, *"run the peak-week schedule three times"* — Dexter kicks off the run against that model and schedule and surfaces it once it lands. This is the usual path.
* **The Modeler's Run control.** The Modeler canvas carries a play button that starts a run of the model you're editing without switching to chat. It reads green when the model passes [validation](/reference/validation) and red when a blocker remains; hover the blocked control to see the error, and use *Fix with Assistant* to hand it to Dexter.

A single model typically accumulates many runs over its life: baseline, variants of the schedule, sensitivity checks, and comparisons after a model edit.

## Reviewing Results

With a run selected, the model's Results view renders that run's KPIs and charts — the ones scoped to a single run, as opposed to the visuals authored for [Experiments](/product/experiments) or [Monte Carlo](/product/monte-carlo), which render on their own surfaces. Each is defined once on the model and evaluated per run, so switching the active run re-renders the same visuals against a different execution — they stay comparable across runs of the same model.

For deeper analysis, Dexter can query the run's dataset tables directly and produce ad-hoc charts, tables, or a report from them.

## Comparing Runs

Head-to-head comparison of multiple runs of the same model is handled by [Experiments](/product/experiments) — a what-if harness that runs a chosen set of model snapshots side by side and renders comparison charts across them. Reach for Experiments when the question is "how does X change if we vary Y" and you want the results laid out together rather than flipped between one at a time.

<Tip>
  For statistical variability from repeated runs of the *same* configuration (not comparing configurations), use [Monte Carlo](/product/monte-carlo): many repetitions of a single model and schedule, aggregated into distributions.
</Tip>

## If You Came Looking for "Pipeline Runs"

Older docs described a pipeline as a template that produced a run each time it executed (with `pending` / `executing` / `completed` / `completed_partial` states). That is no longer how pipelines work. In the current product, a [pipeline](/product/templates) is a document of a derivation that already ran — a record, not a program. When the same derivation is re-done (fresh upload, corrected interpretation, additional outputs), Dexter re-saves the pipeline against the same slug and it updates in place. There is no run history to browse, no execute button, and no run status on a pipeline.