Simulation Studies

​

Overview

A simulation study is a multi-session engagement where you and Dexter 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 — 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 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.

​

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

​

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

​

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.

​

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, 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 — a record of the transformations that shaped raw uploads into the model’s inputs.
• Dashboards and insights built while characterizing the data.
• One or more simulation models with their entities, schedules, constants, lookup tables, KPI and chart definitions.
• Runs under each model, with snapshots captured along the way as the experiments and Monte Carlo batches pin down each configuration worth comparing.
• Experiments and Monte Carlo batches from the analysis phase.
• Reports — the shareable deliverable in PDF, Word, PowerPoint, or Excel.
• Knowledge Base 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 — the general project machinery: manifest, drafts, briefs, attachment
• Simulation Overview — the artifacts a study produces, and how they fit together
• Your First Simulation — the hands-on loop a study automates and extends
• Experiments and Monte Carlo — the analysis surfaces of the later phases
• Results and Analytics — reading what the runs produced