Operating Model — integrate against the canonical capability + scope contract.

One schema. One endpoint. Every capability your tenant exposes — bound to the scope, side-effect level, and obligations your runtime promises to honour.

Quickstart →API reference

The Operating Model is the developer-facing entry point into the constitution’s Operating Model Rail (§18). You declare what your service can do; KYE™ turns that declaration into a runtime contract that every authorize call resolves against.

What it is

A signed declaration of every capability your service offers.

Your service’s Operating Model is a JSON document (schema: the Operating Model record) that enumerates: every capability id you expose, the side-effect level of each (read, write, destructive, financial), the scope grammar that bounds it, the obligations you commit to (rate-limits, redaction, retention), and the policy bundle that decides the runtime verdict. KYE™ treats this document as the authoritative answer to “what can this service do, and under what conditions?” — every authorize call is evaluated against it.

It’s built once, versioned forever, and replayed offline by any auditor with your JWKS. The constitutional lock at §18 forbids any out-of-band capability declarations elsewhere in your stack.

Schema shape

The five top-level fields.

  • operating_model_id — canonical kye:om:<trust-domain>:<subclass>:<local> URN.
  • capabilities[] — capability declarations, each with id, side_effect, scope_grammar, obligations[].
  • policy_bundle_ref — the signed policy bundle (OPA / Cerbos / Cedar) that decides the runtime verdict.
  • signatures[] — one or more Ed25519 signatures over the canonical-JSON encoding.
  • provenance — commit SHA, build attestation, signer chain.

Full schema: https://kyeprotocol.com/schemas/operating_model.v1.json. Reference example: github.com/KYE-Protocol/examples/operating-model.json.

Endpoints

Three endpoints. One contract.

  • POST /v1/operating-model — publish (or rotate) your signed Operating Model. Returns the canonical kye:om:… URN.
  • GET /v1/operating-model/:id — fetch any tenant’s declared Operating Model with its signature chain.
  • POST /v1/runtime/authorize — the runtime endpoint that resolves every action against the Operating Model bound to the calling tenant.

Authentication: mTLS + OAuth2 client-credentials. Rate-limit: 60 publishes per tenant per day; reads are unmetered. All three endpoints emit signed audit events in the kye.operating_model.* family.

SDK calls

Same surface in TypeScript, Python, and Go.

All three SDKs expose operatingModel.publish(doc), operatingModel.fetch(id), and runtime.authorize(req) — identical names, identical semantics.

TypeScript

import { KYE™ } from "@kye/sdk";
const kye = new KYE™({ baseUrl: "https://gateway.kyeprotocol.com", keyRef: "kye:kid:acme:2026Q2" });
const om = await kye.operatingModel.publish(myDoc);
const verdict = await the runtime authorize endpoint({ actor, action, scope });

Conformance fixtures

Run the 17 Operating Model fixtures locally.

The conformance pack ships 17 deterministic fixtures covering: publish-and-fetch round-trip, signature verification, scope-grammar edge cases, side-effect classification, obligation enforcement, policy-bundle binding, and replay-proof of the resulting authorize verdict. Run them with npx @kye/conformance-pack-verifier --filter operating_model.

A green conformance run is the canonical L2 self-attestation evidence; an audit-firm-witnessed run produces L3 / L4.

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