Skip to main content

​
Overview

A gate is a verification checkpoint on a pipeline node. It tells Dexter to perform a specific set of checks, then stop and ask you to sign off before any downstream node runs. Gates are how the platform makes derivation auditable: every value that comes out of a pipeline has been through one or more user-confirmed checkpoints.

​
Where Gates Live

Gates are defined on the pipeline template, on individual nodes:
  • Source nodes — gates are required. Dexter places a gate on every source node automatically. The gate verifies input shape: required columns present, values in valid ranges, recipe codes match the known set, and so on.
  • Transformation nodes — gates are optional, recommended when the transform’s output drives a high-stakes downstream value. A “sanity check on computed mean cycle times” is a typical transform gate.
  • Output nodes — gates are not allowed. By the time a value reaches an output, the corrective lever is always upstream.
A node can carry at most one gate — gating is a single checkpoint per node, not a stack of them. Each gate has the following fields:
  • gate_id (required) — stable identifier
  • name (required) — short label users see in the chat prompt and the Run Information panel
  • description (optional) — context shown alongside the prompt; helpful for explaining why this check exists and what to look for
  • instructions (optional) — agent-facing directive listing the specific checks Dexter must perform. Best written as a Markdown bulleted list so the checks render clearly. This field is consumed by Dexter at run time to decide what to inspect, not displayed verbatim to the user — description is the user-facing field

​
Gate States

Gate state lives on the run, not the template. Each gate record on a run carries a status:
  • pending — Dexter has gathered evidence and is waiting for your decision
  • confirmed — You approved. Downstream nodes unblock
  • rejected — You flagged a problem. Downstream nodes stay blocked until the gate is reopened or the upstream is corrected
Status can change. A rejected gate can be re-confirmed if you change your mind, and a confirmed gate can be reopened.
Reopening a confirmed gate doesn’t roll back results that already landed downstream. The run record is append-only — values produced before the reopening stay on the run. New downstream work blocks until the gate is re-confirmed.

​
Confirming a Gate

When a run reaches a gate, Dexter poses a structured question in the chat panel. The message includes:
  • The evidence Dexter gathered — column counts, row samples, value ranges, the specific checks the gate’s instructions called for
  • A confidence level — high / medium / low — reflecting Dexter’s read on whether the input passed cleanly
  • Confirm and Reject buttons
A typical gate prompt looks like “Source: weekly_throughput.csv. Required columns [‘station’, ‘cycle_time’, ‘shift’] all present. 487 rows, 0 nulls in cycle_time. Cycle times range 12s–94s — within expected bounds. Confidence: high.” Click Confirm to proceed, or Reject to block downstream work. By default Dexter prompts for one gate at a time. For trivially clean gates Dexter may batch a small number into a single prompt — only when each one is independently low-risk and the evidence is straightforward. Multiple gates can sit pending at the same time when independent branches of the DAG reach their checkpoints simultaneously — those still each need their own confirmation.

​
How Gates Appear on the Canvas

Source and transformation nodes carry a small shield icon when a gate is configured on them. In a run, a confirmed gate is marked with a checkmark next to the shield. The Run Information side panel summarizes overall progress with a label like Gates resolved: 2 / 3.

​
When a Derivation Is Wrong

If a derivation comes out wrong, the right correction depends on what happened:
  1. The gate was confirmed by mistake (or the concern that caused a rejection has been resolved without changes) — re-confirm or reopen the gate on the same run. Existing results remain; the gate’s lifecycle reflects your final decision.
  2. The source data was wrong — fix the input, then run the pipeline again with the corrected source. The new run produces fresh results; old runs are preserved for comparison.
  3. The pipeline logic was wrong — edit the template (transformation code, instructions, gate definition), then start a new run.
There is no inline “manual override” on individual result values. Every correction flows through gate confirmation or a new run — the audit trail stays intact by design. If you find yourself wanting to “just fix this one number,” that’s a sign the upstream gate or transform needs adjustment.