CONFORMANCE
What you get: a signed, revocable credential for exactly what the program observed, a badge that re-verifies against that credential every time it renders, and a listing that climbs the ladder in public. Measured, not asserted: the program attests exactly the bytes it re-runs against the published vector suite at your pinned commit.
The badge
The badge resolves to the signed credential behind it, so anyone can check your claim without trusting this site. Revoke the credential and every embedded badge downgrades itself.
KYA-OS
· listed
the visual only, at the rung a new entry starts on: listed. It turns green when the program issues your credential, never before · seed your-slug#L1 full - the same derivation the directory row draws your wave from
the badge this site serves for @kya-os/mcp right now:
Paste this into your README the day you are listed - it is the same /badge/<slug>.svg the build emits and the worker serves, so it climbs as your status does:
It has seven states and nothing else: listed, self-reported, in verification, verified, under appeal, revoked, and unverified (the fail-closed answer to any failure). Only a verified credential with clean status bits renders green. The badge served today is rebuilt from that cryptographic verification on every deploy; the worker tier, which re-verifies per request, is armed and ships on its own dispatch.
What a verified claim gives you
- Interoperability you can point at. Your implementation passed the same 48 vectors the reference implementation passes, so peers know which behaviors to expect from it.
- A claim anyone can check. A signed, revocable credential at a canonical URL, and a badge that re-verifies it - not a logo you paste.
- Behavior under authority. The Level 2 and Level 3 requirements exercise consent gating (
needs_authorization), delegation attenuation (a chain that widens scope is rejected), and revocation, so a verified L3 says those paths were tested against the pinned vectors. Tested is the whole claim: the credential asserts a test result, not that your agent is safe.
How verification works
Requirements are defined in CONFORMANCE.md. Any language that can read JSON and do Ed25519 + SHA-256 can play. A level is claimed in full or as a named subset of vector categories - a subset claim covers exactly the categories it names and never rounds up to the bare level.
Fetch the pinned vectors hash-verified, run all 48 through your adapter.
Open a conformance submission issue with your claim.json.
The program re-runs your suite and attests exactly what it observes.
Your registry entry carries the claim; the credential makes it portable.
Fastest on-ramp: the conformance starter - clone to a submission-ready claim in under an hour.
These are rungs of one ladder, not a separate act: listed in five minutes, self-reported the same hour, verified when the program re-runs your bytes - join on the builders page ->
Services: add a probeUrl to your registry entry and the daily probe verifies your deployment enforces, independent of any claim - a bare request on the wire, answered by the protocol's own refusal.
or copy manually
Prove my KYA-OS implementation conformant: clone https://github.com/kya-os/kya-os-usergroup and follow conformance/starter/README.md - fetch the pinned vector suite, run my implementation against the 48 vectors (suite 1.1.0, vectorSetHash sha256:38f34222fd91e75a162b01a81f83aa40907674f9c1bed72c46f1861cb49ceef5), generate the claim JSON with scripts/make-claim.mjs, and open a conformance submission issue on kya-os/kya-os-usergroup with the claim.
Levels
CONFORMANCE.md defines three levels. Each builds on the previous, with increasing capability requirements, and an implementation must pass all tests for a level to claim conformance at it. Levels are capability tiers, not vector ranges: the suite is one pinned set (suite 1.1.0, 48 vectors in 9 categories, per SUITE-MANIFEST.json), and a claim names the level your implementation supports, in full or as a named subset of categories.
"Level 1 establishes the cryptographic foundation. An implementation at this level can generate identities, sign data, verify signatures, and expose discovery metadata."
Requires an Ed25519 key pair with a did:key DID, SHA-256 over RFC 8785 (JCS) canonical JSON, EdDSA signing and verification in JWS compact serialization, and did:key resolution to a DID Document. Audit logging MAY be implemented.
"Level 2 adds session management with replay prevention and proof generation. An implementation at this level can establish secure sessions and generate non-repudiation proofs."
Requires all of Level 1, plus handshake validation, nonce format and uniqueness (replay prevention), a timestamp skew of 120 seconds by default, session TTL, and detached proofs (a JWS binding a tool request and its response together) that carry the request and response hashes and verify against them. Audit logging SHOULD be implemented.
"Level 3 adds W3C Verifiable Credential-based delegation with revocation support. An implementation at this level can issue, verify, and revoke delegations, and propagate delegation context on outbound calls."
Requires all of Level 2, plus issuing and verifying DelegationCredentials, StatusList2021 status checks, delegation chain validation with cascading revocation, and a delegation proof on outbound calls. Audit logging MUST be implemented.
Audit assurance is a separate axis, not a fourth level: the Audit Assurance Profile ladder (AAP-0 to AAP-4: no claim, Recorded, Chained, Transparent, Observed) is claimed alongside L1 to L3, and each profile requires all lower profiles plus its own executable evidence.
Implementations
| Implementation | Claim | Suite | Status | Links |
|---|---|---|---|---|
| KYA-OS Demo Server | L3 full | 1.0.0 |  |
homepage -> credential -> |
| @kya-os/mcp | L3 full | 1.0.0 |  |
repo -> credential -> |
| your implementation here - claim conformance -> | ||||