KYE Protocol™ · per-feature implication table
Why KYE™? For every feature: what fails without it, and which regulator requirement it satisfies.
Read this page if you're the buyer asking “what do I get that I don't already get from a vendor's audit log?”, the auditor asking “which requirement is this binding?”, or the builder asking “what changes in my system if I adopt this?”.
The table below is the canonical mapping — every row links to the implementation in our repo and to the framework clause it satisfies.
Per-feature implication table
Every row is one canonical KYE™ capability. The implication column names the framework requirement the capability binds — published mapping in framework coverage.
| Feature | Without KYE™ | With KYE™ | Regulator-grade implication |
|---|---|---|---|
| Evidence Pack™ | Vendor exports a JSON log. Buyer reads it on the vendor's portal. Trust by faith. | Ed25519-signed envelope. Anyone with the public key can verify what happened — no portal, no vendor cooperation. | HAARF.2 verifiable-by-third-party · ICO Art.30 RoPA-ready · SR 11-7 §V evidence-supportable model decisions |
| WORM audit + retention | Mutable DB rows. “Append-only” means “append-only by convention.” A DBA can rewrite history. | Datastore append-only triggers on audit tables + object-store immutability with per-table retention years. | SEC 17a-4(f) admissible immutability · FINRA 4511(d) · DORA Art 28(8) · EU AI Act Art 12(1) record-keeping |
| Jurisdiction-aware | One global policy. Cross-border transfers are tracked in a spreadsheet, if at all. | 17 locales · 8 Stage-A jurisdictions declared canonically. Cross-border calls emit a signed lawful-basis envelope automatically (GDPR Art 44-49 mechanism). | GDPR Chapter V transfer mechanism · UK Sovereign-AI HAARF v1.0 · EU AI Act member-state designation · Canada PIPEDA cross-border consent |
| Purpose Permission™ | Coarse-grained role/scope checks. “Read access” means read all of it. | Every action declares its bounded purpose; the Purpose Engine evaluates admissibility per-call against the caller's declaration + lawful-basis registry. | GDPR Art 5(1)(b) purpose-limitation · EU AI Act Art 9 risk-management process · NIST AI RMF GOVERN-1.2 traceability |
| Decision Map™ | “The model said yes/no.” No graph from principal → agent → capability → policy → verdict. | Signed graph emitted by the Decision Engine on every verdict. Replay any decision against the snapshot state that produced it. | SR 11-7 §V model risk management · BCBS 239 risk-data aggregation · EU AI Act Art 13 transparency to deployer |
| Replay Proof™ | “Replay” means re-querying the vendor's prod system — with whatever drift has happened since. | Replayable offline against the sealed snapshot. Public-key verification — the vendor doesn't even need to exist to verify. | DORA Art 28 third-party audit · FCA OpRes immutable-evidence requirement · MiFID II Art 17 algo-trading reconstruction |
| Self-Governance | The vendor's claims about their own controls. (No live receipts.) | The protocol governs itself. Every privileged action on our infra emits the same evidence event family you get for your decisions. Live receipts. | SOC 2 CC1.1 organisational control · ISO 27001 9.1 monitoring of operational controls · UK NCSC CAF B6 |
| Canonical Everything | Wikis describe what should exist. Reality drifts. Drift is found at audit time. | Every concept has all three of {manifest, dictionary, schema} on disk, CI-enforced. 69/69 concepts complete today. | ISO 42001 Annex A.6 documented system · NIST AI RMF MAP-2.1 system characterisation · EU AI Act Art 11 technical documentation |
| Zero Stubs / Mocks | Production paths sprinkled with placeholder markers. The procurement deck does not match prod. | CI gate blocks every placeholder/mock-data marker reaching production (see ). 0 violations across the codebase. | SOC 2 CC8.1 change-management evidence · ISO 27001 8.32 change control · banking-grade procurement readiness |
| Zero Competing Systems | Two implementations of the same concept. Neither matches the spec. Bugs route to the wrong one. | Every named capability has exactly one canonical implementation. Single-implementation gate proves it on every merge. | SR 11-7 §VI model inventory · ISO 42001 Annex A.4 lifecycle — one source of truth per system |
| Native Search Engine | Third-party search SaaS (Algolia, Elastic, Meilisearch). Your data leaves your tenant. | Native edge evidence layer (Cloudflare-platform-only). Zero third-party SaaS in the search path. Signed result envelopes. Substrate details are proprietary and not disclosed in this repository. | DORA Art 28 critical-third-party assessment · UK FCA PS21/3 outsourcing register · GDPR Art 28 processor minimisation |
| Dual-channel sign-off | One admin clicks “approve” on an irreversible action. No second human required. | Banking-grade irreversibles require two-channel approval (in-app + signed email). Hard-coded; can't be turned off per-tenant. | BCBS 239 maker-checker · SOX §404 segregation of duties · FFIEC AIO booklet dual-control |
The full per-control bijection (every framework requirement ↔ the KYE™ artefact that enforces it) lives at /compliance/coverage.html — machine-readable JSON + rendered HTML, regenerated on every push to main.
What KYE™ is not
A standard, not a product replacement. Three positions we deliberately do not claim:
- Not a Drata/Vanta/OneTrust replacement. Those are evidence-collection SaaS. KYE™ is an evidence-generation protocol — they ingest unsigned screenshots; we emit signed envelopes. Use both.
- Not a Purview/Collibra/Alation replacement. Those are data-catalogue products. KYE Data Governance Pack™ adds the data-use admissibility layer on top of any catalogue.
- Not a LangChain/CrewAI/OpenAI Agents SDK replacement. Those are agent scaffolding kits. KYE Agent Dev Kit™ adds the self-governing-by-default envelope so agents built with any of those tools can emit the event family.