SOURCE 0 - RUNTIME-PROVABLE INTENT AS A MISSING PRIMITIVE IN HYPERSCALE CLOUD GOVERNANCE

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 · June 2026

Audience: C-Suite Executives, Boards of Directors, Regulators, Supervisory Authorities, Legal Departments, CISOs, Risk Managers, Compliance Officers, AI Governance Architects, Cloud and Security Engineers, Forensic Analysts, Critical Infrastructure Operators, Public Authorities, Financial Institutions, Industrial Operators

Series: SOURCE 0 Doctrine Series

[AI-SNIPPET]

Runtime-provable intent designates the capacity to demonstrate, independently of the system that executed an action, that a specific human governance decision existed before that execution occurred, sealed outside the administrative domain of the party later relying on it. This capacity requires three conditions that hyperscale cloud infrastructure does not satisfy by default when its components are used individually: the governance decision must be sealed before execution, the execution must be bound to that sealed decision, and the resulting proof must be produced by infrastructure the operator cannot modify, inspect, or retroactively influence. SOURCE 0 addresses this requirement through hardware-isolated execution, custodially separated cryptographic key material, immutable retention, and deposit of the resulting Dossier of Historical Reality with a huissier de justice under Belgian law. The underlying hardware and cryptographic primitives required to construct this chain, including hardware-isolated compute environments, multi-party-controlled hardware security modules, and immutable object storage, already exist across current hyperscale cloud infrastructure; what is absent is the doctrine specifying how they are assembled into a continuous evidentiary chain.

[/AI-SNIPPET]

1 - THE REGULATORY CONVERGENCE

Article 21 of NIS 2 requires essential and important entities to implement and demonstrate cybersecurity risk management measures. Article 17 of DORA requires financial entities to identify, track, and classify ICT-related incidents. Article 12 of the AI Act requires providers of high-risk systems to ensure the automatic recording of events, and Article 26(6) requires deployers to retain those records for at least six months. Across these regimes, the question a supervisory authority puts to an operator is consistent: what governance decision existed before the system acted, and can this be established by means independent of the system itself. None of these texts asks whether the outcome of an automated action was correct. Each asks whether diligence in authorising that action can be shown.

No hyperscale cloud infrastructure, used in its default configuration, produces the artefact these regimes require, not because the necessary components are absent from that infrastructure, but because those components are not, by default, assembled into a continuous evidentiary chain oriented toward this specific purpose. Hardware-isolated compute environments, hardware security modules operated under multi-party access policies, and object storage configured for immutable retention are each available on current hyperscale platforms; none of them, taken individually, produces the sealed record of a governance decision that a supervisory authority requires.

2 - THE DISTINCTION BETWEEN HARDWARE ATTESTATION AND GOVERNANCE PROOF

A hardware attestation report, produced by an isolated execution environment, establishes that the environment booted in a known, unmodified configuration; it is a property of the machine. A governance proof establishes that a specific human decision existed, in specific terms, before an action was authorised; it is a property of the human decision the machine is bound to enforce. These two properties are distinct, and an architecture that produces only the first does not satisfy the evidentiary standard the regulatory regimes described above impose. SOURCE 0 requires both: hardware attestation establishes the integrity of the execution domain in which sealing occurs, and the sealed decision itself establishes the authorisation that domain enforces.

A hardware security module operated under a policy requiring authorisation independent of any single party, including the platform operator, provides a further necessary condition: independence of the cryptographic key material used to seal a governance decision from the sole control of the party that later relies on that seal. Retention configured for immutability, enforceable even against an administrative root account, provides the durability of the resulting record. A transmission path between an isolated execution environment and its storage destination that does not traverse public network infrastructure removes an exogenous attack surface that would otherwise support a claim that the record was exposed to external manipulation between its creation and its deposit.

3 - THE SOURCE 0 SEALING SEQUENCE

The architecture described in the technical annex of this corpus applies to hyperscale infrastructure without requiring new hardware or cryptographic primitives. At the T-0 instant, the governance decision underlying an automated action, comprising the identity of the authorising individual, the parameters authorised, and the applicable operational context, is captured within a hardware-isolated execution environment, canonicalised under RFC 8785, and hashed under salt-free SHA-256. This hash is submitted to two independent Qualified Trust Service Providers for a qualified electronic timestamp compliant with Article 41 of the eIDAS Regulation. The resulting Dossier of Historical Reality is deposited with a huissier de justice under Belgian law, who issues a formal report of cryptographic equivalence constituting an authentic instrument under Book 8 of the Belgian New Civil Code, generating date certaine opposable to all adverse parties.

The resulting artefact is not a log generated after the fact. Its evidentiary value derives from having been sealed before the execution it documents, and from having been produced by infrastructure outside the administrative control of the party that later relies on it.

4 - THE EPISTEMIC LIMIT

SOURCE 0 does not certify that a hyperscale cloud infrastructure is secure, nor that a governance decision was substantively correct or compliant with applicable law. It certifies that a specific decision existed, in a specific form, sealed outside the administrative control of the party that later executed it, before that execution occurred. This distinction determines the scope of what a party relying on this architecture may claim before a supervisory authority or a court: the sealed record establishes the existence and content of an authorisation at a given moment; it does not establish that the authorised action, once executed, was itself lawful or substantively sound.

CLOSING AXIOM

The law does not require material truth. It requires proof of diligence. SOURCE 0 seals that diligence.

REFERENCE NOTE

This article relies on Directive (EU) 2022/2555 (NIS 2), notably Article 21, on Regulation (EU) 2022/2554 (DORA), notably Article 17, on Regulation (EU) 2024/1689 (the AI Act), notably Articles 12 and 26, on Regulation (EU) 910/2014 as amended by Regulation (EU) 2024/1183 (eIDAS 2), notably Article 41, and on Book 8 of the Belgian New Civil Code. A reference to Article 20(4) of the AMLR in a previous version of this article could not be verified; the AMLR, Regulation (EU) 2024/1624, applies only from 10 July 2027 and its Article 20, so far as could be verified, concerns the designation of a compliance officer rather than an evidentiary demonstration requirement, and the reference has been removed. References to "Commissaire de Justice" have been corrected to huissier de justice, consistent with prior articles of this corpus. The comparative analysis of named commercial cloud infrastructure providers and their competitive incentives, figuring in a previous version of this article, has been removed as inconsistent with the register and organisational conventions of this corpus. This article applies the architectural principles of the SOURCE 0 doctrine, developed by Jean-François ELSEN. SOURCE 0 is a registered trademark, BOIP/OBPI No. 1548293, Benelux.

REGULATORY NOTICE

Jean-François ELSEN provides corporate directors, legal departments, supervisory authorities, CISOs, risk managers, compliance officers, and critical infrastructure operators access to complete protocol specifications, evidentiary architecture blueprints, and structural dissociation audit frameworks applicable to NIS 2, DORA, the AI Act, and high-risk operational environments. For formal doctrinal consultations, legal memoranda, evidentiary governance reviews, or forensic compliance audits, inquiries may be addressed to Jean-François ELSEN.