Playbook 2 · vendor conformance run

133 fixtures. One signed report.

If you ship a gateway, agent runtime, or PDP that claims compatibility with KYE Protocol™, you back that claim with a signed kye.conformance_report.v1. This playbook walks you through running the 129-fixture conformance pack against your implementation, signing the report, and posting the verification record to the public KYE Conformant™ registry.

What the pack tests

The conformance pack is a black-box test suite. It does not introspect your implementation; it sends signed input fixtures and checks signed output fixtures. The 133 fixtures cover:

  • Core — entity registration, delegation grant / revoke, scope intersection, the canonical decision pipeline (entity → authority → purpose → scope → state → rules → decision → evidence), audit-event emission, replay-from-evidence-pack.
  • The 10 canonical profiles — one fixture set per profile (core, connector, manifest, conformance, pdp, epdp, spdp, pep, runtime-authority, evidence-replay). Each set verifies that an implementation claiming the profile honours the locked input / output contract.
  • 57 rule packs — rule-pack-load + rule-pack-evaluate fixtures for every shipped rule pack (eu-ai-act, financial-services, payments, healthcare, cargo-routing, compliance-evidence, action-admissibility, recovery, transparency, federation, treasury, custody, …).
  • 49 sector packs — sector-pack-load + obligation-emission fixtures for every shipped sector pack (banking, healthcare, payments, insurance, pharma, logistics, energy, …).
  • Edge / determinism — idempotent retry, all-or-nothing cascade behaviour, version negotiation (Accept-Version), RFC 7807 error envelope, cryptographic-agility (Accept-Crypto-Suite).
  • Self-governance — every conformance run itself emits the §0.3 governance event family; the pack verifies the run's own audit chain integrity.

The 5 steps to a signed report

Step 1 · Clone the pack

git clone https://github.com/KYE-Protocol/app
cd app/internal
npm ci

The pack is open (Apache 2.0). Your gateway can run it locally during CI, in a staging environment, or in production read-only. The pack does not write to your data plane — every fixture targets an isolated tenant URN (kye:tenant:conformance-run-<runtime-uuid>).

Step 2 · Point it at your gateway

# Required
export KYE_GATEWAY_URL=https://your-gateway.example/v1
export KYE_GATEWAY_AUTH="Bearer <token>"

# Optional
export KYE_GATEWAY_RELEASE=1.4.7
export KYE_GATEWAY_TIER=tier-1-bank   # or tier-2 / tier-3
export KYE_DEPLOYMENT_TOPOLOGY=saas    # or self-hosted / hybrid

Step 3 · Run the pack

npm run run
# 133 fixtures · reports per-fixture pass / fail / skip + timing
# Outputs ./out/conformance-report-<timestamp>.json

Every fixture is deterministic. Re-running the pack against the same gateway release at the same git SHA MUST produce a byte-identical report (modulo timestamps, which are normalised in the canonical hash). If your implementation is non-deterministic, the conformance ladder caps you at L1 (Self-Declared).

Step 4 · Sign the report

# Sign with the same Ed25519 key your gateway uses to sign Evidence Packs.
# The pack writes the canonical sha-256 (RFC 8785 JCS) into "content_hash"
# and a detached signature into "signature".
npm run sign -- --kid <kid> --key /path/to/ed25519-private.pem \
                ./out/conformance-report-<timestamp>.json

Step 5 · Post to the public registry

curl -X POST https://api.kyeprotocol.com/v1/conformance/registry \
  -H "content-type: application/json" \
  --data @./out/conformance-report-<timestamp>.json

The public registry validates the signature against the publisher's JWKS (you publish at /.well-known/jwks.json on your gateway host), then writes a verification record into the public registry. You appear on the certification registry with the timestamp, fixture-pass rate, and the conformance level you claim.

The conformance ladder

LevelNameVerifierWhat it asserts
L0DeclaredvendorThe vendor declares conformance. No fixture run required. Marketing-grade only.
L1KYE™ Self-Declared™vendorVendor signs a conformance-report.json showing the fixtures it ran (any subset). Posted to public registry.
L2KYE Self-Tested™vendorVendor runs the full 129-fixture pack and signs the report. 133 / 133 must pass. Deterministic re-run required.
L3KYE Conformant™audit firmAn approved audit firm runs the pack against the vendor's gateway and signs the verification. Annual revalidation.
L4KYE Certified™audit firm + KYE Protocol™ Ltd.L3 plus a signed live-incident playbook walk-through, plus capability-scoped Conformance badges per profile (Core / Authority / Capability / Evidence). Annual revalidation.

A vendor self-attests at L1 / L2 directly. L3 and L4 require an engagement with an approved audit firm; the firm's roster lives at auditors.html.

What lives in a signed conformance-report.json

  • subject. Your gateway URL, vendor name, release tag, deployment topology, advertised profile list (e.g. ["core", "pdp", "pep", "evidence-replay"]).
  • conformance_pack_version. Currently 1.0.0 — the version of the 129-fixture pack you ran.
  • tier_claimed. One of tier-1-bank, tier-2-mid-market, tier-3-reference. Determines which quantitative SLA thresholds apply (p50, p99, throughput, cascade latency).
  • fixtures. One entry per fixture: id, category, outcome (pass / fail / skip), duration_ms, started_at. Skipped fixtures must cite a reason; an L2 claim requires zero skips.
  • content_hash. sha-256 over the canonical RFC-8785 JCS encoding of the report minus the signature field.
  • signature. Ed25519 detached signature of content_hash by the publisher's KID.
  • transparency_receipt. Optional receipt from the publisher's transparency log; the public registry adds one on receipt and links to it.

All fields are validated against kye.conformance_report.v1. The schema is in the public mirror; public/examples/conformance-report.json is a reference example that validates clean against the schema.

Next steps