◎ OS PUB Apache 2.0 ← All specifications

P192 — AIEP — Evidence Peer Verification Protocol

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 protocol through which AIEP evidence corpus nodes collaboratively verify each other’s evidence holdings via probabilistic sampling — enabling a network of peer nodes to detect discrepancies in each other’s evidence corpora and ProvenanceChains without requiring full corpus exchange, using a mutual sampling and attestation mechanism producing PeerVerificationRecords.


Field of the Disclosure

[0003] This disclosure relates to probabilistic peer-to-peer verification protocols for distributed evidence corpora in governed artificial intelligence networks.

[0004] More particularly, the disclosure concerns: a PeerVerificationSession schema; a probabilistic sampling strategy; a PeerVerificationRecord schema; evidence of discrepancy classification; the PeerVerificationGraph linking nodes through their mutual verification histories; and integration with the divergence detection mechanism (P37) and the trust scoring system (P124).


Background

[0005] In a federated AIEP evidence network (P156) where multiple nodes independently hold corpus partitions or full corpus copies, any single node’s evidence holdings are trusted primarily based on its node fingerprint (P46) and trust tier. However, nodes may diverge from expected holdings through software error, hardware failure, incomplete synchronisation, or adversarial manipulation.

[0006] Full-corpus cross-verification between nodes is prohibitively expensive at scale. Probabilistic sampling allows each node to challenge peer nodes on a random subset of its holdings: “Do you have artefact X? What is its content hash?” A peer that cannot provide the expected content hash, or provides an incorrect one, reveals a discrepancy that warrants investigation. Statistical theory guarantees that a sufficient sampling rate detects corpus-wide corruption with high probability even without checking every artefact.


Summary of the Disclosure

[0007] PeerVerificationSession: A verification session is initiated periodically (default: every 12 hours) between a verifying_node and a challenged_node:

  • session_id — SHA-256 of canonical serialisation
  • verifying_node — P46 fingerprint of the initiating node
  • challenged_node — P46 fingerprint of the node being verified
  • sample_size — number of DEIDs sampled in this session (default: 100; configurable by network policy)
  • sample_deid_list — the randomly sampled DEIDs, selected uniformly from the intersection of what the verifying node holds and what the challenged node is expected to hold based on its registered corpus scope
  • session_start_at — ISO 8601 timestamp
  • session_expires_at — session timeout (default: 60 minutes)

[0008] Verification Exchange: For each DEID in sample_deid_list, the verifying node sends a VerificationProbe:

  • probe_id — SHA-256 of canonical serialisation
  • session_id
  • probe_deid — the DEID being probed
  • probe_nonce — a random nonce preventing pre-computed responses The challenged node responds with a VerificationResponse:
  • probe_id — echoed from the probe
  • content_hash — SHA-256 of the artefact’s canonical content
  • hashchain_entry_index — the artefact’s HashChain position (P175)
  • response_signature — signed by the challenged node

[0009] PeerVerificationRecord: The verifying node records the session outcome:

  • verification_record_id — SHA-256 of canonical serialisation
  • session_id
  • verifying_node — P46 fingerprint
  • challenged_node — P46 fingerprint
  • session_completed_at — ISO 8601 timestamp
  • probes_sent — count of probes sent
  • responses_received — count of responses received
  • response_rate — fraction of probes receiving a response (1.0 = all responded)
  • discrepancy_count — count of probes with incorrect content_hash or missing response
  • discrepancy_ratediscrepancy_count / probes_sent
  • verification_verdictPASS (discrepancy_rate ≤ acceptable_threshold), WARN (discrepancy_rate between acceptable and critical threshold), FAIL (discrepancy_rate ≥ critical_threshold)
  • discrepant_deids — list of DEIDs with discrepancies and the found vs expected content hash
  • record_signature — signed by the verifying node

[0010] Verification Thresholds: Network policy (governed by P89) defines:

  • acceptable_discrepancy_rate — default: 0.0 (any discrepancy produces WARN)
  • critical_discrepancy_rate — default: 0.05 (5% discrepancy rate produces FAIL)

[0011] Response on FAIL Verdict: A FAIL PeerVerificationRecord triggers:

  • Immediate notification to the governance node (P89)
  • The challenged node’s trust tier (P124) is placed under TRUST_REVIEW
  • Evidence routing (P182 equivalent logic) reduces the challenged node’s routing weight
  • A HashChainDeviationRecord (P175) is filed for each discrepant_deid

[0012] PeerVerificationGraph: The PeerVerificationGraph records all PeerVerificationRecords as directed edges in a graph (verifying_node → challenged_node). The graph enables network-level analysis: nodes that consistently fail verification across multiple verifiers are identified as SUSPECTED_COMPROMISED; nodes that consistently achieve PASS across all verifiers accumulate higher network trust.


ASCII Architecture

Verifying Node                      Challenged Node
      │                                    │
      │──── PeerVerificationSession ──────▶│
      │      (sample_deid_list)             │
      │                                    │
      │── VerificationProbe (per DEID) ──▶│
      │      (probe_deid, nonce)            │
      │                                    │
      │◀─ VerificationResponse ────────────│
      │      (content_hash, chain_index)    │
      │                                    │
      ▼ compare with local holdings
PeerVerificationRecord
  (discrepancy_count, verdict)

      ├── PASS  → PeerVerificationGraph update (positive)
      ├── WARN  → Log, governance notification
      └── FAIL  → Governance (P89), trust_review,
                  HashChainDeviationRecord (P175)

PeerVerificationGraph:
  network trust analysis → identify SUSPECTED_COMPROMISED nodes

Operational Detail

[0013] Randomness Guarantees: The DEIDs sampled in each PeerVerificationSession are selected using a cryptographically secure pseudorandom number generator seeded with the session_id and a shared network entropy value published daily by the governance node. This prevents either party from predicting or biasing the sample selection.

[0014] Reciprocal Verification: In a healthy network, verification is reciprocal — Node A verifies Node B while Node B independently verifies Node A. Discrepancies detected by both in the same session, for the same DEIDs, indicate a genuine corpus inconsistency rather than a verifier error.

[0015] Sampling Rate Scaling: For large corpus holders with millions of artefacts, the default sample size of 100 probes provides approximately 95% confidence of detecting a 3% corpus-wide corruption rate. Governance policy may require higher sample sizes for nodes with higher trust tiers or for corpora designated as critical infrastructure.


Claims-Exclusion Notice

This specification is published as open-source prior art. No patent claims are asserted by the author in respect of the mechanisms described. Any third party seeking to patent mechanisms substantially equivalent to those described herein is placed on notice of this prior art disclosure.