> ## 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.
# Glossary
> One-stop definitions for the terms ProDex uses — factories, models, runs, projects, the knowledge base, and more.
## Overview
This page defines the vocabulary ProDex uses, as the product uses it today. Terms are alphabetical. Where a term means something different in simulation than in planning or BOMs, the entry says so.
### Artifact
A durable platform object produced by work in ProDex — a simulation model and its runs, a planning model and its runs, a BOM, a configuration template, a pipeline, an insight, a schedule. Artifacts carry provenance and are what you open, edit, and share; when [Dexter](/product/dexter/chat-and-tasks) builds something for you, the result lands as an artifact you can inspect.
### Configuration
An instance produced by resolving a [configuration template](/product/configuration-templates) against a [BOM](/product/bom-overview). The template defines decision points (choose one, choose many, choose at least one); a [configuration](/product/configurations) is the recorded set of selections that resolves them into a concrete product variant.
### Entity
A single shared construct used across the whole platform — simulation, BOMs, and planning all draw from one entity registry rather than keeping separate definitions. In a simulation, an entity is a thing that flows through the model: the item being processed, produced, moved, or transformed at each node. In BOMs and planning, the same entities are the SKUs and materials in the product graph — leaves are raw or supply-only items, assemblies are internal or finished SKUs. See [Entities](/reference/entities).
### Experiment
A comparison across variations of a simulation model or schedule — the artifact behind what-if and sensitivity analysis. An [experiment](/product/experiments) groups related runs so their results can be compared side by side.
### Factory
The top-level container for your entire ProDex workspace. Everything you build — models, entities, BOMs, pipelines, plans, insights, projects, and Dexter's knowledge base — lives inside one active factory, and switching factories switches all of it. See [Factory Management](/product/factory-management).
### Gate
A point in a [project](/product/dexter/projects) where your approval is required before work crosses into the next phase. Gates are presented as [review briefs](#review-brief); Dexter keeps pre-gate work in the project's drafts area until you approve.
### Insight
A factory-scoped analysis artifact — charts and KPIs — that presents results. Each [insight](/product/insights) attaches to a surface (a run, an experiment, or a Monte Carlo batch), and its KPIs are single-value metrics with an explicit display format.
### Knowledge Base
The persistent knowledge Dexter carries between sessions — "memory" is the underlying concept, but **[Knowledge Base](/product/dexter/memories)** is the name you see in the app. It is scoped to the factory, so everything in it is shared by everyone working in that factory, and it covers your operation, your data sources, and the artifacts built for it. A second scope, **[organization memory](/product/dexter/organization-memories)**, is curated by admins and applied read-only across every factory in your organization.
### Model
A structured representation of an operation used for analysis. A **simulation model** is a discrete-event model of a process — nodes, entities, schedules — executed as [runs](#run); a **planning model** is an optimization-oriented representation used with BOMs, demand, supply, and inventory to produce [planning runs](/product/planning-runs). See [Simulation](/product/simulation-overview) and [Planning](/product/planning-overview).
### Monte Carlo
A batch of repeated executions of one simulation model and schedule, run to measure how much the results vary. A [Monte Carlo](/product/monte-carlo) batch is its own artifact type — a sibling to a [run](#run) and an [experiment](#experiment), not a kind of run — and it produces a summary of each KPI (mean, standard deviation, min, max, and median) across the batch.
### Phase
A gated unit of progress inside a [project](/product/dexter/projects) — the work behind one sign-off. Each phase has its own folder of user-visible documents, and the project manifest tracks which phase is current.
### Pipeline
A data transformation defined in the [Data](/product/data-overview) module — a graph of source, transform, and output nodes that turns uploaded source data into cleaned, structured outputs ready for modeling and planning. A pipeline defines the transformation; it is not itself executed as a [run](#run).
A data pipeline is not the same thing as a [configuration template](/product/configuration-templates) in the BOM Configurator — those are a separate, unrelated concept.
### Project
A durable, multi-session effort with its own workspace: a manifest, phase folders for the documents you've approved, and a private drafts area for work in progress. [Projects](/product/dexter/projects) survive across chats and are how larger efforts — like a full [simulation study](/product/simulation-studies) — are organized end to end.
### Review Brief
A structured, one-page document Dexter presents for an approve / request-changes decision (or open-ended feedback) before work advances. Review briefs are how [gates](#gate) are crossed inside projects and how significant work is signed off before it lands downstream.
### Run
A single execution of a model that produces results. **Simulation runs** execute a simulation model against a [schedule](#schedule) and emit event data, KPIs, and charts; **planning runs** execute a planning model against demand and supply inputs and emit a plan. Runs live under their parent model. See [Runs](/product/runs) and [Planning Runs](/product/planning-runs).
### Schedule
A time-based input artifact nested under a simulation model — arrival patterns, shift calendars, material releases — that drives a run. A model can have several schedules, and every run pairs the model with exactly one of them. See [Schedules](/reference/schedules).
### Snapshot
A complete, frozen capture of a simulation model at a point in time. A snapshot embeds its own recursive registry — entities, constants, lookup tables — and its schedule, so it stays reproducible no matter how the live model changes afterward. Experiments run against snapshots and compare the resulting runs. See [Snapshots](/reference/snapshots).
### Task
A visible unit of work Dexter is tracking, shown in a task list while it works. Tasks make in-flight work auditable — you see what Dexter has committed to, what's in progress, and what's done — and they persist through long sessions so nothing is silently dropped. See [Chat & Tasks](/product/dexter/chat-and-tasks).
### Workflow
A named, opinionated procedure Dexter activates to do a specific kind of work — simulation modeling, planning, exploratory data analysis, reporting. Built-in workflows ship with the product; [custom workflows](/product/dexter/custom-workflows) capture recurring procedures of your own.
Most terms above also have a dedicated page with full detail — follow the links in each entry. For the product's overall shape (DES + APS + Dexter), start with [Key Concepts](/getting-started/key-concepts).