Module gate 

The gate framework (SPEC §8 — the moat).

A gate inspects a candidate ModelResponse and returns a GateResult verdict. Gates are async because a real gate is I/O: a subprocess plugin (§8.1), an LLM judge, a test run. Pure inline gates (non-empty, json-valid, schema) simply don’t await. Gate execution is wrapped by an error budget (GateHealth): a gate that errors too often is auto-disabled with an alarm, so a broken gate can neither silently fail closed (burns money) nor silently fail open (burns trust) (§7.2).

Structs

GateHealth

Rolling per-gate error budget (§7.2, §8.3.4). Tracks the last window outcomes; once the error (abstain) fraction over a full window exceeds max_error_rate, the gate is auto-disabled and an alarm is logged. A disabled gate is skipped by the runner (its verdict stops counting) rather than silently failing open or closed.

GateHealthRegistry

Per-(tenant, gate) error budgets for a running proxy (app-level, shared across requests; ADR 0004 §D6). Budgets (window + max abstain fraction) are registered per gate id at startup; the actual rolling-window accounting is a separate GateHealth per (tenant, gate) pair, so one tenant tripping a gate’s budget auto-disables it only for that tenant, not globally. With auth off every request carries the tenant id "default", so there is exactly one bucket per gate and behavior is unchanged from the pre-D6 global registry.

JsonValidGate

Passes only if the completion parses as JSON. Useful for structured-output routes.

NonEmptyGate

Fails an empty (whitespace-only) completion. The cheapest possible sanity gate.

SchemaGate

Validates the candidate (parsed as JSON) against a minimal JSON-Schema subset: top-level type, required, and per-property type. Covers tool-call args and extraction tasks.

Traits

Gate

A verification gate. Object-safe + async so subprocess/model gates fit the same contract.

Functions

aggregate

Aggregate per-gate verdicts into the attempt’s overall verdict.

resolve_gates

Resolve a route’s gate ids into runnable gates. Built-in ids (non-empty, json-valid) map to inline gates; any other id is looked up among the config’s [[gate]] definitions and built as either a SubprocessGate (a cmd gate, SPEC §8.1) or a JudgeGate (a judge gate, §8.3). The judge needs a provider (from registry) and the caller’s credentials (auth, BYOK). An id that is neither built-in nor defined — or a judge whose provider isn’t registered — is skipped with a warning rather than failing the request.