KYE Reality Coupling™ · stable-drift detection for delegated AI actions

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 validauthority OK · purpose OK · scope OK · evidence verifiable
globally wrongthe world the action depends on has shifted
4 schemasanchor · snapshot · coupling check · stable-drift event
1 new noden_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 freshnessIs the upstream authoritative source within its freshness contract? (sanctions lists, price feeds, supplier registry.)
  • Source-of-truth integrityDoes the snapshot's signature verify against the registered key? Is the chain of custody intact?
  • Policy context currentIs the policy version the action was authorised under still in force, or has it been superseded?
  • Environment state currentAre the environmental pre-conditions (market open, jurisdiction active, system in nominal mode) still true?
  • Assumptions currentDid any stated assumption attached to the purpose-grant expire before evaluation?
  • Cross-system consistencyDo 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.

login Action Request

Agent or PEP proposes a delegated action.

flag Purpose

Purpose-grant resolved & scope confirmed.

key Authority

Delegation chain verified end-to-end.

timeline State

Resource & system pre-conditions evaluated.

compass_calibration Reality Coupling™

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

policy Rules

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

verified Decision

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

inventory_2 Evidence

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

replay 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.

AnchorTypeMax stalenessStale effect
OFAC SDN sanctions listexternal_source_of_truth3600 sdeny
Supplier risk registryrisk_context86400 srequire_revalidation
Wholesale market price feedenvironment_state60 srequire_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.

code 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.

OpenSchemas · vocabulary · examples · conformance vectors · reference engine (Apache 2.0)
PaidManaged 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.