Playbook 3 · regulator probe

One decision_id. A full offline replay.

If you are a regulator, an auditor, a dispute panel, or any third party verifying a KYE-anchored decision, you can replay it offline using only the publisher's JWKS — no NDA, no vendor cooperation, no proprietary tooling. The protocol's open contract guarantees that an Evidence Pack™ bound to a decision_id is independently verifiable by anyone holding the publisher's public keys.

What you need

  • The decision_id in dispute or under review — a URN like kye:decision:<tenant>:<sha-prefix>. The party being probed must furnish this; it appears in every audit record they emit.
  • The publisher's /.well-known/jwks.json — their public key set. Always discoverable; the URL never changes.
  • One of: the open KYE™ SDK (TypeScript, Python, or Go) installed, OR curl + jq + an Ed25519 verifier (the SDK is the easy path).
  • No KYE Protocol™ Ltd. cooperation. We name the verifier capability deliberately: there is no field where the protocol publisher can insert itself into a verification.

The 6-step probe

Step 1 · Fetch the Decision Map™

curl -s https://gateway.subject.example/v1/decisions/<decision_id>/map \
  | jq . > decision-map.json

The Decision Map™ is a deterministic projection of one decision: actor → principal → delegation → capability → authority → scope → state → policy → decision → audit → evidence. Every node has a URN; every URN resolves to a signed source artefact. The map is open-format and never edited after first write.

Step 2 · Fetch the Evidence Pack™

EVIDENCE_PACK_ID=$(jq -r '.evidence_pack_id' decision-map.json)
curl -s https://gateway.subject.example/v1/evidence-packs/$EVIDENCE_PACK_ID \
  > evidence-pack.json

The Evidence Pack™ is the signed bundle that backs the decision. Schema kye.evidence.pack.v1. The bundle includes: the canonical Decision Map™, the authority-grant chain at decision-time, the capability invocation record, the relevant rule pack(s) loaded, the obligation set emitted, and any signal-bus events bound to the decision.

Step 3 · Fetch the publisher's JWKS

curl -s https://gateway.subject.example/.well-known/jwks.json \
  > subject-jwks.json

The JWKS lists every key the publisher's gateway has used to sign Evidence Packs, rotated and revoked entries included. The signing KID in the pack header MUST resolve to a non-revoked entry whose not_before ≤ pack timestamp ≤ not_after.

Step 4 · Verify the Evidence Pack™ signature

# Easy path with the open KYE SDK
npx @kye-protocol/sdk verify-evidence-pack \
  --pack evidence-pack.json \
  --jwks subject-jwks.json

# Manual path: extract content_hash, recompute over RFC-8785 JCS, verify Ed25519
jq -r '.signature.value_b64' evidence-pack.json > sig.b64
jq -r '.content_hash'       evidence-pack.json > hash.hex
# verify the Ed25519 signature against the KID-resolved public key

The SDK call returns a boolean + a verdict object. The verdict names which key signed, the timestamp, and whether the signature is structurally valid AND the KID resolves to a non-revoked publisher entry.

Step 5 · Walk the authority chain offline

jq '.authority_chain' evidence-pack.json
# Each entry carries the actor, principal, grant context, scope and
# signature. Verify each delegation signature in turn against the
# JWKS using the SDK's verifyChain() helper — the chain-verification
# construction (per-link entry shape, the scope-attenuation rule and
# the chain-break-detection logic) is part of the patent track and is
# not disclosed in this repository.

This is the substantive verification. You are checking whether the actor at decision-time held a chain of delegations from a root principal that authorised the capability invoked. The protocol guarantees that every link is signed and bound to its parent; the SDK helper applies the canonical verification recipe and returns a single PASS / FAIL with structured break reasons.

Step 6 · Cross-walk against the regulatory framework

jq '.compliance_mappings[]' evidence-pack.json
# Each row maps a KYE™ control to a regulatory framework row, e.g.
#   {"framework":"SR 11-7","section":"III.A","control":"runtime authority"}
#   {"framework":"DORA","article":"Art 6","control":"ICT risk control"}
#   {"framework":"EU AI Act","article":"Art 12","control":"automatic logging"}

289 control mappings across 13 horizontal frameworks (SOC 2, ISO 27001, PCI DSS, PSD3, DORA, NIS2, EU AI Act, ISO 42001, NIST AI RMF, NIST 800-207, NIST CSF, GDPR, FedRAMP) plus 5 sectoral frameworks (HIPAA, MiCA, FFIEC, IEC 62443, 42 CFR Part 2). The compliance-mappings table is part of the protocol; KYE Protocol™ Ltd. does not edit it case-by-case — the cross-walk is deterministic.

What you get

After a 6-step probe, you hold:

  • A signed Decision Map™ you can introduce into a regulatory record.
  • A signed Evidence Pack™ you can attach to a finding, a dispute filing, or an audit working paper.
  • A signature-verification result independent of the subject — you signed it; the subject didn't sign your verdict.
  • A framework cross-walk that maps the decision to the rows in the framework you supervise (SR 11-7 / DORA / EU AI Act / …).
  • Everything is byte-stable. Re-running the probe a year later against the same artefacts produces the same verdict, modulo key rotation.

Probe failure modes — what they tell you

FailureWhat it meansSubject's posture
Pack signature invalidWrong key or tampered bundle.Re-issue from the same audit chain; if the chain was tampered with, the subject is non-conformant.
KID not in JWKSSigning key never published OR revoked before pack timestamp.Subject must reconcile their published key set. A non-published key is a constitutional fail.
Authority link brokenOne delegation in the chain has no valid Ed25519 signature against its claimed signer.The action was not authorised by a chain rooted in a real principal. The decision is unsupported.
Scope expanded mid-chainA sub-delegation grants more than its parent. Constitutionally forbidden.The runtime should have refused to admit this delegation. Either it didn't (implementation defect) or it accepted a forged record.
State mismatchThe state vector at decision-time disagrees with the audit chain projection.The runtime evaluated against stale state; possible cache-coherence defect.
Pack not in transparency logNo transparency receipt for the pack.Transparency log is opt-in; absence is not a fail unless the subject claimed it.

Honest limits

  • We don't tell you the verdict. KYE Protocol™ gives you the evidence and the deterministic verification of that evidence. Whether a particular decision satisfies SR 11-7 III.A or DORA Art 6 remains for you (the regulator) to decide.
  • We don't run the probe for you. The probe is fully offline by design. KYE Protocol™ Ltd. has no role in the verification path. If we ran the probe, we'd be in the loop — we deliberately are not.
  • We don't compel the subject. The subject must hand over the decision_id and their JWKS URL. Refusal to do either is a regulatory matter; we don't have an enforcement role.
  • We don't gate the SDKs. The verifier SDKs (TypeScript / Python / Go) are Apache 2.0. You can fork them, audit them, or rebuild them line by line.

Next steps