Curriculum

The exam: conformance

The conformance exam · Checklist 2026-10-12 · 12 checks · runs are computed live and not stored · Machine form: /v1/curriculum/the-exam · Markdown

The curriculum's exam is the public conformance checklist, carried here verbatim — its version, its checks, and what each check proves. Sitting the exam is running the conformance check against a deployment: GET /v1/conformance runs it against this deployment, and the MCP check_conformance tool runs it against any deployment's URL. A pass is every check on the checklist passing. The result is reported by the deployment under test itself, runs are computed live and stored nowhere, and this surface records no result, keeps no pass rate and issues no credential for passing.

Lessons

• The conformance page — The exam in human form: the checklist, the badge, and how a result reads. Study: /conformance · Run: GET /v1/conformance
• The verifier vectors — The conformance vectors: a reference chain built and signed correctly, plus altered copies labeled with the checks that must fail — how an independent verifier is itself examined. Study: /v1/conformance/vectors
• Reading a failed check — When a check fails, the diagnostics index resolves the signal: what it means and the next step. Study: /diagnostics/conformance-failures · Run: GET /v1/diagnostics/conformance-failures

The checklist

• Discovery documents — The manifest, the OpenAPI description and the agent entry point (llms.txt) are all served, so an agent that has never heard of Rightshold can bootstrap from a bare URL.
• Agent card — The well-known agent card names the platform and its endpoints, so crawlers and agent frameworks can identify the deployment.
• MCP initialize — The MCP endpoint answers a protocol initialize and identifies itself as the Rightshold server with a supported protocol version.
• MCP core tools — tools/list exposes the core rights, identity and ledger tools an agent integration depends on (ask_rightshold, check_license, kya_lookup, verify_rights_manifest, ledger_verify).
• KYA configuration — The open RS-KYA standard's levels (L0–L2) are published at the well-known configuration and at /v1/kya, so relying parties can read the level definitions from the deployment itself.
• Issuer keys published — The keys that sign registration certificates and ledger blocks are published with their status, so signatures can be verified without trusting the deployment.
• JWKS published — The JSON Web Key Set behind kya+jwt tokens is served, so tokens can be verified offline.
• Honest pricing document — The machine-readable pricing lists every line with its planned price, states that nothing is charged during the preview, and names placement, grades and verdicts as never for sale.
• Ledger head served — The public append-only ledger answers with its signed head block, so history is inspectable from the outside.
• Published rate limits — The limits are published at /v1/limits and every API response carries its remaining budget, so agents can pace themselves instead of guessing.
• Ask answers deterministically — A plain-English rights question gets a deterministic license verdict (permitted, prohibited, needs_review or not_documented) — the decision agents actually rely on.
• A2A endpoint — The A2A (Agent2Agent) endpoint the agent card names as its url answers message/send with a completed task carrying the structured result, and tasks/get returns the same task — so A2A-native agents can work with the deployment, not just read its card.