--- title: "KYE Protocol™ — Evidence Pack™ · step 8 of the KYE™ stack" description: "KYE™ Evidence Pack™ — the signed, replayable bundle of audit-chain entries, Decision Maps™, signatures and public-key set that a regulator or auditor…" url: https://kyeprotocol.com/evidence-pack/ lang: en source: "KYE Protocol" --- > KYE™ Evidence Pack™ — the signed, replayable bundle of audit-chain entries, Decision Maps™, signatures and public-key set that a regulator or auditor… Step 8 · Evidence Pack™ # Signed semantic artefact a regulator can replay offline. Steps 1–7 produce names, hierarchy, meaning, contracts, state, decisions and enforcement. Step 8 is the artefact: a signed bundle that ties everything that happened to one decision into a single replayable record any third party can verify against the published JWKS without contacting the issuing system. 1 · What's inside ## Audit chain. Decision Maps™. Signatures. JWKS. - **Audit-chain segment** — the append-only hash-linked sequence covering the decision and its predecessors. - **Decision Map™** — signed inputs → rules → outcome record for the decision. - **Execution-context seal** — a signed record of _exactly which policy version was in force_ at decision time: the `rule_bundle_hash` (sha256 of the compiled rule bundle), the model build hash, the per-signal versions and the wall-clock instant. Without this seal a decision cannot be replayed. - **Continuity inclusion-set** (when the Continuity Profile™ is in play) — the canonical set of intent, state, oversight and drift artefacts bound at decision time. The specific component enumeration and the canonical-encoding rule are proprietary and are not disclosed in this repository. - **Semantic Assertion** (when the Ontology Profile™ is in play) — every term, mapping and predicate consulted at decision time. - **Adoption Evidence Pack™** reference (when the Operating Model Profile™ is in play) — intake + readiness + authority record + gates + commit boundaries + review paths + training. - **Provenance evidence** reference (when the Assurance Card Profile™ is in play) — model / dataset / tool / supplier / licence lineage. - **Signature** — Ed25519 over the canonical-JSON serialisation; key id resolves against the published JWKS. - **Public-key set reference** — the JWKS URL the verifier must trust to replay. 2 · The sealed chain ## One decision. Six sealed stages. An Evidence Pack™ is not a log file. It is an ordered chain in which each stage seals the one before it, so you can read a governed decision the way an auditor replays it — top to bottom, with the order itself carrying the proof. These are the six canonical evidence events KYE Protocol™ emits for every consequential action. 1. 01 Purpose requested `kye.purpose.request.v1` 2. 02 Admissibility decided `kye.purpose.admissibility.v1` 3. 03 Decision mapped `kye.evidence.decision_map.v1` 4. 04 Context sealed `kye.replay.context_seal.v1` 5. 05 Pack assembled `kye.evidence.pack.v1` 6. 06 Replay proved `kye.replay.proof.v1` Each bar starts inside the stage before it: that overlap is the seal. Break any one link and the chain stops verifying — which is why a KYE Protocol™ replay either reproduces the original outcome exactly or fails loudly, and never quietly returns a different answer. 3 · Which policy was in force? ## The proof pins the exact policy version at decision time. Policies change — in regulated work, sometimes day to day. “The agent followed the policy” is not auditable. KYE Protocol™ seals the precise rule set that authorised each action, so the record holds even after the policy moves on. Concretely: an agent approves a transaction at 14:02 under policy **v1.3**. The next day the rule set is tightened to **v1.4**. The Evidence Pack™ for that 14:02 decision still carries the `rule_bundle_hash` of v1.3 and the wall-clock instant it was in force — signed at decision time. A regulator re-running the bundle gets the same outcome under v1.3, and can prove v1.3 (not v1.4) was the authority that allowed the action. The later change to v1.4 cannot rewrite what was provable about the 14:02 decision. - **Versioned** — every compiled rule bundle carries a `version` and a `sha256` `bundle_hash`. - **Pinned at decision time** — the execution-context seal binds that hash plus the wall-clock instant to the specific decision. - **Signed & independently verifiable** — the replay proof is an Ed25519-signed assertion you check against the published JWKS, without contacting the issuing system. 4 · Why one bundle, not seven ## A regulator should not need seven systems. The Evidence Pack™ exists so an auditor, regulator, court, dispute reviewer or downstream tenant can _replay_ a decision end-to-end with one bundle and one JWKS — not a seven-system tour. The same bundle is what an incident-response team replays for forensic reconstruction; what a compliance-mapping rail projects into framework-specific views (SOC 2, ISO 27001, NIST AI RMF, EU AI Act, DORA, …); and what KYE™ Cloud Gateway™ archives under retention. Where to go next ## Walk back through the stack → [← Step 7 · Runtime gateway](https://kyeprotocol.com/gateway/) [Restart · Step 1 · Dictionaries](https://kyeprotocol.com/vocabulary/) [Read the whitepaper](https://kyeprotocol.com/whitepaper/) ## Ready to see your AI agents flagged? Start in shadow mode. We’ll deliver your first Evidence Pack™ in 4–8 weeks. [Apply for pilot →](https://kyeprotocol.com/pilot-apply/) [Try the sandbox →](https://kyeprotocol.com/sandbox/demos/) Canonical KYE™ surfaces referenced on this page: [KYE™ Cloud™](https://kyeprotocol.com/apps/) · [KYE Protocol™](https://kyeprotocol.com/).