Recognise `application/asm+json` in the AI Catalog (tool value/selection manifests)

[YE-YI7]

Following the pattern of #43 (install-manifest) and #27 (OKF bundles): a request to recognise a media type in the standard discovery types list, backed by a running conformance-tested deployment.

The type

application/asm+json — an ASM manifest: machine-readable value/selection metadata for a real-world tool (pricing and billing dimensions, quality signals, SLA, data governance, invocation feasibility, risk/approval class). It answers the question that comes after discovery: among several substitutable entries, which one should this agent actually use, given cost/constraints/governance. Schema + 30-tool open library: https://github.com/YE-YI7/asm-spec

This is the artifact class behind the discussion in Agent-Card/ai-catalog#83 (discovery-time access/monetization signaling), where we contributed field data from the same library.

Running deployment (conformance-tested)

• Catalog: https://asm-spec.onrender.com/.well-known/ai-catalog.json — 30 entries, specVersion: "1.0", urn:air: identifiers, flat-primitive metadata (asm:* keys), artifacts behind url
• Conformance: the official CLI reports PASS, 0 critical errors with strict JSON Schema validation; the only remaining findings are 30 warnings, all Media type 'application/asm+json' is not one of standard discovery types — hence this issue
• The tool's semantic checks caught (and we fixed) five real violations while integrating: missing specVersion, URN charset, mediaType→type, closed root, and nested metadata objects — the conformance tool works, and the flat-primitives constraint is useful firsthand input for the extensions-mechanism discussion (ai-catalog#77)

Ask

1. Add application/asm+json to the standard discovery types allowlist (spec media types + conformance tool), or advise if there's a registration bar we should meet first (happy to write the entry-shape doc).
2. If useful, we'd also be glad to be listed among implementations in the wild (docs: add "Implementations in the wild" (5 conformance-tested ARD dep… #26) as a conformance-tested catalog publisher.

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

[mindpower]

Hi @YE-YI7 , Thanks for opening this issue and for all the work you've put into building a conformance-tested deployment! It's great to hear that the CLI tool's semantic checks helped catch those edge cases during your integration.

To address the different parts of your implementation:

1. The type field and the CLI warnings
   Because the AI-catalog working group prefers to keep the core spec as minimal as possible, the standard type field is intentionally designed as an open format. This means the application/asm+json (and its adherence to the standard +json structured syntax suffix) is valid from a protocol perspective, and we don't need to request an spec change to support it. (unless at some point, we want to make it a known/standard type).

However, you absolutely shouldn't be penalized with 30 warnings by the ARD tooling for using a valid custom type. We can fix this directly in our tooling. We should update the ARD conformance CLI so that unrecognized but properly formatted application/* types emit an info log rather than a warning.

(If you'd be interested in submitting a PR for the CLI adjustment to handle this gracefully, we'd gladly review it! Otherwise, we will add it to our backlog.)

[mindpower]

2. The custom metadata (asm:* keys)
   For your custom metadata extensions, have you considered using a namespace approach like below? It provides a clean, collision-free way to implement these specific fields without requiring changes to the minimal core spec. For example:

{
  "@context": {
    "asm": "https://asm-spec.onrender.com/ns#"
  },
  "identifier": "urn:air:...",
  "type": "application/asm+json",
  "asm:risk_class": "low",
  "asm:approval": "never"
}

(Note: we're working on the spec side to include this to support custom metadata for each catalog entry)

[mindpower]

3. "Implementations in the wild"
   Yes, absolutely! Please feel free to open a PR against the docs to add your catalog to the "Implementations in the wild" section.

Thanks again for the detailed write-up!