Network Working Group                                            T. Sato
Internet-Draft                                           MyAuberge K.K.
Intended status: Standards Track                          24 May 2026
Expires: 24 November 2026


   The Federated Agent Intelligence Protocol (FAIP) for Agentic AI
                              Systems
                       draft-sato-soos-faip-00

Abstract

   AI agents governed by the SOOS protocol family generate a
   continuous stream of cryptographically signed, non-suppressible
   behavioral evidence: intent declarations, Cedar evaluation outcomes,
   escalation decisions, goal completion records, and trust scores.
   Within a single operator's trust domain, this evidence informs
   Progressive Trust scoring [I-D.sato-soos-pt].  Across operators,
   it is discarded.  Each operator's agents learn from their own
   history only.  The aggregate behavioral intelligence available from
   millions of governed agent sessions -- which reasoning patterns
   succeed in which contexts, which escalation judgments prove correct,
   which confidence calibrations hold across diverse task types --
   remains invisible to every participant.

   This document defines the Federated Agent Intelligence Protocol
   (FAIP): the Tier 3 analytics layer of the SOOS protocol family,
   specifying how aggregate behavioral intelligence is derived from
   governed agent Event Streams across participating operators, made
   available to agents and human principals, and protected through
   privacy-preserving aggregation, data residency controls, and
   k-anonymity enforcement.

   FAIP does not share individual session records.  It does not expose
   any operator's proprietary data.  It produces aggregate behavioral
   signal -- empirical, tamper-evident, distributed -- that no single
   participant can generate from their own data alone.  FAIP is the
   first protocol specification for federated behavioral intelligence
   derived exclusively from cryptographically governed agent activity
   records.

   This document establishes the FAIP architecture, its relationship
   to the three-tier analytics model defined in [I-D.sato-soos-idp],
   its privacy and data residency framework, and the scope of
   subsequent FAIP specifications.  Full protocol specification of
   FAIP query interfaces, federation topology, and aggregation
   algorithms is deferred to successor documents.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 24 November 2026.

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.


Table of Contents

   1.  Introduction
   2.  Conventions and Definitions
   3.  The Three-Tier Analytics Model
     3.1.  Tier 1 -- Session-Local Intelligence
     3.2.  Tier 2 -- Operator-Domain Intelligence
     3.3.  Tier 3 -- Federated Intelligence (FAIP)
     3.4.  Tier Boundary Enforcement
   4.  What FAIP Produces
     4.1.  The Aggregate Behavioral Library
     4.2.  Use Case 1 -- Cross-Operator Reasoning Pattern Library
     4.3.  Use Case 2 -- Federated PT Score Contextualization
     4.4.  Use Case 3 -- Systemic Risk Detection
     4.5.  Use Case 4 -- SO Type Behavioral Benchmarks
   5.  What FAIP Does Not Do
   6.  The Privacy Architecture
     6.1.  Data Residency as the Primary Control
     6.2.  K-Anonymity Enforcement
     6.3.  Differential Privacy Considerations
     6.4.  The Non-Suppressibility Guarantee
   7.  FAIP Federation Model
     7.1.  Participation
     7.2.  FAIP Node
     7.3.  Federation Topology
     7.4.  Trust Anchor
   8.  FAIP and the IDP Data Residency Field
   9.  Relationship to Progressive Trust
   10. Relationship to Other SOOS Drafts
   11. Scope of This Document and Future Work
   12. Security Considerations
   13. Privacy Considerations
   14. IANA Considerations
   15. References
     15.1. Normative References
     15.2. Informative References
   Appendix A.  The Institutional Analogy


1.  Introduction

   Consider what happens after a governed AI agent completes a session.
   The GEC writes AEP_SESSION_CLOSED.  The GAR generates a Session
   Audit Record.  The agent's Progressive Trust score is updated.  The
   operator has a richer behavioral record for that agent.

   Then the next operator's agent starts a similar session, in a
   similar context, facing a similar decision.  It has no access to
   what the first agent learned.  It will make the same mistakes,
   encounter the same Cedar DENY patterns, and develop the same
   escalation calibration -- from scratch, through its own sessions,
   within its own operator domain.

   This is the federated intelligence gap.  Each operator's governed
   agents improve within their own domain.  The aggregate behavioral
   knowledge generated across all governed agents -- which reasoning
   patterns succeed in which SO Type contexts, which confidence
   calibration approaches prove accurate across diverse task types,
   which escalation thresholds correlate with correct human principal
   outcomes -- is never pooled.  It cannot be, under any existing
   protocol, without exposing individual session records that contain
   proprietary business logic, personal data, and commercially
   sensitive operational information.

   FAIP closes this gap.  It is the Tier 3 analytics layer of the
   SOOS protocol family: a protocol for deriving aggregate behavioral
   intelligence from governed agent Event Streams across participating
   operators, without exposing any individual session record, any
   operator's proprietary data, or any personal data subject to
   regulatory protection.

   The key insight that makes FAIP possible is what the SOOS Event
   Stream is not.  It is not a business record.  It is not a
   conversation log.  It is not a copy of the data the agent operated
   on.  The Event Stream is a governed behavioral record: which Cedar
   actions were attempted, which were permitted, which were denied,
   how confident the agent declared itself, what escalation judgments
   it made, and whether it achieved its goal.  This behavioral record
   is separable from the underlying business data by design -- Zone A
   Invariant INV-ZA-1 [I-D.sato-soos-sov] Section 4.3.1 prohibits
   personal data in Zone A precisely so that the governance record can
   be retained and analyzed independently of the personal data it
   governs.

   FAIP aggregates the behavioral record, not the business data.
   An operator participating in FAIP contributes: which Cedar actions
   their agents attempted in which SO Type states, at what confidence
   levels, with what outcomes.  They do not contribute: what the
   Sovereign Object contained, who the traveller was, what the booking
   was for, or what business decisions were made.

   The result is a new category of institutional knowledge.  Not
   proprietary to any participant.  Not owned by any platform.
   Empirical, in the sense that it derives from actual governed
   behavior rather than synthetic benchmarks or vendor claims.
   Tamper-evident, in the sense that every contributing record is
   GEC-signed and non-suppressible.  And formally governed, in the
   sense that access to FAIP intelligence is controlled by the same
   Cedar policy framework that governs the agents whose behavior
   produced it.

   This document establishes the FAIP architecture at the -00 level:
   the three-tier model it completes, what it produces, what it
   explicitly does not do, its privacy architecture, and its
   federation model.  Full query interface specification, aggregation
   algorithm requirements, and federation topology protocols are
   deferred to successor documents.  The purpose of this -00 is to
   define the problem, claim the architectural space, and establish
   the normative boundaries within which successor specifications
   must operate.


2.  Conventions and Definitions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

   This document uses the following terms:

   Federated Agent Intelligence Protocol (FAIP):
      The Tier 3 analytics layer of the SOOS protocol family, defined
      in this document.  Specifies how aggregate behavioral intelligence
      is derived from governed agent Event Streams across participating
      operators, privacy-preserved, and made available to agents and
      human principals.

   FAIP Node:
      A participating operator's FAIP endpoint: a component that
      contributes anonymized behavioral aggregates to the FAIP
      federation and receives federated intelligence in return.

   FAIP Federation:
      The network of FAIP Nodes operating under a shared trust anchor
      and common protocol version.  A FAIP Federation has a defined
      membership, governance model, and data residency policy.

   Aggregate Behavioral Library (ABL):
      The corpus of federated behavioral intelligence produced by FAIP:
      anonymized, k-anonymized, and differentially private aggregates
      derived from governed agent Event Streams across FAIP Federation
      members.

   Reasoning Pattern:
      A structured summary of an agent's reasoning approach for a
      class of Cedar action in a class of SO Type state, derived from
      IDP reasoning_basis fields, confidence values, and Cedar
      evaluation outcomes.  Reasoning Patterns in the ABL are
      anonymized and aggregated; they do not identify any individual
      agent, operator, or session.

   Behavioral Benchmark:
      An aggregate performance metric for a specific SO Type and Cedar
      action class, derived from PT Dimension scores across FAIP
      Federation members.  Provides context for interpreting a single
      operator's PT scores relative to the federation.

   FAIP Tier Eligibility:
      The property of an IDP record that permits its behavioral
      signals to be included in FAIP aggregation.  Controlled by the
      tier3_eligible field in the IDP data_residency sub-object
      [I-D.sato-soos-idp] Section 4.2.

   K-Anonymity:
      A privacy property under which any record released by FAIP is
      indistinguishable from at least k-1 other records along every
      quasi-identifying attribute.  K is a FAIP Federation governance
      parameter; minimum value: 50.

   Data Residency Policy:
      The set of jurisdictional and contractual constraints governing
      where FAIP behavioral signals may be stored, processed, and
      accessed.  Derived from the data_residency field in IDP
      [I-D.sato-soos-idp] Section 4.2.

   Governing Enforcement Component (GEC):
      As defined in [I-D.sato-soos-idp]: a runtime component that
      enforces authorization policy, records agent actions to a tamper-
      evident Event Stream, and mediates agent access to Sovereign
      Object instances.

   Progressive Trust Score:
      As defined in [I-D.sato-soos-pt]: a multi-dimensional behavioral
      trust metric for an agent, computed from its GEC-signed Event
      Stream within a single operator's domain (Tier 2).

   Sovereign Object (SO):
      As defined in [I-D.sato-soos-sov]: a causally ordered, policy-
      governed, typed, living document that evolves through a predefined
      finite state space under GEC authority.


3.  The Three-Tier Analytics Model

   The IDP specification [I-D.sato-soos-idp] Section 3.5 defines a
   three-tier analytics architecture for SOOS behavioral intelligence.
   FAIP is the normative specification of Tier 3.  This section
   describes all three tiers to establish FAIP's position in the
   complete model.

3.1.  Tier 1 -- Session-Local Intelligence

   Tier 1 analytics operate within a single AEP Session
   [I-D.sato-soos-aep], on data that does not leave the session trust
   boundary.  No cross-session or cross-operator data flow occurs.

   Examples of Tier 1 analytics:

   - The GEC consults the current session's IDP history to detect
     systematic overconfidence patterns (high declared confidence
     followed by repeated Cedar DENY for the same action class).

   - The RETRY_CONTINUATION reasoning basis type [I-D.sato-soos-idp]
     Section 4.3 uses the current session's DENY history to inform
     the agent's next ACT step.

   - The Transition Graph query [I-D.sato-soos-aep] Section 7.1
     computes viable paths from the current SO state using session-
     local Cedar residual evaluation.

   - The prior_denial_count Cedar context attribute tracks DENY
     patterns within the current session to inform policy evaluation.

   Tier 1 analytics require no data residency controls and no privacy
   mechanisms beyond the normal GEC access controls.  All Tier 1
   analytics are specified fully in [I-D.sato-soos-aep] and
   [I-D.sato-soos-idp].

3.2.  Tier 2 -- Operator-Domain Intelligence

   Tier 2 analytics operate across sessions within a single operator's
   trust domain.  Data crosses session boundaries but does not leave
   the operator's GEC infrastructure.

   The primary Tier 2 analytics specification is Progressive Trust
   [I-D.sato-soos-pt]: PT Dimension scores are computed across an
   agent's full session history within the operator's domain, subject
   to data_residency constraints declared per IDP record.

   Examples of Tier 2 analytics beyond PT:

   - Cross-session Cedar DENY pattern analysis: which Cedar action
     classes consistently produce DENY outcomes for specific SO Type
     states, enabling Cedar policy refinement.

   - Goal completion analysis by SO Type and Cedar action path:
     which transition sequences produce the highest goal completion
     rates, informing Transition Graph optimization.

   - HEM outcome analysis: which HEM trigger conditions produce which
     human principal decision patterns, informing escalation threshold
     calibration.

   Tier 2 analytics are subject to k-anonymity enforcement and
   data_residency constraints at the tier2_eligible field level.
   The Analytics Principal role [I-D.sato-soos-pt] Section 10.3 is
   the Tier 2 access control mechanism.  All Tier 2 analytics
   specifications are in [I-D.sato-soos-pt] and [I-D.sato-soos-idp].

3.3.  Tier 3 -- Federated Intelligence (FAIP)

   Tier 3 analytics operate across operators.  Behavioral signals
   from multiple operators' FAIP Nodes are combined, privacy-preserved,
   and made available as the Aggregate Behavioral Library.

   Tier 3 is FAIP's scope.  The defining property of Tier 3 analytics
   is that no individual operator's session records are exposed.  FAIP
   aggregates behavioral patterns, not sessions.  The unit of
   contribution is an anonymized behavioral signal, not a record.

   FAIP Tier 3 analytics require:

   (a) Explicit FAIP Tier Eligibility per IDP record (tier3_eligible:
       true in data_residency).

   (b) K-anonymity enforcement at minimum k=50 across all released
       aggregates.

   (c) Participation in a FAIP Federation under a shared trust anchor
       and governance model.

   (d) Data residency policy compliance: behavioral signals from
       jurisdictions with data export restrictions MUST NOT cross
       those boundaries even in anonymized form, unless the relevant
       regulatory authority has determined that anonymized behavioral
       aggregates are not subject to the restriction.

3.4.  Tier Boundary Enforcement

   The tier boundaries are normative and MUST be enforced by
   participating GECs.

   A Tier 2 Analytics Principal MUST NOT receive individual session
   records from other operators' domains.  A FAIP Node MUST NOT
   transmit unaggregated session records to the federation.  A FAIP
   query response MUST NOT be traceable to any individual session,
   agent, or operator.

   These boundaries are enforced through:

   (a) The data_residency field in IDP, which records per-session
       tier eligibility at the time of session creation.

   (b) K-anonymity enforcement at the FAIP Node before any aggregate
       is released to the federation.

   (c) The FAIP Federation trust anchor, which certifies that
       participating FAIP Nodes conform to the tier boundary
       requirements of this specification.


4.  What FAIP Produces

4.1.  The Aggregate Behavioral Library

   The Aggregate Behavioral Library (ABL) is the corpus of federated
   behavioral intelligence produced by FAIP.  It is the concrete output
   that operators and their agents consume.

   The ABL is not a database of session records.  It is a library of
   behavioral aggregates: statistical summaries, pattern frequencies,
   benchmark distributions, and anomaly signals derived from the
   collective governed behavioral record of FAIP Federation members.

   The ABL has three content categories:

   Reasoning Pattern Library:
      Aggregated summaries of IDP reasoning patterns that correlate
      with Cedar PERMIT outcomes across the federation, organized by
      SO Type and Cedar action class.  An agent consulting the
      Reasoning Pattern Library before an ACT step can draw on the
      collective experience of agents across the federation that have
      attempted similar actions in similar SO Type states.

   Behavioral Benchmarks:
      Aggregate PT Dimension distributions across the federation for
      specific SO Type and action class combinations.  An operator can
      compare their agents' PT scores against the federation benchmark
      to understand whether their agents are performing above or below
      the collective norm.

   Systemic Signal Layer:
      Anomaly patterns detected across the federation: Cedar action
      classes with unusually high DENY rates across multiple operators
      simultaneously (potentially indicating a policy misconfiguration
      or emerging edge case), HEM trigger conditions with unusual
      outcome distributions, and SO Type state combinations that
      consistently produce goal completion failure.

4.2.  Use Case 1 -- Cross-Operator Reasoning Pattern Library

   An agent preparing an ACT step on a BOOKING_SUSPENDED transition
   in an ATP Booking Object [I-D.sato-soos-sov] Appendix A has access,
   through FAIP, to the aggregate reasoning patterns that have produced
   PERMIT outcomes for that Cedar action class across all federation
   members who have contributed tier3_eligible records for that action.

   The agent does not learn any individual operator's session content.
   It learns: across the federation, IDPs that cited Zone B weather
   sensor attachments as primary reasoning basis, with confidence in
   the range [0.75, 0.85], produced PERMIT outcomes at a rate of 0.83
   in BOOKING_SUSPENDED transitions.  IDPs that cited only Zone A
   state data, with confidence > 0.90, produced PERMIT outcomes at a
   rate of 0.61 -- suggesting that overconfidence without Zone B
   corroboration is a consistent failure pattern in this action class.

   This is the cross-operator equivalent of RETRY_CONTINUATION: the
   agent learns from the collective denied attempts of agents across
   the federation, not just its own session history.

   The Reasoning Pattern Library does not prescribe what an agent must
   declare.  The IDP is the agent's own reasoning declaration; Cedar
   evaluates authority.  The Library is a voluntary reference that
   informs REASON and PLAN steps [I-D.sato-soos-aep] without
   constraining them.

4.3.  Use Case 2 -- Federated PT Score Contextualization

   A human principal reviewing a PT Recommendation for their agent
   currently sees the agent's scores in isolation.  A SAS score of
   0.78 is high or low relative to what?  Relative to a theoretical
   maximum?  Relative to the operator's other agents?

   FAIP Behavioral Benchmarks answer this question with empirical
   federation data.  The PT Recommendation can state: this agent's
   SAS score of 0.78 is at the 71st percentile of all agents in the
   FAIP Federation operating on the same SO Type.  Its JS score of
   0.91 is at the 94th percentile.  Its ES score of 0.67 is at the
   43rd percentile -- below the federation median for this SO Type,
   which warrants attention before any authority elevation.

   This contextualization does not change the PT scoring model.  It
   adds a reference frame that makes the scores actionable for human
   principals who lack the federation-wide context to interpret them
   in isolation.

4.4.  Use Case 3 -- Systemic Risk Detection

   Individual operators cannot observe systemic patterns.  An operator
   whose agents are consistently failing to achieve goal completion on
   a specific SO Type transition sequence may attribute this to their
   own agents or their own Cedar policy configuration.  They cannot
   know whether the same pattern is occurring across the federation.

   FAIP's Systemic Signal Layer aggregates these patterns.  When a
   Cedar action class shows anomalous DENY rates across multiple
   operators simultaneously -- rates that exceed the federation
   baseline by more than a configurable threshold -- the FAIP
   Federation generates a Systemic Signal alert.

   Systemic Signals are not attributed to any operator.  They identify
   the pattern (Cedar action class, SO Type state, approximate onset
   time) without identifying which operators are affected.  An operator
   receiving a Systemic Signal knows that the pattern is not unique to
   their deployment, can calibrate their response accordingly, and
   can contribute their anonymized resolution data to the federation
   once the issue is addressed.

   The Systemic Signal Layer is the protocol-level equivalent of
   coordinated vulnerability disclosure for behavioral AI governance
   failures: a mechanism for the federation to identify and surface
   systemic issues without requiring any operator to expose their
   operational details.

4.5.  Use Case 4 -- SO Type Behavioral Benchmarks

   When a new SO Type is registered -- a new domain, a new industry,
   a new class of governed process -- operators deploying agents for
   that SO Type have no behavioral baseline.  PT scores for new SO
   Types start at the baseline (0.5 for all dimensions) and must
   accumulate from zero.

   FAIP Behavioral Benchmarks for SO Types allow operators to observe
   how agents in the federation are performing on similar SO Types
   from the moment of deployment.  An operator deploying agents for
   a new SO Type in the healthcare domain can reference the federation
   benchmark for the nearest comparable SO Type to calibrate initial
   Cedar policy, mandate ceiling, and agent class assignments.

   This use case is particularly valuable for SO Types that share
   structural properties -- similar state machine topology, similar
   Cedar action namespaces -- even when they operate in different
   domains.  The behavioral patterns that produce reliable governance
   outcomes for complex multi-state SO Types transfer across domains
   in ways that individual operator experience cannot reveal.


5.  What FAIP Does Not Do

   To be unambiguous about FAIP's scope, this section states what
   FAIP explicitly does not do.  These are not limitations to be
   resolved in future versions.  They are design boundaries that
   MUST be preserved in all FAIP successor specifications.

   FAIP does not share session records.  No individual AEP Session
   record, Session Audit Record, or Event Stream entry is transmitted
   to the FAIP Federation.  Only anonymized behavioral aggregates
   cross operator boundaries.

   FAIP does not share personal data.  Zone A Invariant INV-ZA-1
   [I-D.sato-soos-sov] prohibits personal data in Zone A.  Zone B
   content is never included in FAIP contributions.  The behavioral
   signals FAIP aggregates -- Cedar action outcomes, confidence
   values, PT Dimension signals -- contain no personal data by
   construction.

   FAIP does not share proprietary business logic.  The Cedar policy
   sets, SO Type definitions, and operational configurations of
   participating operators are not exposed to the federation.  Only
   the behavioral outcomes of Cedar evaluation -- PERMIT or DENY,
   with the Cedar action class and SO Type state as context -- are
   contributed.

   FAIP does not share agent identity.  No agent_id, agent_provider_id,
   or any identifier that could be linked to a specific agent or
   operator appears in any FAIP contribution.  Agents are represented
   by anonymized behavioral profiles aggregated to the federation
   minimum k-anonymity threshold.

   FAIP does not train foundation models.  FAIP behavioral intelligence
   is available to agents through the FAIP query interface during PLAN
   steps and to human principals through the ProgressiveTrustSummary
   context.  It is not a training dataset.  It does not modify the
   weights of any foundation model.  The improvement pathway FAIP
   enables is operational -- better governed behavior through access
   to collective behavioral intelligence -- not architectural.

   FAIP does not create a central repository.  The FAIP Federation
   is a distributed network of FAIP Nodes.  No single node holds the
   complete ABL.  The federation topology (specified in successor
   documents) is designed to distribute both the data and the
   governance such that no single participant -- including the FAIP
   Federation trust anchor -- can access the complete corpus of
   contributing records.


6.  The Privacy Architecture

6.1.  Data Residency as the Primary Control

   The data_residency field in the IDP [I-D.sato-soos-idp] Section 4.2
   is the per-record control that determines whether a session's
   behavioral signals may be contributed to FAIP.

   The relevant field is tier3_eligible: a boolean that MUST be
   declared at session creation time and MUST NOT be changed
   retroactively.  An IDP record with tier3_eligible: false MUST NOT
   contribute behavioral signals to any Tier 3 aggregation.

   Data residency jurisdiction constraints apply even when tier3_
   eligible is true.  A behavioral signal from a session whose
   data_residency.jurisdiction is "JP" (Japan) MUST NOT be processed
   in, or released to query responses served from, jurisdictions
   with which Japan has incompatible data transfer restrictions,
   unless the relevant regulatory determination has been made that
   anonymized behavioral aggregates are outside the scope of those
   restrictions.

6.2.  K-Anonymity Enforcement

   Every aggregate released by a FAIP Node to the federation MUST
   satisfy k-anonymity at minimum k=50.  This means that any released
   aggregate is derived from at least 50 distinct contributing session
   records, each with distinct agent identities.

   The k=50 minimum is a floor.  FAIP Federation governance may set
   higher k values for specific Cedar action classes or SO Type
   categories that carry higher re-identification risk.

   K-anonymity is enforced at the FAIP Node before any aggregate is
   transmitted.  A FAIP Node that cannot satisfy k-anonymity for a
   requested aggregate MUST NOT release that aggregate.  It MUST
   return a K_ANONYMITY_THRESHOLD_NOT_MET response, which is itself
   informative: it indicates that the federation has insufficient
   data for that specific combination of SO Type, Cedar action class,
   and state, which is itself a useful signal to operators.

6.3.  Differential Privacy Considerations

   K-anonymity is a necessary but not sufficient privacy protection
   for all FAIP use cases.  For Systemic Signal detection and
   Behavioral Benchmark release, differential privacy mechanisms
   SHOULD be applied in addition to k-anonymity.

   The specific differential privacy algorithm and epsilon parameter
   for each FAIP output type are specified in successor documents.
   This document establishes only the normative requirement: FAIP
   successor specifications MUST include differential privacy analysis
   for all Systemic Signal and Behavioral Benchmark outputs.

6.4.  The Non-Suppressibility Guarantee

   FAIP behavioral intelligence derives its epistemic value from the
   non-suppressibility of its source records.  An IDP that declares
   tier3_eligible: true is contributing to FAIP from a GEC-signed,
   append-only Event Stream entry.  That entry cannot be modified
   after commitment.  The agent cannot revise its contribution to
   make its behavior appear better than it was.

   This is what distinguishes FAIP from conventional federated
   learning or benchmark aggregation systems, where participants can
   choose which records to contribute and may have incentives to
   contribute selectively.  In FAIP, the GEC determines what is
   contributed based on the tier3_eligible flag set at session
   creation.  The agent and the operator have no mechanism to
   selectively suppress unfavorable records after the fact.

   The non-suppressibility guarantee is inherited from Event Stream
   invariant INV-1 [I-D.sato-soos-sov] Section 4.2.3: Event Stream
   entries are append-only and MUST NOT be modified or removed after
   commitment.


7.  FAIP Federation Model

7.1.  Participation

   Participation in a FAIP Federation is voluntary.  An operator
   participates by:

   (a) Deploying a FAIP Node as part of their GEC infrastructure.

   (b) Accepting the FAIP Federation governance terms, including the
       data residency policy, k-anonymity enforcement requirements,
       and audit obligations.

   (c) Signing a FAIP Participation Agreement that records the
       operator's identity, their FAIP Node endpoint, their
       contributing SO Type set, and their data residency constraints.

   (d) Submitting to periodic FAIP Node conformance audits conducted
       by the FAIP Federation trust anchor.

   Operators may participate as contributors (providing behavioral
   signals to the federation), consumers (querying the ABL), or both.
   Participation terms for contributor-only and consumer-only
   membership are defined in FAIP Federation governance documents.

7.2.  FAIP Node

   A FAIP Node is a participating operator's FAIP endpoint.  It is
   responsible for:

   (a) Extracting tier3_eligible behavioral signals from the
       operator's GEC Event Streams.

   (b) Anonymizing and aggregating those signals to satisfy
       k-anonymity before transmission.

   (c) Enforcing data residency constraints on outbound signals.

   (d) Receiving ABL query responses from the federation.

   (e) Making ABL intelligence available to the operator's agents
       (during PLAN steps via the GEC Query Interface) and human
       principals (via ProgressiveTrustSummary context).

   (f) Maintaining a FAIP Node Audit Log: a tamper-evident record
       of all contributions made to and queries received from the
       federation, available to the FAIP Federation trust anchor
       for conformance auditing.

   A FAIP Node MUST be operated by, or under the direct control of,
   a participating operator.  The FAIP Federation trust anchor MUST
   NOT have direct access to any operator's GEC Event Stream.

7.3.  Federation Topology

   The FAIP Federation topology -- the network architecture through
   which FAIP Nodes exchange contributions and query the ABL -- is
   not specified in this -00 document.  The topology specification
   in successor documents MUST satisfy the following normative
   requirements established here:

   (a) No single node may hold the complete Aggregate Behavioral
       Library.  The ABL MUST be distributed across the federation.

   (b) The FAIP Federation trust anchor MUST NOT have access to any
       individual FAIP Node's unaggregated contribution data.  The
       trust anchor's role is governance and conformance auditing,
       not data aggregation.

   (c) The topology MUST be resilient to the departure of any single
       FAIP Node, including the trust anchor, without loss of the ABL.

   (d) The topology MUST support jurisdictionally-bounded sub-
       federations: groups of FAIP Nodes that exchange intelligence
       only within a defined jurisdictional boundary, while still
       participating in the broader federation for intelligence that
       is not jurisdiction-constrained.

7.4.  Trust Anchor

   The FAIP Federation trust anchor is the entity responsible for:

   (a) Maintaining the FAIP Participation Agreement registry.

   (b) Certifying FAIP Node conformance to this specification and
       its successors.

   (c) Governing the federation's k-anonymity parameters, data
       residency policies, and participation terms.

   (d) Revoking FAIP Node participation for conformance violations.

   The trust anchor is not a data processor.  It does not hold,
   access, or process any FAIP behavioral signal data.  Its authority
   is governance, not data custody.

   The ATP Foundation (activity-travel-protocol.org) serves as the
   trust anchor for the initial FAIP Federation covering ATP Booking
   Object SO Types.  The trust anchor role for broader SO Type
   categories is a governance question to be resolved in the FAIP
   Federation governance specification.


8.  FAIP and the IDP Data Residency Field

   The IDP data_residency sub-object [I-D.sato-soos-idp] Section 4.2
   is the technical mechanism by which per-session FAIP eligibility
   is declared and enforced.  This section clarifies the relationship.

   The relevant fields are:

   tier3_eligible (boolean):
      MUST be set at session creation time.  If true, this session's
      behavioral signals (Cedar action outcomes, confidence values,
      PT Dimension signals) are eligible for FAIP Tier 3 aggregation.
      MUST NOT be changed retroactively.  Default: false.

   jurisdiction (string):
      The jurisdictional data residency constraint for this record.
      Controls which FAIP Nodes and sub-federations may process
      this session's signals.  Expressed as an ISO 3166-1 alpha-2
      country code or a defined regional grouping (e.g., "EU-EEA").

   retention_days (integer):
      The maximum retention period for this session's records.
      FAIP contributions derived from this session MUST be withdrawn
      from the ABL when the contributing record's retention period
      expires.  The mechanism for retroactive withdrawal from
      aggregated data is specified in successor documents.

   The data_residency field is set by the operator at session
   creation.  It cannot be set by the agent.  An agent MUST NOT
   be able to elevate its own tier3_eligible status.


9.  Relationship to Progressive Trust

   FAIP and Progressive Trust [I-D.sato-soos-pt] are complementary
   specifications at adjacent tiers.

   PT operates within a single operator's domain (Tier 2).  It
   computes behavioral trust scores from the operator's own GEC Event
   Streams.  PT scores are used to route agent task assignments,
   inform HEM decisions, generate authority evolution recommendations,
   and support post-incident forensics -- all within the operator's
   trust domain.

   FAIP operates across operators (Tier 3).  It aggregates the
   behavioral signals that feed PT Dimension scores across the
   federation to produce the Behavioral Benchmarks that contextualize
   any single operator's PT scores.

   The relationship creates a two-level trust intelligence system:

   Operator level (PT):  This agent's SAS score is 0.78.
   Federation level (FAIP):  An SAS score of 0.78 is at the 71st
                              percentile for agents on this SO Type
                              across the federation.

   Neither level is complete without the other.  PT scores without
   federation context are difficult for human principals to interpret.
   FAIP benchmarks without operator-level PT scores have no individual
   referent.

   FAIP also extends the PT trust decay model to the federation
   level.  An SO Type that has not received tier3_eligible
   contributions in a rolling 90-day window has a stale Behavioral
   Benchmark.  Stale benchmarks MUST be flagged as such in all
   FAIP query responses.  The decay principle that governs PT Dimension
   scores at the operator level -- trust must be maintained through
   continued demonstration, not banked indefinitely -- applies equally
   to the federation's aggregate intelligence.


10.  Relationship to Other SOOS Drafts

   IDP [I-D.sato-soos-idp]:
      The IDP data_residency field (Section 4.2) is the per-record
      FAIP eligibility control.  The three-tier analytics model
      (Section 3.5) is the architectural framework FAIP completes.
      The RETRY_CONTINUATION reasoning basis type is the Tier 1
      mechanism that FAIP extends to Tier 3 via the Reasoning Pattern
      Library: agents learn from the collective denied attempts of
      federation agents, not just their own session history.

   PT [I-D.sato-soos-pt]:
      PT is the Tier 2 specification.  FAIP is the Tier 3 specification.
      FAIP Behavioral Benchmarks provide the federation context that
      makes PT scores interpretable.  The PT Dimension signal events
      (SAS, JS, ES, PS, AS) are the primary FAIP contribution unit.

   AEP [I-D.sato-soos-aep]:
      The PLAN step GEC Query Interface [I-D.sato-soos-aep] Section 7
      is the mechanism through which agents access FAIP intelligence
      during session execution.  The Reasoning Pattern Library is
      accessed during PLAN, informing the agent's ACT step without
      constraining it.

   SOV [I-D.sato-soos-sov]:
      Zone A Invariant INV-ZA-1 -- personal data MUST NOT be stored
      in Zone A -- is the architectural property that makes FAIP
      possible.  Because Zone A contains only identifiers, state
      references, and policy-relevant metadata, the Event Stream
      entries that FAIP aggregates contain no personal data by
      construction.  FAIP is built on this invariant.

   GAR [I-D.sato-soos-gar]:
      FAIP Node Audit Logs are subject to GAR audit principles:
      append-only, GEC-signed, non-suppressible.  A Verified External
      Auditor may review a FAIP Node's contribution history to verify
      that tier3_eligible sessions were correctly contributed and that
      k-anonymity thresholds were enforced before transmission.

   MJWT [I-D.sato-soos-mjwt]:
      Access to FAIP query interfaces is governed by Cedar policy and
      requires a valid Mandate JWT with the appropriate Cedar action
      scope for FAIP queries.  The FAIP Cedar action namespace is
      defined in successor documents.


11.  Scope of This Document and Future Work

   This -00 document establishes the FAIP architecture, claims the
   Tier 3 analytics space in the SOOS protocol family, and defines
   the normative boundaries within which all FAIP successor
   specifications must operate.

   The following are explicitly deferred to successor documents:

   FAIP Query Interface Specification:
      The normative API through which agents (at PLAN step) and
      Analytics Principals query the Aggregate Behavioral Library.
      Request and response schemas, authentication, rate limiting,
      and caching semantics.

   Aggregation Algorithm Requirements:
      The normative requirements for how FAIP Nodes aggregate
      behavioral signals before federation contribution.  Differential
      privacy algorithm selection, epsilon parameter ranges, and
      sensitivity analysis for each output type.

   Federation Topology Protocol:
      The network protocol through which FAIP Nodes exchange
      contributions and respond to queries.  Node discovery,
      contribution routing, ABL consistency model, and sub-federation
      boundary enforcement.

   FAIP Governance Specification:
      The governance model for the FAIP Federation: trust anchor
      responsibilities, participation agreement template, conformance
      audit procedures, and federation membership lifecycle.

   Retroactive Withdrawal Protocol:
      The mechanism for withdrawing FAIP contributions when a
      contributing session's retention_days expires or when an
      operator withdraws from the federation.

   FAIP Cedar Action Namespace:
      The Cedar action namespace for FAIP query access control,
      enabling Cedar policies to govern which agents and principals
      may access which categories of ABL intelligence.

   This document's primary contribution is architectural: it defines
   what FAIP is, what it produces, what it explicitly does not do,
   and the privacy framework within which it must operate.  These
   boundaries are normative and MUST be preserved in all successor
   specifications.


12.  Security Considerations

   FAIP Federation integrity.  The value of the Aggregate Behavioral
   Library depends on the integrity of its contributing records.  A
   FAIP Node that contributes fabricated behavioral signals -- falsely
   claiming high PT Dimension signals that were not generated by actual
   governed sessions -- degrades the ABL for all federation members.
   FAIP Federation conformance audits MUST verify contributing FAIP
   Nodes' Audit Logs against their GEC Event Streams.  Fabricated
   contributions constitute a conformance violation and MUST result in
   FAIP Node revocation.

   K-anonymity gaming.  An operator who controls many FAIP Nodes
   could potentially synthesize k-anonymity-satisfying contributions
   that are not genuinely diverse.  The FAIP Federation trust anchor
   MUST enforce diversity requirements on contributions: signals from
   a single operator MUST NOT constitute more than 1/k of any
   released aggregate.  This prevents any single operator from
   dominating the ABL for specific SO Type and Cedar action class
   combinations.

   Query correlation attacks.  A sequence of FAIP queries with
   progressively narrowed parameters could allow a querying party to
   infer information about specific operators or sessions below the
   k-anonymity threshold.  FAIP query interface specifications
   (successor documents) MUST include rate limiting, query diversity
   requirements, and correlation attack detection.

   Trust anchor compromise.  The FAIP Federation trust anchor has
   governance authority over the federation.  A compromised trust
   anchor cannot access session data (the topology design requirement
   in Section 7.3 prevents this) but could falsely certify
   non-conforming FAIP Nodes or revoke legitimate participants.
   FAIP governance specifications MUST include trust anchor key
   rotation procedures and governance oversight mechanisms.

   Non-suppressibility as a security property.  The non-
   suppressibility of FAIP contributions (Section 6.4) is not only a
   privacy and integrity property -- it is also a security property.
   An operator cannot suppress unfavorable behavioral signals after a
   security incident to avoid revealing that their agents were
   behaving anomalously before the incident.  The Systemic Signal
   Layer can detect pre-incident anomaly patterns even if the affected
   operator would prefer not to disclose them.


13.  Privacy Considerations

   FAIP is designed from first principles as a privacy-preserving
   protocol.  The privacy architecture (Section 6) is not a constraint
   added to a data-sharing protocol; it is the defining property that
   makes FAIP possible in a world where behavioral data is sensitive
   and cross-border data flows are increasingly restricted.

   The key privacy properties are:

   No personal data in contributions.  Zone A Invariant INV-ZA-1
   ensures that the behavioral signals FAIP aggregates contain no
   personal data.  This is an architectural guarantee, not a
   contractual commitment.

   Operator consent via tier3_eligible.  No session's behavioral
   signals are contributed to FAIP without the operator explicitly
   setting tier3_eligible: true at session creation.  Operators who
   do not wish to participate in FAIP simply do not set this flag.
   Default is false.

   Data residency jurisdiction enforcement.  Behavioral signals
   respect the jurisdiction constraints declared in their source IDP
   records.  Cross-border signal flows are blocked at the FAIP Node
   level before transmission.

   K-anonymity as minimum guarantee.  The k=50 minimum ensures that
   no released aggregate is traceable to fewer than 50 distinct
   contributing sessions.  Combined with the operator diversity
   requirement (no single operator constitutes more than 1/k of any
   aggregate), this provides re-identification resistance at both the
   session and operator level.

   Right to withdraw.  An operator may withdraw from the FAIP
   Federation.  The retroactive withdrawal protocol (deferred to
   successor documents) specifies how previously contributed signals
   are removed from the ABL over the federation's propagation period.
   The non-suppressibility requirement applies to the Event Stream,
   not to the ABL; withdrawal is a legitimate federation governance
   operation, not a violation of non-suppressibility.


14.  IANA Considerations

14.1.  FAIP Event Type Registry

   Registry name: SOOS Federated Agent Intelligence Protocol Event
                  Type Registry
   Registration procedure: Specification Required.

   Initial registrations: None.  Initial event types are specified
   in FAIP successor documents.

14.2.  FAIP Node Status Registry

   Registry name: SOOS Federated Agent Intelligence Protocol Node
                  Status Registry
   Registration procedure: Specification Required.

   Initial registrations: None.  Initial status values are specified
   in the FAIP Federation Governance specification.

14.3.  FAIP Cedar Action Namespace

   This document requests that IANA reserve the Cedar action namespace
   prefix "faip:" for FAIP query access control actions.  Specific
   action definitions are specified in FAIP successor documents.


15.  References

15.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, May 2017.

   [RFC9562]  Davis, B., Peabody, C., and P. Leach, "Universally
              Unique IDentifiers (UUIDs)", RFC 9562, May 2024.

   [Cedar]    Amazon Web Services, "Cedar Policy Language
              Specification", https://docs.cedarpolicy.com/

   [I-D.sato-soos-idp]
              Sato, T., "The Intent Declaration Primitive (IDP) for
              Agentic AI Systems", draft-sato-soos-idp-03, May 2026.

   [I-D.sato-soos-hem]
              Sato, T., "The Human Escalation Mechanism (HEM) for
              Agentic AI Systems", draft-sato-soos-hem-01, May 2026.

   [I-D.sato-soos-gar]
              Sato, T., "Governance Audit Record (GAR) for Agentic
              AI Systems", draft-sato-soos-gar-01, May 2026.

   [I-D.sato-soos-cap]
              Sato, T., "Constitutional AI Protocol (CAP) for Agentic
              AI Systems", draft-sato-soos-cap-00, May 2026.

   [I-D.sato-soos-sov]
              Sato, T., "The Sovereign Object (SOV) for Agentic AI
              Systems", draft-sato-soos-sov-00, May 2026.

   [I-D.sato-soos-mjwt]
              Sato, T., "The Mandate JWT (MJWT) for Agentic AI
              Systems", draft-sato-soos-mjwt-00, May 2026.

   [I-D.sato-soos-aep]
              Sato, T., "The Agent Execution Protocol (AEP) for
              Agentic AI Systems", draft-sato-soos-aep-00, May 2026.

   [I-D.sato-soos-pt]
              Sato, T., "Progressive Trust (PT) for Agentic AI
              Governance Systems", draft-sato-soos-pt-00, May 2026.

   [GDPR]     European Parliament, "General Data Protection
              Regulation", Regulation (EU) 2016/679, April 2016.

   [APPI]     Government of Japan, "Act on the Protection of Personal
              Information", Act No. 57 of 2003, as amended.

15.2.  Informative References

   [I-D.sato-soos-mad]
              Sato, T., "Multi-Agent Delegation (MAD) for Agentic
              AI Systems", draft-sato-soos-mad-00, forthcoming.

   [I-D.sato-soos-kia]
              Sato, T., "Kernel Identity and Attestation (KIA) for
              Agentic AI Systems", draft-sato-soos-kia-00, forthcoming.

   [I-D.ietf-scitt-architecture]
              Birkholz, H., et al., "An Architecture for Trustworthy
              and Transparent Digital Supply Chains",
              draft-ietf-scitt-architecture, work in progress.

   [I-D.ietf-wimse-arch]
              Salomoni, D., et al., "WIMSE Architecture",
              draft-ietf-wimse-arch, work in progress.

   [EUAIA]    European Parliament, "Artificial Intelligence Act",
              Regulation (EU) 2024/1689, June 2024.


Appendix A.  The Institutional Analogy

   FAIP is not the first attempt to derive aggregate signal from
   distributed individual records while protecting individual privacy.
   Understanding its historical analogues clarifies both what it
   achieves and why it is genuinely novel.

   National census systems aggregate individual demographic records
   into population statistics.  The individual record is protected;
   the aggregate is public.  FAIP does the same for governed agent
   behavioral records.  The difference: census data is self-reported
   and collected periodically.  FAIP data is cryptographically
   signed, non-suppressible, and continuously generated.

   Financial market data systems aggregate individual transaction
   records into price signals, volume data, and market statistics.
   Individual trades are protected; market signals are public.  FAIP
   does the same for governed agent behavioral transactions.  The
   difference: market data is often delayed, can be selectively
   reported, and is subject to manipulation.  FAIP contributions
   are non-suppressible by design.

   Medical research registries aggregate patient outcome data into
   clinical intelligence.  Individual patient records are protected
   by consent and anonymization; aggregate clinical signals are
   published.  FAIP does the same for governed agent outcome records.
   The difference: medical registries rely on consent at the patient
   level and institutional trust at the researcher level.  FAIP
   relies on the GEC's non-suppressible Event Stream and protocol-
   level k-anonymity enforcement.

   What is genuinely novel about FAIP is the combination: behavioral
   evidence that is cryptographically signed and non-suppressible at
   the individual record level, aggregated under formal privacy
   guarantees at the federation level, and governed by the same Cedar
   policy framework that governs the agents whose behavior produced it.
   No census, no financial data system, and no medical registry has
   all three properties simultaneously.

   FAIP is the first protocol specification for this combination.


Author's Address

   Tom Sato
   MyAuberge K.K.
   Chino, Nagano, Japan
   Email: tomsato@myauberge.jp
   URI:   https://activitytravel.pro/
