Every agent output in Modulo passes through at least one gate before the next stage, catching mistakes before they reach a human reviewer or production: the gate passes and the output proceeds, or it fails and the run pauses for review or spawns a correction run. Modulo has four output-side gate types plus input-side guardrails.

Regex gate

A regex gate checks output against a regular expression pattern; it is the simplest and fastest gate type.

What it catches: Secrets and credentials (API keys, tokens, private keys), format violations (missing headers, incorrect date formats), and banned patterns (TODO markers, debugging code).

Configuration: A regex pattern and a description; the gate passes if the pattern does not match (for secrets) or does match (for required elements).

When to use it: On every output, as a first line of defense. Regex gates are cheap and catch the most common and dangerous failure modes; every pipeline should check for secrets.

JSON Schema gate

A JSON Schema gate validates output against a JSON Schema definition: structure, types, required fields, and value constraints.

What it catches: Missing required fields, wrong data types, values outside allowed ranges, structural violations (array when object expected).

Configuration: A JSON Schema document (draft-07). The gate passes if the output validates.

When to use it: For any structured output: a pull request description with required sections, a configuration file. Schema gates are the most common type in Modulo pipelines.

Custom function gate

A custom function gate runs a programmatic check: any validation logic expressible in code.

What it catches: Business logic violations (a discount code applied to an ineligible product), cross-field validation (start date before end date), integration-specific checks (the generated code compiles against the project's type definitions).

Configuration: A function that receives the output and returns pass or fail with an optional evidence message.

When to use it: When the logic is too complex for regex or schema checks. Most flexible, most expensive to maintain, so use only when simpler types cannot.

Scored eval gate (judged, nondeterministic)

A scored eval gate uses an LLM to judge output quality against a rubric, returning a score and a threshold-based pass/fail decision. It is a judged (soft) gate: the same output can score differently on a re-run, so the result is not reproducible.

What it catches: Quality issues that cannot be expressed as rules: code that is correct but poorly structured, documentation that is accurate but unclear, a design that is valid but not idiomatic.

Configuration: A rubric describing good output, a scoring scale, and a pass threshold. The gate passes if the score meets or exceeds the threshold.

When to use it: For subjective quality checks a rule-based gate would miss. They are the most expensive type (an LLM call per check), so use them sparingly where quality matters most, and treat pass/fail as a signal rather than a guarantee.

Guardrails (input-side)

Guardrails are the input-side analogue of gates: deterministic checks, regex or JSON Schema only, evaluated at run creation before the input payload is persisted.

What it catches: Secrets, credentials, and disallowed content in webhook payloads and manual triggers, before they reach any node.

Configuration: An eval definition with eval_type="guardrail". Actions are observe, warn, block, or redact. A block is terminal - the run never dispatches and has no HITL gate. Redact masks matched values before persistence.

When to use it: Protecting the ingestion edge: a guardrail stops structured credentials or banned content at the boundary. Remediation is the guardrail-override endpoint, which re-runs the guardrail pass on operator-supplied input (re-block safe) rather than resuming on the blocked payload.

Block vs warn

Every gate can be configured as block or warn. A block gate stops the run for human review; a warn gate logs the failure and lets the run continue. Block on secrets detection, schema validation failures, or any failure that should never reach production without review. Warn on quality checks, style violations, or any informative but non-blocking check. Warn gates also build confidence by showing what would be caught without blocking the pipeline.

The principle behind this: deterministic gates catch failures before they reach a human reviewer, and the run history shows which gate caught what - including which checks were judged by an LLM rather than evaluated deterministically.