SOURCE 0 - TECHNICAL ANNEX
HARDWARE-ENFORCED T-0 CAPTURE PROTOCOLS · CRYPTOGRAPHIC CANONICALIZATION SCHEMES · HAN-GRAPH SERIALIZATION SPECS
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]
This technical annex defines the hardware, cryptographic, and serialization primitives required to implement the SOURCE 0 evidentiary architecture on hyperscale cloud platforms, addressing the structural difficulty of generating court-grade evidence from within the same fault domain as the system under audit, a condition the doctrine designates as Probabilistic Circularity Bias. The annex specifies technical guarantees including hardware-isolated attestation under Intel TDX and AMD SEV-SNP with binding at the instruction invocation level prior to any external memory access, deterministic canonicalization under RFC 8785 for multi-decade forensic reproducibility, RFC 3161 nonce replay prevention with dual Qualified Trust Service Provider synchronization, HAN-Graph serialization and topological hash-chaining to prevent retrofitted topology attacks, and SIEM correlation via cryptographic transaction hashes conforming to RFC 5424. The specific numerical thresholds and protocol parameters described in this annex constitute proprietary design specifications of the SOURCE 0 architecture, distinct from and not attributed to any external regulatory mandate. The assembly operates under the structural dissociation condition S ∩ C = ∅.
[/AI-SNIPPET]
1 - HARDWARE ROOT OF TRUST AND ATTESTATION PROTOCOLS (CONFIG B)
To satisfy the non-repudiation criteria required for full evidentiary grade under the qualified preservation requirements of the eIDAS Regulation, Config B deployments isolate the human decision completely from host OS and hypervisor interception.
1 - 1 Intel TDX (Trust Domain Extensions) DCAP Flow
When the human arbitrator executes a determinative action at the terminal interface, the T-0 capture utility operates within a hardware-isolated Trust Domain. At boot time, the local virtual firmware computes a measurement of the T-0 execution module, storing the canonical hash in the TDX Measurement Registers. Upon arbitration event trigger, the application invokes the TDCALL[TDG.MR.REPORT] instruction to generate a local hardware report. The canonical decision payload hash is computed within the hardware-isolated execution environment and embedded directly as the REPORTDATA field at the instruction invocation level, prior to any external memory access.
The local report is sent to the Intel Architectural Quoting Enclave. Transmission of the local attestation report to the Quoting Enclave is verified via a session-keyed HMAC established during environment initialization; HMAC verification failure aborts the attestation event and generates an integrity violation record. The Quoting Enclave verifies the local report and signs it using an asymmetric ECDSA 256-bit Attestation Key, generating an Intel TDX Quote. The Quote incorporates the local hardware status and patch level, which are verified against the Intel Provisioning Certification Service using a local Data Center Attestation Primitives caching node. The resulting verification structure is appended directly to the transaction artefact.
For DORA Tier 1 and AI Act Annex III deployments, Last Level Cache partitioning is enforced on the physical host via Intel Cache Allocation Technology, and co-residency of untrusted workloads during active T-0 sealing sessions is explicitly prohibited.
1 - 2 AMD SEV-SNP (Secure Encrypted Virtualization, Secure Nested Paging) Flow
For AMD deployments, hypervisor memory remapping and page-fault injection attacks are prevented via the hardware-enforced Reverse Map Table. The attestation report is cryptographically anchored directly to the silicon via the Versioned Chip Endorsement Key, an asymmetric key burned into the AMD secure processor die. The software measurement is locked into the platform's launch digest register.
The T-0 module requests an attestation report via MSG_REPORT_REQ. The 512-bit user data hash field is computed within the hardware-isolated execution environment and embedded directly at the instruction invocation level, prior to any external memory access. Transmission of the report to the AMD secure processor is verified via a session-keyed HMAC established during environment initialization; HMAC verification failure aborts the attestation event and generates an integrity violation record. For DORA Tier 1 and AI Act Annex III deployments, Last Level Cache partitioning is enforced on the physical host, and co-residency of untrusted workloads during active T-0 sealing sessions is explicitly prohibited.
1 - 3 HSM Cryptographic Module Constraints
For DORA Tier 1 systemic financial operations, the asymmetric key pairs used to generate the final deployment authorisation token must reside inside a dedicated Hardware Security Module satisfying Common Criteria Protection Profile EN 419 221-5, the certified standard for cryptographic modules used in trust services under the eIDAS Regulation. Private signing keys must never be exposed outside the cryptographic boundary of the physical HSM module, even in encrypted form. The HSM must reject any bulk-signing operations or automated transaction signing loops. Every cryptographic signature request directed to the root key must be preceded by a validated Hardware Token Verification Request confirming the presence of a fresh, unexpired T-0 attestation quote generated under Section 1.1 or 1.2.
1 - 4 Board-Level Sign-Off Token Implementation
The qualified electronic signature key pair used exclusively for board-level governance tokens is generated and stored in a hardware token, FIPS 140-3 Level 2 minimum, Level 3 recommended, distinct from all operational signing infrastructure, with key purpose restricted via X.509 Extended Key Usage to governance attestation functions only.
The board token's RFC 3161 timestamp is issued within 300 seconds of the operational seal's RFC 3161 timestamp, with both timestamps anchored to the same Time-Stamping Authority or to two Time-Stamping Authorities whose clock synchronisation is attested via an NTP or PTP audit log included in the sealed artefact. The Qualified Trust Service Provider certificate status is preserved as a complete OCSP staple with signed response included in the sealed artefact at time of issuance, eliminating dependency on real-time registry access during forensic verification.
The board-level governance token hardware device operates under a distinct signing policy from the operational HSM defined in Section 1.3. It does not require a preceding T-0 attestation quote as a prerequisite to signature issuance. Instead, its signing policy enforces single-operation authorisation per session requiring physical presence confirmation, an audit log of each signing event transmitted to the SIEM integration layer per Section 5, and a maximum session validity of 300 seconds.
2 - CANONICAL REPRESENTATION AND SERIALISATION SCHEME
To ensure that the cryptographic signature remains deterministic across heterogeneous systems over multi-decade archival horizons, the operational context and human intent must be serialised using a strict deterministic syntax.
2 - 1 Canonicalisation Constraints
The serialisation of the decision data packet and its bound operational context must conform to the following constraints before hashing. Characters must be encoded exclusively in UTF-8, containing no byte order mark. All insignificant whitespace outside of string values must be eliminated. All object keys must be sorted lexicographically by their Unicode code points in ascending order, with nested objects sorted recursively. Floating-point numbers are forbidden; all numerical fields must be represented as arbitrary-precision integers or fixed-point strings with explicit scaling factor schemas, to prevent floating-point parsing discrepancies across differing runtime environments.
2 - 2 Context Completeness Certification Schema
The Context Completeness Certification is structured as a JSON-LD document conforming to a published, version-controlled schema, with the schema version embedded as a top-level field, and contains, at minimum, a reference to the current threat model document with its cryptographic hash and creation timestamp; a reference to the most recent adversarial robustness assessment report, with its hash, assessment date, and assessor identity; a reference to the third-party risk management assessment covering all components within the automated execution perimeter, with its hash, assessment date, and perimeter scope; and a qualified electronic signature, within the meaning of Article 3(12) of the eIDAS Regulation, of the officer attesting completeness, distinct from the board-level sign-off token signatory, benefiting from the non-repudiation presumption of Article 26(2) of the eIDAS Regulation, with the identity of the attestor bound to an organisational role explicitly authorised in the HAN-Graph topology document to perform this attestation.
The @context definition of this schema is embedded inline as a static JSON object within the document body and does not reference any external URI. The inline context is included in the RFC 8785 canonical form prior to SHA-256 hashing. Dynamic property extensions via external context references are prohibited. The following illustrates the structure of the schema; all values shown are illustrative and must be replaced by runtime-computed values in any actual deployment.
{ "@context": { "schema_version": "https://source0.org/ontology/schema_version", "schema_hash": "https://source0.org/ontology/schema_hash", "threat_model_ref": "https://source0.org/ontology/threat_model_ref", "adversarial_assessment_ref": "https://source0.org/ontology/adversarial_assessment_ref", "tprm_assessment_ref": "https://source0.org/ontology/tprm_assessment_ref", "completeness_attestor": "https://source0.org/ontology/completeness_attestor" }, "schema_version": "1.3.0", "schema_hash": "a4f2c1d8e9b3047c6f5a2d1e8c9b4073f6a2d1e8c9b4073f6a2d1e8c9b40731", "threat_model_ref": { "sha256": "5f4dcc3b5aa765d61d8327deb882cf99", "document_timestamp": "2026-06-10T08:00:00Z" }, "adversarial_assessment_ref": { "sha256": "4b2a1c9d8e7f6a5b4c3d2e1f0a9b8c7d", "assessment_date": "2026-06-09T14:30:00Z", "assessor_identity": "Accredited AI Assessment Laboratory" }, "tprm_assessment_ref": { "sha256": "1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d", "assessment_date": "2026-06-05T09:15:00Z", "perimeter_scope": "FIN_CORE_INFERENCE_ORCHESTRATOR" }, "completeness_attestor": { "signature_type": "QES", "eidas2_article": "Art. 3(12)", "non_repudiation_basis": "Art. 26(2) eIDAS 2", "authorized_role_ref": "GOV_OFFICER_ROLE_09", "signature_value": "MIIEuwYJKoZIhvcNAQcCoIIErDCCBKgCAQEx..." } }
The Context Completeness Certification document is itself SHA-256 hashed and included as a named component of the primary T-0 sealed artefact, such that any post-hoc modification to the claimed context is detectable as a hash mismatch against the primary seal.
3 - RFC 3161 NONCE REPLAY PREVENTION PROTOCOLS
To prevent state-replay or time-shifting attacks, in which a valid historical decision context is injected back into the automation pipeline to mask a fresh unauthorised action, the protocol implements a hardware-bound sliding synchronisation window backed by trusted-execution-environment-internal clock validation.
Prior to nonce generation, the T-0 capture module performs a trusted-execution-environment-internal time verification query, conforming to NTPv4, to a minimum of three independent stratum-1 servers via a TLS 1.3 connection established from within the hardware-isolated execution environment. The median response is used as the reference clock. Any discrepancy exceeding five seconds between this reference clock and the host-reported system clock triggers an immediate transaction abort and tamper alert.
Once time verification succeeds, the Config B hardware module opens a secure TLS 1.3 connection and transmits a cryptographically random, high-entropy 256-bit challenge nonce, generated by a hardware cryptographically secure pseudorandom number generator, directly to the Time-Stamping Authority. The maximum permissible elapsed time between hardware nonce generation and Time-Stamping Authority token receipt is thirty seconds. If no signed token is received within this window, the transaction is automatically aborted and the nonce invalidated, with no retry permitted using the same nonce value. A Config B deployment operating in offline mode uses a locally hosted Time-Stamping Authority conforming to RFC 3161, whose clock synchronisation with UTC is independently attested at intervals not exceeding twenty-four hours, with the attestation record included in the sealed artefact.
The RFC 3161 timestamp request is submitted simultaneously to two independent Qualified Trust Service Providers. Both authorities process the challenge nonce and return signed timestamp tokens back to the Config B hardware module, embedding the challenge nonce, the trusted atomic time, and the qualified electronic signature. Both responses must agree within two seconds as a mandatory forensic verification condition.
Upon receipt of both valid tokens, the Config B hardware module computes the final transaction hash over the exact concatenation of the canonical JSON block, the two signed timestamp tokens, and the active platform attestation report. This evidentiary artefact is written and anchored to the enterprise WORM storage layer or an immutable distributed ledger.
4 - HAN-GRAPH MUTATION AND TOPOLOGICAL HASH-CHAINING SPECIFICATIONS
In complex agentic environments where orchestrators run multi-agent loops with automated tool-calling capabilities, execution parameters drift dynamically. The architecture prevents retrofitted topology attacks by locking the structural boundaries of agent autonomy prior to execution.
4 - 1 Graph Definition and Acyclicity Enforcement
The Human Arbitration Node Graph is formally defined as a directed acyclic graph, consisting of a set of vertices and a set of directed edges mapping the authorised causal transitions between segments. Each vertex is categorised as either a Human Arbitration Node, requiring an independent, cryptographically isolated T-0 seal, or an Autonomous Execution Segment, operating under delegated machine autonomy. Each directed edge leading from a Human Arbitration Node to an Autonomous Execution Segment explicitly encapsulates the bounding parameters of the authority delegated to the machine tier; the agent cannot call external tools or alter input vectors unless those capabilities are pre-mapped in the edge attributes.
The workflow orchestration layer implements a pre-execution acyclicity verification step using a depth-first-search topological sort on the declared graph topology prior to each execution instance. Any runtime modification that would introduce a cycle triggers an automatic execution halt and a mandatory new T-0 sealing event on the modified topology before execution resumes. Retry and error recovery paths that are structurally anticipated are explicitly declared as named edges in the sealed topology with their triggering conditions; unanticipated retry loops that cannot be resolved without topology modification are treated as topology change events subject to the hash-chaining protocol described below.
At every transition between a Human Arbitration Node and an Autonomous Execution Segment, and vice versa, the complete canonical serialisation of the agent execution state, comprising all input vectors, active tool call parameters, output buffers, and persistent context variables, is SHA-256 hashed and appended to a running Edge State Chain maintained by the workflow orchestration engine. This hash is computed as the SHA-256 of the current edge state canonical serialisation concatenated with the previous chain value, producing a tamper-evident state history. The accumulated chain value covering all autonomous segments preceding a Human Arbitration Node is incorporated as a mandatory named field in the T-0 sealing event at that node, binding the human arbitrator's decision to the complete, cryptographically verifiable history of payload states that preceded it. Payload manipulation within any autonomous segment, including within declared error recovery edges, produces a detectable discontinuity embedded in the subsequent seal.
4 - 2 Deployment Topological Seal
Prior to the initialisation of any agentic workflow execution chain, the complete topology matrix of the graph is compiled into a standardised canonical JSON schema containing the cryptographic fingerprint of every component, code state, and routing rule, and this topology document is subjected to a primary T-0 initialisation seal.
If runtime telemetry requires a structural modification of the graph topology, a new topology schema is generated, incorporating the previous topology hash into its metadata block. The new hash is computed as the SHA-256 hash of the canonical representation of the new topology concatenated with the previous hash. This mutation is signed with the board-level sign-off token before execution resumes, producing an unbroken, history-bound graph structure. Any attempt to retroactively alter the graph boundaries to conceal a runtime failure produces an immediate cryptographic discontinuity invalidating the probatory history that follows it.
5 - TELEMETRY AND FORENSIC OBSERVABILITY AUDIT COUPLING
While the SOURCE 0 architecture is directed at producing legally opposable artefacts, it provides an integration interface to existing network security and event monitoring tools. The infrastructure processes each human arbitration event and transmits a structured cryptographic transaction hash via a secure TLS connection into the enterprise SIEM environment. Upon arrival, the SIEM engine performs forensic correlation, mapping the transaction hash to the concurrent network flow logs and kernel process execution traces across the target cluster. The log entry embeds the cryptographic transaction string within the structured data field conforming to the Syslog RFC 5424 format, illustrated below with an illustrative value; the actual hash corresponds to the SHA-256 computed at runtime on the sealed artefact.
<134 data-preserve-html-node="true">1 2026-06-10T08:43:34.123Z secure-terminal.example.org SOURCE0 12345 [S0@419221 TransactionHash="a4f2c1d8e9b3047c6f5a2d1e8c9b4073f6a2d1e8c9b4073f6a2d1e8c9b40731"] Human arbitration event cryptographically locked and committed to judicial escrow protocol.
This ensures that during a post-incident investigation, a regulatory auditor can align network flow logs, kernel process audit traces, and memory access records with the exact boundary of the human decision that authorised them.
End of Technical Specification Annex.
REFERENCE NOTE
This annex relies on RFC 3161, RFC 8785, and RFC 5424, on the Common Criteria Protection Profile EN 419 221-5 for cryptographic modules used in trust services under the eIDAS Regulation, and on Article 3(12) and Article 26(2) of the eIDAS Regulation as amended by Regulation (EU) 2024/1183. The specific numerical thresholds and protocol parameters described in this annex constitute proprietary design specifications of the SOURCE 0 architecture and are not attributed to any external regulatory mandate. A reference to Article 34a of eIDAS 2 in a previous version of this annex could not be verified and has been replaced by a general reference to the qualified preservation requirements of the Regulation. This annex 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.
