DOCTRINE SOURCE 0® — TECHNICAL ANNEX.

HARDWARE-ENFORCED T-0 CAPTURE PROTOCOLS · CRYPTOGRAPHIC CANONICALIZATION SCHEMES · HAN-GRAPH SERIALIZATION SPECS

Technical Specification Document — June 2026

Audience: Information Architects · TEE/HSM Security Engineers · Cloud Confidential Computing Teams

1. HARDWARE ROOT OF TRUST & ATTESTATION PROTOCOLS (CONFIG B)

To satisfy the non-repudiation criteria required for full evidentiary grade under Article 34a of eIDAS 2, Config B deployments isolate the human decision completely from host OS and hypervisor interception.

1.A 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 (TD).

• Enclave Measurement: 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 (TDMR).

• Evidence Generation: Upon arbitration event trigger, the application invokes the TDCALL[TDG.MR.REPORT] instruction to generate a local hardware report. The canonical decision payload hash shall be 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.

• Quoting Enclave Transition: The local report is sent to the Intel Architectural Quoting Enclave (QE). Transmission of the local attestation report to the QE shall be verified via a session-keyed HMAC established during environment initialization; HMAC verification failure shall abort the attestation event and generate an integrity violation record. The QE verifies the local report and signs it using an asymmetric ECDSA 256-bit Attestation Key (AK), generating an Intel TDX Quote.

• DCAP Verification: The Quote incorporates the local hardware status and patch level, which are verified against the Intel Provisioning Certification Service (PCS) using a local Data Center Attestation Primitives (DCAP) caching node. The resulting verification structure is appended directly to the transaction artifact.

• Cache Partitioning Constraints: For DORA Tier 1 and AI Act Annex III deployments, LLC (Last Level Cache) cache partitioning shall be enforced on the physical host via Intel CAT (Cache Allocation Technology), and co-residency of untrusted workloads during active T-0 sealing sessions is explicitly prohibited.

1.B 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 (RMP).

• VCEK Binding: The attestation report is cryptographically anchored directly to the silicon via the Versioned Chip Endorsement Key (VCEK), an asymmetric key burned into the AMD secure processor die.

• Measurement Registration: The software measurement is locked into the platform's launch digest register (LAUNCH_DIGEST).

• Report Construction: The T-0 module requests an attestation report (MSG_REPORT_REQ). The 512-bit user data hash field shall be 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 shall be verified via a session-keyed HMAC established during environment initialization; HMAC verification failure shall abort the attestation event and generate an integrity violation record.

• Cache Partitioning Constraints: For DORA Tier 1 and AI Act Annex III deployments, LLC cache partitioning shall be enforced on the physical host, and co-residency of untrusted workloads during active T-0 sealing sessions is explicitly prohibited.

1.C HSM Cryptographic Module Constraints (eIDAS 2 Compliance)

For DORA Tier 1 systemic financial operations, the asymmetric key pairs used to generate the final deployment authorization token must reside inside a dedicated Hardware Security Module satisfying Common Criteria Protection Profile EN 419 221-5.

• Key Isolation: Private signing keys must never be exposed outside the cryptographic boundary of the physical HSM module, even in encrypted form.

• API Constraints: 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.A or 1.B.

1.D Board-Level Sign-Off Token Implementation Requirements

• Key Segregation: The qualified electronic signature key pair used exclusively for Board-level governance tokens shall be 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 (EKU) OID to governance attestation functions only.

• Temporal Binding: The Board token RFC 3161 timestamp shall be issued within 300 seconds or less ($\Delta t \le 300$ seconds) of the operational seal RFC 3161 timestamp, with both timestamps anchored to the same TSA or to two TSAs whose clock synchronization is attested via NTP/PTP audit log included in the sealed artifact.

• Certificate Status: The QTSP certificate status shall be preserved as a complete OCSP staple with signed response included in the sealed artifact at time of issuance, eliminating dependency on real-time registry access during forensic verification.

• Distinct Signing Policy: The Board-level governance token hardware device operates under a distinct signing policy from the operational HSM defined in Section 1.C. It does not require a preceding T-0 attestation quote as a prerequisite to signature issuance; instead, its signing policy enforces: (a) single-operation authorization per session requiring physical presence confirmation (touch or PIN entry on the hardware token); (b) audit log of each signing event transmitted to the SIEM integration layer per Section 5.A; and (c) maximum session validity of 300 seconds per the temporal binding constraint defined above.

2. CANONICAL REPRESENTATION & SERIALIZATION 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 serialized using a strict deterministic syntax.

2.A Canonicalization Constraints (Deterministic JSON)

The serialization of the decision data packet (represented as $D$) and its bound operational context (represented as $C$) must strictly conform to the following lexical constraints before hashing:

• Encoding: Characters must be encoded exclusively in UTF-8, containing no Byte Order Mark (BOM).

• Whitespace Preservation: All insignificant whitespaces (spaces, tabs, carriage returns, line feeds) outside of string values must be eliminated.

• Key Lexicographical Sorting: All object keys must be sorted lexicographically by their Unicode code points in ascending order. Nested objects must be sorted recursively.

• Numeric Representation: Floating-point numbers are strictly 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.B Context Completeness Certification Schema

The Context Completeness Certification (CCC) shall be structured as a JSON-LD document conforming to a published, version-controlled schema (schema version embedded as a top-level field), containing the following mandatory fields with cryptographic content identifiers. The @context definition shall be embedded inline as a static JSON object within the CCC document body and shall not reference any external URI. The inline context shall be included in the JCS (RFC 8785) canonical form prior to SHA-256 hashing. Dynamic property extensions via external @context references are explicitly prohibited.

{
  "@context": {
    "schema_version": "[https://source0.org/ontology/schema_version](https://source0.org/ontology/schema_version)",
    "schema_hash": "[https://source0.org/ontology/schema_hash](https://source0.org/ontology/schema_hash)",
    "threat_model_ref": "[https://source0.org/ontology/threat_model_ref](https://source0.org/ontology/threat_model_ref)",
    "adversarial_assessment_ref": "[https://source0.org/ontology/adversarial_assessment_ref](https://source0.org/ontology/adversarial_assessment_ref)",
    "tprm_assessment_ref": "[https://source0.org/ontology/tprm_assessment_ref](https://source0.org/ontology/tprm_assessment_ref)",
    "completeness_attestor": "[https://source0.org/ontology/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": "E&Y Accredited AI Lab"
  },
  "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..."
  }
}

• schema_version: Semantic version string of the CCC schema used, enabling multi-year schema evolution tracking without hash ambiguity.

• schema_hash: The SHA-256 hash of the complete, published CCC schema document as published at sealing time; the schema document itself shall be physically appended to the sealed artifact as a named attachment.

• threat_model_ref: SHA-256 hash of the current threat model document, with document creation timestamp, establishing that the threat model presented to the human arbitrator is the specific version bound to this sealing event.

• adversarial_assessment_ref: SHA-256 hash of the most recent adversarial robustness assessment report, with assessment date and assessor identity (natural person or accredited third-party organization), establishing the provenance and recency of the robustness evaluation.

• tprm_assessment_ref: SHA-256 hash of the third-party risk management assessment covering all components within the automated execution perimeter, with assessment date, establishing that supply chain and third-party risk was evaluated prior to the sealing event.

• completeness_attestor: Qualified electronic signature (QES) within the meaning of eIDAS 2 Art. 3(12) of the officer attesting completeness, distinct from the Board-level sign-off token signatory, benefiting from the non-repudiation presumption of Art. 26(2) eIDAS 2; the identity of the attestor shall be bound to an organizational role explicitly authorized in the HAN-Graph topology document to perform CCC attestation.

The CCC document shall itself be SHA-256 hashed and included as a named component of the primary T-0 sealed artifact, 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 advanced nation-state adversaries from conducting state-replay or time-shifting attacks — where a valid historical decision context is injected back into the automation pipeline to mask a fresh unauthorized action — the protocol implements a hardware-bound sliding synchronization window backed by TEE-internal clock validation.

3.A Synchronization Sequence

The transactional execution pipeline functions through a direct cryptographic loop between the hardware and the trusted time authority:

• TEE-Internal Clock Verification: Prior to nonce generation, the T-0 capture module SHALL perform a TEE-internal NTPv4 time verification query to a minimum of three independent stratum-1 NTP servers via a TLS 1.3 connection established from within the hardware-isolated execution environment. The median response SHALL be used as the reference clock. Any discrepancy exceeding 5 seconds between the TEE-internal reference clock and the host-reported system clock SHALL trigger an immediate transaction abort and tamper alert.

• Step 1 — Nonce Injection Request: 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 (represented as $N_c$) generated by a hardware cryptographically secure pseudorandom number generator (HSM/TEE RND instruction) directly to the Time-Stamping Authority (TSA).

• Synchronization Window Constraints: The maximum permissible elapsed time between hardware nonce generation ($N_c$) and TSA token receipt is 30 seconds or less ($T_{\text{sync}} \le 30$ seconds). If no signed TSA token is received within $T_{\text{sync}}$, the transaction is automatically aborted and the nonce invalidated; no retry is permitted with the same nonce value. Network unavailability shall not defer the sealing operation — a Config B deployment operating in offline mode SHALL use a locally hosted TSA conforming to RFC 3161, whose clock synchronization with UTC is independently attested at intervals not exceeding 24 hours and whose attestation record is included in the sealed artifact.

• Step 2 — TSA Signature Integration: The RFC 3161 timestamp request SHALL be submitted simultaneously to two independent QTSPs. Both independent authorities process the challenge nonce and return signed timestamp tokens conforming to RFC 3161 back to the Config B hardware module, embedding the challenge nonce, the trusted atomic time, and the TSA's qualified electronic signature. Both responses SHALL agree within 2 seconds as a mandatory forensic verification condition.

• Step 3 — Evidentiary Binding and Storage Anchor: 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 dual signed TSA tokens, and the active platform attestation report. This multi-layered evidentiary artifact is instantly written and permanently anchored to the enterprise WORM storage layer or an immutable distributed ledger.

4. HAN-GRAPH MUTATION & TOPOLOGICAL HASH-CHAINING SPECS

In complex agentic environments (e.g., orchestrators running multi-agent loops with automated tool-calling capabilities), the system's execution parameters drift dynamically. The architecture prevents Retrofitted Topology Attacks by locking the structural boundaries of agent autonomy prior to execution.

4.A Graph Definition Matrix & Acyclicity Enforcement

The Human Arbitration Node Graph (represented as $G$) is formally defined as a directed acyclic graph consisting of a set of vertices (Nodes) and a set of directed edges mapping the authorized causal transitions between segments.

• Vertices Classification: Each vertex must be explicitly categorized as either a Human Arbitration Node (HAN) — requiring an independent, cryptographically isolated T-0 seal—or an Autonomous Execution Segment (AES) — operating under delegated machine autonomy.

• Causal Partition Boundaries: Each directed edge leading from a HAN to an AES 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.

• Enforcement Engine: The workflow orchestration layer SHALL implement a pre-execution acyclicity verification step using a depth-first search (DFS) topological sort on the declared HAN-Graph topology prior to each execution instance. Any runtime modification that would introduce a cycle SHALL trigger an automatic execution halt and a mandatory new T-0 sealing event on the modified topology before execution resumes.

• Loop Traversal & Edge State Commitment: Retry and error recovery paths that are structurally anticipated SHALL be explicitly declared as named edges in the sealed topology with their triggering conditions; unanticipated retry loops that cannot be resolved without topology modification SHALL be treated as topology change events subject to the SHA-256 hash chaining protocol.

• Edge State Commitment (ESC) Protocol: At every HAN-to-AES and AES-to-HAN edge transition, the complete canonical serialization of the agent execution state — comprising all input vectors, active tool call parameters, output buffers, and persistent context variables — SHALL be SHA-256 hashed and appended to a running Edge State Chain (ESC) maintained by the workflow orchestration engine. The ESC hash is computed as the SHA-256 of the current edge state canonical serialization concatenated with the previous ESC hash value, producing a tamper-evident state history analogous to the topology hash chaining protocol defined in Section 4.B. The accumulated ESC hash covering all AES segments preceding a HAN node SHALL be incorporated as a mandatory named field in the T-0 sealing event at that HAN, binding the human arbitrator's decision to the complete, cryptographically verifiable history of payload states that preceded it. Payload manipulation within any AES segment — including within declared error recovery edges — produces a detectable ESC discontinuity embedded in the subsequent HAN seal.

4.B Deployment Topological Seal

Prior to the initialization of any agentic workflow execution chain:

• Topological Serialization: The complete topology matrix of the graph is compiled into a standardized canonical JSON schema containing the cryptographic fingerprint of every component, code state, and routing rule.

• Primary Seal: The topology document is subjected to a primary T-0 initialization seal.

• Dynamic Mutation Protocol: If runtime telemetry dictates a structural modification of the graph topology, a new topology schema ($G'$) must be generated. The new schema incorporates the previous topology hash ($H_G$) into its metadata block. The new hash ($H_{G'}$) is computed as the SHA-256 hash of the canonical representation of $G'$ concatenated with $H_G$.

This dynamic mutation is signed with the Board-level sign-off token before execution resumes, creating an unbroken, history-directed graph structure. Any attempt to retroactively alter the graph boundaries to hide a runtime failure creates an immediate cryptographic discontinuity that invalidates the entire probatory history.

5. TELEMETRY & FORENSIC OBSERVABILITY AUDIT COUPLING

While SOURCE 0® focuses strictly on generating legally opposable artifacts (Opposability), it provides an integration interface to existing network security and event monitoring tools (Observability).

5.A Log Correlation Protocol

The infrastructure operates an automated forwarding loop. The SOURCE 0® infrastructure engine processes each human arbitration event and instantly transmits a structured, cryptographic transaction hash via a secure TLS connection directly into the enterprise SIEM environment. Upon arrival, the SIEM engine performs real-time forensic correlation, mapping the unique transaction hash directly to the concurrent network flow logs and raw kernel process execution traces across the target cluster.

The log entry transmitted during this sequence must embed the unique cryptographic transaction string within the structured data (SD-PARAM) field conforming to the Syslog RFC 5424 format:

<134>1 2026-06-10T08:43:34.123Z secure-terminal.elsen.corp SOURCE0 12345 [S0@419221 TransactionHash="a4f2c1d8e9b3047c6f5a2d1e8c9b4073f6a2d1e8c9b4073f6a2d1e8c9b40731" /* demonstration hash value — replace with runtime-computed SHA-256 of sealed artifact */ HAN_ID="HAN_NODE_047"] Human arbitration event cryptographically locked and committed to judicial escrow protocol.

This ensures that during a forensic post-incident investigation, a regulatory auditor can align network flow logs, kernel process audit traces, and memory access records with the exact, immutable boundary layer of the human decision that authorized them.

End of Technical Specification Annex (V1.3).

Jean-François ELSEN · Brussels, June 2026. All rights reserved.

SOURCE 0® is a registered trademark of Cabinet Jean-François ELSEN.