ARD Catalog Validator

Validate an ard.json or ai-catalog.json file against the ARD v0.91 rules - and see it the way a registry does.

ARD URN generator

Every ARD identifier is a domain-anchored URN: urn:air:<publisher-domain>[:namespace]:<name>. The publisher segment must be a domain you control - and if you attach a trustManifest, its identity must be issued by that same domain.

urn:air:example.com:resource

Errors, warnings, and the space between

ARD deliberately splits conformance into two tiers. Errors break the entry contract: a missing identifier, displayName or type, both url and data at once (they are mutually exclusive), or a trustManifest whose identity domain does not match the identifier publisher. A registry can reject those outright. Warnings keep the entry valid but weaken or erase its discovery: missing or thin representativeQueries, non-HTTPS artifact URLs, unrecognized type strings, a legacy ai-catalog.json home.

That split mirrors how search engines treat pages: valid HTML with no titles still indexes - badly. Treat warnings here the same way. An entry with zero errors and zero warnings is not just conformant; it is findable, which is the entire point of publishing a catalog.

How to use this tool

  1. Paste your catalog JSON (or load the file) and tell the tool where the file lives - the path changes the verdict.
  2. Click Validate catalog and read the checks table top to bottom: errors first, then warnings.
  3. Use the viewer to see your entries the way a registry ingests them - names, types, capabilities and queries.
  4. Fixing an identifier? Build a spec-shaped URN with the generator below the results and paste it back into your catalog.
  5. When it validates clean, check the live site end-to-end with the AI Agent Discoverability Checker.

Frequently Asked Questions

It validates a catalog against the ARD v0.91 entry rules: every entry needs an identifier in domain-anchored URN form, a displayName, a media-type type, and exactly one of url or data. It then grades the discovery signals the spec recommends - 2 to 5 representativeQueries, capabilities tokens - and the trust rules: a trustManifest must carry an identity, and that identity domain must match the publisher domain inside the identifier URN.
No - and that distinction is the heart of ARD. The schema does not reject an entry that omits them; conformance tooling flags it as a warning. But a registry builds its search index from representativeQueries, so an entry without them is a well-formed catalog entry that agents simply cannot find by search. This validator reports it as a warning with exactly that explanation.
The entries themselves validate identically - the format did not change between v0.9 and v0.91. What changed is discovery: v0.91 consumers must fetch /.well-known/ard.json and only may check the legacy path. Paste your catalog here to check the entries, then republish the same file at ard.json (this validator tells you if your file came from the legacy path and what that costs you).
Two parts. ARD only mandates trustManifest.identity inside the envelope - the rest of the schema belongs to whatever trust framework you declare. And that identity must align with the publisher domain embedded in the entry identifier: an entry claiming urn:air:google.com:... is rejected by a verifying registry unless it can produce an attestation issued by google.com. It is the anti-squatting rule, and this validator enforces the domain match.
No. Validation runs entirely in your browser. Paste the JSON or load a file from disk - nothing leaves the page, so internal or pre-launch catalogs are safe to check.

Was this tool helpful?

Comments

Loading comments...

Check Out Other Popular Tools