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 sei.lock?

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

Freshness gate in CI/CD

sei 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?

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

Risk gate

sei 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

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

Both gates must be green for sei conformance to emit a conformance without blockings. A red gate at either step interrupts the chain.

Blocking is per-criterion, not per-standard

sei conformance blocks per individual criterion (clause), not per complete standard. A prEN 18228 criterion can be blocked while the ISO 23894 profile of the same bundle is covered, and vice versa. This allows precise identification of which clause is missing at which point in the cycle.

---

Two scenarios, the same engine

The demonstration scenarios — loan and medical — 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)	Code change (V1 → V2)	DORA
retinopathy (retina, EU AI Act Annex III §6)	Parameter adjustment (params.yaml: use_mitigated: false → true)	EU AI Act
medical (medical imaging, EU AI Act Annex III §6)	Human HOTL oversight (Art.14)	MDR

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

The treatment modalities (code change, parameter adjustment, 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
sei 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 sei CLI reference for the flags of sei status, sei run, and sei conformance.