Find your first governed AI use case
The KYE™ AI Adoption Navigator™ answers the question every leadership team is asking: where should we use AI for the most value with the least unmanaged risk? Answer ~10 questions about a use case and it maps it on an impact × authority-risk grid, with the authority overlay (assistive → autonomous), the recommended oversight mode, your first governed pilot, and the KYE™ controls to put in place.
The Authority Simulator™: pick a request, watch KYE™ decide
Demo dataYou 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
The same rule agent tries to sell a GBP 4.2M block — far above the desk's auto-approval limit. KYE™ holds it: the agent cannot self-authorise an order this size. The money does not move until a human approval is recorded.
- Action
- trading.order_place
- Purpose
- place a GBP 4.2M block order
- Instrument
- EQ:BP.L
- Side
- sell
- Amount
- 4,200,000
Needs approval Stopped at The side effect commits approval_threshold_breach
The desk head records an approval, and the agent re-submits the same GBP 4.2M block. Now the authority is present — KYE™ allows it. The held order is released, with the approval sealed into the evidence.
- Action
- trading.order_place
- Purpose
- place the block order with recorded desk-head approval
- Instrument
- EQ:BP.L
- Side
- sell
- Amount
- 4,200,000
- Approval recorded
- ✓
Allowed Passed every stage permission_granted
Blocked by the limit, the rule agent attempts to grant itself admin authority to raise its own trading mandate. KYE™ refuses outright: an agent can never authorise the expansion of its own authority.
- Action
- authority.self_escalate.grant_admin
- Purpose
- agent attempts to lift its own trading mandate
Denied Stopped at The side effect commits prohibited_action_requested
A rule-based rebalancer sizes each clip from a random draw. On this run the draw produced a GBP 3.1M order — over the desk limit. The agent is non-deterministic, but KYE™'s verdict on the order it actually proposed is the same deterministic…
- Action
- trading.order_place
- Purpose
- randomised position sizing produced an oversized clip
- Instrument
- EQ:VOD.L
- Side
- buy
- Amount
- 3,100,000
Needs approval Stopped at The side effect commits approval_threshold_breach
An LLM-brained copilot, run at temperature 0 for reproducibility, reasons that it should widen its own mandate to finish the task and proposes granting itself admin. A different brain, the same refusal: KYE™ denies the self-escalation…
- Action
- authority.self_escalate.grant_admin
- Purpose
- model reasoned it should widen its own mandate to complete the task
Denied Stopped at The side effect commits prohibited_action_requested
The highest-risk case: an LLM copilot at temperature 0.9 — genuinely unpredictable — proposes a GBP 2.75M block on a volatile name. You cannot know in advance what it will propose; you CAN know how KYE™ will govern whatever it proposes.…
- Action
- trading.order_place
- Purpose
- model proposed a large block on a volatile name
- Instrument
- EQ:GME.L
- Side
- sell
- Amount
- 2,750,000
Needs approval Stopped at The side effect commits approval_threshold_breach
The same 40-tonne copper warehouse receipt is pledged as collateral to two banks in two jurisdictions. A registry records both and discovers the fraud in an audit 41 days later. The KYE™ authority layer refuses the second registration at…
- Action
- custody.pledge_register
- Purpose
- register a pledge over warehouse receipt WR-CU-40T as loan collateral
- Capability
- custody.pledge_register
- Asset ref
- kye:demo:asset:warehouse-receipt-cu-40t
- Encumbrance recorded
- ✓
- Amount
- 165,000
Denied Stopped at The side effect commits binding_already_encumbered
The asset binding the action targets already carries a recorded encumbrance, so a second authority-consuming registration over it is inadmissible (the double-pledge refusal).
The AI payment assistant requests a 320,000 AMD payment to a verified supplier against a matched purchase order. It is inside the delegated threshold, the payee is the verified one, and the execution grant is live. Nothing needs a human.
- Action
- payment.request
- Purpose
- pay synthetic invoice INV-001 to the verified supplier within the delegated threshold
- Capability
- payment_request
- Instruction ref
- kye:fixture:sme-payment-authority:instruction:PI-001
- Invoice ref
- kye:fixture:sme-payment-authority:invoice:INV-001
- Purchase order ref
- kye:fixture:sme-payment-authority:purchase-order:PO-001
Allowed Passed every stage permission_granted
A 1,800,000 AMD invoice from a verified supplier. The assistant's delegation stops at 500,000 AMD and no approver has recorded consent for this instruction. KYE™ holds it: require_approval, reason payment_threshold_approval_required. The…
- Action
- payment.request
- Purpose
- pay synthetic invoice INV-002 above the delegated threshold without a recorded approval
- Capability
- payment_request
- Instruction ref
- kye:fixture:sme-payment-authority:instruction:PI-002
- Invoice ref
- kye:fixture:sme-payment-authority:invoice:INV-002
- Purchase order ref
- kye:fixture:sme-payment-authority:purchase-order:PO-002
Needs approval Stopped at The side effect commits payment_threshold_approval_required
A payment-class action exceeded the configured threshold for autonomous execution; human approval is required.
A well-formed 420,000 AMD invoice inside the threshold — but the payee account on it is the one a supplier-portal message substituted on 10 September, not the one the SME verified. The rail would settle it. KYE™ denies it…
- Action
- payment.request
- Purpose
- pay synthetic invoice INV-003 whose payee bank details changed since the supplier was…
- Capability
- payment_request
- Instruction ref
- kye:fixture:sme-payment-authority:instruction:PI-003
- Invoice ref
- kye:fixture:sme-payment-authority:invoice:INV-003
- Purchase order ref
- kye:fixture:sme-payment-authority:purchase-order:PO-003
Denied Stopped at The side effect commits supplier_bank_details_changed
The payee bank details on the instruction differ from the last verified record for that supplier. The delegation was granted against the verified payee, not against a payee substituted after verification. Supervisory reading: the instruction is well-formed and would settle; it is the AUTHORITY that is absent, because no one authorised payment to this account.
A 950,000 AMD invoice carries a recorded approval that would clear the threshold — recorded on 11 September, the day BEFORE the supplier's bank details changed and were re-verified. The approver consented to the old payee. KYE™ denies it…
- Action
- payment.request
- Purpose
- pay synthetic invoice INV-004 under an approval recorded before the payee changed
- Capability
- payment_request
- Instruction ref
- kye:fixture:sme-payment-authority:instruction:PI-004
- Invoice ref
- kye:fixture:sme-payment-authority:invoice:INV-004
- Purchase order ref
- kye:fixture:sme-payment-authority:purchase-order:PO-004
Denied Stopped at The side effect commits approval_superseded_by_payee_change
A recorded approval exists but predates the payee change it is being relied on to authorise. The approver consented to the previously verified payee and never saw the new one. Supervisory reading: an approval authorises the instruction that was put in front of the approver, not a later instruction that resembles it — so the threshold control is unmet even though an approval is on file.
A routine 300,000 AMD invoice to a verified supplier, well inside the threshold. The assistant submits it under execution grant B, which expired on 1 September. Absent authority denies regardless of how well-formed the instruction is…
- Action
- payment.request
- Purpose
- pay synthetic invoice INV-005 under an execution grant that expired before submission
- Capability
- payment_request
- Instruction ref
- kye:fixture:sme-payment-authority:instruction:PI-005
- Invoice ref
- kye:fixture:sme-payment-authority:invoice:INV-005
- Purchase order ref
- kye:fixture:sme-payment-authority:purchase-order:PO-005
Denied Stopped at The side effect commits authority_expired
The authority grant was no longer valid at decision time.
The IoDE core scenario. A 2,400,000 AMD instruction: above the threshold, to a payee whose bank details changed since verification, under an approval recorded before that change, submitted on an expired execution grant. The rail would…
- Action
- payment.request
- Purpose
- pay synthetic invoice INV-006 — the four-condition core denial
- Capability
- payment_request
- Instruction ref
- kye:fixture:sme-payment-authority:instruction:PI-006
- Invoice ref
- kye:fixture:sme-payment-authority:invoice:INV-006
- Purchase order ref
- kye:fixture:sme-payment-authority:purchase-order:PO-006
Denied Stopped at The side effect commits authority_expired
The authority grant was no longer valid at decision time.
The agent proposes the action
KYE™ policy decision point
Subject, action, purpose and context, as sent to KYE™.
KYE™ resolves authority and purpose
KYE™ policy decision point
Delegation, scope, thresholds and approvals at decision time.
KYE™ decides and seals
KYE™ policy decision point
Allow, require approval or deny, with a reason code, sealed into the Evidence Pack™.
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.
It scores live in your browser — nothing is sent anywhere unless you choose to share. A pre-adoption tool: it helps you decide where to start. To diagnose authority gaps on AI you've already deployed, use the Authority Risk Profiler™.
The assessment
Pick the answer that best fits one AI use case you're weighing up — scored against the EU AI Act, GDPR, and NIST AI RMF risk bands, with at least one human-approval gate flagged where the law requires it.
0 of 0 answered
Contact
Your request goes to the KYE Protocol™ team, and a receipt with a reference number is emailed to you.
Your result
authority-complexity (0–100)
Where you land on the impact × risk map
The Navigator places your use case in one of four quadrants — the highlighted one is yours.
Your recommended first governed pilot
The KYE™ controls you'll need
Additive to your stack — the controls KYE™ would govern to make this use case production-, enterprise-, and banking-grade: at least the authority, evidence, and ≥1 human-approval gate the EU AI Act, GDPR, and NIST AI RMF require across the 4 risk quadrants. A regulated use will also need a regulatory-obligation mapping and a controls-architecture pass.
Make it official
Your result is a draft kye.ai_adoption_journey_report.v1. The paid AI Adoption Navigator™ diagnostic turns it into a facilitated workshop and a signed, replay-provable AI Adoption Journey Report™ that converts directly into a KYE™ governed pilot. Share your result to get the diagnostic brief.
The free assessment runs entirely client-side; nothing leaves your browser. When you click “Get the diagnostic brief” you're taken to the KYE™ engagement intake (the same Universal Engagement Rail every KYE™ applicant uses) where you choose what to share.
How the Navigator differs from the Authority Risk Profiler™
Two distinct KYE™ tools, two distinct jobs:
- KYE™ AI Adoption Navigator™ — pre-adoption (this page) Greenfield. Where should we use AI? Maps opportunity × authority-risk onto your first governed pilot.
- KYE™ Authority Risk Profiler™ — diagnostic For AI you've already selected or deployed. Surfaces the authority gaps, overlaps, and concentrations in your existing estate.
Canonical KYE™ surfaces referenced on this page: KYE Protocol™ · Systemic Authority Risk™ · Universal Engagement Rail.