Skip to content

Level 3 · Practice & recap

There is no “run it yourself” here — the re-training is GPU-bound. Instead, watch the committed evidence and verify it yourself with only git and froga (no GPU, no dataset). The engine re-derives the verdict from the committed outputs, which is exactly what the nightly reproduce gate does:

With the repo already at the milestone (chip in the arc), verify and re-derive the verdict:

Terminal
# 1. Verify the signed evidence (no GPU, no dataset — just the committed bundle)
froga verify # checks bundle.json against its signature
# 2. Re-derive the gate verdict from the COMMITTED outputs (Outcome::Reused — no re-train)
froga run # reads the committed metrics → GREEN (recall 0.8847, CI low 0.8516)
# 3. Read the evidence by hand
# .froga/bundle.json → control_results[model-dr-sensitivity]: recall 0.8847, passed:true,
# power.ci_low 0.8516 (> 0.80) → clean green
# → means_of_conformance lists eu/mdr@2017 with its GSPR clauses (the crosswalk)
# → overall_residual: HIGH / within (lifecycle: draft, approval: null)
# 4. Compare the other two beats — the engine re-derives red, green, green:
git checkout retina-v1.0.0-red && froga run # RED (recall 0.4165, passed:false)
git checkout retina-v2.0.0-request && froga run # GREEN, but still draft / approval:null

Step 3 is the honest core of “watch, don’t run”: froga run takes the Reused path on the committed outputs, so the current engine re-derives the same colour with no GPU. A nightly CI job does exactly this for all three tags and asserts red / green / green — so the evidence you just read is machine-checked to still reproduce. What you should not see at retina-v2.0.0-request is an approve: the cycle is honestly paused.

The closing acts you can run yourself (they operate on the committed bundle, no GPU, no dataset). Each block below is the REAL step of the steps/ script —the same one that builds the published repository, not a hand copy—: Martha emits the signed conformance per applicable standard + the reconstruct, and requests approval. There the script ends:

Conformance + reconstruct firmados (entitlement + 6 normas) Martha
Commands
  • patch: entitlement.patch
  • froga conformance --standard eu/pren-18228@2026 --outmay fail
  • froga conformance --standard iso/23894@2023 --outmay fail
  • froga conformance --standard eu/ai-act@2024 --outmay fail
  • froga conformance --standard eu/mdr@2017 --outmay fail
  • froga conformance --standard eu/pren-18283@2026 --outmay fail
  • froga conformance --standard eu/pren-18282@2026 --outmay fail
  • froga reconstruct --outmay fail
  • git add -A
  • git commit -m ".froga: conformance + reconstruct firmados"
Solicitar aprobación (froga request) — verde firmado, ciclo en pausa: sin organismo notificado Martha
📍 reproducir retina-v2.0.0-request
git clone https://github.com/Venturalitica/vldemo-retina-screening
cd vldemo-retina-screening
git switch -c try retina-v2.0.0-request
git commitsolicitud de aprobación (el acto lo commitea froga request)

There is no approval step after it, and none on purpose: a Class IIa cannot be closed by self-declaration. The request act is whom the CLI attributes —Martha signs it— and there the cycle rests, at “requested”, anchored at retina-v2.0.0-request.

Your first overlay: one diabetic-retinopathy screener under two regimes at once — EU AI Act high-risk (via Art. 6(1) + Annex I, the product-safety route) and an MDR Class IIa medical device. The patient-safety risk was real (V1 recall 0.4165, missing most DR cases on real ODIR-5K images), the treatment was a versioned code change (class-balanced retraining + a 0.30 threshold), and V2 closed clean GREEN — recall 0.8847, bootstrap CI low 0.8516 > 0.80provably, not by assertion, because the cohort was large enough (contrast Level 2’s honest amber on n = 99). Art. 15 went deep as a real blocking gate with its limits declared (specificity unmeasured, PPV audit-only, single fold/seed, mono-population). Art. 14 went deep as declared, legitimate organizational oversight. The engine emitted a signed MDR crosswalk — documentation, not a conformity verdict — and no DORA (not a financial entity). And then the cycle paused at “requested”: a Class IIa device cannot close without an external notified body the engine is not. That honest stop is Level 3’s whole lesson — the hardest part of compliance is knowing, and saying, where your evidence ends.

What makes Level 3 an 'overlay', and how is the high-risk classification triggered here compared with Level 2?

It is an overlay because one system is subject to two regimes at once: the EU AI Act (governing it as an AI system) and the MDR (governing it as a medical device, Class IIa) stacked on top. The trigger differs from Level 2. Student selection was high-risk because of its useAnnex III §3 (education). The retina screener is high-risk because it is a safety component of a medical device, so the trigger is Art. 6(1) + Annex I (the product-safety route). The same fact — “this is a medical device” — both makes it AI Act high-risk (via Art. 6(1)) and makes it an MDR device in its own right. (No DORA: the operator is a clinic, not a financial entity.)

The engine emits a signed MDR document for this system. Why is that a 'crosswalk, not a verdict', and why must you never say the system is 'MDR-governed'?

Because the engine’s invariant is that it does not compute conformity — it projects already-signed evidence. The MDR output is a signed crosswalk: a faithful, verifiable mapping of what was measured and declared onto the MDR’s GSPR clauses — documentation a manufacturer prepares for a notified body, not a statement that the device is MDR-conformant. Structurally, the MDR is binding law, not a harmonised AI-risk-management standard cited for Article 9, so it sits outside the engine’s verdict-bearing authority chain and confers no presumption. Calling the system “MDR-governed” because it carries the crosswalk over-claims a capability the engine does not have; the conformity verdict belongs to the MDR’s own route — for a Class IIa device, an external notified body. Caption it: “signed crosswalk, NOT a conformity verdict.”

V2 closed clean GREEN — the patient-safety gate passed and the CI cleared the line. So why does the cycle pause at 'requested' instead of being approved?

Because a Class IIa medical device cannot close its conformity cycle on the manufacturer’s own attestation. The MDR conformity-assessment procedure (Article 52) requires an accredited, independent notified body to assess the evidence and issue a certificate before the device can go on the market — and the engine is not a notified body. It signs with the developer’s own key (a fictional Dev Demo signer), which is self-declaration, the opposite of the independent third-party assessment the MDR demands; and the MDR also requires a clinical evaluation (Annex XIV) that lives outside any risk-management engine. A green technical gate is necessary but not sufficient. So the most honest thing the lifecycle can do is pause at “requested” (state draft, approval: null): everything before the notified body is done and signed, and the cycle waits at the boundary it cannot cross. That pause is the notified-body GAP, written into the state machine.

You have now met your first overlay, two deep articles (15 and 14), and the honest notified-body GAP. The other overlays stack different regimes on the same spine: