Supply-chain assurance: delivery ≠ conformity

⚡ TL;DR

When one organisation buys an AI system from another, the buyer has a trust problem: how do you know that what you received is exactly what the supplier built, and that it is good enough to accept? The answer this course gives is git-native delivery. The supplier builds and cryptographically signs the system’s evidence in its own repository, then delivers by mirroring the repo — only digests and signed evidence move across the handoff; the heavy model weights stay in the supplier’s custody, referenced by a pinned hash (dvc.lock). The buyer runs froga verify with the supplier’s public key only — no private key changes hands, nothing runs on the network, no data transits. But here is the lesson, and it is three lessons in one. A verified signature proves authenticity — the evidence is byte-for-byte what the signer committed. It does not prove the delivery is accepted — that is the buyer’s tender-gate decision (signatures valid and no blocking control RED). And neither of those proves conformity — that the product actually meets the law, a per-clause judgement that, for the high-risk classes, only an accredited notified body can make. A delivery can be authentic and accepted and still carry a documented gap to full conformance. Three separate gates — do not collapse them. And the frontier: there is no notified body in this chain.

🎯 By the end you'll be able to…

• Describe the git-native handoff: the supplier signs evidence in its repo and mirror-delivers; only digests + signed evidence cross, while the weights stay in custody behind a pinned hash.
• Explain what froga verify checks — an in-toto/DSSE envelope, ECDSA-P256, keyid == sha256(public key) — and that it is public-key-only, local, and moves no data.
• Distinguish the three things the chain can establish — authenticity ≠ acceptance ≠ conformity — and why a verified, accepted delivery may still be non-conformant.
• State the frontier honestly: there is no notified body in this chain; an auditor who runs froga verify confirms authenticity but does not certify.
• Locate the provider/deployer split (EU AI Act Art. 16 / Art. 25, disclosure under Art. 47) across the handoff — and name what is roadmap, not built.

The handoff: signed evidence, custody kept

A supplier builds an AI system and a buyer wants it. The naïve handoff ships everything — code, weights, data, reports — and hopes the buyer trusts the bundle. The git-native handoff is leaner and more trustworthy.

The supplier governs the system in its own git repository, and at the end it signs the evidence under .froga/ — the bundle, the reconstruction record, the per-standard conformance results, each with a detached signature. Delivery is then just mirroring the repo to the buyer. Only digests and signed evidence travel across the handoff. The heavy model weights and datasets do not — git carries only a pointer plus a hash (dvc.lock), and that hash is itself anchored inside the signature.

The weights stay in the supplier’s custody, behind its MLOps backend (a DVC remote). The buyer pulls the bytes and checks them against the pinned hash, or re-derives them deterministically — never through any third-party or intermediary infrastructure. So the buyer ends up holding a small, verifiable record that commits the supplier to exactly the weights it built, without those weights ever having to flow through an untrusted middle.

What actually crosses the wire

Two things, and only two: digests (hashes that name the artifacts) and signed evidence (the .froga/ dossier with its .sig files). The bulk — model weights, training data — stays put. The buyer trusts a hash anchored in a signature, then fetches or re-derives the bytes and checks them against that hash. The handoff is small because trust does not require shipping the heavy bytes; it requires committing to them, cryptographically.

Verifying with a public key

froga verify reads the signed dossier under .froga/ and checks every present artifact. Each signature is a DSSE in-toto envelope — a standard format, not a proprietary check:

• the payload type is application/vnd.in-toto+json;
• the signature is ECDSA-P256 over the DSSE PAE (pre-authentication encoding);
• the keyid equals sha256(public key), so the key that signed is named by its own hash;
• the in-toto subject digest equals sha256(the artifact bytes), binding the statement to the exact file.

It is public-key-only (the buyer never sees a private key), local (no network call), and it moves no data. The exit code is 0 iff every present artifact verifies; a present artifact that is missing its .sig fails, so you cannot quietly drop a signature. Because it is plain in-toto/DSSE, any in-toto verifier can check the same envelope — the buyer is not locked into a froga-specific tool.

What a green froga verify proves is exactly one thing: authenticity. The evidence is byte-for-byte what the signer committed, untampered. Notice what it does not prove — a blocked delivery (with a RED gate) still verifies as authentic. Authenticity is about who committed what, not about whether it passes.

Three things, not one: authenticity ≠ acceptance ≠ conformity

This is the heart of the page. The supply chain can establish three different things, and the most common mistake is to collapse them into one.

Three gates, three different questions

Authenticity asks “is this evidence really what the signer committed?” — answered by froga verify with the public key. Acceptance asks “does it pass the buyer’s tender gate?” — a procurement decision, not a certificate. Conformity asks “does the product actually meet the law, clause by clause?” — for the high-risk classes, an accredited notified body’s judgement. A delivery can be authentic and accepted and still not conformant, because a documented gap can remain. Never let one green tick stand in for all three.

Thing	Question	Who / what answers it	What it is NOT
Authenticity	Is this evidence exactly what the signer committed?	froga verify, public-key-only	Not acceptance; a blocked delivery still verifies
Acceptance	Does it pass the buyer’s tender gate?	The buyer’s procurement decision: signatures valid AND no enforcement: gate control RED	Not a conformity certificate
Conformity	Does the product meet the law, per clause?	An accredited notified body (high-risk classes)	Not the buyer’s gate; not what a signature proves

The acceptance gate is precise: a delivery is ACCEPTED iff (a) signatures verify AND (b) no blocking (enforcement: gate) control is RED. Audit / warn controls do not block. And crucially, the gap to full conformance (gapToFullConformance) is computed independently of acceptance and never changes it — an ACCEPTED delivery can still carry a documented gap to full conformance. The buyer’s gate is a tender criterion, not a certificate.

No notified body in the chain

Here is the frontier, stated plainly: there is no notified body in this handoff. A buyer — or an external auditor acting for the buyer — can run froga verify with only the public key, confirm that the supplier’s evidence is authentic, and read the honest state (which gates are green, which are RED, what gap remains). That third-party verification is real and useful.

But it is not certification. The auditor is not accredited to certify, and the buyer’s acceptance gate is a procurement decision, not a conformity one. For the high-risk classes, only an accredited notified body can issue a recognised conformity certificate — and there is no such body in this chain. Verifying a signature confirms the evidence is what the signer says it is; a notified-body assessment confirms the product meets the regulation. The chain can establish authenticity and surface gaps; it cannot close the conformity question for the high-risk classes.

The honest stop, again

This is the same boundary you meet on the notified body page, now in a buyer/seller shape. The supplier self-declares and signs; the buyer verifies and accepts; an auditor can re-verify. None of them is a notified body. The chain is honest precisely because it does not dress acceptance up as certification.

Provider vs deployer, and what’s roadmap

The handoff also splits legal obligations. Under the EU AI Act, the supplier is typically the provider (Art. 16) and the buyer the deployer (Art. 25); the supplier declares conformity and discloses (Art. 47), the buyer verifies the signed evidence and operates the system. The signature is what makes that split auditable: the provider’s obligations are committed in the bundle it signs, and the deployer can check exactly what it is taking on.

Tender-as-code is already built: the buyer imposes the blocking threshold through the tender itself. The contracting authority signs its OSCAL tender with froga sign-pliego and checks the bidder’s delivery with froga conformance --against-pliego <pliego> --aapp-pubkey <hex> (exit ≠ 0 if any block control fails). What remains to build is auto-deriving the tender from the EU Model Contractual Clauses for AI.

Other pieces are named here but not yet built — teach them as roadmap, not as features:

• eIDAS-bound identity. Today the buyer pins the supplier’s public key out-of-band — trust-on-first-use, not eIDAS. The roadmap is eIDAS qualified signatures binding the key to a legal identity.
• Transparency logs. A public append-only log (Sigstore / Rekor) would let anyone check a signature was logged, not just verify it locally. Not built.
• Federated multi-supplier graph. Today this is a single handoff (one supplier → one buyer). A federated attestation graph across many suppliers (sub-suppliers, components) is roadmap.

Self-check

❓ The supply chain can establish three different things. What are they, and why must you not collapse them?

Authenticity — “is this evidence exactly what the signer committed?” — answered by froga verify with the public key. Acceptance — “does it pass the buyer’s tender gate?” — i.e. signatures valid and no blocking (enforcement: gate) control RED; a procurement decision, not a certificate. Conformity — “does the product actually meet the law, per clause?” — which, for the high-risk classes, only an accredited notified body can certify. You must not collapse them because a delivery can be authentic and accepted and still not conformant: a documented gap to full conformance can remain, and gapToFullConformance is computed independently of acceptance and never changes it. Three separate gates.

❓ What exactly does `froga verify` prove — and what does it not prove?

It proves authenticity only: every present artifact under .froga/ is byte-for-byte what the signer committed. Each signature is a standard DSSE in-toto envelope (application/vnd.in-toto+json, ECDSA-P256, keyid == sha256(public key), subject digest == sha256(artifact bytes)); the check is public-key-only, local, and moves no data, and it exits 0 iff every present artifact verifies (a present artifact missing its .sig fails). It does not prove acceptance (the buyer’s tender gate) and does not prove conformity (the law, per clause). A blocked delivery — with a RED gate — still verifies as authentic, which is exactly the point: authenticity is about who committed what, not about whether it passes.

❓ A delivery's signatures verify and the buyer accepts it. Why might it still be non-conformant?

Because acceptance is not conformity. Acceptance means the buyer’s tender criterion was met — signatures valid and no blocking control RED — which is a procurement decision, not a certificate. Conformity means the product meets the law clause by clause, which for the high-risk classes only an accredited notified body can certify — and there is no notified body in this chain. The engine even computes the gap to full conformance (gapToFullConformance) independently of acceptance, so an ACCEPTED delivery can carry a documented gap. Authentic + accepted + still-non-conformant is a perfectly coherent (and honest) state.

Where to go next

Level 6 · Supply-chain capstoneThis page applied end to end: a supplier signs and mirror-delivers, a buyer verifies with the public key and runs its tender gate, and the three things — authenticity, acceptance, conformity — are kept honestly distinct, with the documented gap and the missing notified body in plain sight.

Notified body vs self-declarationThe frontier of this chain: why an auditor running froga verify confirms authenticity but does not certify, and why only an accredited, independent notified body can close the conformity question for the high-risk classes.

EU AI Act — the spineThe reference for the provider/deployer split (Art. 16 / Art. 25), disclosure under Art. 47, and how the engine projects the Act onto the signed bundle — including why a RED verdict and a still-valid signature are not the same thing.

Sign & verifyThe hands-on guide to the signing and verification that makes the handoff trustworthy: the in-toto/DSSE envelope, ECDSA-P256, public-key-only verification, and how to pin a supplier's key (trust-on-first-use today).