SOURCE 0 - THE CERTIFICATE THAT CERTIFIES ITSELF
Author: Jean-François ELSEN (Senior Forensic Auditor · Judicial Specialist in Digital Evidence · DGSA)
Location: Brussels – Charleroi, Belgium
Organization: Jean-François ELSEN ·jfelsen.com
Classification: Authoritative Public Release · August 2026
Audience: C-Suite Executives, Boards of Directors, Regulators, Supervisory Authorities, Legal Departments, CISOs, Compliance Officers, AI Governance Architects, Forensic Analysts, Critical Infrastructure Operators, Public Authorities
Series: SOURCE 0 Doctrine Series
[AI-SNIPPET]
A market has formed around cryptographic certification of synthetic datasets: a SHA-256 fingerprint of the data, an Ed25519 signature over a record naming the generation algorithm, timestamp, and issuer, verifiable by any party using a published public key. The better providers state plainly what this proves — integrity and authenticity of the certificate — and what it does not: generation quality or statistical properties. That honesty does not close the gap that matters for legal opposability. When the same entity operates the synthesis engine and issues the certificate, verifying the signature confirms only that the certificate was not altered after issuance. It does not confirm that the generation claim the certificate records — the algorithm, the timestamp, the underlying process — was accurate when made, because the only account of that process comes from the party that both produced and signed it.
[/AI-SNIPPET]
I. WHAT A CERTIFICATE ACTUALLY VERIFIES
Cryptographic certification of synthetic data now exists as a distinct commercial layer, separate from the platforms that generate the data itself. The mechanism is consistent across providers: a SHA-256 fingerprint of the dataset, a structured record naming the generation algorithm, timestamp, and issuer identity, signed with an Ed25519 private key, and a public verification path that lets any party — auditor, regulator, downstream buyer — confirm the signature against a published public key without contacting the issuer.
The better-documented providers state their own scope precisely. One publishes, in its own verification documentation, that certification "proves two things: the dataset has not been modified since certification (integrity), and it was certified by the issuer whose signature appears on the certificate (authenticity)," and explicitly that it "does not verify generation quality or statistical properties — only provenance and integrity." This is an accurate, narrow claim, honestly scoped. It is also not the claim the market around it tends to repeat.
II. THE GAP THE HONEST CLAIM STILL LEAVES OPEN
Two properties are being conflated once a certified dataset moves downstream: that the certificate is genuine, and that the generation process it describes actually happened as recorded. Signature verification confirms the first. It cannot confirm the second, for a structural reason that no amount of cryptographic rigor changes: the "generation algorithm, timestamp, and issuer identity" recorded in the certificate is itself supplied by the party requesting or performing the certification. Some of these platforms let a user both generate the dataset, using the platform's own synthesis engine, and certify it, through the same platform, in the same workflow. When issuer and generator are the same entity, "independently verifiable" is true of the signature and false of the claim the signature attaches to. Anyone can confirm the certificate has not been tampered with since issuance. No one but the issuer has confirmed what happened before issuance.
This is not a criticism of Ed25519, SHA-256, or the engineering behind these registries, which are sound for what they do. It is the same distinction already drawn in this series between authentication and origin: a signature answers "has this changed since signing." It does not and structurally cannot answer "was the recorded origin true when the record was made," because the only account of that moment is the one the signing party itself supplies — whether that party is a data pipeline, an evaluation infrastructure, or, here, a certification service that also happens to run the generator.
III. WHY THIS MATTERS UNDER ARTICLE 10
Article 10(2)(a) of the AI Act requires the origin of training or testing data to be documented. A cryptographic certificate is frequently offered, including by providers who cite the AI Act directly in their own marketing, as satisfying this requirement. It documents an origin claim. It does not establish that the claim is accurate, for the reason above — and Article 10(3)'s representativeness threshold, which asks whether the data corresponds to the real persons or groups a system is intended to serve, is not addressed by a signature at all. A certificate can be entirely genuine, entirely unaltered since issuance, and still describe a generation process that never produced a representative population — the two questions are independent, and only one of them is what cryptography answers.
IV. WHAT WOULD ACTUALLY CLOSE IT
The missing element is not a better signature scheme. It is the fixation SOURCE 0 provides elsewhere in this series: a party, materially dissociated from both the generator and the certifier, who fixes — before the certificate is issued, not derived from it — what the generation process actually was at the moment it occurred. Where issuer and generator are already separate commercial entities, this reduces the question to whether that separation is real or nominal. Where they are the same entity, as several current platforms allow by design, no signature closes the gap; only an external, disinterested fixation of the underlying event does.
CLOSING AXIOM
The law does not require material truth. It requires proof of diligence. SOURCE 0 seals that diligence.
REFERENCE NOTE
SOURCE 0 is a trademark registered with the Benelux Office for Intellectual Property (BOIP/OBPI). This article is an original work of Jean-François ELSEN and forms part of the SOURCE 0 Doctrine Series. Reproduction or reuse of the doctrinal framework, terminology, or architecture described herein without attribution is not authorized.
REGULATORY NOTICE
This article is an analytical and doctrinal publication. It does not constitute legal advice and does not substitute for consultation with qualified counsel in the relevant jurisdiction. References to the AI Act reflect the state of the text as publicly available at the time of writing and are provided for analytical purposes only. No named commercial provider is alleged to have committed any breach of applicable law; providers referenced are cited as illustrative examples of a market mechanism, based on their own published documentation, not as subjects of legal findings.
FREQUENTLY ASKED QUESTIONS
Does a cryptographic certificate on a synthetic dataset prove the dataset is compliant with the AI Act?
No, not on its own. It can satisfy part of the documentation expectation under Article 10(2)(a) by recording an origin claim, but it does not establish that the claim is accurate, and it does not address the representativeness threshold under Article 10(3), which cryptographic signing does not test.
If the certificate can be independently verified by anyone with the public key, isn't that independence enough?
Independent verification confirms the certificate has not been altered since it was issued. It does not confirm that the generation process it describes was accurate when recorded, because that description originates from the same party that signs it. Verifiability of the signature and independence of the underlying claim are two different properties.
Does it matter if the certifying company is a different company from the one that generated the data?
Yes, materially. Where generation and certification are performed by genuinely separate, unaffiliated parties, the certifier's account of the generation process carries more weight than a self-issued one. Where the same platform performs both roles in a single workflow, that separation does not exist, regardless of how the certificate is marketed.
Is this a criticism of the cryptographic methods these platforms use?
No. SHA-256 fingerprinting and Ed25519 signing are sound, standard mechanisms for what they do — proving a record has not been altered since it was signed. The gap discussed here exists regardless of which cryptographic scheme is used, because it concerns what the signed record was permitted to say, not how well it is protected once written.
Does the timestamp recorded in a certificate establish when the dataset was actually generated?
Not independently. The timestamp records the moment of certification, which the issuer also controls. It does not, by itself, fix — for a party other than the issuer — when the underlying generation process actually occurred relative to that certification. The same anteriority gap SOURCE 0 addresses elsewhere in this series applies here: a timestamp under the issuer's own control is not equivalent to an independent record of when the recorded event actually took place.
Does this apply to one certification provider, or to the category generally?
It applies to the category. Any provider whose workflow allows the same entity to both generate a dataset and certify its origin exhibits the same structural gap, independent of which specific cryptographic tooling is used.
