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.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. Dexter: the AI agent embedded throughout ProDex. Dexter 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 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 (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 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.Organizations can also maintain organization-wide memories that apply across every Factory. Ask your admin whether that layer is in use.
Modeling and Data
Model: a discrete event simulation of an operation, built as a flow graph. Models are edited in the Modeler 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 are what Experiments compare, and you can restore one back into the Modeler to keep working from it. Run: an execution that produces results. There are two kinds, and it matters which you mean:
Experiment: a comparison across 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 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 live under the sidebar’s Data surface — see the Data overview.
Entity: something that flows through your simulation model — a part, an order, a batch. 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.
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 surface. Configuration template: a configurable product structure — option classes, selection rules, and constraints that define the space of valid product variants. Templates live under Configurator. Configuration: a concrete instance produced by walking a configuration template and making a choice at each decision point. Configurations plug into planning and simulation. Plan: the main output of a planning run — 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.Conversations and session context are transient — they exist around your interaction with Dexter and are not artifacts of the Factory.