Level 6 · The framing — the procurement handoff and the laws of the chain

§1 — The procurement handoff (three actors)

Every earlier level lived inside one organisation: a supplier’s Quality role and engineer ran the loop and signed the bundle. The capstone changes the camera. Now there are three kinds of actor, and the interesting thing happens between them.

• The provider (supplier). The organisation that built and signed the AI system in its own git repo. There are two of them here. Ollomar Diagnóstica S.L. built a retina screener; EduAtlante Analytics S.L. built an education model. Inside each, the team you already know — 🛡️ James and 🧑‍💻 Martha — did exactly what Levels 1-5 taught: declared the system, governed the risk, measured the controls, and signed the bundle with the developer’s own key.
• The deployer (the receiving public body). Servizo Atlante de Saúde (org slug saude-atlante), a fictional AAPP, is procuring both systems. It does not build anything; it receives, verifies, and accepts (or rejects).
• The external auditor. 🔎 Aitor sits on the buyer side. His job is narrow and sharp: confirm that what the supplier delivered is authentic and read its honest state — using nothing but the supplier’s public key.

The handoff itself is git-native: each supplier mirrors its signed delivery repo to the buyer. What crosses the boundary is only the small, signed stuff — the manifest, the reconstruction record, and the conformance projections, each with its detached signature. The heavy model bytes never travel through Venturalítica infrastructure: git carries only a pointer and a hash (dvc.lock) that is itself anchored in the signature. The receiving body fetches the actual weights from the MLOps backend (a DVC remote today) with dvc pull and checks the hash, or it re-derives them with froga reconstruct.

What crosses the boundary — and what stays in custody

The delivery is not a data dump. Across the org boundary travel only: .froga/bundle.json (the signed manifest), .froga/reconstruct.json (how it was built), and conformance/*.json (the per-standard projections) — each with its .sig. The model weights are referenced by hash in dvc.lock, and that hash is signed, so tampering is detectable — but the bytes themselves stay in the supplier’s DVC remote. The buyer pulls them separately and checks the hash. Authenticity is established over the signed artefacts; data custody never moves to the buyer’s verifier or to Venturalítica.

§2 — Which laws govern the chain

A procurement chain is not governed by a single Article — it is governed by who-owes-what across the handoff. Be precise about each.

• EU AI Act Art. 47 (EU Declaration of Conformity / disclosure) — reframed for a chain. Art. 47 is about the provider declaring conformity. In a signed handoff this becomes a two-sided act: the supplier declares (it signs its bundle and its conformance projections), and the buyer verifies the signed evidence rather than taking the declaration on trust. The declaration is still the supplier’s; verification gives the buyer a cryptographic reason to believe the declaration is authentic (not whether it is correct in law — that is conformity, §4).
• Arts. 9-15 revisited — the whole spine, now read by the buyer. Everything Levels 1-5 built — risk management (Art. 9), data governance (Art. 10), record-keeping (Art. 12), transparency (Art. 13), human oversight (Art. 14), accuracy/robustness (Art. 15) — is exactly the dossier the buyer now reads. The capstone does not add new spine articles; it changes who is looking at them: the provider produced the evidence, the deployer audits it.
• Art. 16 / Art. 25 (provider vs deployer) — who owns what. This is the chain’s spine. Art. 16 lists the provider’s obligations (build the system right, run the conformity assessment, draw up the documentation, sign the DoC). Art. 25 governs the deployer (and the cases where a deployer becomes a provider). In our chain the split is clean: the supplier (provider) signs in its repo; Servizo Atlante de Saúde (deployer) verifies and accepts. The acceptance decision is a deployer act; it does not transfer the provider’s conformity obligations onto the buyer, and it does not discharge them either.
• Tender-as-code — REAL today. The buyer imposes the blocking threshold through the tender itself; it is not supplier-declared. The contracting authority signs its OSCAL tender with froga sign-pliego (same ECDSA-P256+DSSE scheme as the evidence) and checks the bidder’s delivery with froga conformance --against-pliego <pliego> --aapp-pubkey <hex>: it verifies the tender’s signature, intersects the clauses the tender marks as block with the bidder’s signed conformance evidence, and exits ≠ 0 if any fail. Signature authenticity still does not imply acceptance nor conformance — three distinct checks.
• EU MCC-AI (Model Contractual Clauses for AI procurement) — ROADMAP (clause generation). The EU publishes Model Contractual Clauses for public procurement of AI; the High-Risk set has 21 articles (its Art. 8 ≈ AI Act Art. 15, accuracy/robustness). The OSCAL tender signed today is hand-authored; auto-deriving it from the MCC-AI is what remains to build. We name MCC-AI so you know that remaining frontier, not to claim it.
• in-toto / DSSE — REAL today. The signatures Aitor checks are not proprietary. Each artefact is a DSSE in-toto envelope (payloadType: application/vnd.in-toto+json) with an ECDSA-P256 signature over the DSSE PAE, a keyid equal to sha256(public key), and an in-toto subject digest equal to sha256(artifact bytes). Any in-toto verifier can check it — froga verify is one mirror of a standard contract, not a walled garden.

Provider vs deployer — the split that the chain runs on

The single most important responsibility line in this level: the provider signs, the deployer verifies and accepts. Art. 16 keeps the conformity burden on the supplier (Ollomar, EduAtlante) — they built it, they assessed it, they signed the DoC. Art. 25 puts the deployer (Servizo Atlante de Saúde) on the acceptance side: read the signed evidence, decide whether to take delivery. The buyer’s “accepted” verdict is a procurement decision against the tender, not a re-assignment of the provider’s legal obligations and not a certificate. Mixing these up is the most common chain mistake — keep them apart.