The two gates: freshness and risk

The RDD flow requires passing two sequential gates before asserting conformance. Neither substitutes the other: fresh evidence with metrics outside the threshold is not conformant, and valid metrics on stale evidence are not conformant either.

Gate 1 — Freshness

Question: is the signed evidence current with respect to froga.lock?

froga status compares the current digests of the triple (code, model, dataset) against the anchors in froga.lock. If any digest has diverged, the freshness gate fails:

froga status          # exit 0 → fresh; exit ≠ 0 → stale

This gate can be integrated as a necessary condition in any CI/CD pipeline. Its failure does not indicate a metrics problem; it indicates that the signed bundle does not describe the system that is running, which makes any conformance assertion on it invalid.

The freshness gate logic is described in detail in Typed drift.

Gate 2 — Risk

Question: do all blocking controls pass their thresholds?

froga run executes the pipeline, measures the metrics, and evaluates each control declared in froga.yaml (ISO 23894 §6.4.4 — risk evaluation vs appetite). If any blocking control exceeds its threshold, the risk gate fails with exit ≠ 0:

froga run             # exit 0 → all blocking controls green

The evidence bundle is signed and anchored regardless of the gate result: the evidence of the failure is also recorded, which allows tracing the empirical arc FAIL → PASS through the treatment commits.

Details of how a control defines the red/green state are in The red/green loop.

The combined flow

froga status          →  gate 1: fresh?
   ↓ (exit 0)
froga run             →  gate 2: risk within appetite?
   ↓ (exit 0)
froga conformance     →  projection onto ISO 23894 / prEN 18228 catalogues

Both gates must be green for froga conformance to emit a conformance without blockings. A red gate — or an INCONCLUSIVE/underpowered control — at either step interrupts the chain. In the current public demos this does NOT happen: all seven systems land in GAP because of honestly measured controls (e.g. loan’s fairness is INCONCLUSIVE, not green). Clean conformance is reserved for systems with sufficient evidence, not for the illustrative scenarios.

The scenarios, the same engine

The demonstration scenarios — loan, retina-screening and spine-segmentation — collapse to the same engine because the engine does not distinguish between treatment types, only between gate colours:

Scenario	Treatment type	Regulatory framework
`loan` (credit, EU AI Act Annex III §5(b))	Bias treatment via the `mitigate` flag (`params.yaml: false → true`, fairlearn) → fairness control INCONCLUSIVE	DORA
`retina-screening` (retina, SaMD MDR Class IIa, EU AI Act Art.6(1))	Same `mitigate` flag (`false → true`, retrain with balanced class + threshold 0.30) → sensitivity gate `recall_score > 0.80`	MDR
`spine-segmentation` (medical imaging, SaMD MDR Class IIb, EU AI Act Art.6(1))	Measured Dice gate (`> 0.85`) + HOTL human oversight (Art.14) on the worst subgroup	MDR

The frameworks field in the signed evidence directs the projection to the corresponding clause catalogues (froga conformance --standard eu/pren-18228@2026 / --standard iso/23894@2023). The same bundle is projected onto different frameworks.

The treatment modalities (code/config change via the mitigate flag, HOTL human oversight, prompt adjustment) are described in Treatment modalities.

Normative relevance

Gate	Covered clause
Gate 1 (freshness)	EU AI Act Art. 9(1)(d) — continuous monitoring; ISO 23894 §6.5 (treatment evidence)
Gate 2 (risk)	ISO 23894 §6.4.4 — evaluation vs appetite; EU AI Act Art. 9(2) — proportionality of controls
`froga conformance` post-gates	ISO 23894 §6.4–§6.5 complete; prEN 18228 §9–§10; EU AI Act Art. 9 and Art. 11 (partial)

See the froga CLI reference for the flags of froga status, froga run, and froga conformance.