---
title: "KYE™ Reality Coupling™ — stable-drift detection for delegated AI actions"
description: "KYE™ Reality Coupling™ detects stable drift — when a delegated AI action remains locally valid (authority OK, purpose OK, scope OK, evidence verifiable)…"
url: https://kyeprotocol.com/solutions/reality-coupling/
lang: en
source: "KYE Protocol"
---

> KYE™ Reality Coupling™ detects stable drift — when a delegated AI action remains locally valid (authority OK, purpose OK, scope OK, evidence verifiable)…

KYE™ Reality Coupling™

# Authorised. Evidenced. Grounded.

A delegated AI system can remain explainable, trusted, high-performing and cryptographically verifiable while slowly decoupling from current operational reality. KYE™ Reality Coupling™ detects that before trusted automation causes trusted harm.

1 · What stable drift is

## When everything is locally valid and the system is still wrong.

**Stable drift is when everything remains locally valid while the system becomes globally wrong.** The agent has authority. The purpose is in scope. The action is on-policy. The evidence pack verifies offline against the public keys. And the world has moved — the supplier is now high-risk, the sanctions list refreshed, the policy was superseded, the price feed froze — and the trusted automation acts anyway.

### locally valid

authority OK · purpose OK · scope OK · evidence verifiable

### globally wrong

the world the action depends on has shifted

### 4 schemas

anchor · snapshot · coupling check · stable-drift event

### 1 new node

n\_reality\_coupling in the PDP pipeline

**Why the existing rails are not enough.** Authority Gates check delegation. Purpose Permissions check intent. State Engine checks pre-conditions on the resource. Rules Engine checks policy. Evidence Pack™ proves the decision is replayable. None of them ask: _is the world the action depends on still the world we authorised against?_ Reality Coupling™ is that question — and that signal — as a first-class node.

2 · What it checks

## Six grounding dimensions, one signed verdict.

A coupling check inspects the dimensions on which a delegated action depends. Each dimension is grounded in a `kye.reality_anchor.v1` with an explicit freshness contract. The node aggregates the per-anchor outcomes into a single `coupling_result` · `runtime_effect` · `severity` emitted as `kye.reality_coupling_check.v1`.

- **Source-of-truth freshness** Is the upstream authoritative source within its freshness contract? (sanctions lists, price feeds, supplier registry.)
- **Source-of-truth integrity** Does the snapshot's signature verify against the registered key? Is the chain of custody intact?
- **Policy context current** Is the policy version the action was authorised under still in force, or has it been superseded?
- **Environment state current** Are the environmental pre-conditions (market open, jurisdiction active, system in nominal mode) still true?
- **Assumptions current** Did any stated assumption attached to the purpose-grant expire before evaluation?
- **Cross-system consistency** Do the independent systems-of-record agree, or has one drifted into conflict with another?

3 · Decision-flow integration

## A new node between State and Rules.

The PDP pipeline gains one node — `n_reality_coupling` — between `n_state_precondition` and `n_rules_eval`. It is non-enforcing: its `runtime_effect` feeds rules evaluation as an additional signal, not as a verdict. Rules decide; coupling tells rules what the world looks like right now.

### Action Request

Agent or PEP proposes a delegated action.

### Purpose

Purpose-grant resolved & scope confirmed.

### Authority

Delegation chain verified end-to-end.

### State

Resource & system pre-conditions evaluated.

### Reality Coupling™

`n_reality_coupling` — anchors fetched, freshness checked, drift signal emitted.

### Rules

Rules engine consumes the coupling signal alongside state & authority inputs.

### Decision

Allow / allow-with-constraints / require-approval / deny.

### Evidence

Evidence Pack™ sealed with coupling-check & any drift-event references.

### Replay

Offline auditor replays the pipeline including the coupling node deterministically.

4 · Sample anchors

## Three anchors from a financial-services tenant.

An anchor is a typed, owned, freshness-contracted reference to a slice of operational reality. Banking-grade tenants typically register dozens; this is the V1 starter set illustrated in `/examples/reality-coupling/financial-services-anchor.json`.

| Anchor | Type | Max staleness | Stale effect |
| --- | --- | --- | --- |
| OFAC SDN sanctions list | `external_source_of_truth` | 3600 s | `deny` |
| Supplier risk registry | `risk_context` | 86400 s | `require_revalidation` |
| Wholesale market price feed | `environment_state` | 60 s | `require_human_review` |

**Stale-effect ≠ severity.** An anchor's `stale_runtime_effect` tells the engine what to do when freshness fails. Severity is computed from the anchor type and the drift kind. A stale sanctions list trips `deny` at `critical`; a stale risk registry trips `require_revalidation` at `high`; a near-expiry feed trips `allow_with_constraints` at `medium`.

5 · Sample stable-drift event

## What a drift event looks like on the wire.

When the coupling check decouples and the local-validity bundle reports all four local checks passed, the detector emits a `kye.stable_drift_event.v1`. The event is referenced from the action's Evidence Pack™ and routed to the control owner per the recommended obligations.

kye.stable\_drift\_event.v1 — supplier risk uplift since authorisation

```
{
  "schema_version": "kye.stable_drift_event.v1",
  "drift_event_id": "kye:drift:acme:2026-05-14:a4f1",
  "check_id": "kye:coupling-check:acme:2026-05-14:a4f1",
  "action_id": "kye:action:acme:supplier_payment_release:inv-90213",
  "actor_entity_id": "kye:agent:acme:ap-automation-bot",
  "principal_entity_id": "kye:entity:acme:finance-office",
  "drift_type": "verified_but_stale",
  "severity": "high",
  "detected_at": "2026-05-14T12:30:15Z",
  "anchors_implicated": [
    {
      "anchor_id": "kye:anchor:acme:supplier-risk-registry",
      "anchor_type": "risk_context",
      "snapshot_id": "kye:snapshot:acme:supplier-risk-registry:2026-05-14T12-30-00Z"
    }
  ],
  "expected_state":  { "supplier_risk_rating": "low" },
  "observed_state":  { "supplier_risk_rating": "high", "uplift_at": "2026-05-14T11:42:00Z" },
  "description": "Locally-valid AP automation action releases payment to a supplier whose risk rating was uplifted to high after the purpose-grant was issued. Action remains authorised and evidenced; grounding has shifted.",
  "reason_codes": [
    "supplier_risk_uplift_since_authorization",
    "assumption_supplier_risk_rating_at_authorization_no_longer_holds"
  ],
  "recommended_runtime_effect": "require_human_review",
  "recommended_obligations": [
    "notify_finance_controller",
    "freeze_subsequent_releases_to_supplier_pending_review"
  ],
  "evidence_refs": [ "kye:evidence:acme:ap-release:inv-90213" ]
}
```

6 · OSS & proprietary

## Open contracts, managed engines.

The four schemas, the vocabulary, the example payloads and the conformance test vectors are open under Apache 2.0 — the same licence as the rest of KYE Protocol™. The managed engines (anchor ingestion at scale, signed snapshot stores, cross-tenant drift telemetry) and the sector-specific anchor libraries (financial services, healthcare, energy, logistics) are paid components of the KYE™ Cloud™ commercial tier.

### Open

Schemas · vocabulary · examples · conformance vectors · reference engine (Apache 2.0)

### Paid

Managed anchor ingestion · signed snapshot store · sector libraries · cross-tenant drift telemetry

7 · Next

## Authorised. Evidenced. Grounded.

Bring KYE™ Reality Coupling™ into your existing PDP. Pilot it on one high-blast-radius capability. See the stable-drift signal land in the Evidence Pack™ before you enforce.

[Apply for pilot](https://kyeprotocol.com/pilot-apply/) [View Approval Brief™](https://kyeprotocol.com/solutions/informed-approval/) [Browse Evidence Pack™](https://kyeprotocol.com/evidence-pack/) [Read whitepaper](https://kyeprotocol.com/whitepaper/)

Canonical KYE™ surfaces referenced on this page: [KYE™ Cloud™](https://kyeprotocol.com/apps/) · [KYE Protocol™](https://kyeprotocol.com/) · [Purpose Permission](https://kyeprotocol.com/glossary/).