---
title: "Operating Model · KYE™ Developer Tools™"
description: "Developer guide for integrating against the KYE™ Operating Model API — capability declarations, scope contracts, runtime endpoints, and conformance fixtures."
url: https://kyeprotocol.com/developers/docs/operating-model/
lang: en
source: "KYE Protocol"
---

> Developer guide for integrating against the KYE™ Operating Model API — capability declarations, scope contracts, runtime endpoints, and conformance fixtures.

# 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 →](https://kyeprotocol.com/developers/quickstart/) [API reference](https://kyeprotocol.com/developers/api/)

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™](https://kyeprotocol.com/compliance/) · [KYE Protocol™](https://kyeprotocol.com/).