Don’t trust our governance. Verify it.

Most AI-governance vendors ask you to trust a closed scoring black box: opaque logic, a number you cannot reproduce, an audit trail that lives only on their dashboard. KYE Protocol™ takes the opposite stance — its schemas, ID format and examples are public, its OSS surface is Apache-2.0, and every governance decision is Replay-Proof™: you verify it offline from a published JWKS alone, with no KYE™ service in the loop. Open where it counts for trust; commercial in the engine.

Start a governed pilot Verify a live decision

Two answers to one question: “why should I believe your governance?”

Every governance buyer — a CISO, a DPO, counsel, a CFO — eventually asks the vendor to prove the verdict. There are only two honest answers, and they are not the same. This is a fair contrast, not a strawman: closed governance can be competent; it simply asks you to trust rather than letting you check.

Proprietary / closed governance

  • Trust the vendor. The scoring logic is internal IP you cannot inspect or reproduce.
  • Opaque scoring. You get a verdict and a confidence band; the rules that produced them are not disclosed.
  • Audit = their dashboard. The evidence lives in their console, on their clock, and disappears if you churn.
  • Verification needs the vendor. To re-check a past decision you must call their service and trust the answer.

KYE Protocol™ — open + verifiable

  • Public schemas, ID format and examples. The contract every decision is shaped by is on the open web for you to read before you buy.
  • Apache-2.0 OSS surface. The public/oss/ tree — including the software/constitution Kit™ KYE™ dogfoods — ships under a permissive licence you can fork.
  • Replay-verifiable evidence. Each decision is sealed into an Evidence Pack™ you keep, mapped across 164 frameworks.
  • Verification needs no vendor. Anyone re-derives the proof from the published JWKS — KYE™ does not have to be online for the check to hold.

Trust-me vs verify-me, in one picture

The whole argument reduces to where proof lives. In a closed system, proof is locked inside the vendor and you take the verdict on faith. In KYE Protocol™, the proof is a signature you and any third party can check against keys the vendor has already published.

Left: a closed black box emits a verdict you must trust. Right: KYE publishes a signed decision plus a public key, and anyone verifies it independently. Trust me Closed box internal scoring Verdict take on faith You cannot re-check Proof stays inside the vendor. Verify me Signed decision Evidence Pack + context seal Public JWKS published key Anyone verifies offline no KYE service in the loop Proof travels with the decision.
Left, the proof never leaves the vendor, so checking it means trusting them. Right, Authority Sourcing™ seals the decision and KYE™ publishes the verification key, so you — or your auditor — re-derive the proof independently.

What “open” honestly means here

KYE Protocol™ is not fully open-source, and we will not let this page read as if it were. Being precise about the boundary is itself part of being verifiable — overclaiming is the opposite of trustworthiness.

The honesty boundary. What is open is the vocabulary, the schemas, the URN ID format, the worked examples, and the Apache-2.0 software/constitution Kit™ — plus the public-key verifiability of every output. The runtime that actually makes admissibility decisions — the engine, the mechanisms, the patent-track internals — is commercial. So the claim is narrow and true: open where it counts for trust (the schemas you read and the proofs you check), commercial in the engine that earns its keep. KYE Protocol™ is not a fully open-source product, and a page about transparency should say so plainly.

Why this split is the trustworthy one: you do not need the engine’s source to trust a decision — you need to read the contract it was shaped by and re-check the proof it emitted. KYE™ opens exactly those two surfaces and keeps the engine commercial, rather than open-washing the parts that do not affect whether you can verify the result.

Why a CISO, a DPO, counsel and a CFO each prefer verifiable

Verifiability is not a developer nicety — it changes what each buyer can defend. One open, replay-proof contract serves four very different questions.

For a CISO — when an agent does something it should not have, you replay the sealed decision and read the exact failed control, instead of escalating a support ticket into a closed vendor’s queue.
For a DPO — open schemas mean you can show a supervisory authority precisely what data shaped a decision under the EU AI Act™ Article 12 logging duty and GDPR accountability — not a vendor’s paraphrase.
For counsel — a Replay-Proof™ Evidence Pack™ is admissible on its own signatures; it does not depend on a vendor staying solvent or cooperative to stand up in a dispute.
For a CFO — an Apache-2.0 surface plus portable evidence is the opposite of lock-in: your audit trail and the contract behind it survive a vendor switch, mapped across ISO/IEC 42001™ and NIST AI RMF.

Start a governed pilot See the self-audit fixture