> ## Documentation Index > Fetch the complete documentation index at: https://docs.interchange.io/llms.txt > Use this file to discover all available pages before exploring further. # Identity documents > Who publishes what, where it lives, and how Interchange uses it — adagents.json, brand.json, the agent card, and the AAO registry. 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. | Document | Who owns it | Where it lives | What it answers | | ---------------------------------------- | ------------------------ | ----------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **`adagents.json`** | The **publisher** | `https:///.well-known/adagents.json` | Two things: **which agents are authorized** to sell my inventory (and over which properties), and **what inventory I have** — my collections, placements, and creative formats | | **`brand.json`** | The **brand / operator** | `https:///.well-known/brand.json` | Which agents I **own and run** (by role), where their signing keys live, and my corporate **hierarchy** (house / parent brand) | | **Agent card** (`get_adcp_capabilities`) | The **agent itself** | the agent's own endpoint | What the agent **claims it can do** — the AdCP capabilities it supports | The **`ads.txt` `managerdomain`** entry is a legacy one-hop bridge: a network-managed publisher that hosts no `adagents.json` of its own (for example, a Raptive/CafeMedia-managed domain) delegates to its manager's file. Resolution handles this automatically — see [Discover agents](/v2/storefront/tasks/discover-agents#how-adagents-json-resolves). ### 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.** A sales agent must be **registered** with AAO to be connected as an inventory source. Publisher authorization is separate: that publisher's `adagents.json` says which agent may sell which properties. Interchange resolves and surfaces that authorization today as an advisory warning when it is missing; it is not a source-connection, product-authoring, or activation blocker. The registry's compliance verdict (`passing`, `pending`, `degraded`, or `failing`) is **advisory**. A non-passing verdict is surfaced as a prominent warning, but it does **not** block your storefront from going live and transacting. You can sell while compliance is still pending. Concretely, across the storefront lifecycle: | Moment | What's checked | Blocks? | | ------------------------------------------------- | --------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------- | | **Connect a source** | the agent is **registered** with AAO | **Yes** — an unregistered agent can't be connected (a registry that's unreachable is a "try again," not a "no") | | **Go live** | AAO **compliance** verdict | **No** — informational. A non-`passing` verdict shows as a warning; it never holds back go-live | | **Author products / set up publisher references** | the publisher's `adagents.json` **authorizes** this agent for the inventory | **No today** — Interchange warns when a resolved publisher file does not authorize the agent, then lets setup and product authoring continue | 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.** Today the supported path is **you publish upstream, we pick it up** — host your own `adagents.json` / `brand.json` and we read it live (with a manual re-resolve when you update). An OAuth-connected "manage my identity on my behalf" path is on the roadmap. Your brand's corporate hierarchy (`house` / `keller_type` / `parent_brand`) is read and displayed today; using it to drive business rules such as rate cards across a brand family is also roadmap, not yet live. 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:///.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.`, 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](/v2/setup/storefront-onboarding#verify-your-company). ## 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=` 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](/v2/concepts/glossary)). Interchange resolves all three live (see [how adagents.json resolves](/v2/storefront/tasks/discover-agents#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.