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

# Key Concepts

> The vocabulary the rest of the documentation assumes: Factories, Dexter, artifacts, projects, the knowledge base, models, and runs.

## Overview

ProDex leans on a small vocabulary, and nearly all of it hangs off one idea: a **Factory** is your workspace, and everything else — your data, your models, your plans, and the agent that builds them — lives inside it. This page defines those terms, grouped by where you'll run into them. If a word feels unfamiliar anywhere in these docs, it's defined here; for the full alphabetical list, see the [Glossary](/reference/glossary).

## The Workspace

**Factory**: the workspace container. A Factory holds everything about one operation — simulation models and their runs, data pipelines, BOMs and configuration templates, planning models and plans, experiments, insights, reports, and the knowledge base Dexter maintains about it. You choose the active Factory in the **factory selector** at the top of the left sidebar; every surface below the selector is scoped to it. See [Factory Management](/product/factory-management).

**Dexter**: the AI agent embedded throughout ProDex. [Dexter](/product/ai-assistant) builds simulation models, profiles data, runs analyses, drafts reports, and executes workflows on your behalf. You interact with Dexter primarily on the **Chat** surface, but it stays aware of your context on every other page too.

## Working with Dexter

**Conversation**: a single thread of [Chat](/product/dexter/chat-and-tasks) with Dexter. Conversations are the unit of interaction; longer-running efforts that span multiple conversations belong in a **Project**.

**Session context**: what Dexter knows about your current position in the app — the page you're on and the objects you have selected (a specific model, run, pipeline, or BOM). Session context is picked up automatically with every message you send; you don't restate it.

**Artifact**: anything of durable value produced in the platform, by you or by Dexter. Artifacts include simulation models, data pipelines, plans, schedules, BOMs, configuration templates, configurations, insights, experiments, and downloadable [reports](/product/dexter/reports) (PDF, PowerPoint, Word, Excel). Every artifact lives inside your Factory and carries provenance back to its inputs.

**Project**: the durable home for an effort too big for one conversation — a full simulation study, a multi-week model build. A [Project](/product/dexter/projects) is organized into **phases**, each ending in a **gated sign-off** where you approve the phase's output before the next begins. Dexter resumes a Project across sessions, picking up exactly where the last conversation left off. Projects live under the top-nav **Projects** surface.

**Knowledge Base**: Dexter's durable memory of your operation — how the factory actually runs, what your uploaded data means, and what has been built in the platform. It's per-Factory, human-readable, and editable, under the top-nav **Knowledge Base** surface. See [Knowledge Base](/product/dexter/memories).

<Info>
  Organizations can also maintain [organization-wide memories](/product/dexter/organization-memories) that apply across every Factory. Ask your admin whether that layer is in use.
</Info>

**Workflow**: a recurring task your team saves after teaching Dexter how you like it done, so Dexter runs it the same way every time. [Custom workflows](/product/dexter/custom-workflows) live under the top-nav **Workflows** surface.

## Modeling and Data

**Model**: a discrete event simulation of an operation, built as a flow graph. Models are edited in the [Modeler](/product/simulation-modeling) and live inside your Factory.

**Snapshot**: a frozen copy of a model exactly as it was at one moment — the model plus everything it depends on, from its schedule and resources down to its settings — so a result can always be traced back to the precise setup that produced it. [Snapshots](/reference/snapshots) are what [Experiments](/product/experiments) compare, and you can restore one back into the [Modeler](/product/simulation-modeling) to keep working from it.

**Run**: an execution that produces results. There are two kinds, and it matters which you mean:

| Run type           | What it executes                                                               | Where you see it                              |
| ------------------ | ------------------------------------------------------------------------------ | --------------------------------------------- |
| **Simulation run** | One execution of a simulation model                                            | [Results](/product/results-and-analytics)     |
| **Planning run**   | One execution of a planning model, producing a plan and its order fulfillments | [Planning results](/product/planning-results) |

**Experiment**: a comparison across [snapshots](/reference/snapshots) of a model — you freeze the variants you want to weigh, then read them side by side with pivoted charts and KPI overrides. [Experiments](/product/experiments) have their own sidebar surface.

**Monte Carlo**: a batch of runs of a single model that varies the random seed each time, so you can see the spread of outcomes rather than a single trajectory. It has its own sidebar surface.

**Pipeline**: the auditable record of how raw uploaded data (spreadsheets, MES exports, ERP reports, PDFs) was turned into platform-ready inputs like cycle time distributions, processing times, or demand profiles — the trail from each source to the derived value, not a program you re-run. [Pipelines](/product/templates) live under the sidebar's **Data** surface — see the [Data overview](/product/data-overview).

**Entity**: something that flows through your simulation model — a part, an order, a batch. [Entities](/reference/entities) are created by sources, move through stations and buffers, and exit at sinks.

**Resource**: something entities consume or contend for as they flow — an operator, a machine, a tool, a fixture. Resources have calendars that define when they're available, which is how shifts are modeled.

**Schedule**: the timing structure attached to a model — what runs when, for how long, under which shift pattern. See [Schedules](/reference/schedules).

## Products and Planning

**BOM**: a Bill of Materials — the recipe for a product, capturing which components go into which assemblies. A component can be used in more than one product, and a material can never contain itself. BOMs live under the sidebar's [**BOMs**](/product/bom-overview) surface.

**Configuration template**: a configurable product structure — option classes, selection rules, and constraints that define the space of valid product variants. [Templates](/product/configuration-templates) live under **Configurator**.

**Configuration**: a concrete instance produced by walking a configuration template and making a choice at each decision point. [Configurations](/product/configurations) plug into planning and simulation.

**Plan**: the main output of a [planning run](/product/planning-runs) — what to make, when, and in what quantity, balancing demand against inventory targets and finite capacity. A planning run also returns the **order fulfillments** that go with the plan: which demand orders are met, and in which period. See the [Planning overview](/product/planning-overview).

<Note>
  Conversations and session context are transient — they exist around your interaction with Dexter and are not artifacts of the Factory.
</Note>

<Tip>
  You don't need to memorize any of this before starting. Work through [Your First Project](/getting-started/your-first-project) and come back here whenever a term needs pinning down.
</Tip>