P229 — AIEP — Federated Trust System
Applicant: Neil Grassby Classification: Patent Application — Confidential Priority: Claims priority from GB2519711.2 filed 20 November 2025 Architecture Layer: AIEP Phase 2 Support Layer
Framework Context
[0001] This specification operates within an AIEP environment as defined in GB2519711.2 and GB2519798.9. The present specification defines the federated trust establishment mechanism that enables independent AIEP deployments to establish verifiable trust relationships under which evidence exchange and joint reasoning are permitted.
Field of the Invention
[0002] The present invention relates to federated trust systems and cryptographic attestation architectures for distributed evidence-bound artificial intelligence.
[0003] More particularly, the invention relates to a system for establishing mutual trust between independent AIEP deployments through cryptographic attestation of node identity, governance policy commitment, and operational integrity, without requiring a centralised trust authority.
Background
[0004] Federation of AIEP evidence ledgers requires that each node can verify that a remote node: operates a conformant AIEP evidence ledger; is committed to a governance policy compatible with the local policy; has not been tampered with (hardware attestation); and is operated by an identified legal entity.
[0005] Standard TLS certificate systems establish channel security but not the operational integrity of the remote system. A purpose-built AIEP trust attestation mechanism provides deeper trust assurance aligned with the specific requirements of federated evidence exchange.
Summary of the Invention
[0006] The invention provides a Federated Trust System (FTS) implementing a four-layer trust attestation protocol: identity attestation (cryptographic proof of node identity using a self-sovereign identity scheme); policy attestation (cryptographic commitment to a governance policy hash); operational integrity attestation (hardware-level attestation of the running software stack using P244); and evidence ledger continuity attestation (cryptographic proof that the node’s evidence ledger is unmodified since the last attestation point).
[0007] A federation relationship is established when all four attestation layers are satisfied between two nodes. Trust levels — PROVISIONAL, ESTABLISHED, or TRUSTED — are assigned based on attestation completeness and history.
ASCII Architecture
Node A wants to federate with Node B
|
v
+---------------------------------------------+
| Federated Trust System (FTS) |
| |
| Layer 1: Identity Attestation |
| Layer 2: Policy Attestation |
| Layer 3: Operational Integrity (P244) |
| Layer 4: Ledger Continuity |
+---------------------+-----------------------+
|
all 4 pass?
| |
v v
Trust Level Assigned Federation Denied
(PROVISIONAL/TRUSTED) + Denial Record
Detailed Description
[0008] Identity Attestation. Each AIEP node holds a self-sovereign identity (SSI) document containing its public key, legal entity identifier, and AIEP deployment version. Identity attestation verifies that the requesting node controls the private key corresponding to its declared identity.
[0009] Policy Attestation. The requesting node submits a commitment containing: the SHA-256 hash of its active governance policy; a signed statement that the policy has been in effect for at least the configured minimum period; and the policy version number. The receiving node checks the policy hash against its compatibility list.
[0010] Operational Integrity Attestation. The requesting node provides a hardware attestation report (P244) certifying the integrity of the running software stack. This prevents federation with nodes running modified or tampered AIEP implementations.
[0011] Ledger Continuity Attestation. The requesting node provides a signed Merkle root of its evidence ledger. Subsequent attestation cycles verify that the root advances monotonically, confirming ledger append-only integrity.
[0012] Trust Level Management. PROVISIONAL trust is assigned on first successful attestation. ESTABLISHED trust requires successful attestation for at least N consecutive attestation cycles. TRUSTED status requires ESTABLISHED trust plus positive track record of evidence exchange without integrity violations.
Technical Effect
[0013] The invention provides decentralised, cryptographic trust establishment for federated AIEP deployments without dependency on a centralised trust authority. By requiring four independent attestation layers — identity, governance policy, operational integrity, and ledger continuity — the system prevents federation with nodes that are impersonating, non-compliant, tampered, or maintaining non-append-only ledgers. By assigning trust levels progressively over multiple attestation cycles, the system prevents single-cycle trust misrepresentation from immediately enabling high-trust evidence exchange.
Claims
-
A computer-implemented method for federated trust establishment, the method comprising: (a) verifying peer node identity through cryptographic certificate exchange and digital signature verification against a governance-authority-issued certificate; (b) evaluating governance policy compatibility by comparing the peer node’s committed governance policy hash against the local compatibility list; (c) evaluating operational integrity through a hardware attestation report certifying the integrity of the peer node’s running software stack; (d) evaluating ledger continuity by verifying that the peer node’s signed Merkle ledger root advances monotonically across attestation cycles; and (e) assigning trust levels progressively — PROVISIONAL on first successful attestation, ESTABLISHED after N consecutive successful cycles, TRUSTED after ESTABLISHED status with positive evidence exchange track record — and gating evidence exchange by trust level.
-
The method of claim 1, wherein identity attestation detects certificate forgery attempts by verifying certificate chain against the governance authority root certificate.
-
The method of claim 1, wherein governance policy incompatibility identified at the policy attestation layer prevents evidence exchange in policy-incompatible categories even when other attestation layers pass.
-
The method of claim 1, wherein hardware attestation failure marks the peer node as TAMPERED, preventing all evidence exchange until a fresh attestation passes.
-
The method of claim 1, wherein attestation cycle records are admitted to the local evidence ledger as trust event artefacts, maintaining a full history of peer trust evolution.
-
A Federated Trust System comprising: one or more processors; memory storing a peer trust registry, attestation cycle records, and trust level transition logic; wherein the processors are configured to execute the method of claim 1.
-
A non-transitory computer-readable medium storing instructions that, when executed by a processor, implement the method of claim 1.
Abstract
A federated trust system for evidence-bound artificial intelligence establishes trust between peer AIEP nodes through four sequential attestation layers: cryptographic identity verification, governance policy compatibility, hardware-attested software stack integrity, and monotonically advancing ledger Merkle root verification. Trust levels are assigned progressively over multiple attestation cycles to prevent single-cycle misrepresentation. Evidence exchange is gated by trust level, and all attestation events are recorded in the local AIEP evidence ledger.