Certified-conformance registry

The Spec License §5 says the name travels only with a passing suite. This is where that becomes mechanical: a verifier runs handsel verify --attest against a live endpoint and, on an all-green run, signs a conformance pass-attestation — a canonical two-segment blob (resource · product · suite_commit · checks_digest · verified_at) that anyone can verify-before-parse under a published verifier key. The verified badge links here; the plain badge stays free to wear.

Loading the registry…

How an attestation earns — and loses — the mark

Earn. handsel verify --attest against your live edge; on a passing suite it emits a signed attestation naming the exact suite_commit and a digest of the check vector.
List. The attestation is added to registry.json (today by PR; a handsel publish-attestation follow-up opens it for you).
Lapse (revocation). A newer pinned suite supersedes older attestations — their suite_commit no longer matches the current pin, so they read lapsed. A re-verification cron re-signs on a schedule; miss the freshness window and the mark drops. Stop passing, lose the verified mark on the next cycle. Lapsed entries are kept for history, never deleted.

Status. The attestation format and its offline verifier ship today (@handsel/conformance-kit, handsel verify --attest); this registry is the static, git-backed home (Option A: least attack surface, no money-path). A hosted submission endpoint and the automated re-verification cron are a documented follow-up — until then attestations land by PR.