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

# Gates

> A gate is a point in a project where your approval lets the work cross a boundary — an explicit human sign-off that closes each project phase.

## Overview

A **gate** is a point in a [Project](/product/dexter/projects) where **your approval lets the work cross a boundary**. It's how ProDex slows down at the moments that matter — before a phase of work becomes the foundation for everything after it — and gives you an explicit sign-off instead of a quiet drift forward.

Nothing is a gate by default: a gate exists because the project has reached a decision that you, not [Dexter](/product/ai-assistant), have to make.

## Where Gates Live

Gates live inside **Projects** — the durable, multi-session efforts (a [simulation study](/product/simulation-studies), a planning build) that ProDex tracks across conversations. A project is divided into **phases**, and each phase closes with a gate.

<Note>
  Projects are the most important place gates show up, but not the only one: the same review-and-approve step (a **request for review**) is a general mechanism Dexter can use to pause for your sign-off — for instance inside a [custom workflow](/product/dexter/custom-workflows). What you won't find are gates attached to objects like data sources, [pipelines](/product/templates), or individual simulation [runs](/product/runs) — a gate is always a deliberate point where Dexter asks for your judgment, not a status field on a thing.
</Note>

A project's phase structure is designed for the work at hand: Dexter proposes the phases at the start of the project and revises them as reality demands. Each phase is a gated unit of progress — the work behind one point where you sign off before the next builds on it.

## The Gate Lifecycle

1. **Work in progress.** Dexter drafts the phase's deliverable in the project's private workspace, iterating with you as needed.
2. **Review brief presented.** When the phase's work is ready for sign-off, Dexter presents a **review brief**: a self-contained summary of what you are approving, the assumptions the decision rests on, and the evidence behind it (tables, figures, the actual numbers). The brief is the gate.
3. **Approve or request changes.** You either approve the brief or send it back with feedback.
4. **On approval**: the phase's deliverable lands in the project's visible phase directory, the project's current phase advances, and Dexter picks up the next phase's work.
5. **On request-changes**: Dexter iterates on the deliverable in light of your feedback and re-presents the brief when it's ready. The gate stays open until you approve.

Gate states in practice are simple: **awaiting your review**, **approved** (the phase has closed), or **changes requested** (Dexter is iterating). There is no auto-timeout, no partial approval, and no rejection that permanently blocks the project — a gate stays open until you close it.

## Who Approves, and How

You do — always. Gates are the surface where the project waits on human judgment. Approval is a single action on the review brief. If more than one person on your team should weigh in, discuss offline; the platform records the approval from whoever confirms it in the workspace.

## What Approval Unblocks

Approving a gate does three things:

* **Lands the deliverable.** The document the brief rested on moves into the project's phase directory, where it becomes the durable, user-visible record of that phase's work.
* **Advances the project.** The project's current-phase cursor moves forward, so the next session resumes in the new phase without ambiguity about where things stand.
* **Frees dependent work.** Any phase whose brief rested on the just-approved deliverable can now be started or picked back up.

The project's final gate closes the project itself.

## When Work Needs to Be Redone

If a phase's work turns out to be wrong after the gate closed — a validation gap surfaces later, an assumption breaks, the operation itself changes — the fix is to **reopen the affected phase and work through its gate again**. The prior deliverable is revised (or replaced), a new brief is presented, and you sign off on the corrected work. Later phases whose deliverables depend on the reopened one get reviewed and re-approved as needed.

<Tip>
  **Reopening is expected as projects mature.** Gates make the "what changed and when" auditable rather than lost — don't treat a closed gate as a reason to avoid correcting the work behind it.
</Tip>

## Gates and Simulation Studies

The clearest example is a **[simulation study](/product/simulation-studies)**. A credible study's phases each produce a specific deliverable that later phases depend on: the charter (the decision the model exists to drive and the bar it must clear), the data foundation, the operational representation, the sources and assumptions behind each parameter, the validation record. Each of those is a natural gate — you approve the charter before the model gets built against it, the data foundation before parameters are fitted from it, and the validation record before the model's recommendations go to management. The gates are what make the study defensible when the results reach a room full of stakeholders.

The same shape applies to other multi-session efforts (a planning-model build, a BOM restructuring effort): Dexter designs the phases and their gates around the specific work.

## Limits and Caveats

* **The phase-boundary framing is project-specific.** The phased, sign-off-per-phase structure this page describes belongs to projects; an ordinary chat isn't a gated surface. Dexter can still pause for an explicit review outside a project — a [custom workflow](/product/dexter/custom-workflows) can request one — but there's no gate attached to data sources, pipelines, or runs as objects.
* **Gates are human sign-offs, not automated checks.** They don't validate the underlying work — that's the deliverable's own responsibility (a [validation](/reference/validation) record, a data quality assessment). A gate confirms that a human read what was produced and accepted it.
* **The phase structure is not fixed.** Dexter designs and revises the phases as the project teaches; the gates move with them. If a phase turns out to be the wrong shape, restructure the phases and gate the new shape rather than forcing bad work through the wrong gate.
* **Approval binds to the deliverable, not to a version number.** Reopening a phase and re-approving it is the correct pattern when work needs to change; there is no "gate rollback" separate from that.

## If You Came Looking for Pipeline Gates

Older docs described gates as verification checkpoints living on pipeline source and transformation nodes, with pending/confirmed/rejected states and Confirm/Reject buttons in chat. **That surface does not exist in the current product.** [Pipelines](/product/templates) are documents of derivations that already ran — there is nothing on a pipeline to approve or reject, and no gate fields on any node. Verifying that a pipeline's numbers match reality belongs to the artifact those numbers feed (a simulation model's validation record, an [EDA](/product/exploratory-analysis) dashboard's user confirmation), not to a gate on the pipeline itself.