6 schema changes between AI Catalog 0.2 and 1.0 that break static audits

On 26 August 2026 I added public/.well-known/ai-catalog.json to this site, wired it into the HTTP Link header as rel="service-desc", verified it returned 200 application/json with Access-Control-Allow-Origin: *, and left it alone. Six weeks later, on 7 October, PageSpeed Insights rolled out its new Agentic Browsing category and failed the file on sight.

The error message was four words: ai-catalog.json schema is invalid. Clearing it took two commits (dc02dbe and 2689b83), because fixing what the written specification asked for still failed the validator Google actually ships.

#PageSpeed Insights added an Agentic Browsing audit that rejects 0.2 manifests

Unlike Performance or Accessibility, which score a page from 0 to 100, Lighthouse's Agentic Browsing panel grades a pass/fail ratio across four checks. One of those checks fetches /.well-known/ai-catalog.json and validates it against the Agentic Resource Discovery (ARD) / AI Catalog 1.0 schema.

Every early adopter who wrote a manifest in late summer 2026 wrote it against draft 0.2. The first breaking change is the version string itself: "specVersion": "0.2" is no longer recognised. Bumping it to "1.0" is step one, and doing only step one simply reveals the five structural errors underneath it.

#Entries rename id to identifier and host renames name to displayName

Draft 0.2 used short, familiar JSON keys: host.name for the publisher's name, and id on each object inside entries[]. Specification 1.0 (defined in the CDDL at github.com/Agent-Card/ai-catalog/specification/ai-catalog.md) renames both.

• Change 2 (`entries[].id` → `entries[].identifier`). Every AssetEntry in entries[] must carry identifier. All eight entries on this domain — two plain-text context files, the XML sitemap, the RSS feed and the four identity pages — keep their urn:air:sumandebnath.houseofnamus.com:... URNs, under the new key.
• Change 3 (`host.name` → `host.displayName`). The top-level host object is now typed as HostInfo, where the human-readable publisher label is displayName and is the only required property on the object.

Neither rename changes the meaning of the field. Both fail a 0.2 file immediately because the 1.0 validator rejects unknown properties alongside missing required ones.

#HostInfo drops url, description and contact down to four allowed keys

In 0.2, host was where you described the site owner in prose: name, url, description and contact. In 1.0, HostInfo is locked down with additionalProperties: false and permits four keys in total:

That is Change 4. Leaving url, description or contact inside host fails the schema check even after displayName and identifier are added. On this site, documentationUrl points at https://sumandebnath.houseofnamus.com/llms.txt.

#Lighthouse rejects the root extensions block that the specification itself defines

When I stripped description and contact out of host in commit dc02dbe, I did not delete them. I followed the specification and moved them into the official metadata extension at the root of the document: extensions["https://ai-catalog.org/extensions/metadata"].

I pushed dc02dbe, ran PageSpeed Insights against the live URL, and watched it fail with the exact same error: ai-catalog.json schema is invalid (3/4 passed).

That is Change 5, and it is the trap you only find by testing against the live validator. Lighthouse's JSON schema enforces additionalProperties: false at the document root and allows only three top-level properties: specVersion, host and entries. A root-level extensions object — even one using the specification's own namespace — fails validation.

{
  "specVersion": "1.0",
  "host": {
    "displayName": "Suman Debnath",
    "identifier": "sumandebnath.houseofnamus.com",
    "documentationUrl": "https://sumandebnath.houseofnamus.com/llms.txt"
  },
  "entries": [
    {
      "identifier": "urn:air:sumandebnath.houseofnamus.com:context:llms-txt",
      "displayName": "Site summary for language models",
      "description": "A generated, always-current summary of every page on the site...",
      "type": "text/plain",
      "url": "https://sumandebnath.houseofnamus.com/llms.txt",
      "representativeQueries": [
        "Who is Suman Debnath?",
        "What is on sumandebnath.houseofnamus.com?"
      ]
    }
  ]
}

Removing the seven lines of root extensions in commit 2689b83 moved PageSpeed Insights from 3/4 to 4/4 passed. Nothing was lost by deleting them: the biography and contact email were already declared in `/llms.txt`, in the root Person JSON-LD, and on /about.

#Copying did:web from the spec example points resolvers at a 404 unless you host did.json

The sixth change is what goes inside host.identifier and entries[].type, where copying the specification's examples verbatim turns a syntax fix into a false claim.

Every example in the specification sets "identifier": "did:web:example.com" on host. Under the W3C did:web method, claiming did:web:sumandebnath.houseofnamus.com is a promise that a resolver can fetch https://sumandebnath.houseofnamus.com/.well-known/did.json and receive a valid DID Document with verification keys. This site does not host a DID document and has no use for one. Setting host.identifier to the bare domain ("sumandebnath.houseofnamus.com") satisfies the schema without advertising infrastructure that 404s.

#Eight Low warnings on media types stay because HTML pages are not MCP cards

Even with 4/4 passed, expanding the Agentic Browsing details panel in PageSpeed Insights shows eight Low severity warnings on this file — one for every entry in entries[]. Lighthouse flags text/plain, application/xml, application/rss+xml and text/html as *"not standard discovery types"*.

The validator's internal allowlist expects agent-protocol MIME types: application/agent-card+json, application/mcp-server-card+json, skill bundles or sub-catalogs. Yet the specification's own text states that an AI Catalog is artifact-agnostic, and its normative CDDL example includes an entry with "type": "application/parquet".

I left all eight warnings in place. /llms.txt is text/plain. /sitemap.xml is application/xml. /about is text/html. Relabelling a web page as application/mcp-server-card+json to make eight Low badges disappear would tell every agent reading the catalog to parse an HTML document as a Model Context Protocol server descriptor.

One more moving target is worth watching if you maintain this file. The upstream working group has already renamed the canonical specification path from /.well-known/ai-catalog.json to `/.well-known/ard.json` (with rel="ard" in the Link header), treating ai-catalog.json as the legacy path that clients *may* still check. As of October 2026, Lighthouse still fetches ai-catalog.json. Until the audit catches up with the rename, ai-catalog.json is the file that has to stay valid.