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.

Operating Model Profile, stage by stage

Demo data

You learn: How it works, one stage at a time. You can: Run it end to end.

  1. Use-case intake

    KYE Protocol™

  2. runtime decision

    KYE Protocol™

  3. replayable evidence

    KYE Protocol™

How this widget is built
Demonstrates
KYE Protocol™
Components
  • The stages this page describes
Flow
Each stage in order, as the page sets it out. Architecture diagram
Used on

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 IntakeKYEUseCaseIntake — actor type, expected actions, systems, data classes, external effects, commit actions.

02

Readiness AssessmentKYEReadinessAssessment — multi-dimension scoring with a canonical interpretation. Scoring construction is proprietary.

03

Risk ClassificationRisk tier (low / medium / high / critical) embedded in the assessment.

04

Map AuthorityKYEEntityAuthorityRecord — living governance record per delegated actor.

05

Place GatesKYEAuthorityGate records before high-impact capabilities.

06

Configure RuntimeKYECommitBoundary records bind recommendation ↔ committed action.

07

ExecuteRuntime KYEPolicyDecision at the decision endpoint.

08

EvidenceKYEAdoptionEvidencePack — signed, hash-chained, offline-verifiable.

09

ReviewKYEReviewPath — multi-step human-review chain with SLAs.

10

ImproveRevisions 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.

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.

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

Ready to see your AI agents flagged?

Start in shadow mode. We’ll deliver your first Evidence Pack™ in 4–8 weeks.

Canonical KYE™ surfaces referenced on this page: Evidence Pack™ · KYE™ Cloud™ · KYE Protocol™.