"Privacy-preserving" is a claim that has been stretched until it means almost nothing. On the protocol layer it can mean something specific: the inputs to relevance are restricted to public, request-bound signals — context hints from the moment, sponsor declarations, and content provenance. The user is separated from the match by construction, not by promise.
A privacy claim is only as strong as the architecture that enforces it. "Privacy-preserving matching" on this protocol means three things, each verifiable by reading the input contract:
These three are the contract. If any of them fails, "privacy-preserving" is a marketing word, not an architectural property.
The protocol excludes a specific list of inputs from the matching function, not as a recommendation but as a definition. The matching function is forbidden from reading:
If a system labels itself "contextual" but draws on any of these, it is doing behavioral matching with a contextual layer on top — not privacy-preserving matching as the protocol defines it.
The full relevance mechanism is described on the sister page within contextual-ads.ai: see /trust-safe-relevance. The short version: the match function takes three public inputs (context hints describing the moment, sponsor declarations, content provenance) and returns a relevance score that is reproducible from those inputs alone.
This page is not a re-explanation of the relevance function. This page is the privacy contract that says what the relevance function is not allowed to take as input.
| In the request (allowed) | Out of the request (excluded) |
|---|---|
| Context hints describing the current conversation moment | Any cookie, device ID, account ID, or fingerprint |
Sponsor manifests at /.well-known/agent-ad.json | Any external profile store or identity graph |
| Content provenance headers (FCS) on the surrounding content | Any prior-request history beyond the current moment |
| Sponsor category and placement constraints | Any third-party attribution chain |
"In the request" means: visible to the match function at decision time, derived from artifacts that exist independently of the requester. "Out of the request" means: not visible to the match function, by protocol definition.
Implementations may define the context window, but it must remain request-bound and non-identifying.
Two common claims sound adjacent but mean different things:
Privacy-preserving matching on this protocol is neither of those. The identifier is not part of the match function's input set at all. The match function has no user identifier input to authorize.
The difference is architectural, not editorial.
OpenAI Ads computes placement against conversation intent using context hints, landing-page content, and ad copy. Their product makes a strong, observable separation between the ad selection process and any user-account identifier on their platform; the ad-policies and product docs describe this as a buyer-side property of their system.
Privacy-preserving matching as a protocol generalizes that property: it specifies an input contract that other agent runtimes, ad systems, and verification tools can implement independently — without needing to share OpenAI's stack or trust OpenAI's policy enforcement.
OpenAI Ads can operate while honoring this contract. Agent runtimes that want a portable, verifiable privacy contract benefit from the protocol-level definition.