KYE Operating Model Profile™ · v1.0

From readiness to runtime control.

Who runs the protocol. Who runs the engine. Who runs the tenant. Three layers. Three sets of keys.

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.

paymentspayment_executionBefore a prepared payment becomes an executed payment.
sendexternal_messageBefore an outbound message leaves the tenant.
drawcontract_signatureBefore a contract / e-signature is sealed.
medical_servicesclinical_actionBefore a clinical action is performed.
terminalinfrastructure_commandBefore an infrastructure command is issued.
cloud_downloaddata_exportBefore a data export leaves the tenant.
keycredential_rotationBefore a credential is rotated.
verifiedevidence_exportBefore 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 emailarrow_forwardsend email
prepare paymentarrow_forwardexecute payment
recommend refundarrow_forwardissue refund
draft contractarrow_forwardsign contract
suggest clinical steparrow_forwardperform clinical step
plan infra changearrow_forwardexecute command
recommend access grantarrow_forwardissue access grant
propose policy editarrow_forwardapply 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.

smart_toy

Entity Authority Record™ · preview

Finance Payment Preparation Agent

pilot
Owner
Finance Ops · kye:user:finance_owner_001
Risk tier
high
Approved capabilities
invoice.read, payment.prepare, supplier.notify
Prohibited capabilities
payment.execute, contract.sign, credential.rotate
Required gates
kye:gate:payment_execute, kye:gate:external_send
Commit boundaries
kye:commit-boundary:payment_execution
Evidence
evidence_pack_available
Review due
30 days · monthly cadence
Revocable
yes · cascade required
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.

Expected effects (tick all that apply)
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.