Reference implementation showcase: value/selection metadata riding AI Catalog `metadata` + Server Card `_meta` (live wire formats & routes)

[YE-YI7]

Following the pattern of #34 — live wire formats and routes from a running implementation, for the WG to sanity-check the extension surfaces (this is not a proposal to widen the card spec; the core stays identification/discovery).

What this is a datapoint for

#30 names a consumer class that never connects to a live server: registries, developer portals, orchestrators planning tool routing. Alongside "what does this server do," that class also has to answer "which of these substitutable entries should the agent use" — which needs selection signals: cost, eligibility (reach/platform/setup), data governance, risk/approval. We've had that layer running in production for a few weeks, riding the two extension surfaces that already exist, with zero core-schema changes:

• AI Catalog entries carry a namespaced block in the ADR-0012 metadata object
• Server Cards carry a reverse-DNS _meta key pointing at the same document

Discovery flow

flowchart LR
  C[Client] -->|GET /.well-known/ai-catalog.json| A[asm-spec.onrender.com]
  A -->|entry.metadata.asm: static eligibility| C
  A -->|entry.url| M[/manifest/service_id/]
  C -->|GET manifest: full mutable value doc| M

Loading

Routes (live)

Document	Route	Notes
AI Catalog	/.well-known/ai-catalog.json	30 entries, ADR-0012 metadata extension
Full manifest	/manifest/{service_id}	mutable value doc (pricing/quality/SLA)
Selection	POST /select	gated choice + risk/approval surface

Wire format — catalog entry (captured live, trimmed)

{
  "identifier": "urn:air:asm:us-census/data-api@current",
  "displayName": "US Census Bureau Data API",
  "mediaType": "application/asm+json",
  "url": "https://asm-spec.onrender.com/manifest/us-census/data-api@current",
  "metadata": {
    "asm": {
      "asm_version": "0.3",
      "taxonomy": "tool.data.real_estate",
      "invocation": {
        "interface": "rest_api",
        "reach": "cloud",
        "agent_operable": true,
        "agent_completable_setup": true
      },
      "operational": { "risk_class": "low", "approval": "never" },
      "manifest_url": "https://asm-spec.onrender.com/manifest/us-census/data-api@current"
    }
  }
}

Split rule we converged on after a few iterations (it matches the drift concern raised in #34): static facts an agent gates on live inline; anything mutable (pricing, quality, SLA) lives behind url so freshness has exactly one source and catalog entries never drift.

Why metadata/_meta and not the card

The card/catalog core answering only "what is this and how do I connect" has worked fine for us as consumers — none of this required spec changes, which we read as evidence the extension surfaces are shaped right. Selection signals are opinionated and evolving; keeping them namespaced (metadata.asm, io.asm-spec/*) lets implementations converge on conventions before anything is standardized, exactly what ADR-0012's "registries can define their own metadata schemas" anticipates.

Happy to adjust shapes to track the charter as it lands — and to compare notes with other implementations carrying non-core metadata.

(Implementation and this write-up drafted with Claude; reviewed and approved by me.)