--- title: "KYE Protocol™ — Operating Model Profile · readiness to runtime control" description: "KYE™ Operating Model Profile™ — the enterprise adoption layer of KYE™. From use-case intake to readiness, authority records, authority gates, commit…" url: https://kyeprotocol.com/operating-model/ lang: en source: "KYE Protocol" --- > KYE™ Operating Model Profile™ — the enterprise adoption layer of KYE™. From use-case intake to readiness, authority records, authority gates, commit… KYE™ Operating Model Profile™ # From readiness to runtime control. Who runs the protocol. Who runs the engine. Who runs the tenant. Three layers. Three sets of keys. [Apply for pilot →](https://kyeprotocol.com/pilot-apply/) [Read the docs](https://kyeprotocol.com/docs/) **KYE™ Operating Model Profile™** turns AI-governance operating models into runtime authority decisions and replayable evidence — from use-case intake to controlled execution. Plain Q&A ## Plain Q&A Short questions. Short answers. - **Who runs the rules?** The protocol. - **Who runs the engine?** The engine team. - **Who runs the data?** You do. - **Who holds the keys?** You do. - **Where do logs go?** To your store. - **Where do proofs go?** To your store. - **Do you see raw data?** No. Never. - **Can I bring my own KMS?** Yes. - **Can I bring my own store?** Yes. Plain take ## Plain take Three layers. Three sets of keys. Clear lines. - Protocol owns the rules. - Engine owns the runtime. - Tenant owns the data and the keys. - We never see your raw data. Ever. 1 · The 10-stage journey ## Use-case intake → runtime decision → replayable evidence. Each stage emits a signed event onto KYE™ Signal Bus™ and is recoverable from the audit ledger. 01 **Use Case Intake** `KYEUseCaseIntake` — actor type, expected actions, systems, data classes, external effects, commit actions. 02 **Readiness Assessment** `KYEReadinessAssessment` — multi-dimension scoring with a canonical interpretation. Scoring construction is proprietary. 03 **Risk Classification** Risk tier (`low` / `medium` / `high` / `critical`) embedded in the assessment. 04 **Map Authority** `KYEEntityAuthorityRecord` — living governance record per delegated actor. 05 **Place Gates** `KYEAuthorityGate` records before high-impact capabilities. 06 **Configure Runtime** `KYECommitBoundary` records bind recommendation ↔ committed action. 07 **Execute** Runtime `KYEPolicyDecision` at the decision endpoint. 08 **Evidence** `KYEAdoptionEvidencePack` — signed, hash-chained, offline-verifiable. 09 **Review** `KYEReviewPath` — multi-step human-review chain with SLAs. 10 **Improve** Revisions to any of the above; full revision chain in the audit ledger. 2 · Authority Gates™ ## Place runtime gates before high-impact actions. Authority Gates™ define where an AI worker, workflow, API, model or tool must stop, check authority, request approval, deny execution, quarantine the action or generate evidence. ### payment\_execution Before a prepared payment becomes an executed payment. ### external\_message Before an outbound message leaves the tenant. ### contract\_signature Before a contract / e-signature is sealed. ### clinical\_action Before a clinical action is performed. ### infrastructure\_command Before an infrastructure command is issued. ### data\_export Before a data export leaves the tenant. ### credential\_rotation Before a credential is rotated. ### evidence\_export Before an evidence pack is exported beyond the tenant. 3 · Commit Boundary™ ## AI can recommend. KYE™ decides whether the action may commit. The commit boundary is the point where an AI suggestion, plan, draft or preparation becomes an external action with real-world effect. draft emailsend email prepare paymentexecute payment recommend refundissue refund draft contractsign contract suggest clinical stepperform clinical step plan infra changeexecute command recommend access grantissue access grant propose policy editapply policy edit **Separate recommendations from committed actions. KYE™ checks authority before the action becomes real.** 4 · Entity Authority Record™ ## Every AI agent, workflow, model or tool gets a governed authority record. Owner. Purpose. Capabilities. Scope. State. Risk. Decisions. Evidence. Revocation status. One living record — signed, chain-bound, replayable. Entity Authority Record™ · preview ### Finance Payment Preparation Agent pilot 5 · Schemas (Apache 2.0, public mirror) ## Ten normative objects. Validated in CI. - `operating-model-profile.json` — profile manifest - `use-case-intake.json` — stage 1 intake - `readiness-assessment.json` — stage 2 multi-dimension assessment - `entity-authority-record.json` — stage 4 living record per actor - `authority-gate.json` — stage 5 runtime gate - `commit-boundary.json` — stage 6 recommendation ↔ commit boundary - `review-path.json` — stage 9 human-review chain - `training-record.json` — per-owner training + certification - `adoption-evidence-pack.json` — stage 8 signed pack - `governed-catalog-entry.json` — discovery entry per governed entity Each stage emits a signed event onto KYE™ Signal Bus™. The runtime never relies on out-of-band webhooks — KYE™ uses an authenticated, signed event bus with replay-resistant signatures. 6 · Try it — readiness checker ## Tell us about your AI worker. We'll show what KYE™ requires. Front-end illustration only — no data leaves the page. Real implementations call `POST /v1/readiness-assessments`. ## Contact Your request goes to the KYE Protocol™ team, and a receipt with a reference number is emailed to you. Name Email Organisation Topic Message I agree to the [privacy policy](https://kyeprotocol.com/legal/privacy/). Send ### Suggested KYE™ requirements Heuristic illustration. The real `POST /v1/readiness-assessments` applies the calibration values held in the operating-model engine. 7 · Open / paid boundary ## The contracts are open. The managed engine is paid. One sentence: a signed, replayable proof of decision. Open source ### Open - Operating Model Profile™ schema - Use-case intake + readiness assessment schemas - Entity Authority Record™ schema - Authority Gate™ + Commit Boundary™ schemas - Review path + training record schemas - Adoption Evidence Pack™ schema - Governed catalogue entry schema - Reason-code dictionary · signal bus event names - Sample payloads · basic conformance fixtures Commercial track ### Paid - KYE™ AI Worker Readiness App™ - KYE™ Authority Gate Designer™ - KYE™ Commit Boundary Monitor™ - KYE™ Governed Entity Catalog™ Pro - KYE™ Cloud Portal™ - KYE™ Academy™ · training + certification - Readiness scoring + risk tiering engines - Side-effect classification + commit-boundary detection - Sector-specific readiness packs · BYOC / on-prem Where to go next ## Adjacent reading. What it is. Why it matters. What to do next. [Continuity Profile™ →](https://kyeprotocol.com/continuity/) [Discoverability Profile™ →](https://kyeprotocol.com/discoverability/) [Ontology Profile™ →](https://kyeprotocol.com/ontology/) [Vocabulary →](https://kyeprotocol.com/vocabulary/) [Glossary — operating-model entries](https://kyeprotocol.com/glossary/#operating-model) [Whitepaper.7](https://kyeprotocol.com/whitepaper/#sec-7-7) ## 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: [Evidence Pack™](https://kyeprotocol.com/evidence-pack/) · [KYE™ Cloud™](https://kyeprotocol.com/apps/) · [KYE Protocol™](https://kyeprotocol.com/).