Illustrative

The Authority Simulator™ — see the decision, not just the outcome.

Set a scenario below — an AI actor, an action, the purpose it was authorised for, the state of that authority, and a jurisdiction. Then watch the action climb the cypress: the Map of KYE™ lights each stage as KYE Protocol™ evaluates it — Purpose, Authority, Delegation, Execution, Evidence, Finality — or stops cold at a refusal, before the side effect ever lands. Change one input and watch the verdict change.

Run it on your own actionTry the simulator

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.

Should this action have been allowed? Watch KYE Protocol™ decide.

Try it — pick a scenario

Each scenario runs the same six-stage chain on the canonical cypress. Watch where the action is admitted (green) and where it is refused (red) — the refusal always stops the climb before the side effect. The most instructive ones are the failures: an expired authority, an out-of-scope purpose, a copilot reaching above its level.

Authorised payment Authority expired Out of purpose Copilot oversteps Advisory answer

ADMITTED — sealed to Authority Finality™

An L3 payment, in scope, with valid authority. Every stage admits; the decision is sealed and replay-verifiable from public keys alone.

REFUSED at Authority Resolution™

The authority that would license the payment has expired. The action is refused at Authority — before the money ever moves.

REFUSED at Purpose Permission™

The action falls outside the declared purpose it was authorised for, and is refused at the very first stage.

REFUSED at Delegation

An L1 advisory copilot attempts an L3 payment. Purpose and authority check out, but delegating payment authority it does not hold is refused.

ADMITTED — recorded

An L1 copilot publishes an answer to a customer. It is admitted and recorded with an Evidence Pack™; Authority Finality™ is reserved for L3+ consequential actions.

Illustrative & deterministic: each scenario shows the KYE Protocol™ decision flow; it does not call the production Decision Engine and makes no claim about any real system.

How the decision is made

KYE Protocol™ does not score the model or watch the logs after the fact. It judges the action at the moment it is attempted, against the same six-stage chain the simulator walks — fail-closed, so an action that fails any stage is refused before its side effect. The actor's level (from the KYE™ Consequential Actor Framework™) sets how far it must climb:

  • Purpose & Authority — was the action within its declared purpose, and does a valid authority license it? Most refusals happen here.
  • Delegation — an L1 copilot cannot quietly perform an L3 payment; delegating authority it does not hold is refused.
  • Execution → Evidence → Finality — admitted at the moment, recorded as a signed Evidence Pack™, and for L3+ actions sealed to Authority Finality™, replay-verifiable against the EU AI Act™, NIST AI RMF, and ISO/IEC 42001.

Run it on a real action.

The simulator is illustrative; the engine behind it is not. If your team is putting an AI actor into a consequential path — a payment, an account, a clinical recommendation, a trade — a governed pilot runs this decision on your real workflow and leaves you with a signed Evidence Pack™ you can hand to a regulator. Adopt AI without losing legitimate control.

Start a governed pilotThe trust layer for consequential action

Canonical KYE™ surfaces referenced on this page: KYE Protocol™ · Purpose Permission.