Level 6 · In depth — authenticity ≠ acceptance ≠ conformity

§4 — Authenticity ≠ acceptance ≠ conformity

This is the heart of the capstone — the payoff of the whole course. There are three different judgements, made by three different parties, answering three different questions. Confuse any two of them and you will trust the wrong thing.

Judgement	The question it answers	Who makes it	Output	Retina (A)	Education (B)
Authenticity	Are the bytes exactly what the private-key holder signed?	🔎 Aitor via froga verify	firma VÁLIDA / exit 0	✅ authentic	✅ authentic
Acceptance	Does the buyer’s tender (pliego) door open?	Servizo Atlante de Saúde (deployer)	accepted / blocked	❌ BLOCKED	✅ ACCEPTED
Conformity	Does each clause of the law hold?	An accredited notified body	a certificate	⚠️ not conformant (gap)	⚠️ not conformant (gap)

Both deliveries have a VALID signature (authenticity), but their gate verdict differs — and neither is CONFORMANT (no notified body in the chain):

Venturalítica·demo.venturalitica.ai

●Ollomar (retina) · VALID signature · BLOCKED

Venturalítica·demo.venturalitica.ai

●EduAtlante (education) · VALID signature · ACCEPTED

Read the table down each column. Supplier A (retina) is authentic + NOT accepted + NOT conformant: its signatures verify perfectly, but its blocking model-dr-sensitivity control is RED, so the tender door stays shut — and it still carries a documented gap to full conformance. Supplier B (education) is authentic + accepted + NOT conformant: its signatures verify, its blocking fairness-parity control passes so the tender door opens — but it still has a documented gap to full conformance. Neither delivery is “conformant”; conformity is a separate, per-clause judgement that nobody in this chain has issued.

The acceptance gate is concrete and lives in cloud/lib/froga/delivery-acceptance.ts as deliveryAcceptance. A delivery is ACCEPTED iff (a) the signatures verify (trusted) and (b) no control with enforcement gate/block is failing. The order matters: signature failure is checked first → blocked (signature); else a failed gate control → blocked (control); else accepted. Crucially, audit/warn controls in red do NOT block — only blocking controls do.

`gapToFullConformance` is computed independently — and never flips the verdict

The engine also computes gapToFullConformance = (verdictKind === "gap") — and it does so independently of the accept/block decision; it never changes whether a delivery is accepted or blocked. Both deliveries are gap, so both carry a documented gap to full conformance — even the accepted education model. That is the honesty bolt: “accepted” means the tender criterion was met, not fully conformant. The cloud i18n labels this door “Acceptance — tender gate” and states verbatim that the per-clause conformity opinion “is issued by the notified body” — not by this gate. The gate opens a procurement door; it does not close a conformity question.

Why both verify VÁLIDA yet differ — the one-sentence test

If someone tells you “the signature verifies, so we’re good to go,” stop them. Verify answers is it authentic? (both: yes). Accept answers does our tender door open? (A: no, B: yes). Conformity answers does it meet the law clause by clause? (both: not established — a gap remains, and only a notified body can close it). Three questions, three answers, never collapse them into one.

§5 — No notified body in the chain

This is the most important frontier of the whole course, and the capstone states it plainly: there is no notified body anywhere in this procurement chain.

🔎 Aitor verifies (he proves authenticity) and reads the honest state (he can see blocked vs accepted, and the documented gap). He does not certify. He is not accredited, he is not designated in NANDO, and he has no certificate to issue. His value is exactly his honesty: he can establish authenticity for his principal and surface the open state — including telling the buyer “this delivery is authentic and blocked” or “authentic, accepted, and still carrying a gap to full conformance.”

The acceptance gate is the tender door, not a CE certificate. When Servizo Atlante de Saúde marks the education delivery “accepted,” that is a procurement decision against its pliego (valid signatures + no blocking RED). It is not a conformity assessment, and it is not a CE mark. For the retina delivery this matters twice over: the screener is a medical device, and its delivery includes an MDR crosswalk (conformance/eu_mdr_2017.json, the 7th signed artefact). That crosswalk is a cross-map only — never read it as “MDR governed.” An MDR Class IIa device cannot self-declare; its MDR conformity-assessment procedure (Art. 52) sends it to a notified body for a third-party conformity assessment that includes a clinical evaluation. Nothing in this chain does that. The retina delivery is honestly blocked on its accuracy gate and would, even if that gate were green, still require a notified body that is simply not present.

Verify is not certify — and accept is not certify

Two boundaries, one rule. Aitor’s verify confirms the evidence is what the signer says it is — not that the product meets the law. The buyer’s acceptance gate confirms the tender criterion is met — not that the product is conformant. Only an accredited, independent notified body can issue the recognised certificate (for the higher-risk classes), and there is none in this chain. So the most you can truthfully say at the end of this handoff is: the deliveries are authentic, one cleared the tender door and one did not, and both still carry a documented gap to full conformance that only a notified body could close. That is the honest ceiling of a signed supply chain without a notified body.

Notified body vs self-declarationThe sharp line this section depends on: verifying a signature (authenticity) and a buyer's acceptance gate (procurement) are both distinct from a third-party conformity assessment by an accredited notified body — which nobody in this chain performs.

§6 — What is in custody, and what is roadmap

Two honesties to close on: where the heavy bytes actually live, and which frontiers are named but not built.

Custody. Git carries only a pointer + hash for the model: dvc.lock, whose hash is anchored in the signature. The heavy model bytes travel via the MLOps backend (a DVC remote today) and never through Venturalítica infrastructure. The receiving body does dvc pull and checks the hash against the signed dvc.lock, or re-derives the artefact with froga reconstruct. So the supply chain moves trust (signed digests) without moving data (the weights) — which is exactly what lets Aitor verify with a public key alone.

Tender-as-code — REAL today. The blocking threshold is imposed by the tender, not supplier-declared. The contracting authority signs its OSCAL tender with froga sign-pliego (same ECDSA-P256+DSSE scheme as the evidence) and the buyer 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.

Roadmap — named, NOT built. These are real frontiers; do not present any of them as shipped:

• EU MCC-AI clause generation — generate the High-Risk Model Contractual Clauses (21 articles) from the tender. Not built (the tender signed today is hand-authored in OSCAL, not derived from the MCC-AI).
• eIDAS (key ↔ legal identity) — bind a signing key to a legal entity. Today the buyer pins the public key out-of-band — trust-on-first-use (TOFU), not eIDAS. Aitor knows which key signed; he does not have a legal certificate that that key belongs to that company.
• Sigstore / Rekor transparency — a public, append-only transparency log of signatures. Not built; signatures today are detached and verified locally.
• Federated multi-supplier graph — a single signed graph across many suppliers and tiers (sub-processor → supplier → buyer). Not built; today it is two independent point-to-point deliveries.
• 10-year evidentiary retention — durable, tamper-evident long-term retention of the signed dossiers. Not built.

The key Aitor pins is TOFU, not eIDAS

Be precise about what authenticity buys you. froga verify proves the bytes were signed by the holder of a specific private key. It does not prove that key belongs to Ollomar Diagnóstica (or EduAtlante). Today the buyer pins the supplier’s public key out-of-band and trusts it on first use (TOFU). Binding key → legal identity is eIDAS — and that is roadmap. So the honest statement is: authentic, signed by the pinned key — not legally attributed to the company until eIDAS closes that gap.