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

# Simulation Studies

> Running a full simulation study as a multi-session project: phases, gated sign-offs, and a defensible record from raw data to recommendation.

## Overview

A **simulation study** is a multi-session engagement where you and [Dexter](/product/dexter/chat-and-tasks) take a modeling question from raw data to a defended recommendation: scoping the decision, understanding the data, building the model in pieces you can each validate, running the experiments that answer the question, and leaving a written record credible enough to take to management.

A study runs as a [project](/product/dexter/projects) — the durable container that carries a manifest, phases, gated sign-offs, and approved artifacts across as many conversations as the work takes. That page covers the project machinery in general; this one covers how a simulation study uses it: the phase arc, what each gate certifies, and what the study leaves behind.

## A Study vs. a One-Off Conversation

Most simulation work fits in a plain conversation: a quick model, a chart, a data profile, a schedule tweak. The chat ends, the artifacts remain in the factory, and nothing is lost.

A study is different in kind, not just size. It's long; later answers depend on earlier decisions; the artifacts must be auditable; and someone will act on the recommendation. Losing the record of *why* a distribution was fitted the way it was — or *which* ground-truth check the finished model cleared — would sink the effort. The project gives the study its own workspace, a phase structure with sign-offs, and a bridge into the [Knowledge Base](/product/dexter/memories) so any future session picks the work up with full context.

Reach for a study when:

* the decision is consequential — capital, staffing, customer commitments, capacity planning;
* the model has to be **defensible**, with a validation record behind it;
* the work will clearly span more than one sitting, or more than one person.

## Where Studies Live

Studies live on the **Projects** page in the sidebar, alongside Chat, Knowledge Base, and Workflows. It lists every project in the current factory with its current phase and latest update; opening one shows its manifest, its phases, and the artifacts approved in each phase.

<Note>
  There's no "New project" button on the Projects page — projects come into being when Dexter opens one, with your approval. Until the first study exists, the page shows an empty state explaining exactly that.
</Note>

## Starting a Study

Three ways in, all converging on the same flow:

* Use the **New simulation project** quick action ("Create a project and build a sim from your data") offered on a new conversation.
* Ask directly — *"I want a model of our packaging line to decide whether to add a second labeler."* If the shape of the work warrants a study, Dexter proposes one.
* Switch the selector next to the message input from **Chat** to **Project** before sending, to tell Dexter up front the work should run as a project.

However it starts, the opening moves are the same:

1. **Scoping.** Dexter asks what decision the model needs to drive, in your terms: what's being weighed, what "correct enough" looks like, which data sources exist, what ground truth the finished model must be validated against, and how deep the model needs to go.
2. **The charter.** Dexter drafts a short charter — the decision, the sources of truth, the bar the model must clear — and presents it as the study's first [review brief](/product/dexter/chat-and-tasks#review-briefs). Nothing is modeled until you approve it.
3. **The project opens.** The study appears on the Projects page with the charter as its first artifact, a phase plan designed for your context, and a rolling *where things stand* cursor.

<Tip>
  The scoping answers shape everything downstream — the phases, the sign-off criteria, and what "validated" will mean. Give the ground-truth question real thought here: name the numbers you already trust (a month of throughput actuals, known cycle times, a shift's output) that the model will later have to reproduce.
</Tip>

## The Phases of a Study

A **phase** is a unit of progress that ends at a sign-off: it produces one or more artifacts you review and either approve or send back. The next phase doesn't start until the current one closes. The plan is designed for your study — phases split, merge, and reorder to fit the goal, the data, and how well the operation is already understood. There is no fixed phase template; the arc below is one *illustrative* shape, not a script Dexter marches through. A typical study looks something like:

| Phase                              | What it produces                                                                                                                                                             | Closed by your sign-off that...                              |
| ---------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------ |
| **Charter**                        | The decision, the sources of truth, the bar to clear                                                                                                                         | ...this is the right question and the right bar              |
| **Data foundation**                | Per-source write-ups; [data pipelines](/product/templates) shaping raw uploads into modeling-ready inputs; ground truth held back for validation                             | ...the data is understood and the ground truth is set aside  |
| **Operational representation**     | A plain-language statement of the operation as the model will represent it — flow, resources, schedules, constraints, quirks                                                 | ...the description matches your floor                        |
| **Sources and assumptions**        | A written source for every key parameter: fitted distribution, named dataset, or stated assumption                                                                           | ...the parameter list and carried assumptions are acceptable |
| **Model construction**             | The [model](/product/simulation-modeling), built as sub-models verified individually against things you know they should reproduce                                           | ...each piece behaves as expected in isolation               |
| **End-to-end validation**          | The assembled model run against the held-back ground truth, compared statistically — the **validation record**                                                               | ...the model has cleared its bar                             |
| **Experiments and recommendation** | The what-ifs from the charter, run as [experiments](/product/experiments) (and [Monte Carlo](/product/monte-carlo) where variability matters), plus a written recommendation | ...the recommendation is supported                           |
| **Handoff**                        | A [report](/product/dexter/reports) — usually a PDF or slide deck — for the audience that didn't sit through the study                                                       | ...the deliverable is ready to share                         |

Phases can loop back: if end-to-end validation surfaces a gap the operational representation missed, the plan revises rather than pushing through — and plan changes arrive as briefs too.

<Warning>
  The validation record is only as strong as the ground truth held back in the data foundation phase. If that step is rushed — or the "ground truth" was also used to fit parameters — end-to-end validation stops meaning anything. This is the phase to slow down on.
</Warning>

## Sign-Off Gates

At the end of each phase, Dexter presents the decision as a **review brief**: a one-page document laying out what you're approving, the assumptions and judgment calls it rests on, and the evidence — tables, charts, the actual numbers — so you can settle it from the brief alone. You **approve** or **request changes**:

* On approval, the deliverable lands in the phase's folder as a durable artifact, the phase advances, and work waiting on the gate is freed.
* On changes requested, Dexter iterates and re-presents. Nothing crosses a gate until you approve it.

The same review-brief gate governs advancing the current phase and closing the study itself. In-progress work stays in the project's private drafts area — never cited in briefs, never shown as part of the record.

<Info>
  Want to see something before it's ready for approval? Ask — drafts are hidden by default, not locked away.
</Info>

## Continuity Across Sessions

A study almost always spans multiple conversations, and several mechanisms make the pickup seamless:

* **The manifest is the resume point.** Its rolling *where things stand* section names what's in flight, what's blocked, what's next, and what questions are open — kept current so the next session (or the next teammate) starts exactly where the last one stopped.
* **The Knowledge Base carries the operational context.** What the study teaches Dexter about your operation — process flow, capacity, vocabulary, per-source data guides — lands in the factory's [Knowledge Base](/product/dexter/memories), and the project's bridge document indexes the entries the study depends on. Future sessions reload that understanding instead of re-asking.
* **Conversations attach to the project.** Resume by opening the study from the Projects page or by naming it to Dexter in a new chat; Dexter reads the manifest, the phase artifacts, and the bridge before touching the work. One project is active per conversation.
* **Tasks stay visible.** Multi-step work inside a phase — data cleaning, model construction, an analysis — runs through the task list you can watch in chat.

## What a Study Leaves Behind

Every artifact a study produces is a first-class factory object, usable on its own after the project closes. A typical study leaves:

* **The study documents** — charter, data write-ups, operational representation, assumptions register, validation record, recommendation — one per phase, in the project.
* **[Data pipelines](/product/templates)** — a record of the transformations that shaped raw uploads into the model's inputs.
* **[Dashboards and insights](/product/insights)** built while characterizing the data.
* **One or more [simulation models](/product/simulation-modeling)** with their entities, schedules, constants, lookup tables, KPI and chart definitions.
* **[Runs](/product/runs)** under each model, with **[snapshots](/reference/snapshots)** captured along the way as the experiments and Monte Carlo batches pin down each configuration worth comparing.
* **[Experiments](/product/experiments)** and **[Monte Carlo](/product/monte-carlo)** batches from the analysis phase.
* **[Reports](/product/dexter/reports)** — the shareable deliverable in PDF, Word, PowerPoint, or Excel.
* **[Knowledge Base](/product/dexter/memories) entries** encoding what the study taught Dexter about your operation.

The project keeps the *reasoning* connected — which artifact answered which question, under which assumptions. The artifacts stand on their own outside it.

## Limits and Caveats

* **Studies are opened by Dexter, with your approval** — kick one off from the quick action, the composer's **Project** option, or by asking. There's no manual New-project form.
* **One project per conversation.** If a chat resets or you switch efforts, re-attach the intended study before continuing, or the work lands outside it.
* **The phase plan is proposed, not imposed.** If a phase doesn't match how you think about the decision, say so at scoping — revisions later are fine, but cheaper early.
* **Nothing crosses a gate silently.** Dexter won't promote a draft into the record without your approval; correcting an already-approved artifact flows through a revised brief, keeping the record trustworthy.
* **Reports are generated on request.** The handoff phase scopes the deliverable — audience, format, what to lead with — rather than auto-producing a PDF at close.
* **Studies are factory-scoped.** A study lives in the factory it started in and can't move across factories.

## Where to Go Next

* [Projects](/product/dexter/projects) — the general project machinery: manifest, drafts, briefs, attachment
* [Simulation Overview](/product/simulation-overview) — the artifacts a study produces, and how they fit together
* [Your First Simulation](/getting-started/your-first-simulation) — the hands-on loop a study automates and extends
* [Experiments](/product/experiments) and [Monte Carlo](/product/monte-carlo) — the analysis surfaces of the later phases
* [Results and Analytics](/product/results-and-analytics) — reading what the runs produced