P158 — AIEP — Real-Time Evidence Streaming 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 for subscribing to and receiving continuous, event-driven evidence updates from AIEP mirrors (P60–P63), federated evidence providers (P156), and distributed evidence index nodes (P133) through a canonical EvidenceStreamEvent format and a StreamBroker component, enabling AIEP nodes to maintain a near-real-time evidence state without relying solely on scheduled poll-based ingestion.

Field of the Disclosure

[0003] This disclosure relates to real-time evidence streaming protocols for governed artificial intelligence reasoning systems.

[0004] More particularly, the disclosure concerns an EvidenceStreamEvent schema, a StreamSubscription negotiation procedure, a StreamBroker routing component, back-pressure and flow control mechanisms, and a guaranteed-delivery acknowledgement model allowing AIEP nodes to receive evidence updates within bounded latency bounds while preserving the ordering and integrity guarantees required for deterministic reasoning.

Background

[0005] AIEP evidence ingestion has historically operated on a scheduled poll model: normaliser nodes (P10) query mirrors (P60–P63) and distributed index nodes (P133) at configured intervals, retrieving new or updated artefacts for processing. This model introduces latency between evidence publication and evidence availability for reasoning, which is acceptable for stable evidence corpora but inadequate for high-velocity domains (financial data, medical journal preprints, legislative updates, real-time sensor data) where evidence age is a critical quality dimension.

[0006] A streaming model requires careful design within the AIEP deterministic framework. Evidence updates received out-of-order, duplicated, or missing can corrupt the temporal ordering guarantees of the ProvenanceChain (P150) and the freshness model (P147). The streaming protocol must therefore define ordering semantics, deduplication, back-pressure, and acknowledgement procedures compatible with the AIEP evidence lifecycle.

[0007] No existing AIEP specification defines a streaming model for evidence ingestion. This disclosure establishes the canonical protocol, enabling any AIEP node to act as a StreamSubscriber and any mirror, federation provider, or index node to act as a StreamEmitter.

Summary of the Disclosure

[0008] An EvidenceStreamEvent is the atomic unit of the streaming protocol. It comprises:

• event_id — SHA-256 hash of the canonical serialisation of all other event fields
• event_type — enumeration: EVIDENCE_NEW, EVIDENCE_UPDATED, EVIDENCE_WITHDRAWN, EVIDENCE_QUARANTINED, MANIFEST_REFRESH
• evidence_id — identifier of the affected EvidenceNode (null for MANIFEST_REFRESH)
• source_node_id — node fingerprint (P46) of the emitting node
• sequence_number — monotonically increasing integer within the emitting node’s stream; used for gap detection
• event_timestamp — ISO 8601 timestamp of the event
• payload_hash — SHA-256 hash of the event payload (EvidenceNode for NEW/UPDATED; null for WITHDRAWN/QUARANTINED)
• payload — the EvidenceNode object for NEW/UPDATED events; null for others

[0009] StreamSubscription: A StreamSubscriber node negotiates a subscription with a StreamEmitter by sending a SubscriptionRequest specifying:

• subscriber_node_id — the subscriber’s node fingerprint
• subject_scope — taxonomy codes (P160) identifying subject areas of interest
• jurisdiction_filter — ISO 3166 codes restricting events to specific jurisdictions (optional; null = all)
• event_types — list of desired event_type values
• start_sequence — sequence number from which events should be delivered (0 = beginning; null = live-only)
• max_batch_size — maximum number of events per delivery batch
• delivery_mode — PUSH (emitter sends to subscriber endpoint) or PULL (subscriber polls)

[0010] StreamBroker: A StreamBroker is a routing component that aggregates events from multiple StreamEmitters and fans them out to registered StreamSubscribers according to their SubscriptionRequest filters. The StreamBroker maintains a bounded event buffer per emitter, ordered by sequence_number. Subscribers receive events in sequence-number order for each source emitter. The StreamBroker deduplicates events by event_id within a configurable deduplication window.

[0011] Acknowledgement and Guaranteed Delivery: Each delivered event batch contains a batch_id. The StreamSubscriber responds with an Acknowledgement message containing the batch_id and the highest sequence_number successfully processed. The StreamBroker retains unacknowledged events for a configurable retention period (default: 24 hours) and retransmits on timeout. After the retention period expires, undelivered events are written to the subscriber’s MissedEventLog in the ledger (P80).

[0012] Back-Pressure: Where a StreamSubscriber’s ingestion pipeline (P10) is saturated, the subscriber sends a BackPressureSignal to the StreamBroker specifying a resume_after_ms interval. The StreamBroker buffers events for that subscriber during the back-pressure window. Where the buffer reaches its max_buffer_size, the StreamBroker drops events of type EVIDENCE_UPDATED (preferring the most recent update) and retains all EVIDENCE_WITHDRAWN and EVIDENCE_QUARANTINED events unconditionally.

[0013] Ordering Guarantees: The streaming protocol guarantees per-emitter ordering by sequence_number. Cross-emitter ordering is not guaranteed; the receiving AIEP node’s ingestion pipeline assigns a local_ingestion_timestamp used for local ordering. The ProvenanceChain (P150) for each artefact records the event_id of the streaming event that triggered its ingestion, preserving the provenance of stream-sourced artefacts.

ASCII Architecture

─────────────────────────────────────────────────────────────
EMITTERS                  BROKER                 SUBSCRIBERS
─────────────────────────────────────────────────────────────
Mirror Node (P60) ──┐
Federation Prov  ──┬┼──▶ ┌─────────────────┐
Index Node (P133)──┘│    │  StreamBroker   │ ──▶ AIEP Node A
                    │    │  - dedup        │     (PUSH/PULL)
                    │    │  - sequence ord │
                    │    │  - back-pressure│ ──▶ AIEP Node B
                    └───▶│  - retry buffer │
                         └────────┬────────┘
                                  │ MissedEventLog
                                  ▼
                         ┌─────────────────┐
                         │  Ledger (P80)   │
                         └─────────────────┘

Operational Detail

[0014] Gap Detection: The StreamSubscriber monitors sequence_number continuity for each emitter. If a gap is detected (sequence numbers n and n+2 received, n+1 missing), the subscriber sends a GapRecoveryRequest to the StreamBroker specifying the missing sequence number range. The StreamBroker retrieves the missing events from its retention buffer and retransmits. If the events have expired from the retention buffer, the subscriber falls back to a directed poll of the emitter’s evidence index for the time window corresponding to the gap.

[0015] Stream Security: EvidenceStreamEvents are signed by the emitting node using the node’s private key (P46). The StreamBroker verifies event signatures before buffering. Subscribers may additionally verify the payload_hash against the received payload before ingestion. Events failing verification are dropped and logged as StreamIntegrityViolationRecords in the ledger.

[0016] Volatility Integration: StreamEmitters for high-volatility evidence sources (P163 LIVE or HIGH volatility classification) are expected to emit events within 60 seconds of source change. AIEP nodes subscribing to such streams should configure max_batch_size = 1 to minimise ingestion latency for time-critical evidence updates.

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.