◎ OS PUB Apache 2.0 ← All specifications

P153 — AIEP — Protocol Version Negotiation Framework

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 handshake and negotiation protocol enabling two AIEP nodes running different protocol versions to establish a compatible operating mode for evidence exchange, schema interpretation, and cross-node validation, without requiring either node to upgrade before communication can proceed.

Field of the Disclosure

[0003] This disclosure relates to protocol version negotiation frameworks for distributed governed artificial intelligence reasoning node networks.

[0004] More particularly, the disclosure concerns a capability advertisement and negotiation handshake that produces a shared NegotiatedProtocolProfile specifying the maximum protocol version, schema version, capability set, and serialisation format that both nodes support, governing all subsequent evidence exchanges between them.

Background

[0005] AIEP nodes operating in a distributed environment may run different versions of the AIEP core protocol as the specification evolves. A node running v1.3 may need to exchange evidence with a node running v1.1. Without a negotiation framework, the v1.3 node cannot know which features the v1.1 node supports, and may transmit evidence artefacts using schema fields or serialisation formats that the older node cannot process.

[0006] Protocol version mismatches in distributed AI systems are a common cause of silent data loss: newer nodes may simply drop unrecognised fields without signalling the error, causing evidence artefacts to be admitted with incomplete metadata. A negotiation framework prevents this by establishing a shared capability floor before any evidence exchange begins.

[0007] No existing AIEP specification defines the capability advertisement format, the negotiation message exchange sequence, the profile selection algorithm, or the downgrade and retry procedure when a node’s minimum supported version exceeds the peer’s maximum.

Summary of the Disclosure

[0008] Capability Advertisement: When a node initiates a connection to a peer for evidence exchange, it transmits a CapabilityAdvertisement comprising:

node_id — the advertising node’s canonical identifier
protocol_versions_supported — ordered list of supported protocol versions
schema_versions_supported — ordered list of supported EvidenceNode schema versions
capabilities — named list of optional protocol capabilities
serialisation_formats — ordered list of preferred serialisation formats
min_protocol_version — the minimum version the advertising node will accept

[0009] Negotiation Response: The receiving node evaluates the CapabilityAdvertisement against its own capability set and responds with a NegotiationResponse comprising:

accepted — boolean
negotiated_protocol_version — the highest version both nodes support
negotiated_schema_version — the highest schema version both nodes support
negotiated_capabilities — the intersection of capabilities both nodes support
negotiated_serialisation_format — the preferred format from the intersection
rejection_reason — if accepted is false, the reason (e.g. VERSION_BELOW_MINIMUM)

[0010] NegotiatedProtocolProfile: If accepted is true, both nodes operate under the NegotiatedProtocolProfile derived from the NegotiationResponse for the session duration. All evidence artefacts exchanged are serialised using the negotiated format, and schema fields absent in the negotiated schema version are omitted or mapped to their closest ancestor.

[0011] Downgrade Handling: If the negotiated protocol version is below the initiating node’s preferred version, the initiating node logs a ProtocolDowngradeRecord noting both nodes’ versions, the negotiated version, and capabilities unavailable in the downgraded session.

[0012] Session Re-Negotiation: Either node may initiate re-negotiation during a session by sending a new CapabilityAdvertisement. Re-negotiation events are appended to the session log.

[0013] Well-Known Version Endpoint: Nodes publish their current CapabilityAdvertisement at the .well-known/aiep/capabilities endpoint (P61 extension), enabling pre-connection version discovery.

Technical Effect

[0014] Capability intersection negotiation enables the AIEP network to evolve incrementally: newer nodes gain new capabilities when connected to other new nodes, and fall back to a compatible profile when connected to older nodes.

[0015] Well-known endpoint publication of capability advertisements enables pre-connection version discovery, reducing failed connection attempts from version incompatibility.

[0016] Explicit minimum version enforcement and rejection reason codes surface version floor violations clearly, preventing silent data loss from partial schema support.

Claims

A protocol version negotiation framework for a distributed governed AI reasoning node network, the framework comprising: a CapabilityAdvertisement transmitted by the initiating node listing supported protocol versions, schema versions, capabilities, and serialisation formats; a NegotiationResponse from the receiving node specifying the negotiated profile as the intersection of both nodes’ capabilities; and a NegotiatedProtocolProfile governing all evidence exchanges in the session.
The framework of claim 1, wherein a ProtocolDowngradeRecord is produced when the negotiated protocol version is below the initiating node’s preferred version, recording both nodes’ versions and the capabilities unavailable in the downgraded session.
The framework of claim 1, wherein negotiation fails and a session is not established if the negotiated protocol version is below either node’s minimum protocol version, with a rejection reason code returned to the initiating node.
The framework of claim 1, wherein nodes publish their current CapabilityAdvertisement at a well-known endpoint, enabling pre-connection version discovery by any peer before initiating a connection.

Brief Description of the Drawing

FIG. 1 — Version negotiation handshake sequence: initiating node → CapabilityAdvertisement → receiving node → NegotiationResponse → NegotiatedProtocolProfile established.

FIG. 2 — Capability intersection algorithm: initiating node capability set ∩ receiving node capability set = negotiated capabilities.

Abstract

A protocol version negotiation framework enables AIEP nodes running different protocol versions to establish a compatible operating mode for evidence exchange. When a connection is initiated, the requesting node transmits a CapabilityAdvertisement listing its supported protocol versions, schema versions, capabilities, and serialisation formats. The receiving node computes the intersection and returns a NegotiationResponse. Both nodes operate under the resulting NegotiatedProtocolProfile for the session duration. Downgrade events are logged. Nodes publish their capabilities at a well-known endpoint for pre-connection discovery.

Licence

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