snowdata
Get started

Open & verifiable

ARD & Agentic Conformance.

The SnowData Network doesn't ask agents to take our word for it. Every resource is published as a signed did:web catalog an agent can verify by recomputing the proof from the bytes — no call back to the issuer. Everything below is independently runnable.

Follow the open contract (ARD #7)

Status. The catalogs, verifier, and corpus below are live today. The seven-property contract and conformance-vector format are an open proposal under discussion in ARD spec issue #7 with the Vaara and TRACE authors. Field names are provisional pending the spec editor.

Verify it yourself

Don't trust — recompute

A standalone, dependency-free verifier (Node ≥ 18). It fetches a catalog, resolves the issuer's did:web document itself, re-canonicalizes each entry, content-addresses it, and checks the Ed25519 signature — carrier-agnostic, with no issuer in the loop.

curl -s https://www.snowsure.ai/ard-verify.mjs \
  | node - https://www.snowsure.ai/.well-known/ai-catalog.json

# same checker, any producer:
curl -s https://www.snowsure.ai/ard-verify.mjs | node - https://lux.ski/.well-known/ai-catalog.json

Runnable conformance

A corpus, not a claim

snowsure-did-web-conformance (v1.0.0) is a standalone, versioned corpus — it imports no SnowData/SnowSure code, so passing it is conformance to the published fixtures, not to us. Two suites: per-record recompute (content address + result re-derivation + signature) and record-set completeness (duplicates, authorized-with-no-outcome, executed-with-no-result, and dropped records all detected — “absent never means clean”).

curl -sL https://www.snowsure.ai/conformance/snowsure-did-web-conformance-v1.0.0.tgz \
  | tar -xz && node snowsure-did-web-conformance/run.mjs

corpusDigest sha256:b6f24a00cfdb9f08058cc8f8c61fa9ea6c0d6495384d5eb8a64cb9518edfd61a · browse the corpus. Content addresses are deterministic SHA-256 over the canonical bytes, so a different-language tool (a std-lib Python generator) re-mints them with no shared code — the vectors are independently producible, not just checkable.

The proposed contract

Seven checkable properties

The shared idea under discussion: pin a small set of checkable properties and let every format be an instance under it — none of them the envelope. The checker and the generator are both commodities; the normative artifact is the content-addressed, digest-pinned vector set any runner reproduces.

1Canonical bytes

The record declares exactly which canonicalization produced the bytes being addressed (here: JCS / RFC 8785).

2Content address

A digest over those canonical artifact bytes — not over a producer's later assertion about the result.

3Evidence family + schema

It names the kind of evidence it carries and the schema/version a consumer reads it under.

4Scope + freshness

It states the boundary it covers and when the observation was made or expires.

5Recompute

A consumer can re-derive the claimed result from the bytes — or the record says it is issuer-attested.

6Coverage

Missing or unchecked coverage is explicit, so absent never quietly reads as clean.

7Non-claims

The record states what it does not cover — anything outside scope, freshness, or coverage.

The network

Signed across the family

Every catalog below is published with a signed did:web trust manifest and is independently verifiable with the command above. Discovery runs through the SnowData Network.

More