Put KYE™ inside your product.

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.

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.

Canonical KYE™ surfaces referenced on this page: Purpose Permission.