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.

​

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.

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, 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. For source families that sell publisher inventory through an agent URL, the agent URL a publisher authorizes depends on the storefront source model. If the seller connects an external AdCP sales agent, publishers authorize that external agent’s URL. 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. Modular sources only need publisher adagents.json authorization when the module or execution path exposes a publisher-facing agent URL. 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.