]> Cisco Meraki

albisht@cisco.com

Web and Internet Transport AI Preferences AI preferences realtime communications SIP media control This document defines how Artificial Intelligence (AI) preference expressions are bound to signaling and media protocols used for real-time, session-based communications such as the Session Initiation Protocol (SIP) and associated Session Description Protocol (SDP) offers. It specifies a reusable binding model, concrete SIP header field conventions, and SDP attributes that allow endpoints, intermediary services, and AI assistants to advertise, negotiate, and enforce requirements about AI-driven processing of session metadata, media control events, and telemetry. The goal is to align real-time protocol behavior with the AI Preferences (AIPREF) vocabulary without disrupting existing call control semantics. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the AI Preferences Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction Real-time communications (RTC) deployments are increasingly assisted by AI-driven components that evaluate signaling metadata, media control messages, and quality of experience (QoE) measurements. Examples include AI-based call routing, automated troubleshooting, adaptive encoding, or compliance monitoring. When these components operate on user or service provider data, the AI Preferences (AIPREF) working group requires that stakeholders can express and enforce preferences that describe what AI systems may inspect, retain, or export. Existing AIPREF documents define preference vocabularies and repository behavior, but do not specify how those preferences are conveyed through session control protocols. This document fills that gap for SIP-based systems and applies the same pattern to other RTC bindings that reuse SIP constructs (including SIP events, PUBLISH, and WebRTC gateways). The binding guidance is protocol-agnostic where possible so that additional RTC protocols (such as XMPP Jingle or proprietary session controllers) can follow the same pattern.

Goals The binding framework MUST:

1. Preserve backwards compatibility with SIP user agents, gateways, and middleboxes that are unaware of AI preference signaling.
2. Permit endpoints and administrative domains to advertise locally enforced AI policies and to consume peer policies before AI processing begins.
3. Support mid-dialog updates so that AI processing can adapt when session context changes (e.g., escalation from audio to video, invoking transcription services, or triggering automated remediation workflows).
4. Allow binding of AI preferences to both signaling-layer artifacts (message bodies, header fields, event packages) and media-layer descriptions (SDP attributes, record routes, and telemetry streams).

Scope This document describes:

• A binding model that maps AIPREF vocabulary elements to SIP dialog state and SDP descriptions.
• A compact token and URI-based encoding carried in SIP header fields and bodies.
• Procedures for preference discovery, negotiation, and error handling across dialogs, subscriptions, and conferencing primitives.
• Operational recommendations for intermediaries, policy servers, and AI enforcement points.

This document does not standardize AI algorithms, privacy-preserving enforcement techniques, or the semantics of individual AIPREF vocabularies beyond referencing existing definitions in other working group documents such as and .

Requirements Language 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 when, and only when, they appear in all capitals, as shown here.

Terminology The terminology defined in RFC3261, RFC3264, and the AIPREF framework documents applies. This document additionally uses the following conventions:

• AI Preference Token (APT): A compact, possibly signed representation of one or more AIPREF statements, retrievable via URI or carried inline.
• Preference Attacher: The SIP entity that injects an APT into signaling or SDP (e.g., originating user agent, outbound proxy, or application server).
• Preference Enforcement Point (PEP): A network element or AI component that validates and enforces APT requirements prior to processing protected data.
• Real-Time Preference Channel: Any mechanism that conveys updated APTs after a dialog is established (e.g., re-INVITE, UPDATE, INFO, SUBSCRIBE/NOTIFY pair).

Binding Requirements The following requirements guide bindings for SIP and related RTC protocols:

• Visibility: APTs SHOULD be visible to the entities that are expected to enforce them, including downstream AI assistants. When hop-by-hop protection (e.g., TLS) is applied, intermediaries outside the trust domain MUST NOT rely on APTs they cannot validate.
• Integrity: APTs SHOULD be signed or integrity-protected when transported across untrusted proxies to prevent unauthorized downgrades.
• Idempotency: Repeated delivery of identical APTs MUST NOT cause state divergence. Implementations MAY treat the most recent valid APT as authoritative.
• Granularity: Bindings MUST allow preferences scoped to dialogs, media sections, or individual features (e.g., telemetry streams, AI feature lists). APTs therefore include target metadata identifying the scope (dialog-id, media mid, or subscription identifier).
• Fallback: Endpoints that cannot satisfy received preferences MUST reject or redirect the request using standard SIP procedures (e.g., 488 Not Acceptable Here) and SHOULD include diagnostic information.

Binding Model The model in illustrates how preferences flow through RTC signaling.

APT flow from originator through SIP/SDP binding to enforcement | SIP / SDP |--------->| Enforcement | | Originator | | Binding | | Point / AI | +----------------+ +----------------+ +----------------+ ^ | | | Publish / Fetch | Dialog signaling | Media / Data +-------------------------+----------------------------+ ]]>

1. An originator (user agent, operator policy engine, or regulator) issues an APT identifier or token.
2. The preference attacher embeds the token using one or more bindings defined in this document.
3. Enforcement points inside AI workloads retrieve, validate, and apply the referenced constraints before consuming protected data.

Bindings MUST reference the same canonical APT identifier when expressing preferences across signaling and media layers to avoid ambiguity. shows how dialog-scoped and media-scoped bindings share one APT identity.

Shared APT identity across SIP header and SDP attributes

SIP Signaling Binding

AI-Pref Header Field This document defines the AI-Pref SIP header field. Each instance conveys metadata that allows receivers to retrieve or validate an APT. AI-Pref = "AI-Pref" HCOLON pref-value *(COMMA pref-value) pref-value = pref-id *(SEMI pref-param) pref-id = token / quoted-string ; identifier or opaque token pref-param = ("scope" EQUAL token) / ("type" EQUAL token) / ("version" EQUAL 1*DIGIT) / ("integrity" EQUAL token) / ("uri" EQUAL LAQUOT absoluteURI RAQUOT)

Usage Rules shows a representative call flow for advertising and confirming AI-Pref during dialog establishment and a mid-dialog update.

SIP call flow with AI-Pref on INVITE, response, and mid-dialog UPDATE |------ INVITE AI-Pref ------->| | (scope=dialog) | | | |<----- 183/200 AI-Pref -------| |<------ 183/200 AI-Pref ------| (domain policies) | | | | |------------- ACK / PRACK (echo accepted APT ids) ---------->| | | | |======= early / confirmed media + AI enforcement ============| | | | |------ UPDATE AI-Pref ------->|------ UPDATE AI-Pref ------->| | (e.g., enable transcription | | | scope change) |<----- 200 OK AI-Pref --------| |<----- 200 OK AI-Pref --------| | ]]>

1. Initial INVITE: The originating user agent client (UAC) SHOULD include an AI-Pref header referencing all preferences that govern AI handling of dialog metadata or media diagnostics. The header MAY appear multiple times when different scopes are advertised (e.g., scope=dialog, scope=media).
2. Provisional Responses: Proxies and user agent servers (UAS) MAY add AI-Pref headers to responses in order to enumerate additional policies that downstream AI components MUST accept before the session is confirmed.
3. ACK and PRACK: These messages MUST echo the latest accepted AI-Pref identifiers when the UAS requires confirmation. Absence of AI-Pref in ACK implies acceptance of the most recent set.
4. Mid-Dialog Updates: Re-INVITE and UPDATE requests MUST include AI-Pref whenever the preference scope of any media stream is modified. This allows AI systems that adapt encoders, perform transcription, or modify layouts to obey updated constraints.
5. SUBSCRIBE/NOTIFY: Event packages (e.g., dialog package, KPML, presence) MAY carry AI-Pref headers so that AI assistants consuming event payloads adhere to the advertised constraints.

Compact Tokens and URIs pref-id values can represent:

• Inline tokens that encode the full preference statement (e.g., CBOR Web Token referencing vocabulary keys).
• Handles that require dereferencing via HTTPS using the uri parameter.
• Versioned identifiers that map to entries in a policy repository.

Receivers MUST treat unknown parameters according to RFC3261 rules (ignore them) and MUST NOT assume that the absence of AI-Pref implies permission to process data without AI constraints.

Error Handling

• If a UAS cannot comply with mandatory preferences, it SHOULD reply with 488 Not Acceptable Here and include a Warning header value of 399 aipref "Preference unsupported".
• When integrity verification fails, the recipient SHOULD respond with 403 Forbidden and MAY include diagnostic details in a Reason header referencing AI-Integrity-Failure.
• Gateways that strip AI-Pref MUST insert a History-Info entry explaining the removal so downstream entities understand why enforcement data is missing.

SIP Body Considerations When APTs are too large for header fields, this document RECOMMENDS embedding them inside a multipart body part with media type application/aipref+json or application/aipref+cbor and referencing that part via Content-ID. This allows richer metadata (e.g., signed manifests) without overloading SIP header processing.

SDP and Media Binding

a=aipref Attribute An SDP media description MAY include one or more a=aipref attributes, each binding a specific media stream to an APT identifier. a=aipref:<scope> <identifier> [<parameter>=<value> ...] Valid scopes include session, group, and mid. Parameters align with the AI Pref vocabulary, for example:

• features=media-metrics,rtcp-xr
• retention=24h
• export=aggregated-only

Endpoints MUST ensure that SDP attributes remain consistent with SIP-level AI-Pref headers. If SDP renegotiation removes an attribute, the corresponding AI processing MUST stop or transition to the remaining allowed scope.

RTP Control and Telemetry RTP control protocols such as RTCP, RTCP XR, and RTP/RTCP extensions for feedback may carry AI-relevant telemetry. Implementations SHOULD map telemetry streams to the same APT identifiers declared in SDP by including the identifier in RTCP SDES items or header extensions defined for this purpose. When that is not feasible, implementations MAY rely on the dialog-level AI-Pref scope while documenting the implicit association.

Preference Discovery and Synchronization

Retrieval via HTTPS Preferences referenced via uri MUST be retrievable over HTTPS with mutual authentication when sensitive. Servers SHOULD support conditional requests and caching so intermediaries can reuse validated APTs across multiple dialogs.

Repository Interaction Policy repositories MAY expose a REST interface where clients submit dialog metadata (Call-ID, From-tag, To-tag) and receive the authoritative list of applicable APT identifiers. This pattern is especially useful for large conferencing services where centralized policy engines coordinate AI workloads.

Conflict Resolution {#conflict-resolution} When multiple APTs apply to the same resource, the following precedence rules apply unless a policy repository states otherwise:

1. User-specific preferences override domain defaults.
2. Domain-level regulatory requirements override individual relaxations.
3. The most restrictive constraint wins when two preferences conflict on the same vocabulary key.

summarizes the default evaluation order.

Default APT conflict-resolution precedence

Endpoints MAY advertise their conflict-resolution policy through the policy parameter inside AI-Pref headers (e.g., policy=strictest-wins).

Operational Considerations

• Logging: Preference attachers SHOULD log emitted APT identifiers alongside Call-ID values to support audits and incident response.
• Testing: Interoperability testing MUST verify that dialogs proceed when AI-Pref is absent, ensuring that legacy devices remain compatible.
• Scaling: Implementations SHOULD compress header fields using SIP over HTTP/3 (RFC9397) or similar transports when large preference sets are common.
• Federation: Peering domains MAY translate local preference identifiers into a shared namespace. Translation MUST NOT weaken constraints without explicit consent from the originator.

Security Considerations Preferences often contain sensitive information about user intent, regulatory exposure, or organizational policy. Therefore:

• Transport security such as TLS (for SIP over TLS, WebSocket, or HTTP/3) MUST be used whenever an AI-Pref header or body carries tokens that could be replayed or tampered with.
• APT signatures SHOULD be validated before AI systems act on the encapsulated instructions. Validation includes issuer authentication, expiration checks, and revocation status.
• Implementations MUST guard against downgrade attacks where a malicious intermediary strips AI-Pref headers. Techniques include SIPS-only routing, end-to-end integrity with S/MIME, or redundant signaling through policy repositories.
• Preference tokens SHOULD minimize personally identifiable information. Instead of embedding explicit user identifiers, use pseudonymous handles that map to access-controlled directories.
• Systems MUST treat AI enforcement failures as security incidents when they result in unauthorized data processing. Telemetry SHOULD be rate-limited to avoid revealing preference patterns to attackers probing the signaling fabric.

Privacy and End‑User Impact Considerations Real‑time and session‑oriented communication protocols (e.g., SIP, SDP, WebRTC, RTP/RTCP, QUIC‑RTC) directly mediate human‑to‑human interaction. Introducing AI‑usage preference signaling into these protocols therefore has immediate consequences for end users, including creators, participants, accessibility users, researchers, and the general public. This section outlines considerations necessary to ensure that AIPREF signaling in real‑time environments does not unintentionally restrict legitimate uses, undermine user autonomy, or create new privacy risks.

Impact on User Autonomy and Consent AI‑usage preferences expressed at the signaling or media layer may be interpreted as binding restrictions by downstream systems. Implementations MUST ensure that:

• Preferences are treated as expressions of intent, not as access‑control mechanisms.
• End users retain the ability to override platform‑imposed defaults when they are the originators of the content.
• Intermediaries (e.g., conferencing platforms, SIP proxies, TURN servers, media mixers) do not silently substitute or modify user‑provided preferences.

Because real‑time sessions often involve multiple participants, systems SHOULD provide clear and accessible mechanisms for users to understand what AI‑related preferences are being signaled on their behalf.

Avoiding Over‑Restriction of Beneficial Uses Real‑time communication is frequently used for accessibility (captioning, translation), education, archiving, and research. Overly broad or ambiguous preference categories—particularly those related to “AI Input” or “AI Training”—may unintentionally block beneficial, lawful, or expected uses. Implementations SHOULD:

• Distinguish between AI‑assisted user features (e.g., live transcription) and model‑building uses (e.g., training).
• Avoid treating a single preference (e.g., ai-input=n) as a blanket prohibition on all automated processing.
• Provide clear documentation on how preferences interact with accessibility features.

Preference categories defined in AIPREF vocabulary drafts (e.g., search, ai-input, ai-train / train-ai) SHOULD be interpreted narrowly and consistently. Category triggering MUST be based on observed processing behavior, not on product labels or marketing terms. In particular:

• Presentation of indexed session artifacts with links or short excerpts that direct participants to the source (for example, meeting-search hit lists) is evaluated under search when that vocabulary applies.
• Using retrieved session content as grounding or context for generated answers triggers the applicable inference/use category in addition to any search trigger.
• Updating model weights or other long-term model state from session content, interaction logs, or derived embeddings triggers train-ai (or a more specific training category when present).

When multiple categories are triggered, implementations MUST evaluate declared preferences for each triggered category and resolve conflicts using the precedence rules in . Appendix A provides a non-normative decision tree and edge-case matrix for classification consistency.

Transparency to Participants Real‑time sessions may involve dynamic negotiation (e.g., via SDP offer/answer). When AI‑usage preferences are conveyed:

• Endpoints SHOULD surface these preferences to human participants in a clear and non‑technical manner.
• Systems SHOULD indicate when preferences differ between participants or when intermediaries have applied additional constraints.
• If preferences affect session features (e.g., disabling transcription), participants SHOULD be notified.

Lack of transparency may create a chilling effect, where users avoid lawful or beneficial uses due to uncertainty.

Intermediary Handling and Privacy Leakage Signaling AI‑usage preferences at the session layer may inadvertently reveal information about user intent, content sensitivity, or organizational policy. For example, a preference of ai-train=n may imply that the content is proprietary or confidential. To mitigate this:

• Intermediaries MUST NOT add, remove, or alter AI‑usage preferences unless explicitly authorized by the originating endpoint.
• Preferences SHOULD be encrypted or integrity‑protected when carried in protocols that support such mechanisms (e.g., DTLS‑SRTP, QUIC).
• Implementations SHOULD avoid exposing preferences in logs, analytics, or telemetry unless necessary and with appropriate safeguards.

Compatibility with Archiving and Research Real‑time communication is often recorded for compliance, education, or archival purposes. AI‑usage preferences SHOULD NOT be interpreted as prohibiting:

• lawful archiving,
• time‑shifted review,
• accessibility processing, or
• research uses permitted by local law.

Where preferences do apply to stored recordings, systems SHOULD preserve the preferences alongside the stored media, consistent with the behavior defined in for HTTP representations.

Avoiding Platform‑Level Overreach Large communication platforms may be tempted to apply AI‑usage preferences globally on behalf of users. This can undermine user autonomy and distort the intent of AIPREF. Platforms SHOULD:

• Allow per‑participant and per‑stream preferences.
• Avoid applying organization‑wide defaults without clear user visibility.
• Provide APIs for endpoints to express their own preferences without mediation.

Interoperability and Open Ecosystem Considerations Real‑time protocols are used across diverse environments, including open‑source clients, small organizations, and global platforms. To avoid fragmentation:

• Preferences SHOULD be optional and non‑blocking.
• Absence of a preference MUST NOT be interpreted as consent.
• Implementations SHOULD follow the vocabulary and semantics defined in AIPREF drafts to ensure consistent interpretation across ecosystems.

IANA Considerations IANA is requested to perform the following actions.

SIP Header Field Registration Register the AI-Pref header field in the "Header Fields" sub-registry under "Session Initiation Protocol (SIP) Parameters" with the following values:

• Header Name: AI-Pref
• Compact Form: none
• Reference: This document

SDP Attribute Registration Register the aipref attribute in the "att-field (media level only)" registry defined by RFC4566 with the following values:

• Attribute name: aipref
• Type of attribute: media / session
• Subject to charset: no
• Purpose: Associates SDP media sections with AI preference tokens
• Reference: This document

Acknowledgments This work is informed by discussions within the AIPREF working group, including contributions on network privacy controls and media quality automation. Related vocabulary-boundary discussions (including search versus training overlap) also informed Appendix A.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document describes Session Initiation Protocol (SIP), an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences. [STANDARDS-TRACK] This document defines a mechanism by which two entities can make use of the Session Description Protocol (SDP) to arrive at a common view of a multimedia session between them. In the model, one participant offers the other a description of the desired session from their perspective, and the other participant answers with the desired session from their perspective. This offer/answer model is most useful in unicast sessions where information from both participants is needed for the complete view of the session. The offer/answer model is used by protocols like the Session Initiation Protocol (SIP). [STANDARDS-TRACK] This specification defines the new UPDATE method for the Session Initiation Protocol (SIP). UPDATE allows a client to update parameters of a session (such as the set of media streams and their codecs) but has no impact on the state of a dialog. In that sense, it is like a re-INVITE, but can be sent before the initial INVITE has completed. This makes it very useful for updating session parameters within early dialogs. This document describes an extension to the Session Initiation Protocol (SIP) defined by RFC 3261. The purpose of this extension is to provide an extensible framework by which SIP nodes can request notification from remote nodes indicating that certain events have occurred. Note that the event notification mechanisms defined herein are NOT intended to be a general-purpose infrastructure for all classes of event subscription and notification. This document represents a backwards-compatible improvement on the original mechanism described by RFC 3265, taking into account several years of implementation experience. Accordingly, this document obsoletes RFC 3265. This document also updates RFC 4660 slightly to accommodate some small changes to the mechanism that were discussed in that document. [STANDARDS-TRACK] RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document specifies a Session Description Protocol (SDP) grouping mechanism for RTP media streams that can be used to specify relations between media streams. This mechanism is used to signal the association between the SDP concept of "media description" and the Web Real-Time Communication (WebRTC) concept of MediaStream/MediaStreamTrack using SDP signaling. Informative References This document describes an extension to the Session Initiation Protocol (SIP). The purpose of this extension is to provide an extensible framework by which SIP nodes can request notification from remote nodes indicating that certain events have occurred. [STANDARDS-TRACK] This memo defines the Session Description Protocol (SDP). SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. [STANDARDS-TRACK] This document defines the Real-time Transport Protocol (RTP) payload format for packetization of Opus-encoded speech and audio data necessary to integrate the codec in the most compatible way. It also provides an applicability statement for the use of Opus over RTP. Further, it describes media type registrations for the RTP payload format. The WebRTC framework specifies protocol support for direct, interactive, rich communication using audio, video, and data between two peers' web browsers. This document specifies the non-media data transport aspects of the WebRTC framework. It provides an architectural overview of how the Stream Control Transmission Protocol (SCTP) is used in the WebRTC context as a generic transport service that allows web browsers to exchange generic data from peer to peer. Open Future Mozilla This document defines a vocabulary for expressing preferences regarding how digital assets are used by automated processing systems. This vocabulary allows for the declaration of restrictions or permissions for use of digital assets by such systems. Google Mozilla Content creators and other stakeholders might wish to signal their preferences about how their content might be consumed by automated systems. This document defines how preferences can be signaled as part of the acquisition of content in HTTP. This document updates RFC 9309 to allow for the inclusion of usage preferences.

Category Trigger Decision Tree and Edge-Case Matrix This appendix is non-normative. It helps implementers determine which AIPREF categories are triggered by observed behavior in real-time systems, then evaluate preferences for all triggered categories. It complements WG vocabulary discussion on search / train-ai boundary cases.

Decision Tree summarizes the behavior-based trigger flow; the numbered steps below match the diagram.

Non-normative category trigger decision flow trigger search | +-- used as grounding for generation? -- yes --> trigger inference/use | +-- updates model weights / long-term | model state? -------------------- yes --> trigger train-ai | v Evaluate preference for EACH triggered category | +-- conflicting outcomes? -- yes --> Conflict Resolution | v Effective result (allowed / disallowed / unknown) ]]>

1. Identify the operation performed on content:
   • Acquisition only (capture/store without a use decision)
   • Retrieval, indexing, or ranking for search presentation
   • Grounding or context injection for generated output
   • Model update or parameter adaptation
2. If the operation directs users to source locations via links and associated search content, trigger search.
3. If content is used as grounding or context to generate answers, trigger the applicable inference/use category.
4. If the operation updates model weights or long-term model state, trigger train-ai (or a more specific training category if present).
5. Evaluate declared preference values (allowed, disallowed, unknown) for every triggered category.
6. If outcomes differ across triggered categories, apply the combination and specificity rules in (strictest-wins unless a stated policy says otherwise).

Category trigger is behavior-based, not keyword-based. Labels in signaling artifacts are inputs to evaluation; triggering reflects what the system actually does with content.

Worked Examples

Example A: Search Snippet Only

• Behavior: index and retrieve recorded-session hits; show links or short snippets; no grounding; no model update
• Triggered categories: search
• Notes: if snippets remain within search presentation behavior, no train-ai trigger occurs

Example B: Search Plus Grounded Answer

• Behavior: retrieve session sources, then generate an assistant answer with grounded context and citations
• Triggered categories: search plus the applicable inference/use category
• Notes: primary overlap case; both preferences must be evaluated

Example C: Search Plus Continuous Learning

• Behavior: ranking or recommendation model updated from interaction logs derived from session content usage
• Triggered categories: search plus train-ai
• Notes: stress case for precedence when search is allowed but train-ai is disallowed

Edge-Case Matrix The following representative scenarios use expected effective results of Allowed, Disallowed, or Unknown. Ambiguity notes flag cases where current vocabulary text may not yet yield a stable interpretation across reviewers.

ID	Input source	Processing stage	Output behavior	Categories triggered	Declared preferences (example)	Expected effective result	Rationale / ambiguity
EC-1	Stored session / hybrid	indexing + retrieval	link or snippet only	search	search=y	Allowed	Classic search presentation; no training or generation
EC-2	Stored session / hybrid	retrieval + grounding + generation	generated answer with citations	search + inference/use	search=y, inference=n	Disallowed	Grounded generation is blocked even if search is allowed
EC-3	Interaction logs from crawler- or user-sourced sessions	ranking model update	ranking scores only	search + train-ai	search=y, train-ai=n	Disallowed	Continuous learning triggers training category; strictest-wins
EC-4	User-supplied prompt plus crawler-sourced context	grounding + generation	generated answer	inference/use (+ search if retrieval UI present)	inference=n	Disallowed	Hybrid input does not waive inference preference on retrieved context
EC-5	Crawler-sourced corpus	test-time adaptation	adapted model outputs	train-ai (or adaptation-specific category)	train-ai=n	Disallowed / Unknown	Under-specified if adaptation is not clearly "model update" in vocabulary text
EC-6	Session content	embedding cache for RAG	cached vectors used later for retrieval	search and/or train-ai	search=y, train-ai=n	Unknown	Ambiguity: embedding cache may be treated as search-internal processing or as lasting derived state
EC-7	Live or recorded media	accessibility transform of excerpts	captions / transformed snippets	typically neither search nor train-ai alone	accessibility allowed by policy	Allowed	Beneficial accessibility processing SHOULD remain available; see privacy considerations
EC-8	Dialog telemetry	media-metrics feature under APT scope	QoE analytics only	scoped by APT features	APT forbids export beyond aggregated metrics	Allowed only within APT	Binding-scoped example: enforce APT granularity rather than vocabulary overlap

Independent reviewers SHOULD be able to classify EC-1 through EC-4 and EC-7 consistently using the decision tree above. EC-5 and EC-6 remain explicitly tied to open vocabulary-boundary discussion and SHOULD be marked Unknown until the base AIPREF definitions stabilize.