---
title: "KYE™ Scenario Testing™ — Future-state testing for delegated AI actions"
description: "KYE™ Scenario Testing™ runs a proposed agent action through a deterministic stress evaluator before it executes"
url: https://kyeprotocol.com/solutions/scenario-testing/
lang: en
source: "KYE Protocol"
---

> KYE™ Scenario Testing™ runs a proposed agent action through a deterministic stress evaluator before it executes

KYE™ Scenario Testing™

# Future-state testing for delegated AI actions.

Before an AI agent acts, KYE™ Scenario Testing™ runs the proposed action through a deterministic stress evaluator. The output: a signed `kye.scenario_run.v1` with a risk level, a recommended decision, and a list of recommended controls — emitted to the PEP, the approval pipeline, and the Evidence Pack™. No surprises at execution time.

1 · What it is

## Pre-execution simulation, deterministic, replay-safe.

A scenario is a target object (an agent action, a delegation, a policy change) plus a list of stressors — perturbations that ask "what if this dimension moves?" The scenario engine evaluates each stressor against a small lookup table, aggregates the bumps, and emits a single deterministic outcome: `risk_level` · `recommended_decision` · `recommended_controls[]`.

### 4

Risk levels (low / medium / high / critical)

### 4

Recommended decisions (allow → deny)

### 12+

Stressor kinds in the V1 lookup

### same input → same output

Deterministic, replay-CI gated

- **Schema-conformant.** Every run validates against `kye.scenario_run.v1` — same artefact whether emitted by the V1 heuristic engine or the V1.1 rich engine.
- **Banking-grade hardening.** Injectable structured logger, `latency_ms` on every result, no `Math.random`, no internal-error message leak.
- **Composable.** The output feeds the Approval Brief™ composer and the Consequence Mapping™ engine without translation — the brief carries the `scenario_run_id` so the approver sees the simulation evidence inline.

2 · The flow

## From action request to recommended decision.

### 1. Action request

Agent or PEP describes the target object — id + object\_type + summary.

### 2. Stressor list

Caller (or Stress Test™ profile) supplies the list of perturbations to evaluate.

### 3. Engine evaluation

`runScenario()` aggregates per-stressor bumps from the V1 heuristic table; intensity multipliers apply.

### 4. Scenario run emitted

`kye.scenario_run.v1` with a deterministic `scenario_run_id`, risk\_level, recommended\_decision, recommended\_controls, latency\_ms.

### 5. Hand-off

Run is referenced by the Approval Brief™ and sealed into the Approval Evidence Pack™ — auditable end-to-end.

3 · Stressor kinds (V1)

## A small lookup, auditable end-to-end.

V1 ships an intentionally small set of stressor kinds — enough to cover the highest-blast-radius shapes a banking-grade tenant sees. Each entry maps to a numeric risk-bump and a list of controls the bump implies. Unknown stressor kinds contribute zero risk by safe default; the rich engine (V1.1) replaces this with a learned + counterfactual evaluator.

| Stressor kind | Bump | Implied control(s) |
| --- | --- | --- |
| `amount_above_threshold` | 2 | `dual_control:second_approver_required` |
| `novel_counterparty` | 2 | `enhanced_due_diligence` |
| `authority_chain_long` | 1 | `chain_replay` |
| `cross_border_transfer` | 2 | `sanctions_screening` |
| `outside_business_hours` | 1 | `business_hours_alert` |
| `sub_processor_first_use` | 2 | `sub_processor_review` |
| `scope_widening` | 3 | `scope_freeze`, `human_review` |
| `off_policy_action` | 3 | `policy_owner_review` |
| `recently_revoked_grant` | 3 | `block_until_reissue` |
| `bulk_action` | 1 | `batch_size_cap` |
| `velocity_spike` | 2 | `rate_cap` |
| `privacy_high_class_data` | 2 | `dp_review` |

**Aggregation.** Per-stressor bumps are summed (multiplied by intensity: low=1, medium=2, high=3). A score of 0–2 maps to `low/allow`; 3–5 to `medium/allow_with_constraints`; 6–8 to `high/require_approval`; 9+ to `critical/deny`. Same input → same output, every time.

4 · Use it

## One call from your PEP-Express or gateway.

The engine is a TypeScript edge worker library — mounted directly by PEP-Express and the runtime gateway in front of high-blast-radius agent actions. Library, not a deployed worker.

import { runScenario } from "@kye/scenario-engine"; const result = await runScenario({ scenario\_id: "kye:scenario:payment-agent-scope-expansion", tenant\_id: "kye:tenant:acme-bank", target\_object: { id: "kye:agent-action:expand-payment-limit-50k", object\_type: "agent\_action", summary: "Expand per-transaction limit from $10k to $50k on FedNow." }, stressors: \[ { id: "s1", kind: "scope\_widening", intensity: "high" }, { id: "s2", kind: "amount\_above\_threshold", intensity: "high" }, { id: "s3", kind: "novel\_counterparty", intensity: "medium" } \], evaluated\_at: "2026-05-14T09:30:00.000Z" }, { logger }); // result.risk\_level === "critical" // result.recommended\_decision === "deny" // result.recommended\_controls === \["dual\_control:second\_approver\_required", // "enhanced\_due\_diligence", // "human\_review", // "scope\_freeze"\] // result.scenario\_run\_id === "kye:scenario-run:..." (deterministic) // result.latency\_ms === 0.42

5 · Next

## Pair with Informed Approval for human sign-off.

A scenario run is the input to the Approval Brief™ — the structured, signed pack a human approver sees at decision time. No blind approvals.

[Informed Approval](https://kyeprotocol.com/solutions/informed-approval/) [Evidence Pack™](https://kyeprotocol.com/evidence-pack/) [Decision Engine](https://kyeprotocol.com/decision-engine/)

Canonical KYE™ surfaces referenced on this page: [KYE Protocol™](https://kyeprotocol.com/).