Step 6 · Decision Engine

The KYE™ Decision Engine — decisions over meaning + state.

Step 5 holds the live instance graph. Step 6 is the engine that walks it. The Decision Engine (KYE™ Decision Engine™) consumes a candidate request, traverses the Authority Graph™, evaluates ontology-bound predicates, runs continuity + discoverability checks, and returns a signed verdict with reason code.

Apply for pilot →Read the docs

The Authority Simulator™: pick a request, watch KYE™ decide

Demo data

You learn: Why an agent's request is allowed, held for approval or refused, and that the refusal lands before the side effect. You can: Pick a case and run it.

A rule-based execution agent places a small GBP 8,500 hedge adjustment on a permitted instrument — comfortably inside the desk's auto-approval limit. Nothing needs a human.

Action
trading.order_place
Purpose
place a small hedge adjustment within the desk mandate
Instrument
EQ:VOD.L
Side
buy
Amount
8,500

Allowed Passed every stage permission_granted

  1. The agent proposes the action

    KYE™ policy decision point

    Subject, action, purpose and context, as sent to KYE™.

  2. KYE™ resolves authority and purpose

    KYE™ policy decision point

    Delegation, scope, thresholds and approvals at decision time.

  3. KYE™ decides and seals

    KYE™ policy decision point

    Allow, require approval or deny, with a reason code, sealed into the Evidence Pack™.

  4. The side effect commits

    KYE™ policy decision point

    Only an allowed action reaches the rail; a held or refused one stops here.

How this widget is built
Demonstrates
KYE™ runtime decision (kye_decide)
Components
  • Demo scenario registry (kye.demo_scenario.v1)
  • Runtime evaluate engine
  • Reason Code Dictionary™
  • Evidence Pack™
Flow
Request → authority and purpose resolved → decision with reason code, sealed → the side effect commits only when allowed. Architecture diagram
Used on
  • /simulator/: The simulator itself: every case is runnable.
  • /: The simulator itself: every case is runnable.
  • /lab/: The simulator itself: every case is runnable.

1 · What it does at decision time

Walks the chain. Signs the verdict.

For every candidate decision the Decision Engine resolves the actor / principal / capability / scope context, evaluates it against the bound authority graph, ontology, continuity and discoverability inputs, and returns a verdict with a reason code. The verdict is bound into a signed Decision Map™ and chain-linked into the audit ledger.

The specific check ordering, the inter-check short-circuit rules, the verdict alphabet, and the per-verdict obligation set are proprietary and are not disclosed in this repository. Conformant runtimes consume the canonical contract via the private decision-engine binding.

2 · The decision endpoint

One authorize call.

POST /v1/runtime/authorize
Content-Type: application/json

{
  "actor_entity_id": "kye:agent:finance_agent_001",
  "principal_entity_id": "kye:user:finance_owner_001",
  "capability_id": "kye:capability:payment.prepare",
  "scope": { "amount": { "value": 240, "currency": "GBP" } },
  "delegation_id": "kye:delegation:0xabc"
}

Custom per-vendor gates are replaced by one signed verdict + one signed Decision Map™, replayable offline by any third party with the published JWKS.

Where to go next

Continue the stack →

Every claim here is backed by the open KYE Protocol™ contracts and verifiable end-to-end from the publisher's JWKS — you check it yourself, you don't take our word for it.

← Step 5 · Knowledge graphStep 7 · Runtime gateway →

Ready to see your AI agents flagged?

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

Apply for pilot →Try the sandbox →

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