Publishers integrate by serving the protocol, not by handing over logs.

Who this is for

This page is for content publishers and operators of agent surfaces — sites and runtimes that generate or modify content using AI models and want that content to be readable by an ad-relevance protocol that does not require user tracking.

Specifically:

• Publishers running agent-mediated surfaces (chat, conversational search, AI-generated article surfaces).
• Operators of AI runtimes (assistants, model gateways) that produce responses for end users.
• Anyone whose response stream could be the surface an ad is placed against.

Not for: ad buyers (see OpenAI Ads or the sister page for sponsor-side publishing), behavioral ad networks, identity-graph vendors.

What you publish

Three artifacts, all at stable URLs or in response headers:

1. FCS trust headers on AI-generated and agent-modified responses. The four-header set described in the FCS-2.1 spec: X-FCS-Version, X-FCS-Content-Hash, X-FCS-Model, X-FCS-Signature. Emitted at response time, computed from the body and your signing key.
2. A public verification key at /.well-known/fcs-signing-keys.json — the path already used by the FCS worker and spec references. The key lets any consumer verify the headers.
3. Optional: a content-publisher manifest at /.well-known/agent-ad.json if you are also serving as a sponsorship endpoint. Most pure content publishers do not need this — it is the sponsor-side artifact, covered on the sister page.

That is the full content-publisher integration surface. Three artifacts. None of them describes the user.

What you do NOT publish

The protocol asks the publisher for content provenance, not for the requester's identity. Specifically, integration does NOT require:

• Forwarding query logs to a third party.
• Sharing audience cohorts, segments, or interest categories.
• Emitting user identifiers (cookie, device, account, hashed email).
• Maintaining a per-user state object that an ad system reads.
• Adopting a third-party tracking pixel or attribution chain.

If a vendor pitches "contextual integration" but asks for any of the above, that is behavioral integration with a contextual label, not contextual-as-architecture.

The integration surface, concretely

Three things to add to your origin server's response pipeline:

Step	What you do	Where
1	Compute the four required FCS headers on AI-generated or agent-modified responses	Response middleware
2	Publish your public verification key at a stable URL	/.well-known/fcs-signing-keys.json
3	Sign content at generation time, not at request time	Generation pipeline

Implementation examples and verification guidance are linked from the FCS-2.1 spec as they stabilize. The integration is response-side: nothing about it requires a database of users.

How this differs from log-handoff and pixel integration

Three common alternatives have different shapes:

• Log-handoff ships request logs (queries, IPs, timing) to an ad-tech partner that then matches against a profile graph. The integration is outbound: data leaves the origin, and trust verification happens downstream of the publisher. With FCS, the only thing that leaves the origin is a content hash and a signature.
• Pixel/tag integration loads third-party scripts that read browser state and emit identifiers. Participation requires running third-party code on the publisher's surface. With FCS, headers are emitted from the publisher's own server; no third-party code is required to participate.
• Server-side data forwarding sends a curated subset of request data to a partner environment. The integration is still outbound. With FCS, the only outbound artifact is the content hash and signature carried in the response itself.

The architectural distinction: FCS asks the publisher to publish (declarative, public, auditable), not to forward (transactional, private, opaque).

Where this fits relative to OpenAI Ads

OpenAI Ads frames relevance around conversation, context, and ad details. FCS-signed landing pages make the publisher-side content signal more verifiable for any crawler or ad system that evaluates the page — the read is anchored to content provenance, not just to what a crawler happened to fetch.

FCS-emitting publishers produce a signal that is portable across any ad system that consumes the headers — not just one platform. The integration is portable by design.

What this is not

• Not a SaaS subscription. The protocol is open; no per-publisher pricing applies to emitting the headers.
• Not an ad exchange. Publishers do not auction inventory through this page.
• Not a behavioral profile system in disguise. The integration surface is the response, not the user.
• Not a replacement for OpenAI Ads or any specific ad platform — those are buyer-side products that can consume the publisher-side signal this protocol defines.
• Not a guarantee against bad actors. Emitting FCS headers does not prevent a determined adversary from spoofing content; verification depends on key publication and signature checks downstream.