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 and datasets, BOMs and configuration templates, planning models and plans, Gantt documents, apps, reports, and the knowledge base Dexter maintains about it. Each Factory belongs to the person who created it; sharing one gives a teammate their own copy. 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; a longer-running effort can span many conversations, with the Knowledge Base carrying context between them. Response mode: how Dexter trades speed for thoroughness in a conversation — Turbo, Fast (the default), Max, or Ultra. You pick it next to the send button. See Response modes. 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, datasets, plans, Gantt documents, BOMs, configuration templates, configurations, apps, and downloadable reports (PDF, PowerPoint, Word, Excel). Every artifact lives inside your Factory. Goal: a long-running task with a clear finish line. You set it from the composer’s + menu, approve it once, and Dexter keeps working toward it until it has verified it’s done. See Goal approval. 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 and human-readable: browse it on the Knowledge Base page in the left navigation, and ask Dexter to change it. 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. Run: an execution that produces results. There are three kinds, and it matters which you mean:
Scenario comparison: running each variant you want to weigh — the model after an edit, or a copy of it — as its own simulation run, then comparing the runs. Ask Dexter to lay them out side by side. See Comparing runs.
Replications: running the same configuration several times with different random seeds, so you can see the spread of outcomes rather than a single trajectory. Ask Dexter to run a configuration with several seeds. See Replications.
Pipeline: repeatable data preparation Dexter builds for you — the same inputs, transformations, and checks every time, for data that arrives again and again, like a weekly MES export. A run that changes its output tables publishes new versions of them in Datasets. Pipelines live on the Pipelines tab of the sidebar’s Data page — see the Data overview.
Dataset: a versioned data table your factory relies on, such as a capacity catalog or a code crosswalk. You can browse, filter, and correct it, and compare versions. Datasets live on the Datasets tab of the Data page.
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. A resource’s capacity can change during a run, which is how shifts, breakdowns, and staffing changes are modeled.
Schedule: the timing structure attached to a model — what runs when, for how long, under which shift pattern. See Schedules. Not the same as a Gantt.
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 nested decisions 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. A configuration resolves to a parts list for one order; feeding it into planning or simulation is a separate step. Plan: the main output of a planning run — what to make, when, and in what quantity, balancing on-time demand against inventory targets within 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. Gantt: an editable timeline of jobs on machines, crews, or project phases, which you and Dexter build together. It doesn’t sequence jobs for you, and a plan doesn’t turn into Gantt jobs on its own. See Gantt.Session context is transient — it’s captured with each message you send. Conversations are saved to your history in the Factory, but they aren’t artifacts: what lasts from them is what Dexter built.