KYE Shadow Mode™

Shadow Mode — a flag, not new runtime code.

Every KYE™ Engine — Authority, Purpose, Decision — supports a mode parameter. Under mode: shadow, every check still runs. Every Decision Map™ is still sealed. Every Evidence Pack™ is still signed. The Commit Boundary™ suppresses every side effect. production_action_blocked is invariantly false.

rocket_launch Apply for pilot → menu_book Read the docs

Pricing · how to access Shadow Mode

Shadow Mode itself is free. The runtime it’s a flag on is paid.

Shadow Mode is not a separate product — it’s the mode parameter every KYE™ Engine accepts. So “is Shadow Mode free?” depends on what you mean: the flag is free; the runtime that responds to the flag, and the engagement that wires it against your real workflow, is paid. Three tiers of access:

science 1. Free · Sandbox Clone the OSS SDK and run a local gateway in mode: shadow against the public Sandbox. Synthetic data, no signed evidence against your traffic, no quota. Anyone can do this today. rocket_launch 2. Paid pilot · £35–125k We run the runtime in mode: shadow against your real workflow for 4–6 weeks. Signed Evidence Packs™. Authority Gap report. 100% credit against year-1 annual. SKUs: KYE-AUDIT-PILOT-001, KYE-HAARF-PILOT-001, KYE-NHS-PILOT-001, KYE-FCA-PILOT-001 · production_systems_touched: shadow-mode-only is the constitutional safety guarantee on every one of these. workspace_premium 3. Annual licence · permanent Starter → Strategic tier (KYE-STARTER-ANNUAL-001 … KYE-STRATEGIC-ANNUAL-001). Permanent mode: shadow deployment as part of the runtime; flip individual gates to mode: enforce per the 6-rung adoption ladder. You own the cadence.

Why this matters: Shadow Mode is the safety primitive that lets KYE™ ship to regulated buyers without ever blocking a customer’s production agent. The flag itself can’t be a SKU — that would make safety pay-walled. The engagement that operationalises the flag on your real traffic is the SKU.

What shadow mode does

Every engine runs. Every Decision Map™ is sealed.

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.

The Entity Engine resolves the actor's KYEID and attestation chain.
The Authority Engine checks the actor's claimed authority against the live Authority Graph™.
The Purpose & Scope Engine checks Admissibility against any matching Purpose Permission™.
The State Engine reads the six-dimension state vector (entity, authority, delegation, credential, risk, recovery).
The Rules Engine evaluates rights, obligations and stop conditions.
The Decision Engine emits a simulated decision simulated_allow · simulated_allow_with_constraints · simulated_requires_approval · simulated_deny.
The Evidence Engine signs the Decision Map™ and seals an Evidence Pack™.

What it does NOT do

Shadow mode never blocks production.

It does not return a deny to your API gateway.
It does not cancel a workflow step.
It does not revoke an OAuth token.
It does not quarantine a model output.
It does not mutate any IAM/SSO state.

production_action_blocked is locked to false at three layers: the type system (the schema constrains it to a const), the engine code (the Commit Boundary skips side effects when mode = shadow), and a CI gate (shadow-mode-non-blocking) that fails any build whose examples violate the invariant.

Data captured per action

One signed `kye.evidence.observed_action.v1` per request.

Each Observed Action carries: actor, on-behalf-of, action verb, target type and reference, claimed authority source and reference, claimed purpose, observation timestamp, stack binding id, request fingerprint, and an Ed25519 signature from the customer's binding key. schema Read the schema

Evidence generated

A Shadow Evaluation per action; an Authority Gap per class.

For each Observed Action, the Decision Engine returns a Shadow Evaluation (kye.decision.shadow_evaluation.v1). When the Shadow Evaluation would have denied or required approval, the Authority Gap classifier groups the failure into one of nine locked classes, each of which maps to a Guard Recommendation type.

Authority Gaps detected

Bounded, canonical, signed.

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. The taxonomy covers classes like missing authority grants, out-of-scope actions, unbound purposes, stale delegations, and rate-cap exceeded scenarios.

The specific gap-class enumeration, the per-class detection rule, and the severity-routing contract are proprietary and are not disclosed in this repository. Conformant runtimes consume the canonical taxonomy via the private Authority Gap Detector binding.

When to move to enforcement

Promote one Guard at a time.

Stage 4 (Guard) installs the smallest possible KYE™ control. The Guard runs in shadow first; promotion to enforce is governed by a signed Adoption Stage transition with a pre-agreed observation window and per-customer promotion criteria. The specific promotion contract (window length, false-positive threshold, rollback rules, dual-channel approval) is proprietary and is not disclosed in this repository.

Security and privacy controls

Read-only by default. Customer KMS for credentials.