Ad placement does not enter answer generation. Here is the separation contract.

What the editorial firewall is

The editorial firewall is a separation contract between two paths in an agent runtime:

• Answer generation path — the agent reads the user's request and the model's own context, and produces the response. Inputs: the conversation, the model's training, the agent's tools and grounded sources.
• Ad placement path — given the produced response (or its content shape), the agent decides whether to place an ad alongside it and which candidate to select. Inputs: relevance function output, candidate manifests, broadcast feed, provenance check.

The firewall says: the second path runs after the first, against the first's output. It does not feed back into answer generation. No ad-buy state, no campaign signal, no buyer's bid is ever an input to the model's response.

If a system runs ad selection in parallel and then shapes the answer to better match an ad, that is not an editorial firewall. It is an editorial pipe.

Why this matters

The agent surface conflates two things the open web kept separate: editorial content (what the publisher wrote) and ad inventory (what the brand bought). On the open web, the page existed first and ads were placed against it. On agent surfaces, both are generated at the same moment.

That co-generation creates a temptation: shape the model's answer toward content that monetizes better. If the temptation is structural rather than disciplined-by-policy, three failures follow:

1. Answer integrity collapses — the user can no longer trust that the answer reflects the model's reasoning rather than buyer demand.
2. Brand safety is undermined — sponsors lose confidence that their ad is appearing next to neutral content rather than content engineered for ad fit.
3. The agent's editorial authority is lost — once buyers can influence answers, the surface stops being a model speaking and becomes a placement engine speaking.

The firewall exists to make all three failures architecturally impossible, not just policy-discouraged.

The separation mechanism

The separation is enforced at the level of the agent runtime's data flow, not at the level of human discretion. Three architectural rules constitute the firewall:

• One-way dependency. The ad placement path may read from the answer-generation path (e.g., the produced response, its topic shape) but the answer-generation path may not read from the ad placement path (no candidate set, no buyer state, no live bid).
• Post-generation ordering. Ad placement decisions are computed after the response is generated, not in parallel where state could leak.
• No feedback loop. Ad outcomes do not feed into answer generation as ad-placement state.

These rules are observable in the agent runtime's code paths. A runtime that violates any of them does not implement the editorial firewall, regardless of policy claims.

How the firewall is observable

The firewall is not just a promise. It is verifiable by reading three things:

1. The agent runtime's data-flow architecture — does the answer-generation path have any read access to ad-placement state? A diagram that shows the dependency direction settles the question.
2. The eligibility check timing — does pre-render verification (see /brand-safety-verification) run after the answer is fixed, or could it influence the answer's shape? The verification flow's place in the pipeline matters.
3. A publisher-published architecture statement — publishers can link an editorial-firewall architecture statement from the covenant manifest or from their site documentation. Agents and auditors can read the statement and check it against the runtime's observable behavior.

The firewall becomes a property runtimes can attest to, not a slogan they can rebrand around.

Where this fits relative to OpenAI Ads

OpenAI describes ads as labeled and separate from ChatGPT responses. That is OpenAI's editorial firewall on their own surface.

The editorial firewall as described here generalizes that property: it specifies an architectural separation that any agent runtime — not just OpenAI's — can implement, attest to, and be verified against. A multi-vendor agent ecosystem benefits from the firewall being a portable contract, not a single platform's product policy.

OpenAI Ads enforces editorial separation on its own surface. Pre-render verification, ABF, and the editorial firewall together let other agent runtimes do the same, with manifest-level attestation that brands and users can read.

What the editorial firewall is not

• Not a policy. It is an architectural rule that policy can sit on top of, but policy alone does not constitute the firewall.
• Not a ban on ads — the firewall is about separation, not absence. Ads run; they just don't influence answers.
• Not a guarantee against bad creative — relevance and brand safety are separate concerns (see sister pages). The firewall only addresses the ad-to-answer influence channel.
• Not a partnership with any model provider.
• Not a substitute for transparent ad labeling — the firewall keeps the channel separated; labeling tells the user which part is ad.

How a runtime attests to firewall integrity

Three things an agent runtime does:

1. Document the data-flow direction. Publish an architecture description (or a diagram URL referenced from /.well-known/agent-ad.json) showing one-way dependency from answer-generation to ad-placement.
2. Publish an architecture statement and link it from the manifest or site documentation. A short statement describing the runtime's editorial separation — data-flow direction, post-generation ordering, no-feedback-loop — linked from the covenant manifest or from a stable site documentation path. A dedicated schema field (e.g., editorial_firewall) may be added later as the manifest schema evolves; for now the statement-plus-link approach is the contract.
3. Make the verification step observable. Pre-render verification (/brand-safety-verification) runs after the answer is generated, so an external auditor can confirm the ad placement decision did not gate the answer.

The integration documentation lives at /docs/abf/. Specifics on the architecture-statement convention and the auditor-readable architecture description will be drafted as part of that documentation work.