Ads can be relevant without tracking. Here is how the mechanism works.

What "trust-safe relevance" means

Relevance is the answer to: of all ads that could be shown right now, which is most appropriate for this moment? Behavioral systems answer it by ranking ads against a stored profile of the viewer. Trust-safe relevance answers it without that profile.

Three public inputs replace the profile:

1. Conversation context — the semantic shape of the current moment, expressed as context hints (intent clauses), not keywords.
2. Sponsor declaration — the advertiser's published manifest of what they are offering, including category, attestation, and eligibility constraints.
3. Content provenance — FCS headers attesting where the surrounding content came from, so brand-safety checks can run before render.

A relevance function operating on these three inputs is auditable when the implementation publishes the scoring logic or a reference verifier — given the same public inputs, an independent reader can re-run the function and check the answer. A behavioral relevance function is not auditable in that sense, because the profile is private and time-dependent.

Why this is mechanically possible (and not a privacy compromise)

Three technical components, each with public academic grounding (see Technical foundations below), make this work:

• Commercial-intention generation — a small layer that maps an agent-mediated conversation to a structured representation of what the user is trying to accomplish. The representation is ephemeral, not stored, and not tied to identity.
• Sparse vocabulary expansion — the relevance score is computed in a sparse vocabulary space, which is interpretable, auditable, and avoids the opacity of dense behavioral embeddings.
• Bias guardrails — a guardrail layer prevents systematic bias toward LLM-generated content, so the relevance function does not silently amplify one content distribution over another.

None of these components require a user identifier. None require cross-site tracking. None build a profile that persists between requests.

The relevance is built from the request, not from the requester.

The relevance function, abstractly

For a given moment with context hints C, against a set of sponsor declarations S each with their own eligibility constraints, the relevance score for a candidate ad s ∈ S is:

relevance(s, C, provenance) = match(s.intent_descriptor, C)
                              × eligibility(s, provenance)
                              × guardrail_weight(s)

• match(...) — the sparse-vocabulary overlap between the sponsor's declared intent descriptor and the context hints of the moment.
• eligibility(...) — binary; does the sponsor's declaration permit placement against content of this provenance?
• guardrail_weight(...) — the bias-correction factor.

None of these terms takes a user identifier as input. The function is closed over public, auditable signals.

How this differs from behavioral relevance

Behavioral	Trust-safe
Inputs include a stored user profile	Inputs are limited to the moment + public declarations + provenance
Relevance depends on history	Relevance depends on the current request
Score is opaque (dense embedding)	Score is interpretable (sparse vocabulary)
Audit requires accessing the profile	Audit requires only the public inputs
Privacy risk: the profile	Privacy risk: none in the same kind

The trade-off: trust-safe relevance can lose information that behavioral systems retain (purchase history, prior conversions). What it gains: the relevance function is portable, auditable, and not bound to a single advertiser's data moat.

Where this fits relative to OpenAI Ads

OpenAI Ads computes placement against conversation intent using context hints, landing-page content, and ad copy — the same family of public signals trust-safe relevance describes. The product implements one operational version of the broader trust-safe relevance idea on its own platform.

Trust-safe relevance is the protocol-layer description of how that works in general — not a competing product, but the framework that lets other agent runtimes implement the same approach without rebuilding the trust math from scratch.

OpenAI Ads can operate without the contextual-ads.ai protocol. Agent runtimes that want a portable, auditable relevance function benefit from it being defined.

What trust-safe relevance is not

• Not a no-relevance system — it still ranks ads against context; it just doesn't use a behavioral profile to do it.
• Not a one-size-fits-all algorithm — implementations can vary; the protocol defines the input/output contract, not the internal model.
• Not behavioral-with-extra-steps. The architecture excludes user identifiers and cross-site state by construction, not by promise.
• Not a substitute for brand-safety verification — relevance and safety are separate concerns. See the sister page.

How the relevance feeds the verification step

The relevance function outputs a ranked candidate set. The verification step (on the sister page) is what runs against each candidate before the ad is rendered. The split:

• Relevance (this page) answers: which ads could appropriately match this moment?
• Verification (sister page) answers: for the top candidate, is it safe to render right now?

The first is computed from context. The second is computed from the verifiable manifest at /.well-known/agent-ad.json. Together they make placement decidable without user tracking.