Level 6 · Supply chain — the capstone

🟡 Partial — The two signed deliveries are REAL published repos (org Venturalitica), each hand-tagged at HEAD as a single state (no V1→V2 arc): vldemo-retina-delivery @ retina-delivery-v1.0.0-blocked and vldemo-quickstart-delivery @ quickstart-delivery-v1.0.0-accepted. The `froga verify` transcripts shown below are REAL (froga 0.1.1) — both print `firma VÁLIDA` and exit 0. The nightly reproduce gate re-runs `froga verify` (asserting exit 0) plus an acceptance jq mirror across both tags, asserting BLOCKED for the retina delivery and ACCEPTED for the education one. Honest frontiers: there is NO notified body in the chain (Aitor verifies, he does not certify). Tender-as-code IS built (`froga sign-pliego` + `froga conformance --against-pliego`: the threshold is imposed by the tender); still ROADMAP are EU MCC-AI clause generation / eIDAS key-to-legal-identity binding / Sigstore-Rekor transparency / a federated multi-supplier graph / 10-year evidentiary retention.

TL;DR

This is the capstone. Across Levels 1-5 a supplier’s team — James (Quality) and Martha (engineer) — built and signed an AI system inside its own git repo. Now zoom out to the procurement chain. A receiving public body, Servizo Atlante de Saúde (org saude-atlante), is buying AI from two suppliers, and each one delivered by mirroring its signed repo — only digests and signed evidence move; the heavy model weights stay in the supplier’s custody. Supplier A — Ollomar Diagnóstica S.L. ships a retina screener (a medical device). Supplier B — EduAtlante Analytics S.L. ships an education model. An external auditor, Aitor, sitting on the buyer side, verifies each delivery using only the supplier’s public key — no private keys, no data transit, no network calls. Here is the whole course’s payoff in one line: both deliveries verify as authentic (firma VÁLIDA, exit 0) — even the one that is blocked — yet one is BLOCKED and one is ACCEPTED, and NEITHER is “conformant”. The acceptance gate is a tender (pliego) criterion (valid signatures and no blocking control RED), not a conformity certificate; and there is no notified body anywhere in this chain. Three distinct things, never to be confused: authenticity (does the signature check out?) ≠ acceptance (does the buyer’s tender door open?) ≠ conformity (does each clause of the law hold, per a per-clause judgement?). Aitor proves the first, the tender gate decides the second, and only an accredited notified body can issue the third — which nobody in this chain does.

This level zooms out from one supplier to the whole procurement chain. If you have not met an external auditor or the supply-chain framing, read these first:

Level 5 · Talent screening — Aitor debutsThe previous level, where the external auditor Aitor first appeared: he ran `froga verify` with only a public key to confirm authenticity and read the honest open state — but did NOT certify. Level 6 puts Aitor at the centre, verifying TWO suppliers across a procurement handoff.

The supply chain — signed handoffs across organisationsThe concept this capstone runs on: a federated chain of signed deliveries (supplier → buyer), where only digests and signed evidence cross the boundary, weights stay in custody, and authenticity / acceptance / conformity are three distinct judgements.

Prerrequisitos

The whole spine (Levels 1 and 2 for the high-risk Articles 9-15 backbone), More than the AI Act, and ideally all three overlays (Level 3 retina/MDR, Level 4 credit/DORA, Level 5 talent/employment), plus What is a risk? for the RED / AMBER / GREEN vocabulary. A note on materials:

This level is WATCH, not run. You do not build or sign anything here — the two suppliers already did that in their own repos (that was Levels 1-5). You take the buyer’s seat: you clone each delivery, read the committed dossiers, and run the real froga verify transcripts shown in §3. The acceptance verdict (blocked / accepted) is read from the committed evidence, mirrored by the nightly gate.
Aitor (external auditor, public-key-only verification) is the central figure now, on the buyer side. James and Martha are inside a supplier — they built and signed the system in the earlier levels; here their work is the input Aitor verifies.

By the end you'll be able to…

Describe the three-actor procurement handoff: a provider (supplier) signs in its own repo, a deployer (the receiving public body) verifies and accepts, and an external auditor (Aitor) checks authenticity with only a public key — and say what crosses the boundary (digests + signed evidence) and what does not (the model weights).
Run (and read) the real froga verify transcripts for both deliveries, and explain why both print firma VÁLIDA and exit 0 even though one delivery is blocked.
Hold apart the three distinct things: authenticity ≠ acceptance ≠ conformity — and place each of the two deliveries on all three axes.
Explain the acceptance gate as a tender (pliego) criterion (valid signatures and no blocking control RED) — and why gapToFullConformance is computed independently and never flips the accept/block decision.
Say why there is no notified body in the chain: Aitor verifies and reads the honest state but does not certify (no accreditation, not in NANDO), and the MDR crosswalk in the retina delivery is a cross-map only, never “MDR governed”.
Explain how the tender imposes the threshold: the contracting authority signs its OSCAL tender with froga sign-pliego and the buyer checks the delivery with froga conformance --against-pliego (exit ≠ 0 if any block control fails) — the threshold is imposed by the tender, not supplier-declared.
Name the roadmap frontiers honestly: EU MCC-AI clause generation from the tender, eIDAS key↔legal-identity binding (today the buyer pins the key out-of-band = TOFU), Sigstore/Rekor transparency, a federated multi-supplier graph, and 10-year retention.

Lessons in this level

The framing — the procurement handoff and the laws of the chainA receiving public body procures AI from two suppliers who built and signed their system in their own git repo; which laws govern the supply chain.

The verification with a public keyAitor, external auditor, verifies each delivery with ONLY the supplier's public key (no private keys, no data transit): both verify as authentic, yet one ends up BLOCKED and one ACCEPTED.

In depth — authenticity ≠ acceptance ≠ conformityThe three distinct things (verify ≠ the tender door ≠ the per-clause judgement), why there is no notified body in the chain, and what is in custody versus what is roadmap.

Course recapReview the capstone payoff (authenticity ≠ acceptance ≠ conformity) and self-check what you learned across the whole course.