SRF·Semantic Resonance Field v2.0

Kernel (base) MKP core

Depends on: AD‑01 [OV], AD‑04 [TG], AD‑05 [MRP], AD‑08 [SO], AD‑16 [ME] · All cards

Δp / Δ_embed / Δ_tools routing, band thresholds, cross‑session drift extension, and drift-derived constraints consumed by the Action Ticket and plan hash.

AD‑06 [DG] — Drift & Δ‑Triad Routing

Aliases: none Naming lineage: draft‑era tag [NG] retired; [DG] is canonical. Cluster: Kernel (base) Depends on: AD‑01 [OV], AD‑04 [TG], AD‑05 [MRP], AD‑08 [SO], AD‑16 [ME]

0. For humans

What question does this answer?

"When the system's behaviour or answers change, how do we measure that, decide if it matters, and route conservatively (clarify, test, summarise, or roll back) instead of continuing like nothing happened?"

How do I know it's live?

You can point to:

  • A runtime Δ‑triad: delta_p_norm (textual delta per token), delta_embed (semantic delta), delta_tools (tool behaviour delta), optionally plus delta_mi_excess as a corroborant.
  • A triad branching logic that maps those signals + NLI/STS + SPD into triad_branch_id ∈ {A_Default, T_Ht, T_HeHp, T_FailSafe, …} and then into a concrete MRP state.
  • FHR entries per session with: Δ‑triad bands by domain/locale/context_band, counts of triad branches taken, how often Δ triggered HOLD/TEST or MKP.

Where do I see it?

  • UI: "Why this decision?" drawer with cues like "Large change vs earlier answer; re‑checking before committing." Optional Advanced drawer showing Δ bands (low/medium/high).
  • FHR / logs: delta_p_norm, delta_embed, delta_tools, delta_mi_excess, triad_branch_id, mi_upgrade, delta_band_counts{low, med, high}, drift incidents & remediation actions.

Quick checklist

  • Implemented if: Δ‑triad computed and logged per context band; NLI/STS discriminates style from meaning; finite set of triad branches with documented MRP routing; drift in high-stakes domains changes behaviour.
  • Key artefacts: triad branch definitions, drift routing rules, NLI/STS threshold configuration.
  • Key FHR fields: delta_p_norm, delta_embed, delta_tools, triad_branch_id, drift_incidents_count.
  • Key failure codes: DRIFT_INCIDENT_OPENED, T_FailSafe.
  • Escalation path: T_FailSafe → MKP / FAILSAFE → AD‑12 [OP] incident.

1. Purpose & scope

AD‑06 [DG] defines:

  1. What "drift" means in the SRF kernel (which kinds we care about and at what level: lexical, semantic, tools, behaviour over time).
  2. The Δ‑triad as a runtime instrument: how we compute the three main deltas and why we normalise them.
  3. The branching rules that convert Δ‑triad + NLI/STS + SPD into routing decisions (HOLD/OPTIONS/TEST/DECIDE, or MKP/FAILSAFE).
  4. The invariants: Δ never acts alone; NLI/STS protects paraphrases; Δ is per‑context‑band; ΔMI is corroborant only.

Measurement details (estimators, ROC/PR, SESOI, power) live in AD‑16 [ME]; AD‑06 specifies how those numbers are used at runtime.

2. Types of drift we care about

AD‑06 is concerned with behavioural drift, not weight‑level training drift (handled via CI & RA):

  1. In‑session answer drift. The model changes its answer to the same or equivalent question as the session unfolds.
  2. Tool‑behaviour drift. The model starts calling different tools, or calling them differently, for similar inputs.
  3. Context / framing drift. The kernel's internal sense of constraints, assumptions, or goals shifts without explicit user consent.
  4. Locale / cultural drift (session‑level). Shifts in language, register, or normative stance that do not match the active culture pack or preferences.

AD‑06 does not try to freeze everything; it insists that meaningful changes get noticed, measured, and routed through the protocol instead of being silently absorbed.

3. Δ‑triad: what we measure

3.1 Δp (textual delta, length‑normalised)

delta_p_norm measures how much the model's token‑level predictions change between two comparable contexts, per token. Computed on either next‑token distributions or sampled outputs in measurement mode (deterministic T=0 path). Normalised by prompt length (/ prompt_len_tokens). Banded by context_band ∈ {short, med, long}, domain, locale, tokeniser family.

Low Δp_norm = text behaviour is stable. High Δp_norm = the model is "thinking differently" about what text to emit, even if semantics might still align.

3.2 Δ_embed (semantic delta)

delta_embed measures the semantic shift between outputs or internal representations: typically computed as distance between sentence‑level embeddings. Normalised and banded similarly.

Low Δ_embed with high Δp_norm ≈ style change (paraphrasing). High Δ_embed implies meaning shift, requiring more caution.

3.3 Δ_tools (tool behaviour delta)

delta_tools measures changes in what tools the model calls and how: compares set of tools used, frequency, argument patterns. Normalised per context_band & domain.

Low Δ_tools = same tool plan. High Δ_tools = the system is using different capabilities (potentially more powerful or more sensitive ones).

3.4 ΔMI (corroborant, not a gate)

delta_mi_excess measures approximate mutual information change between context and next‑token distribution, adjusted vs a shuffle baseline.

Key rule: ΔMI is never used as a standalone gate. It can only tighten a decision when Δp_norm and/or Δ_embed already indicate a problem.

AD‑16 [ME] specifies estimators (MI method, shuffle baseline, confidence intervals). AD‑06 defines the runtime gating rule: ΔMI is an extra warning light, not a fire alarm on its own.

4. Filtering out "just style": NLI/STS and SPD

Before treating a large Δ as meaningful drift, AD‑06 requires a semantic sanity check:

  1. NLI/STS check. Compare old vs new answer. If NLI says "Entailment" and STS ≥ threshold (semantic similarity high), treat Δ as style, not meaning.
  2. SPD layer. If SPD (IG/PP/DRT/AEG/SAM) identifies the change as a different phrasing in a coherent discourse context: route to HOLD for clarification at most; do not treat as serious drift.

Only when NLI/STS indicate Non‑Entailment/Contradiction, or STS is below threshold in a high‑stakes domain, does Δ become a candidate for triad branching into TEST/HOLD/FAILSAFE.

This prevents legitimate paraphrases from repeatedly triggering drift alarms.

5. Triad branches & routing

AD‑06 defines branch IDs that summarise how Δ‑triad and supporting checks look:

  • A_Default — all green. Δp_norm, Δ_embed, Δ_tools within low/medium bands; NLI/STS fine; SPD clear. → MRP stays in DECIDE, or brief HOLD for UX reasons only.
  • T_Ht — high textual + semantic delta. Δp_norm and Δ_embed above high band; NLI/STS indicate non‑entailment or contradiction. → MRP → TEST or HOLD: re‑evaluate, present options, or summarise inconsistency.
  • T_HeHp — high embed + high tools. Δ_embed and Δ_tools high; gate decisions or tool plan significantly altered. → MRP → TEST + possible MKP, especially if safety‑critical.
  • T_ToolsOnly — tool drift only. Δ_tools high, Δ_embed low/med; semantics same but capabilities changed. → MRP → TEST or HOLD: ask user to confirm new tool use; may require Ask‑First.
  • T_FailSafe — severe drift / instrumentation suspicion. Δp_norm wild, Δ_embed high, Δ_tools high; plus environment anomalies. → MRP → FAILSAFE: refuse, summarise, or roll back; log incident, potentially switch to MKP.

Exact boundaries between branches come from AD‑16 [ME] (SESOI and banding). AD‑06 requires: a finite set of branch IDs, logged as triad_branch_id, each with a clear mapping to MRP transitions.

6. What drift routing makes the system do

6.1 In‑session drift

When Δ‑triad + NLI/STS + SPD classify a change as meaningful drift, AD‑06 mandates:

  • Never silently overwrite earlier commitments. The system must either explicitly revise ("Earlier I said X; re‑checking, I now think Y. Here's why…") or ask the user to confirm.
  • Route through MRP: at least one turn in HOLD or TEST before DECIDE, for medium/high drift in high‑stakes domains.
  • Update context headers (AD‑15 [PA]) instead of smearing change: update "Assumptions," "Constraints," or "Open contradictions" slots and show that to the user.

6.2 Tool / capability drift

When Δ_tools is high: require Ask‑First before using a new class of tools, especially if they involve data exfil, external calls, or storage. For large capability shifts, AD‑06 can force a temporary MKP profile or a backoff to simpler operations until user consent and/or CI checks catch up.

6.3 Drift vs awe/deference

AD‑06 and AD‑28 [AF] talk to each other: if drift coincides with high awe/deference, AD‑06 must prefer TEST/HOLD and Ask‑First, not DECIDE. Deference is never allowed to cover up drift.

6.4 Cross-session drift

When session continuity is active (AD‑30 [SC], continuity_light or continuity_full modes), AD‑06's Δ‑triad instrument is extended to inter‑session baselines. continuity_drift_score (AD‑30 [SC] §4) uses the same Δ‑triad methodology to detect when accumulated attunement has diverged from safety baselines across sessions. The response logic is tighten‑only: additional checks, never silent relaxation.

7. FHR fields & events

AD‑06 defines the semantics of fields that AD‑08 [SO] provides.

7.1 Per‑session / per‑domain aggregates

  • delta_p_norm_band_counts{low, med, high}
  • delta_embed_band_counts{low, med, high}
  • delta_tools_band_counts{low, med, high}
  • Optionally: delta_mi_band_counts or summary statistics.

By: domain, locale, context_band, tokenizer_family.

7.2 Branch and routing statistics

  • triad_branch_counts{A_Default, T_Ht, T_HeHp, T_ToolsOnly, T_FailSafe, …}
  • Per branch: branch_to_mrp_state_counts{HOLD, OPTIONS, TEST, DECIDE, FAILSAFE}

Flags: drift_incidents_count, drift_resolved_in_session_count, drift_unresolved_count.

7.3 Events

  • DELTA_TRIAD_EVAL{delta_p_norm, delta_embed, delta_tools, delta_mi_excess, triad_branch_id}
  • DRIFT_ROUTING_DECISION{triad_branch_id, mrp_state_before, mrp_state_after}
  • DRIFT_INCIDENT_OPENED{reason, branch_id}
  • DRIFT_INCIDENT_RESOLVED{incident_id}

These events are joined to CI/RA/evidentiary chain entries for post‑mortems.

8. Invariants vs configurable degrees of freedom

Hard invariants:

  • The system must compute and log a Δ‑triad (Δp_norm, Δ_embed, Δ_tools) per relevant context, normalised and banded (domain×locale×context band).
  • ΔMI is not allowed to act as a standalone gate; it only tightens decisions when other deltas already signal risk.
  • NLI/STS & SPD checks are used to discriminate semantic drift vs style change before treating drift as critical.
  • There is a finite set of triad branch IDs, each with a documented mapping to MRP transitions and guardrails.
  • Medium/high drift in high‑stakes domains must pass through HOLD/TEST (or FAILSAFE/MKP) before DECIDE.
  • Drift responses must be explicitly acknowledged (not silent overwrites of earlier answers).

Configurable degrees of freedom:

  • Exact thresholds and bands for low/med/high deltas per domain×locale×context band.
  • Which branch IDs exist beyond the canonical set, as long as each is mapped conservatively.
  • Exact NLI/STS thresholds by domain.
  • Which domains require more aggressive drift handling (e.g. clinical, legal, compliance).
  • AD‑01 [OV]: declares Δ & drift as part of the control lattice and invariants (not just analytics).
  • AD‑03 [CS] / AD‑16 [ME] / AD‑18 [SE]: define challenge content and SAP for calibrating Δ bands, ΔMI, and operating points (offline). AD‑06 uses those thresholds at runtime.
  • AD‑04 [TG]: gate outcomes combine with drift; if Δ indicates the system is treating a topic as less risky than before, gates may clamp behaviour.
  • AD‑05 [MRP]: uses triad_branch_id and Δ bands as Tier‑2 signals in the Meta‑Priority Matrix.
  • AD‑08 [SO]: provides FHR schema and dashboards, including Δ and triad branch stats.
  • AD‑15 [PA]: uses Δ to suggest summarise, archive & anchor, context compression, or Pin Review when context nears cliffs.
  • AD‑16 [ME]: specifies instrument methodology — Δ/L normalisation, MI estimators, coupling diagnostics, tokeniser‑swap tests, translation drift metrics, morphology probes, calibration curves. (This content was formerly in the V4 computational‑linguistics card, then carrying the local alias [CL], and is now redistributed; see Naming & Reference Rules, §4.)
  • AD‑28 [AF]: uses Δ + awe/deference metrics to detect "seduction" patterns; drift plus high awe is particularly suspicious.
  • AD‑29 [PLG]: PLG's applied Δ‑triad instance (AD‑29 §6) operationalises AD‑06's canonical instruments for projection/loop contexts; scope‑adjacent move detection (AD‑29 §6.1) feeds into triad branching as a third class of semantic movement alongside in‑scope and style‑only.
  • AD‑30 [SC]: cross-session drift detection extends the Δ‑triad instrument to inter‑session baselines; continuity_drift_score uses the same methodology.

10. Acceptance: when can you say "AD‑06 is implemented"?

You can truthfully claim AD‑06 [DG] is live if:

  1. Your deployment computes and logs Δ‑triad metrics (Δp_norm, Δ_embed, Δ_tools, optionally ΔMI) per context band, with calibrated bands.

  2. You use NLI/STS and SPD to distinguish semantic drift from stylistic variation before acting.

  3. You have a finite set of triad branches (triad_branch_id) with clear semantics and conservative routing into MRP states.

  4. Drift in high‑stakes domains changes behaviour: more HOLD/TEST, Ask‑First, Present‑Options, summarise/anchor, or MKP/FAILSAFE — not just "we log and ignore it."

  5. FHR and events expose: Δ bands, branch counts, drift incidents and resolutions, so RA, ops, and governance can see how often drift happens and how you responded.

If Δ metrics exist but do not feed into routing; or if drift never changes behaviour; or if ΔMI is used as a black‑box gate on its own; then AD‑06 is not truly implemented. You have metrics without a drift protocol.