Reference publisher: Snowdata / SnowSure — travel & outdoor snow intelligence

[mikeslone]

Summary

Snowdata and SnowSure have published ARD ai-catalog.json manifests for verified ski-resort snow intelligence — MCP servers, REST/OpenAPI, Answer Engine, and a category search registry. We believe this is among the first travel/outdoor-data publishers on ARD.

A reference-catalog PR is forthcoming: mikeslone:add-snowdata-snowsure-reference-catalogs

Live catalogs

Publisher	URL
Snowdata (corporate + federation hub)	https://www.snowdata.ai/.well-known/ai-catalog.json
SnowSure (consumer MCP + API + Answer Engine)	https://www.snowsure.ai/.well-known/ai-catalog.json
Snowdata live MCP (sub-catalog target)	https://mcp.snowdata.ai/.well-known/ai-catalog.json

Search registry

POST https://www.snowdata.ai/api/ard/search

{"query":{"text":"best powder in the Alps this week"},"pageSize":5,"federation":"referrals"}

Conformance (snowdata-ai-catalog.json)

�[1m�[36m=== Conformance Validation Summary ===�[0m
�[1m�[32mCONFORMANCE STATUS: PASS�[0m
Validated with 0 critical specification errors and 6 warnings.

Registry POST /search: PASS on https://www.snowdata.ai/api/ard

Resources

• Trust / provenance: https://www.snowdata.ai/for-ai/trust
• Announcement: https://www.snowdata.ai/news/snowsure-ard-discovery
• OpenAPI: https://www.snowdata.ai/.well-known/openapi.json

Ask

1. Feedback on our catalog structure (federation of Snowdata + SnowSure via nested application/ai-catalog+json entries per ADR-0003)?
2. Is there a planned index of reference publishers we should be listed on?
3. Happy to iterate on the reference examples in the linked PR.

— Snowdata Inc. / SnowSure

[mikeslone]

Network update since this was opened: the verified federation has grown beyond SnowSure + Snowdata to five independent publishers — SnowSure, Snowdata, LUXSKI, Afore, and Ski Limone — each serving its own signed ai-catalog.json. The Snowdata/SnowSure registry (POST /api/ard/search, alias /search) now federates all of them: 44 indexed resources, 41 verified via did:web identity + Ed25519 entry-bound trust-manifest signatures (RFC 7515 detached JWS over RFC 8785 JCS). Verification is enforced — only signed, verified entries are ranked.

On the open question above ("is there a planned index of reference publishers we should be listed on?"): beyond the publisher PRs (#12, #15), we'd suggest the registry itself is a candidate for the Reference Implementations page as the first vertical (domain-specific) discovery service, alongside Hugging Face Discover, GitHub Agent Finder, and Cisco AI Catalog — it demonstrates ARD federation + trust working end-to-end for a single domain. Happy to open that PR if it's wanted.

Open standard for the vertical (publish + sign + verify): https://opensourcesnow.com

Quick check across the federated network:

curl -sS -X POST https://www.snowsure.ai/search \
  -H 'content-type: application/json' \
  -d '{"query":{"text":"best powder in the Alps this week"}}' \
  | jq -r '.results[] | "\(.score)\t\(.source)\t\(.displayName)"'

[mikeslone]

Update: all of our catalogs now pass this repo's conformance CLI (conformance/bin/conformance-test manifest <url>) — 5/5, zero critical errors.

Publisher	Domain	Role	Conformance
SnowSure	snowsure.ai	Discovery registry (ski & snow) + publisher	PASS
SnowData	snowdata.ai	Discovery registry (ski & snow) + publisher	PASS
Afore	afo.re	Discovery registry (editorial travel) + publisher	PASS
LUXSKI	lux.ski	Publisher	PASS
Ski Limone	skilimone.com	Publisher	PASS

Five independent did:web publishers; three run live ARD POST /search registries with cross-federation. All entries carry did:web + Ed25519 entry-bound detached JWS (RFC 7515 over RFC 8785 JCS), with keys at /.well-known/did.json. Reference registry: POST https://www.snowsure.ai/search.

Running the CLI surfaced two genuinely useful spec-strictness points for other implementers, FWIW:

1. The host object is additionalProperties: false — url/description/contact aren't allowed there (only displayName, identifier, documentationUrl, logoUrl, trustManifest).
2. trustManifest doesn't permit ad-hoc fields like workloadIdentity/publishedFrom; publishing origin goes in provenance[] and attestations require mediaType.

Happy to open a PR adding an "implementations in the wild" table to the README — glad to match whatever placement/format you'd prefer.