Build on KYE™ · KYE™ Inside — embed the authority + evidence engine

Put KYE™ inside your product.

The authority + evidence engine you embed so your app can prove who authorised every consequential action — without building the governance plumbing yourself. Your branded product keeps its own face; KYE Protocol™ runs underneath as a black-box engine: the SDK/API, the decision point at the action boundary, and sealed evidence you can replay. Ship audit-ready in weeks, not quarters.

rocket_launch Start a proof of concept verified See an Evidence Pack™ integration_instructions What you embed
What “embedding the engine” means

You call the engine; it rides the rails as-is.

Build on KYE™ is not a rebuild and not a services engagement — it is the existing KYE Protocol™ runtime, embedded under your own branded app through a stable SDK and API. Your team writes the product; the engine answers one question at the action boundary — was this action authorised? — and returns a sealed, replayable record. You never re-implement the governance layer.

  • SDK / API you call, not a framework you host. Your app sends the proposed consequential action to the engine and receives an ALLOW / DENY / REQUIRE-approval verdict. The TypeScript and Python SDKs wrap the same endpoints KYE Protocol™ runs internally — integration is a client call, not a governance rewrite.
  • The decision point at the action boundary. Purpose Permission™ admissibility is evaluated the moment an action is proposed — before money moves, before an account is touched, before a document is filed. The verdict is the gate; your app enforces it.
  • Evidence Pack™ sealing, automatic. Every governed action emits the §0.3 evidence family (kye.purpose.admissibility.v1, kye.evidence.pack.v1, kye.replay.proof.v1) into a WORM audit trail. You get a hash-sealed Evidence Pack™ per action without writing a line of audit code.
  • Replay-Proof™ from public keys alone. An auditor, a regulator, or your own risk team can re-derive any verdict from the sealed record and KYE Protocol™'s published keys — no access to your database, no trust in your word. Irreversible actions carry dual-channel sign-off.
One engine, many branded projections

The KYE™ Inside pattern, applied under your ops apps.

These are integration patterns, not shipped KYE™ products — the same embedded engine answering “who authorised this?” under whatever branded operations app your team already ships. You own the workflow and the UI; KYE Protocol™ supplies the authority and the evidence underneath.

payments Payments & AP/AR An AP/AR app where an agent releases a payment run or approves an invoice — the embedded engine proves the release was within authorised limits before the money moves.
build CMMS / maintenance A CMMS where an agent dispatches a work order or signs off a safety-critical repair — KYE Protocol™ records who was allowed to authorise it.
local_shipping Supplier & order A procurement app where an agent places a supplier order or amends a contract — the engine seals a replayable record of the authority behind each commitment.
engineering Field ops A field-operations app where an agent approves an on-site change or releases equipment — the authorisation is governed at the boundary and evidenced for later replay.
Worked example

EPC contracting: an agent releases a change-order.

Picture a branded EPC capital-project platform your team builds for contractors. An agent inside it proposes a change-order release worth several hundred thousand on a live project, or approves a milestone invoice against the contract. The moment it acts, the embedded KYE Protocol™ engine decides whether that agent was authorised — and proves it.

  • The action is checked before it lands. The change-order release is sent to the engine as a proposed consequential action; Purpose Permission™ admissibility returns ALLOW only if the agent's delegated authority covers that project, that value band, and that change type.
  • The proof is sealed, not asserted. The verdict and its inputs are hash-sealed into an Evidence Pack™ in a WORM trail, re-derivable by the client's auditor via Replay-Proof™ from public keys alone.
  • The value is faster enterprise adoption. Because your platform ships with banking-grade authority and evidence built in, it passes a regulator-style spot check on day one — cutting an enterprise buyer's security review from weeks to days instead of stalling the deal for a quarter.
Who it’s for & how you adopt it

SDK → govern → evidence → replay.

Build on KYE™ is for product teams and platform builders who ship an app where an agent or a system takes a consequential action — and who would rather embed a proven authority engine than build, staff, and defend one. Adoption is four honest steps, and the engine stays a black box behind your brand.

  • 1. SDK. Add the KYE™ SDK to your service and send proposed consequential actions to the engine. Days of integration, not a governance programme.
  • 2. Govern. The engine evaluates admissibility at the action boundary and returns the verdict your app enforces — ALLOW, DENY, or REQUIRE-approval with dual-channel sign-off on irreversibles.
  • 3. Evidence. Every governed action seals an Evidence Pack™ into a WORM audit trail automatically — your compliance surface, populated for you.
  • 4. Replay. Any verdict is Replay-Proof™ from KYE Protocol™'s public keys alone, so auditors verify without touching your systems.

Honest scope: KYE™ governs whether the action was authorised and proves it — it is not your application. You build the product and own the workflow; the engine supplies authority finality and the evidence, and nothing more.

Which door is yours

Embed the engine — a different door from co-founding or listing.

Build on KYE™ is the buy-and-embed path: you take the existing engine as-is and run it under your own product. If your need is co-creation or public recognition, those are separate surfaces — and you will be pointed to them honestly.

  • Build on KYE™ — embed the engine. You ship your own branded app and embed the KYE Protocol™ authority + evidence engine underneath, via SDK/API. This page.
  • Venture Studio — co-found a new venture. If instead you want KYE™ as a co-founder taking equity in a brand-new authority-native company, that is the KYE Authority-Native Venture Studio™ — not this.
  • KYE-Powered Directory™ — be listed as an adopter. Once you run on the engine, you can consent to public listing in the KYE-Powered Directory™. That is recognition, not the embed itself.

Bring the product. Put KYE™ inside it.

Start a proof of concept: send your first consequential action through the engine, get back a sealed Evidence Pack™, and see your app prove who authorised it — in weeks, not quarters.

rocket_launch Start a proof of concept → verified See an Evidence Pack™