◎ OS PUB Apache 2.0 ← All specifications

P156 — AIEP — Federated Evidence Network Standard

Publication Date: 2026-03-27 Status: Open Source Prior Art Disclosure Licence: Apache License 2.0 Author/Organisation: Phatfella Ltd Schema: AIEP_OS_SPEC_TEMPLATE v1.0.1 — https://aiep.dev/schemas/aiep-os-spec-template/v1.0.1

Framework Context

[0001] This disclosure operates within an Architected Instruction and Evidence Protocol (AIEP) environment as defined in United Kingdom patent application number GB2519711.2, filed 20 November 2025, the entire contents of which are incorporated herein by reference.

[0002] The present disclosure defines a standard allowing independent organisations — universities, research institutions, government agencies, commercial data providers, and sovereign bodies — to expose their evidence collections to the AIEP evidence discovery layer through a canonical federation contract and signed evidence manifests, becoming FederatedEvidenceProviders discoverable by any AIEP node.

Field of the Disclosure

[0003] This disclosure relates to federated evidence network standards for governed artificial intelligence reasoning systems.

[0004] More particularly, the disclosure concerns a FederationContract schema, a signed EvidenceManifest publication mechanism, a discovery protocol, and a governance interface through which AIEP-governed reasoning systems can locate, evaluate, and selectively ingest evidence from federation members without requiring centralised evidence storage.

Background

[0005] The AIEP distributed evidence index (P133) enables AIEP nodes to discover evidence artefacts from other AIEP nodes. However, many valuable evidence repositories are maintained by organisations that do not run AIEP node infrastructure but wish to make their data discoverable to AIEP-governed systems. A lighter-weight federation interface is required to admit these providers without requiring full AIEP node deployment.

[0006] Evidence federation must be governed: not every organisation that wishes to become a provider should be automatically trusted at the same confidence tier. A federation contract should specify the provider’s domain, subject matter scope, jurisdiction, evidence format, refresh schedule, and trust tier, enabling consuming AIEP nodes to make governed admissibility decisions based on the contract terms.

[0007] No existing AIEP specification defines the FederationContract format, the EvidenceManifest publication and signing procedure, or the discovery mechanism through which AIEP nodes locate and evaluate federation members.

Summary of the Disclosure

[0008] A FederationContract is a structured document signed by the FederatedEvidenceProvider organisation, comprising:

provider_id — canonical identifier for the provider organisation
provider_domain — registered domain of the provider
subject_scope — schema-defined taxonomy codes identifying the subject matter of the evidence collection
jurisdiction — ISO 3166 jurisdiction codes applicable to the evidence
evidence_format — the format of published evidence (AIEP_EVIDENCE_NODE, BibTeX, RDF, CSV, JSON-LD)
refresh_schedule — the publication frequency of manifest updates (cron expression)
trust_tier_claim — the provider’s self-asserted trust tier claim (consuming nodes evaluate this against their own trust scoring policy)
manifest_endpoint — the URL at which the signed EvidenceManifest is published
signing_key_fingerprint — the SHA-256 fingerprint of the public key used to sign manifests
contract_version — semantic version of the FederationContract
contract_timestamp — ISO 8601 date of contract publication

[0009] EvidenceManifest: A signed document published by the provider at manifest_endpoint at each refresh_schedule interval, comprising:

provider_id referencing the FederationContract
manifest_timestamp — ISO 8601 publication timestamp
evidence_entries — list of EvidenceManifestEntries, each containing: source_url; content_hash; retrieval_timestamp; jurisdiction; subject_tags; language (BCP 47)
manifest_signature — cryptographic signature of the canonical serialisation of all fields, using the key identified by signing_key_fingerprint

[0010] Manifest Verification: Consuming AIEP nodes verify an EvidenceManifest by: (a) fetching the provider’s public key from the provider’s .well-known/aiep/federation-key endpoint; (b) confirming the key’s fingerprint matches signing_key_fingerprint in the FederationContract; (c) verifying the manifest_signature against the canonical serialisation of the manifest; and (d) checking manifest_timestamp falls within the configured maximum manifest age.

[0011] Federation Registry: FederationContracts are published in the AIEP Federation Registry — a distributed directory hosted at multiple AIEP hub nodes — enabling any node to discover available providers by subject scope and jurisdiction. Entries in the Federation Registry are signed by the submitting hub node and carry a registry_admission_timestamp.

[0012] Selective Ingestion: On discovering a provider, a consuming AIEP node evaluates the FederationContract against its local FederationAdmissionPolicy (governing required trust tier, jurisdiction coverage, subject scope match, and minimum refresh schedule). If the contract satisfies the policy, the node registers the provider for periodic manifest pull. EvidenceManifestEntries pulled from the manifest are submitted to the local evidence admission gate (P145 LCAP equivalent) for governed admission; they are not automatically admitted.

[0013] Contract Revocation: A provider may revoke a FederationContract by publishing a signed RevocationNotice at the manifest_endpoint. Consuming nodes receiving a RevocationNotice suspend manifest pulls from the provider and log a FederationRevocationRecord. Existing artefacts admitted from the provider remain in the evidence index but are flagged as PROVIDER_REVOKED pending governance review.

Technical Effect

[0014] The FederationContract and EvidenceManifest architecture enables non-AIEP organisations to participate in the evidence ecosystem without deploying AIEP node infrastructure, extending the range of evidence sources available to AIEP-governed reasoning systems.

[0015] Cryptographic manifest signing — combined with trust tier claims evaluated locally per-node rather than globally — preserves the decentralised trust model of AIEP: no central authority decides which providers are trusted; each consuming node applies its own FederationAdmissionPolicy.

[0016] The governed admission gate application to manifest entries ensures that federation does not bypass the evidence admissibility controls: federated evidence receives the same trust scoring, jurisdiction filtering, and deduplication treatment as directly retrieved evidence.

Claims

A federated evidence network standard for a governed AI reasoning system, the standard comprising: a FederationContract schema specifying provider identity, domain, subject scope, jurisdiction, evidence format, refresh schedule, trust tier claim, manifest endpoint, and signing key fingerprint; a signed EvidenceManifest published by the provider at each refresh interval listing evidence entries with source URLs, content hashes, and jurisdiction metadata; and a manifest verification procedure confirming the manifest signature against the provider’s public key.
The standard of claim 1, wherein a consuming AIEP node evaluates a FederationContract against a local FederationAdmissionPolicy governing minimum trust tier, jurisdiction coverage, subject scope match, and refresh schedule, and registers the provider for periodic manifest pull only if the contract satisfies the policy.
The standard of claim 1, wherein EvidenceManifestEntries pulled from a provider manifest are submitted to the local evidence admission gate for governed admission rather than automatically admitted, ensuring that federated evidence receives the same trust scoring, jurisdiction filtering, and deduplication treatment as directly retrieved evidence.
The standard of claim 1, wherein a provider revokes a FederationContract by publishing a signed RevocationNotice, causing consuming nodes to suspend manifest pulls and flag previously admitted artefacts from the provider as PROVIDER_REVOKED pending governance review.

Brief Description of the Drawing

FIG. 1 — Federation discovery and ingestion flow: provider publishes FederationContract → node discovers via Federation Registry → evaluates FederationAdmissionPolicy → manifest pull → admission gate.

FIG. 2 — EvidenceManifest structure: manifest_timestamp, evidence_entries array, manifest_signature, and signing key verification path.

Abstract

A federated evidence network standard enables independent organisations to expose evidence collections to AIEP-governed reasoning systems without deploying AIEP node infrastructure. A FederationContract specifies the provider’s subject scope, jurisdiction, format, refresh schedule, and signing key. Providers publish signed EvidenceManifests at a defined endpoint at each refresh interval. Consuming nodes discover providers through a Federation Registry, evaluate FederationContracts against local admission policies, and pull manifests periodically. Manifest entries are submitted to the local evidence admission gate rather than automatically admitted. Providers may revoke contracts with a signed RevocationNotice.

Licence

Apache License 2.0 — https://www.apache.org/licenses/LICENSE-2.0