The technical layer behind Authority Finality™.

A KYE™-governed action is the same shape whether the actor is a human pressing a button, a service account hitting an API, or an AI agent running a tool. That uniformity is the whole point.

The runtime emits a signed Decision Map™™ with every /v1/runtime/authorize response. The map shows which inputs led to the verdict — the principal, the delegation, the actor, the capability, the scope, the state, and the policy — bound to the audit-chain entry and the evidence pack. Verifiable offline with public keys alone.

Try the live version on the agent-backed purchasing simulator — change any input and watch the chain recompute.

A registry is passive. KYE Protocol™ is a runtime authority layer — when authority changes, downstream systems must know before the next request lands. The KYE Signal Bus™ emits signed, replayable events for every grant, revocation, state transition, decision, approval, recovery action and evidence-pack lifecycle. Subscribers verify with public keys alone, deduplicate by event id, and bind every signal back to the audit chain.

24 event families · 79 well-known types (nine highlighted below)

Canonical envelope · one shape across every event

Schema: https://kyeprotocol.com/schemas/signal.json. Signing covers the full envelope; subscribers verify with the publisher's published JWKS.

{
  "schema_version":  "kye.webhook.v1",
  "event_id":        "kye:event:01HX...",
  "event_type":      "kye.authority.revoked",
  "event_version":   "1.0",
  "occurred_at":     "2026-05-06T21:30:00Z",
  "tenant_id":       "tenant_acme",
  "correlation_id":  "kye:corr:agent_purchase_001",
  "causation_id":    "kye:event:01HX-prev...",
  "actor_entity_id":     "kye:entity:agent:shopping_agent_456",
  "principal_entity_id": "kye:entity:person:customer_123",
  "subject_ref":     "kye:authority:grant:purchase_001",
  "reason_code":     "principal_revoked_authority",
  "data": { "previous_state": "active", "new_state": "revoked",
            "affected_capabilities": ["kye:capability:payment_action:card_purchase"] },
  "audit_ref":     "kye:audit:event_001",
  "evidence_refs": ["kye:evidence-pack:authority_revocation_001"],
  "delivery":  { "idempotency_key": "kye:event:01HX...", "replayable": true },
  "signature": { "algorithm": "ed25519", "key_id": "kye:key:webhook_signing_001",
                 "signature": "..." }
}

Endpoints · subscribe, manage, replay

• POST /v1/webhook-endpoints · GET · PATCH · DELETE — manage subscriber endpoints + filter expressions
• POST /v1/webhook-endpoints/{id}:test · :rotate-secret — synthetic-event smoke test, signing-key rotation
• GET /v1/webhook-deliveries · POST .../{id}:replay — delivery log + per-delivery replay
• GET /v1/events · GET .../{id} · POST .../{id}:replay · GET /v1/event-types
• POST /v1/signals · POST /v1/signals/subscribe · GET /v1/signals/replay · GET /v1/signals/{id} — KYE Signal Bus™ publisher side

Delivery guarantees

• Signed — over the canonical envelope, with JWKS-based verification and no shared secrets. Conformance test vectors verified in CI; the signing construction itself is part of the patent track.
• Idempotent — subscribers dedup by event_id; replays carry the same id.
• Retried — exponential backoff under a publisher-configured budget; per-subscriber retry policy.
• Dead-lettered — exhausted retries land in DLQ for operator-initiated replay.
• Replayable — ≥ 24-hour replay window via /v1/signals/replay; subscribers refetch missed events without involving the publisher.
• Audit-bound — every publish, delivery, and retry is recorded as an audit event linked via audit_ref + evidence_refs.
• Three transports — HTTPS webhook (REQUIRED), SSE / WebSocket (OPTIONAL), Kafka-compatible topic (OPTIONAL).
• SSF / CAEP boundary adapter — KYE™ event types translate to OpenID Shared Signals Framework + CAEP at trust-domain boundaries; lossless for the in-scope families.

What ships today

Envelope schema, every event-family schema, error / reason codes, delivery-receipt format, verifier SDK (TypeScript / Python / Go), reference Gateway webhook handler + retry loop + DLQ + replay endpoint, conformance test vectors. All Apache 2.0.

Worked example · agent-purchase revocation

A customer revokes their shopping-agent's payment authority. One signed kye.authority.revoked event fans out to five subscribers: bank freezes the agent card token; merchant platform blocks future agent purchases; agent runtime removes the payment_action.card_purchase capability; SIEM opens an alert linked to the audit-chain ref; audit pipeline emits kye.evidence_pack.generated for the regulator-facing pack. All five verify with the same public-key set; the regulator can replay the entire flow offline.

Most systems collapse identity, authority and risk into one boolean. KYE Protocol™ keeps them separate so a single failure mode — expired credential, suspicious behaviour, lost key — changes the right dimension without nuking the rest.

Quick map: the state vector has 6 dimensions below (each transitions independently). The entity_state dimension — the lifecycle of the actor itself — takes 15 well-defined values (see the simulator below). The other five dimensions have smaller value sets shown on each card.

Each dimension cascades independently. Stop the entity? Authority freezes, delegations & capabilities revoke, credentials stay valid (so post-mortem keeps working), risk locks at last-known. The vocabulary is open and pinned in the conformance pack.

Click through them. Try an illegal move (the protocol blocks it). Stop, quarantine or revoke an entity and watch the cascade roll down to its delegations, payment authorities and resource grants.

KYE Protocol™ has three layers. Runtime Governance — authority, state, decisions, policy, evidence, audit. Protocol Design — schemas, dictionaries, taxonomies, metadata, graph, profiles, registries, conformance. Developer Adoption — APIs and SDKs. The separation matters: what the protocol decides is independent from how it ships, which is independent from how you use it.

Tier A · Runtime governance — what KYE™ decides

Tier B · Protocol design — how KYE™ classifies and ships

Tier C · Developer adoption — how KYE™ reaches developers