Lab
KYE Protocol™ Lab
Run one governed agent action end to end, in your browser.
Purpose Permission API
Demo dataYou learn: What the purpose-permission endpoints take and return. You can: Pick a request and send it.
Clinical lead · Issue the grant
Request
POST /purpose-permissions
{
"grantee": "<grantee>",
"purpose": "<purpose>",
"scope": "<scope>",
"ttl_days": 90
}
Response 201
{
"grantee": "kye:ent:halden.example:agent:clin-03",
"id": "kye:purpose:halden:clin-03:clinical-summarise-2026q4",
"issued_by": "kye:ent:halden.example:officer:clinical-lead",
"not_after": "2027-01-01T00:00:00Z",
"not_before": "2026-10-01T00:00:00Z",
"principal": "kye:ent:halden.example",
"purpose": {
"id": "kye:purpose-class:clinical.summarise",
"label": "Summarise care records for the treating clinician"
},
"restrictions": {
"dual_control": false,
"jurisdiction": [
"GB"
],
"rate_cap": {
"requests_per_minute": 20
},
"requires_evidence": true
},
"scope": {
"actions": [
"read",
"summarise"
],
"data_classes": [
"health.record"
],
"resources": [
"kye:res:halden.example:ehr:ward-7"
]
},
"version": 1
}Clinical lead · Reconfirm for 90 days
Request
PATCH /purpose-permissions/%3Cid%3E
{
"ttl_days": 90
}
Response 200
{
"id": "kye:purpose:halden:clin-03:clinical-summarise-2026q4",
"not_after": "2027-04-01T00:00:00Z",
"reconfirmed_at": "2026-10-14T10:20:00Z"
}Clinical lead · Revoke the grant
Request
DELETE /purpose-permissions/%3Cid%3E
Response 200
{
"id": "kye:purpose:halden:clin-03:clinical-summarise-2026q4",
"revoked_at": "2026-10-14T10:25:00Z",
"revoked_reason": "Clinical lead revoked the grant (demo)"
}How this widget is built
- Demonstrates
- App API
- Components
- /api/v1/purpose-permissions
- OpenAPI contract (app.yaml)
- Flow
- Requests come from the app API contract; the issue response is the demo grant. Architecture diagram
- Used on
- /examples/: On the examples page, with the rest of its scenario.
- /sandbox/demos/demo/: The sandbox demo: the same calls, answered from the contract.
- /lab/: The lab: call the API in your browser.
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.
