CONFORMANCE
Measured, not asserted. The program attests exactly the bytes it re-runs against the published vector suite at your pinned commit.
How verification works
Requirements live 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 44 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 ->
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 44 vectors (suite 1.0.0, vectorSetHash sha256:81d537d4574d3f66d651a03ca41c0b18493b67ea6f3e61aba47d1bda4f3cf49b), generate the claim JSON with scripts/make-claim.mjs, and open a conformance submission issue on kya-os/kya-os-usergroup with the claim.
The badge
The payoff of the pipeline. A badge is not a logo you paste — it resolves to the signed credential behind it, so anyone can verify your claim without trusting this site. The waveform is the credential's signature fingerprint: the same credential always draws the same wave, and a re-issued one redraws it completely.
It renders verified only while the claim links its credential; revoke the credential and every embedded badge downgrades itself. Amber means the program is still re-running your suite.
Embed it the day you are listed: the static tiers build with the site — grey listed and self-reported, amber in verification — and the badge upgrades itself as your status climbs the ladder, because the Phase B worker takes over the same URLs for live credential verification. Only the worker ever renders verified.
KYA-OS
✓ L1 verified v1.0.0
KYA-OS
◌ in verification
KYA-OS
· no claim
static tiers build with the site at /badge/<slug>.svg · the verified tier ships at Phase B on the same paths — states shown are the real state machine
Levels
Identity anchored - anonymous calls stop here. Ed25519 signing and verification over canonical digests, against a DID the caller can prove it owns. The entry point for any implementation.
Sessions that refuse replay - handshake, nonce and skew rules, and detached proofs binding every response to its request over a live transport binding.
Authority you can revoke - attenuated delegation chains, fail-closed revocation checks, and tamper-evident audit, enforced end to end. The level that stops a rogue spend.
Verification states
claim.json received. The claim is public from the moment it lands — nothing is gatekept. open a submission issue ->
The claim links its credential. Only this state counts as verified — a claim without a linked credential never displays it.
The static badge tiers at /badge/<slug>.svg mirror these chips; the verified tier ships at Phase B of the program as live credential verification on the same paths. Until then the status chips are the source of truth.