Frequently Asked Questions

The fastest way is to run our completely free check – we inspect your site against the current ARD spec and tell you exactly what passes and what doesn't. ARD is a technical specification with strict requirements for data structures, endpoints, and behavior, so it's genuinely hard to self-assess manually. For ongoing assurance – knowing you're still compliant after the next spec release – CorgiMaps continuously generates and maintains a compliant ARD surface for you.

You have two paths. The DIY route is to build and host ARD-compliant endpoints yourself, mapping your product, pricing, and inventory data from all your source systems and files into the exact schema the spec requires and then keep that build current as the spec evolves. The more straightforward path is using CorgiMaps, which connects to your existing data sources and generates compliant ARD endpoints for you, with no custom build necessary.

Shopping behavior is moving into AI assistants. Already, 73% of consumers are using AI in their shopping journey, and Accenture estimates that by 2030 more than 30% of online commerce – close to $3.1 trillion – will run through AI agents. If an AI can't see your products, it will recommend a competitor who is visible. Showing up isn't optional marketing. This is where the next purchase decision happens.

No. Each agentic-commerce protocol defines its own data structures, endpoints, tools, and transport. So supporting one does not make you compliant with another. They overlap in spirit but differ in the details, so each requires its own compliant surface. CorgiMaps covers the major protocols at once from a single connection to your data, instead of building and maintaining a separate integration for each.

Different AI assistants and shopping platforms back different protocols, and no single one covers every surface. Supporting only one means you're invisible everywhere it isn't used. To reach as many shopping surfaces as possible, you generally need to support several protocols at once, which is why CorgiMaps maintains compliant surfaces across the major protocols from one place rather than one at a time.

Keeping up is continuous work, not a one-time task. Specs ship new releases, requirements change, and entirely new protocols keep emerging. Doing this by hand means tracking 6–12 evolving specifications and re-validating after every release. This is exactly what CorgiMaps maintains for you. It tracks the spec changes and keeps your endpoints compliant as they land, so your team doesn't have to monitor the protocols at all.

Frequently. Major releases tend to land on roughly a quarterly cadence, with smaller changes and activity happening as often as weekly across the protocols and their governing bodies. Because the space is young and moving fast, a surface that's compliant today can fall behind within a few weeks if no one is watching.

Yes. As new versions of ARD are published and AI platforms deprecate support for older ones, a surface that was compliant can quietly stop working, and you may not notice until you've dropped out of AI results. Staying compliant means tracking every release and updating accordingly. CorgiMaps handles this version drift for you, keeping your ARD surface current as the spec moves.

Building ARD support yourself typically means months of custom engineering – mapping your data into the schema, standing up and hosting endpoints, and testing against the spec – followed by constant monitoring of 6–12 evolving protocols to stay compliant. CorgiMaps removes nearly all of that: it generates compliant endpoints in minutes from your existing data and keeps them current as the specs change, so there's no build and no ongoing maintenance burden on your team.

A JSON document at /.well-known/ard.json on your domain with an entries array. Each entry describes one agentic resource you offer, such as an MCP server or an A2A agent card, with a urn:air identifier, a media type, a display name, and a url or inline data for the resource's own descriptor. Agents and registries read it to find what you have.

It finds your manifest, validates it against the current ARD schema, and checks each entry: the identifier, the media type, representative queries, and the publisher identity if you declare one. It then sends GET requests to up to 10 entry links to confirm they resolve and, for JSON types, that the body parses as JSON. Registry entries are declared-only and are not fetched. It also checks basic hygiene such as HTTPS and CORS. It never sends credentials and never calls a registry's search API.

ARD is a machine-readable manifest: a list of the callable resources you offer, each with a type and a link to its descriptor, published at /.well-known/ard.json. llms.txt and agents.md are separate files with their own purposes. This check looks only at the ARD manifest and the links it publishes, and does not read or assess either of them.

ai-catalog is ARD's predecessor, and its path was /.well-known/ai-catalog.json. The ARD spec says a publisher on that path should move to /.well-known/ard.json, and that consumers may still consult the old path but are not required to. That is why the check falls back to ai-catalog.json when it finds no manifest at ard.json, and reports a warning when it does.

No. ARD is how an agent finds your MCP server or A2A agent card; MCP and A2A are how it then uses them. A clean ARD result says nothing about whether the server card or agent card behind an entry is valid, since those are checked separately.

Not yet. The current version is v0.91 and its status is "Proposal", so details can change between versions. The check is pinned to one version of the spec and the result says which. Expect to revisit your manifest as the spec moves.