Identity documents

Interchange does not own your identity. You publish it — at your own domain, signed with your own keys, on your own clock — and we read it. The Agentic Advertising Organization (AAO) registry fills the gap until you’ve published, and computes a few things you don’t publish yourself. That’s the whole model: owners publish; the registry is a fallback and a compute layer; we read and trust what’s there. This page is the canonical answer to “what are all these documents, and how does Interchange use them?” The short version: registration gates connection; authorization is publisher-controlled and surfaced as an advisory signal today; compliance informs.

​

Storefront operator vs. publisher domains

A storefront has one operator domain: the legal or operating entity that runs that storefront. Choose its scope to match the storefront. For example, a regional storefront would use the regional entity domain, while a genuinely group-wide storefront would use the parent group’s domain. Create separate storefronts when regions need separate operators, commercial rules, or administration. The sites and titles sold through that storefront remain publisher domains; they do not replace the operator domain. Each publisher authorizes the sales agent from its own adagents.json. Those files can be small pointers to one centrally maintained authoritative document, so a group does not need to copy the same full configuration into every title’s file.

​

The three documents (and the one that isn’t)

Three identity documents matter, each owned and published by a different party, plus one legacy bridge. The AAO registry is not one of them — see below.

​

The AAO registry is not a document

The registry is a source and compute layer over those documents, not a document anyone owns. It does four things:

1. Computes compliance. It grades an agent’s self-declared capabilities against AAO test storyboards and publishes a verdict (passing, pending, degraded, or failing). The agent doesn’t publish this — the registry computes it.
2. Hosts a community mirror of a publisher’s adagents.json so an unpublished publisher is still discoverable. A community mirror lists no authorized agents — it exists to be found, never to authorize. An empty mirror is not a denial.
3. Hosts publisher-managed AAO copies when a publisher chooses an AAO-hosted setup. In that mode, the publisher still proves authority from its own domain by serving an authoritative_location stub that points at the AAO-hosted document.
4. Carries discovery metadata (discovery_method, hosting.mode) describing whether a record is owner-published or a community fallback.

Publisher creative formats in storefront adapters follow the same ownership rule. They are published as URL-free format_kind / format_options declarations under the publisher domain (for example, Snapchat under snapchat.com). The adapter does not create a separate Scope3 creative-agent URL or format namespace. Tenant-local templates such as Figma frames use only their base format_kind; they do not create a synthetic publisher catalog. AudioStack likewise uses the standard audio_hosted kind directly, with an exact duration in params.duration_ms_exact when needed; it has no separate AudioStack format namespace. For retail-media platforms such as CitrusAd and Criteo, the retailer owns the publisher catalog under the retailer’s domain — the technology vendor’s domain is not a substitute. A self-published document always supersedes the community fallback, and the registry resolves that internally. AAO-hosted records converge only after the publisher-origin well-known URL is reachable and verifies the hosted document. We trust whatever the registry returns, but use the hosting metadata to explain which setup state it is in.

​

Gates vs. signals

This is the distinction that matters, and the one most worth getting right: an agent being AAO-compliant (“did it pass the test suite?”) is a different question from an agent being authorized to sell a publisher’s inventory (“does that publisher’s adagents.json list it?”). Different owners, different documents, different consequences. One thing blocks setup today: agent registration. Everything else is surfaced as a signal during setup and product authoring. Concretely, across the storefront lifecycle: So if you hear “your AAO compliance is pending,” that is not “you can’t go live.” It’s an advisory you can act on (or ignore) on your own schedule. If you hear “this publisher hasn’t authorized the agent,” treat that as a publisher-owned authorization problem to fix before depending on that inventory, not as a reason to stop setup or product drafting.

​

Why we ask for AAO, and what we do with it

We read the registry to (1) confirm an agent you connect is a real, registered participant, (2) show you its compliance verdict as a signal, and (3) discover the publishers and brands tied to your domain. We don’t use it as a Scope3 allowlist — the registry is the source of truth, and we surface what it says rather than deciding for ourselves.

​

What we’ll publish for you — and what we never will

If your publisher isn’t in the registry yet, we help you get discoverable — we read your inventory identity (your formats, placements, and AdCP Collections) live from the adagents.json you publish, and surface it. Publishing that identity for you — so you don’t have to host the file yourself — is on the roadmap (see the note below), not live today. We will never touch your authorization. We do not mint or edit your adagents.json authorized_agents[] for you — granting an agent the right to sell your inventory is always your act, made in your own document.

Identity we help you publish; authorization we only ever reference.

If the registry reports hosting.mode: "aao_hosted" for a publisher that has started self-hosting, check the publisher-origin well-known URL first. The queried domain’s https://<publisher>/.well-known/adagents.json must be crawler-accessible and must return either the full file or a valid pointer to the authoritative file. A JSON file that only works from a browser, only works on www.<publisher>, or blocks non-browser crawlers will not be treated as validated self-hosting. If a brand lookup comes back empty during onboarding, see what to do when your brand isn’t found.

​

How networks and managed publishers get represented

A network or SSP that sells across many publisher domains it doesn’t own — and a publisher that hosts no file of its own — still fits this model, through delegation, not self-declaration. A network can’t host a file on its own domain claiming it sells someone else’s inventory; authorization is always the domain owner’s act. Instead:

1. The network publishes one manager adagents.json on a domain it controls, listing its agent(s) and the publishers it represents. This is just the adagents.json model applied to the network’s own domain.
2. Each publisher delegates to the network, by any one of:
   • an ads.txt MANAGERDOMAIN=<network-domain> line — a one-line delegation; the publisher hosts no adagents.json of its own (the Raptive/CafeMedia pattern), or
   • an authoritative_location pointer in the publisher’s own adagents.json redirecting one hop to the network’s centrally-hosted file, or
   • a delegated / ad_network delegation_type entry in the publisher’s adagents.json (see the glossary).

Interchange resolves all three live (see how adagents.json resolves), so once a publisher delegates, the network’s whole managed footprint is discoverable — no per-publisher file authoring required.

​

Changing from a modular source to an external agent

Replacing a modular source with your own external sales agent changes which publisher authorization applies; it does not retroactively make the modular source an Interchange authorization case. A modular source only needs publisher adagents.json authorization when its module or execution path exposes a publisher-facing agent URL. Once an external AdCP sales agent becomes the source, publishers authorize that external agent’s URL before the seller depends on that inventory. More generally, for source families that sell publisher inventory through an agent URL, the URL a publisher authorizes depends on the storefront source model. If the seller connects its ad server directly to Interchange and uses Interchange’s hosted storefront agent, publishers authorize the canonical Interchange storefront agent URL: https://interchange.io. Linked storefront inventory uses the upstream storefront’s own authorization model. For network-managed publishers, put that authorization in the manager’s file and have publishers delegate to it through MANAGERDOMAIN or authoritative_location. If a publisher also hosts a direct adagents.json pointing somewhere else, that direct file can shadow the manager-domain fallback. The fix is to restore delegation: make the publisher file point to the same manager file, or remove the publisher file so its ads.txt MANAGERDOMAIN delegation is used. The delegation itself — that one ads.txt line or adagents.json entry — is the publisher’s authorization act, and it is the only step that must originate with the domain owner. A network can guide its publishers to add it, but we never mint it for them (see What we’ll publish for you — and what we never will, above): a network cannot make itself authorized for inventory whose owner hasn’t delegated.