SOURCE 0 - PROVING WHEN A DISCLOSURE OCCURRED

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 · July 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]

If an organisation asserts that an AI disclosure was made to a data subject on a given date, what independently corroborates that assertion. Article 50 of the EU AI Act does not answer this question, because it is not a disclosure-content question — it is an evidentiary question, and it applies whether or not disclosure occurred. This article treats the general problem of proving the timing of a disclosure, independently of any specific timestamping mechanism, and establishes the three conditions a record must meet before it can function as proof rather than as a self-serving claim.

[/AI-SNIPPET]

1 - THE QUESTION LEFT OPEN

The distinction already established in this series is that Article 50 imposes a duty to disclose, not a duty to prove that disclosure occurred at a stated time. That distinction is not academic. Once an organisation is asked — by a regulator, a claimant, or a court — to substantiate that a specific disclosure was made before a specific date, the substantiation has to come from somewhere. Article 50 is silent on where. It contains no pre-execution fixation mechanism and no requirement to preserve evidence of the disclosure's timing. That silence produces no operational consequence as long as no one disputes the date. It becomes a live liability the moment a regulator, a claimant, or a court does. This article addresses that silence directly: what does it take, in general, for a record to prove timing, before any specific mechanism is introduced.

2 - THE DEFAULT ANSWER IS INSUFFICIENT

The default answer inside most organisations is a system log: an application server records a timestamp when a disclosure banner is rendered, when a consent screen is presented, when an automated message is sent. This record has a date on it. Under ordinary internal review, that date is treated as settled fact.

It is not settled fact once a party outside the organisation has an incentive to dispute it. A system log is authored, stored, and — critically — alterable by the same organisation whose diligence is in question. A log entry with a timestamp of 14:32 asserts that something happened at 14:32. It does not, by itself, prove that the entry was not created, edited, or backdated at a later point by an administrator with legitimate write access to the system. The assertion and the evidence for the assertion originate from the same controlled environment.

The timing of a disclosure is not incidental to whether it complies with Article 50. Article 50(5) requires that the information referred to in paragraphs 1 to 4 be provided in a clear and distinguishable manner at the latest at the time of the first interaction or exposure. A disclosure that occurred, but occurred after that point, does not satisfy the obligation regardless of how accurately worded it was. Proving the moment of disclosure is therefore not a generic evidentiary exercise transposable to any regulatory text — it is the proof of a specific, dated compliance threshold that Article 50 itself sets.

3 - WHY THE SOURCE OF THE RECORD IS THE PROBLEM

This is not a question of whether the organisation is honest. It is a structural feature of any record generated and held entirely within the perimeter of the party whose compliance is being tested. A record cannot certify its own integrity to a sceptical outside party, because the party best positioned to have altered the record is the same party asserting that it was not altered. This is the Endogenous Audit Paradox: a system audited only by artefacts it generated and controls cannot supply independent proof of its own prior state.

An evidentiary structure is not designed for the case where every party acts in good faith. It has to hold under the hypothesis of a dispute, under the hypothesis that the organisation's own interest is adverse to the claim being examined, and under the hypothesis of an external audit conducted by a party with no reason to extend the organisation the benefit of the doubt. A record that depends on the good faith of the party it is meant to judge fails under exactly the conditions it exists to survive.

The practical consequence for an AI disclosure claim is direct. A log line, an email server timestamp, an internal audit trail entry — all of these may be true, and all of them are equally deniable in principle, because none of them were fixed by a party without the ability or motive to alter them.

Technical controls layered onto an internal record do not change this. An append-only log structure prevents silent overwriting of individual entries, but it does not establish who controlled the system that decided what to append, or when. Role-based access restrictions limit who can write to a system, but the organisation retains that access itself. An internal hash chain proves that a record has not been altered since the hash was computed — it says nothing about whether the hash was computed at the time claimed. Each of these controls addresses tampering after the record's creation. None of them addresses the prior question of who fixed the record's origin, and none of them removes that origin from the perimeter of the party whose diligence is in question.

The same limitation applies to any general rule that would admit an internal record as evidence on the strength of its having been kept in the ordinary course of business. Such a rule addresses whether a record may be considered at all — not whether the record's date is accurate, whether it was altered after creation, or whether it was fixed independently of the party asserting it. Admissibility of a record and proof of its timing are two different questions, and satisfying the first does not resolve the second.

4 - WHAT INDEPENDENT PROOF ACTUALLY REQUIRES

Three conditions, jointly, distinguish a record capable of functioning as proof from a record that is merely an internal claim.

The first is content fixation: the exact state of what was disclosed — the wording, the interface, the configuration in force at that moment — must be captured as it existed, not reconstructed afterward from documentation or memory.

The second is verifiable timing: the moment of that capture must itself be attributable to a point in time that the asserting party cannot have chosen retroactively. A date typed into a document does not meet this condition. A date attached by a mechanism the asserting party does not control does. This condition concerns the attribution itself — whether the date can be trusted at all.

The third is extraneity: the party or mechanism performing the fixation and the timing must sit outside the administrative perimeter of the system being audited. If the same actor that runs the AI system also runs the clock the system is judged against, the clock is not independent — it is a second output of the same process under scrutiny. This condition concerns where that mechanism sits — a date can be independently attributable in principle and still fail this condition, if the party being tested is the one operating the mechanism that attributes it.

A record satisfying only one or two of these conditions is documentation. A record satisfying all three is proof. Most compliance tooling in current use — audit logs, versioned documentation, internal timestamping — satisfies at most the first condition and sometimes the second. It does not satisfy the third, because the mechanism generating the record remains inside the perimeter of the party being tested.

5 - THE MECHANISM QUESTION

Stating the three conditions does not, by itself, specify how they are met in practice for an AI disclosure event. That is a distinct and narrower question — which timing mechanism actually produces a date the asserting party cannot have chosen, and what makes that mechanism legally, not merely technically, robust. This is treated separately, in the next article of this series.

The three conditions set out above are not an abstract checklist. They are precisely the conditions SOURCE 0's pre-execution attestation architecture is built to satisfy jointly, for the disclosure artefact itself, before the interaction it discloses ever takes place.

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 proprietary pre-execution cryptographic attestation architecture developed by Jean-François ELSEN, registered with the Benelux Office for Intellectual Property under number BOIP/OBPI 1548293. This document is published by Jean-François ELSEN, Senior Forensic Auditor, Judicial Specialist in Digital Evidence, and Dangerous Goods Safety Adviser (DGSA).

REGULATORY NOTICE

This document constitutes doctrinal analysis and does not constitute legal advice. references to the ai act are provided for general orientation and do not dispense with case-specific legal consultation.