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

# Your First Simulation

> Build and run your first simulation model in ProDex, step by step.

## Overview

This guide walks you through building and running a basic simulation by hand. By the end you'll have a working model, a completed run, results you can read, and a Snapshot ready for experiments.

<Tip>
  The fastest path to a first simulation is conversational: describe your process to [Dexter](/product/dexter/chat-and-tasks) — or start from your own data with [Your First Project](/getting-started/your-first-project) — and the agent builds the model for you. This page is the manual walkthrough for when you want to understand each piece yourself. The two paths produce the same artifacts and mix freely: Dexter already knows which model you have open, so you can hand any step below to it mid-build.
</Tip>

## Step 1: Pick a Factory and Create a Model

A model lives inside a factory. Pick the factory you want to work in from the global selector at the top, then open the [Modeler](/product/simulation-modeling) and create a new model from the model selector in the top bar. Give it a name and an optional description. The model is your container: every component, configuration field, and run lives inside it.

## Step 2: Define Your Entities

[Entities](/reference/entities) are the items that flow through your simulation: raw materials, intermediates, finished goods. They're **factory-scoped**, so anything you define here is reusable across every model in the same factory.

In the Modeler's left panel, open the **Library** tab. At the bottom of the panel are **Entities** and **Lookups** buttons: click **Entities** to open the modal and add the items your model needs. Each entity type carries **typed attributes** (Boolean, Number, Text, Text List, Number List) that get stamped when the entity is created at a Source, travel with it through the graph, and can be read by any [expression](/reference/expressions) along the way.

## Step 3: Build the Model Graph

The canvas is where you build your simulation as a graph of connected components. The **Library** tab holds the component palette:

* **Source**: generates entities and introduces them into the model
* **Process**: applies a delay, optionally consuming resources
* **Buffer**: holds entities in a queue with an optional capacity limit
* **Router**: splits entity flow based on logic you define
* **Station**: a capacity-constrained container that groups components into a work center
* **Combiner**, **Separator**, **Transformer**: batch entities together, split one into many, or change/mutate an entity. Typically attached to a Station rather than standalone.
* **Sink**: removes entities from the model. The exit point.

**Resources** aren't dragged onto the canvas. They're model-scoped capacity pools (workers, machines) defined in the side panel and attached to the Processes that draw from them.

Drag a component from the Library onto the canvas, then connect components by dragging from one node's output handle to another's input handle. The minimum viable model is **Source → Process → Sink**.

## Step 4: Configure Components

Click any component on the canvas to open its configuration panel. For a first model:

* **Source**: which entity type to generate, arrival logic (a fixed interval, a [distribution](/reference/distributions), or a [DSL expression](/reference/expressions)), and initial attribute values
* **Process**: processing time, resource requirements, optional Station placement
* **Router**: routing logic — conditional rules, percentage splits, or round robin
* **Resource** (side panel): capacity and allocation discipline

Most numeric fields accept either a literal value or an expression referencing [constants and lookup tables](/reference/constants-and-lookups), entity attributes, and simulation state. Define a constant for any number you expect to tune later — it pays off the first time you sweep a scenario.

<Note>
  A **Transformer** doesn't have to change the entity type: configuring the same input and output type is the standard way to mutate attributes mid-flow (incrementing a rework counter, marking a QC result). And when you need batching, a **Hold-mode Buffer** with a conditional *Release Entity* hook often beats Combiner + Separator because it preserves per-entity lineage. See [Combiners, Separators & Transformers](/reference/batching).
</Note>

## Step 5: Set Simulation Duration

In the model's top bar, set how long the simulation should run using the **DDD:HH:MM:SS** duration picker. This controls the length of each run in simulated time.

If the run should follow real calendar time — shifts, planned releases, downtime windows — pair the model with a [schedule](/reference/schedules) instead. Schedule **material releases** are a second arrival mechanism that coexists with your Sources' own arrival logic, so decide deliberately which one (or both) drives each entry point.

## Step 6: Run the Simulation

The run controls live at the bottom of the canvas: **Run simulation** (green play), **Step**, and **Playback speed**. Click **Run simulation** to execute the model end to end. Runs execute against your **live working model**, so iteration is fast: tweak, run, repeat.

The play button doubles as the [validation](/reference/validation) indicator. **Green** means the model is structurally valid and ready. **Red** means there's a specific blocker: hover the button to see the error and a **Fix with Assistant** action that hands the failure to Dexter for a one-click proposal.

## Step 7: Review Results

Open [Results](/product/results-and-analytics) to see your run's output:

* **KPIs**: single-number metrics. KPIs aren't a fixed built-in set — they're authored on your model (describe the metric you want and Dexter writes the underlying query), then computed automatically on every subsequent run. Formats cover counts, percentages, durations, currency, and more.
* **Charts**: visualizations authored the same way, from time series and bar charts to histograms and mixed multi-series charts.
* **Event-level data**: every run records a full event-level trace — entity lifecycles, process activity, resource activity — that the results views and Dexter can drill into when a KPI looks off.

When you want to share what you found, ask Dexter for a **report**: it can produce PDF, Word, PowerPoint, or Excel deliverables straight from your results.

## Step 8: Capture a Snapshot

Click the **disk icon** in the Modeler's top bar to open the *Create Snapshot* dialog. Give it a name (e.g., *"First run baseline"*) and an optional description, then click **Create Snapshot**.

<Note>
  **A Snapshot isn't Save.** The Modeler auto-saves your edits continuously, and plain runs execute against the live model. A [Snapshot](/reference/snapshots) is an immutable capture of model + schedule — the unit that [Experiments](/product/experiments) and [Monte Carlo](/product/monte-carlo) replay as cases. Capturing one now gives you a frozen baseline to compare every future change against.
</Note>

## What's Next

* Understand how the pieces fit together in the [Simulation Overview](/product/simulation-overview)
* Model a more realistic facility with the full [Modeler](/product/simulation-modeling) component reference
* Compare candidate changes side by side with [Experiments](/product/experiments), and quantify variability with [Monte Carlo](/product/monte-carlo)
* Run a full improvement study as a multi-session project: see [Simulation Studies](/product/simulation-studies)
* Prefer starting from data? Follow [Your First Project](/getting-started/your-first-project)