Overview
Every simulation run in ProDex produces a full set of results: KPI summaries, charts, and a detailed event log. Results are stored permanently and can be compared across runs or exported for reporting.
Each Results page is also the launch surface for Monte Carlo seed sweeps on the current configuration and for the Simulation Event Log — both reachable from the top bar without leaving the page.
The Results page is scoped to a single run. For cross-run comparison, see Experiments. For durable cross-cutting dashboards that aren’t tied to one run, see Insights. For statistical analysis across many seeds of one configuration, see Monte Carlo.
KPIs
KPIs (Key Performance Indicators) are summary metrics computed from simulation output. They’re defined on your model and computed automatically after each run.
KPI Types
Numeric KPIs return a single number, optionally with a unit suffix (e.g., “units/hr”, “min”) and a color hint for dashboard display.
Text KPIs return a short label (1–3 words) — useful for status indicators like feasibility or run classification.
Authoring and Inspecting KPIs
KPI results appear as cards at the top of the Results page. Hovering a card reveals a single kebab ⋮ menu in the top-right corner with two items:
- View source code — opens a modal showing the KPI’s full definition: a formula header in a tinted box (e.g. “Lead time = 1/n ∑ (Terminate time − Create time)”), a plain-English description, and the underlying DuckDB SQL with syntax highlighting.
- Delete — removes the KPI from the model.
The + Create KPI dashed tile opens a Dexter dialog titled Create KPI with the subtitle “Describe the metric you want to track and the AI will build it.” and a single textarea (placeholder: “e.g. average lead time, completed orders, or utilization of Station A”). The dialog has Cancel and Create buttons. Describe the metric in natural language and Dexter writes the SQL against the available dataframes and saves the KPI back to the model. KPIs are not authored manually — the Dexter path is the supported authoring flow.
Charts and Visualizations
Charts are defined on your model and rendered automatically from run output. ProDex supports thirteen chart types in the Add Chart picker:
| Type | Use case |
|---|
| Line | Time series — throughput over time, queue length over time |
| Area | Same as line but with filled area |
| Stacked Area | Filled area showing component contributions over time |
| Bar | Comparisons across categories |
| Stacked Bar | Bars decomposed into stacked sub-categories |
| Pie | Part-to-whole breakdowns |
| Scatter | Correlation between two variables |
| Histogram | Distribution of a metric across events |
| Heatmap | 2D grid with color intensity — e.g., utilization by resource and shift |
| Gantt | Job timeline visualization |
| Table | Tabular data output |
| Box Plot | Statistical spread (min, quartiles, max) across multiple runs |
| Mixed | Combination chart (e.g., bars + a trend line on the same axis) |
Charts on a Run are static snapshots, not live queries. Each chart’s data is computed once and committed when the run finishes — the chart doesn’t refresh if you re-run the underlying queries elsewhere or if the model changes. To pick up changes, ask Dexter to regenerate the chart, or open a fresh run.
+ Create chart dashed tile opens a Dexter dialog titled Create chart with the subtitle “Describe the chart you want and the AI will build it.”, plus a Chart type dropdown that defaults to Any (optional) — leave it as-is and Dexter picks the type, or pin it to a specific type. Describe the chart you want and Dexter writes the underlying query, picks the right type if you didn’t, and saves the chart back to the model. Like KPIs, charts are authored through Dexter rather than a manual editor.
Per-Chart Actions
Hovering a chart reveals two icons in the top-right corner: an expand icon (left) and a kebab ⋮ menu (right).
The kebab menu has three items in chart-mode for every chart type: View source code → Download chart → Delete. When a chart is currently displaying its source code (after clicking View source code), the first menu item flips to Show chart so you can return to the rendered chart.
View source code replaces the chart’s rendering with a three-part explanation panel:
- A formula header in a tinted box — e.g.
Cumulative throughput(h) = ∑ Units exited in hour i
- A plain-English description paragraph of what the chart measures and how it’s computed
- The actual DuckDB SQL that produced the chart, with syntax highlighting — full
WITH / SELECT query, joins, window functions, and all
This is by design — every chart is fully traceable from the rendered visual back to the SQL, in the same view, without leaving the page. It’s the canonical “where did this number come from?” surface.
Download chart exports the chart as an image (distinct from the page-level Export PDF). Delete removes the chart from the model immediately (no confirmation prompt).
The expand icon opens a fullscreen modal with the chart on the left and the source-code panel (formula + description + SQL) embedded on the right — so you don’t have to flip between modes to see both. The modal header has Download chart and Delete icons in the top-right alongside the close (X).
Querying Simulation Data
Under the hood, KPIs and charts aren’t preconfigured dashboards — they’re backed by DuckDB SQL queries against detailed simulation event tables. After every run, ProDex populates a set of dataframes capturing entity lifecycle events, process activity, resource activity, and more. KPIs and charts are queries that extract and aggregate from those tables.
This has a practical consequence: the platform can answer any question the event data supports, not just the ones someone anticipated at model design time. A question like “show me the 95th percentile cycle time for rush orders that went through the rework loop on the evening shift” is a SQL query away — you don’t need a dashboard pre-built for it. Dexter writes those queries on your behalf when you describe the metric you want.
Available Dataframes
Every run produces the following dataframes, identified by their exact snake_case name (these are also the table names you SELECT FROM in DuckDB SQL). Column names are exact and case-sensitive — query against them directly.
| Dataframe | What it answers |
|---|
entity_lifecycle | Entity lifecycle: when each entity entered the system, where it went, how long it spent in each component, when it terminated. The main source for throughput, cycle time, and flow-based metrics. |
entity_movements | Component-to-component movement tracking with timestamps. Every time an entity transitions from one component to another, it’s recorded here. Used for flow analysis and for reconstructing the path of specific entities. |
process_activity | Process-level detail: when each process started, completed, or blocked; which entity was processed; how long processing took. The source for process utilization and bottleneck analysis. |
resource_activity | Resource utilization over time: when each resource was acquired, released, or had its capacity changed. The source for resource utilization charts and over/under capacity analysis. |
buffer_activity | Buffer levels over time: when entities entered and exited each buffer, queue depth, maximum observed queue. Source for WIP and queue-length metrics. |
station_activity | Station-level capacity tracking: slot occupancy, when capacity was taken and released, which entity lineage each slot belongs to. Essential for debugging station blocking. |
entity_attributes_lookup | Deduplicated reference table of every distinct attribute combination an entity carried during the run — keyed so you can join from entity_lifecycle and slice metrics by attribute (e.g., “cycle time by product type”). |
component_lookup | Static reference data about components in the model — types, names, station membership. Used to resolve component IDs to human-readable names in query results. |
metadata | Run-level metadata — model identifiers, schedule reference, duration, and other top-level run properties. Used to filter and group queries across runs. |
| Dataframe | Present when |
|---|
schedule_definition | The run was driven by a schedule. |
event_lookup | The model declares event hooks or listeners. A static registry of every event name the model emits — names, source components, and trigger contexts. Join from topic_activity or state_variable_activity to resolve runtime firings back to their event definitions. |
topic_activity | At least one topic emission fired during the run. |
state_variable_activity | At least one state variable assignment fired during the run. Source for state-driven metrics (shift state, current WIP counter, inventory levels). |
Working With the Data
In practice, this is where Dexter shines. Describe the metric you want in natural language and Dexter writes the SQL query, runs it, and either answers directly or saves the result as a new KPI or chart. Dexter knows the schemas and column names; you don’t have to memorize them.
For power users tracing queries directly, understanding which dataframe answers which question is the key skill. A question about flow (“how many units went through?”) lives in Entity Lifecycle; a question about contention (“how busy was the CNC?”) lives in Resource Activity; a question about assembly blocking lives in Station Activity.
Single Run Results
When you open a Run, the page is laid out as:
- Top bar (left → right): back arrow, model name, run name, separator, run date, trash icon (deletes the run). The run name is inline-editable — click it to put it into edit mode, then press Enter to save or Escape to cancel.
- Top-bar actions (right side): Simulation Event Log, Export PDF, Monte Carlo.
- KPI cards at the top of the main area, each revealing a kebab
⋮ menu on hover (View source code / Delete).
- Charts in the main area, each with an expand icon and a kebab
⋮ menu on hover (see Per-Chart Actions).
- A vertical AI Assistant rail tab pinned to the right edge of the viewport — clicking it re-opens the Dexter chat panel.
When you switch to the Monte Carlo view (next section), the top bar collapses to: back arrow, model name, separator, “Monte Carlo”. From the empty state (no MC runs yet), a centered Run Monte Carlo button opens the Monte Carlo Simulation modal. Once Monte Carlo runs exist, the top bar reflects the run summary.
Simulation Event Log
The Simulation Event Log opens as a right-side slide-in drawer. The drawer header has the title Simulation Event Log on the left and an Export button (with download icon) plus a close (X) on the right. A search input at the top filters rows in place (placeholder “Search…”). Each row reads time | queue/area | event (e.g. 12:00:00 710-to-I-Test Staging Area Tube created) and includes both flow events (entity created, process started, entity routed, etc.) and every event hook firing.
Use the Event Log to debug event-driven behavior, validate routing decisions, or confirm that scheduled actions fired when expected. The Export button produces a tabular export of the trace; for the polished narrative report including KPIs and charts, use Export PDF instead.
Monte Carlo
Monte Carlo simulation runs the same configuration N times with different random seeds and reports the distribution of outcomes instead of a single number — mean, standard deviation, percentiles, and a confidence band on every chart. That’s the difference between “throughput is 847 units/day” and “throughput is 847 ± 23, with a 95th percentile of 891.”
ProDex exposes Monte Carlo in two places, depending on the question you’re asking:
- Single-run Monte Carlo. The Monte Carlo button in the Results top bar switches the page into the Monte Carlo view. From the empty state, click the centered Run Monte Carlo button to open the Monte Carlo Simulation modal — title “Monte Carlo Simulation”, subtitle “Run multiple simulations with randomized parameters to analyze statistical variation in results.”, an N Runs input (default 100; helper text “Number of simulation seeds (1–1,024)”) and a Run Simulation button with a play icon. Sweeps seeds for the current configuration only — use it to quantify how sensitive a single Snapshot is to randomness before deciding whether it’s worth comparing against alternatives.
- Per-Snapshot Monte Carlo inside an experiment. Inside an Experiment, trigger Monte Carlo on each Snapshot’s individual Run page when you want both cross-Snapshot comparison and per-Snapshot confidence intervals.
For most models, 100 seeds give a good balance of statistical reliability and runtime. Push to 200+ when you care about tail metrics (P95/P99) — the tails need more samples to stabilize. The hard maximum is 1,024 per batch.
Comparing Snapshots
The Experiments section is where structured cross-configuration comparison lives. An Experiment is a set of Snapshots added to a comparison; the view lays KPIs out side by side, overlays distributions when Monte Carlo is on, and lets you drill into any Snapshot’s detailed run results.
For ad-hoc inspection of past Runs without setting up an experiment, open them individually from the Runs list.
Downloading Results
ProDex supports several export paths:
- PDF — the top-bar Export PDF button on any Results page (single-run or Monte Carlo) produces a polished, branded report containing KPI summaries, charts, and Dexter-authored narrative. The same artifact can also be requested from Dexter conversationally (“Generate a PDF summary of this run”) when you want to tailor what’s included.
- Event log export — the Simulation Event Log drawer has its own Export button in the drawer header for the raw event trace.
- Per-chart image — every chart’s kebab
⋮ menu has a Download chart action that exports the chart as an image, distinct from Export PDF.
- Excel / CSV of KPIs and chart data — there’s no top-bar Excel export. Ask Dexter (“Export the results to Excel”) and Dexter will generate it from the underlying dataframes.
