Review Gate

Origin & evolution

The clearest ancestor is Stage-Gate, developed by Robert G. Cooper, whose study of 252 new-product histories across 123 firms gave the term its first appearance in print in 1988 (Stage-Gate International). A Stage-Gate process separates stages of product development with gates that act as Go/Kill decision⚖️DecisionStrategyA recorded decision with context, rationale, and consequencesView reference → points: a project advances only when a reviewer judges it ready, and may be killed instead. The gate exists to stop investment in work that should not continue.

Software borrowed the pattern under the banner of human-in-the-loop control. As deployment📤DeploymentEngineeringA deployment eventView reference → pipelines automated more of the path to production, teams reintroduced deliberate pauses, the manual approval before a release, the sign-off before a destructive migration. The thinking matured from "gates slow us down" toward "gates put a decision where the risk🎲RiskComplianceA risk to the product or businessView reference → is", placing approval at the few points where a wrong automated step is expensive to undo.

How it works in practice

A deploy-production workflow runs⏯️Workflow RunWorkflows & AgentsAn execution of a workflowView reference → build, then test, then a review gate, then the deploy step. When run #92 reaches the gate, the workflow stops and notifies the on-call engineer. She reads the diff, confirms the database migration is reversible, and approves. The approval is written down with her name, the time, and a one-line reason. The deploy step then runs. Had she rejected, the run would have halted at the gate and the release would not have shipped. The gate turned an unattended pipeline into one with a single, deliberate human decision at the point of maximum consequence.

Review gate vs. its neighbours

• Approval record🔏Approval RecordWorkflows & AgentsA record of an approval decisionView reference → is the immutable evidence🔎EvidenceValidationData supporting or refuting a hypothesisView reference → a gate produces: who decided, when, and why. The gate is the checkpoint; the record is the artefact left behind after it is cleared, the thing an audit reads later.
• Workflow template🎻Workflow TemplateWorkflows & AgentsA reusable workflow templateView reference → owns the gate as part of its structure, declaring where in the sequence the pause sits. The gate governs whether a given run may pass that point; the template decides the gate exists at all.
• Release is often what a gate guards. A gate can block a release until approval is granted, making the gate the mechanism and the release the thing held back.

In the graph

In the Unified Product Graph, a review gate sits in the automation region as the control point in an automated flow. It attaches to its workflow through workflow_template_gated_by_review_gateWorkflow Templategated byReview Gatehierarchy, so the structure of every run carries the checkpoint. Its outcome🏆OutcomeStrategyA desired business or user outcomeView reference → is recorded through review_gate_approved_via_approval_recordReview Gateapproved viaApproval Recordhierarchy, giving each decision a durable, queryable trace. When a gate stands between work and shipping, review_gate_blocks_releaseReview GateblocksReleasecross-domain makes that dependency⛓️DependencyTeam & OrganisationA cross-team or system dependencyView reference → explicit, and workflow_run_passes_through_review_gateWorkflow Runpasses throughReview Gatecausal ties a specific execution to the moment it cleared. Modelling the gate as its own entity is what lets the graph distinguish the checkpoint from the decisions made at it.