SRF·Semantic Resonance Field v2.0

Kernel (base) MKP core

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

MRP state machine (HOLD / OPTIONS / TEST / DECIDE), MPM priority matrix, Degraded Safe Mode, Action Ticket reduced interface, and human‑initiated state transitions.

AD‑05 [MRP] — Meta‑Resolution Protocol & Meta‑Priority Matrix

Aliases: None Cluster: Kernel (base) Depends on: AD‑01 [OV], AD‑04 [TG], AD‑08 [SO]

0. For humans

What question does this answer?

"When multiple safety and quality signals disagree, who wins — and how do we guarantee the system always takes a conservative, reproducible path (Hold, Options, Test, Decide)?"

How do I know it's live?

You can point to:

  • A finite state machine over the four visible MRP states (HOLD, OPTIONS, TEST, DECIDE) that every turn is in, with logged transitions.
  • A Meta‑Priority Matrix (MPM): a documented precedence table that orders signal classes (PEL/gates, security, truth/drift, SPD, UX/attunement) and maps combinations to a specific next state.
  • Logs/FHR where each turn has: mrp_state_before, mrp_state_after, mpm_decision_id, mpm_priority_tier, mpm_reason_codes[].

Where do I see it?

  • UI: the Journey Strip (Hold → Options → Test → Decide) showing current MRP state and history; optional Action Trace showing last N transitions.
  • FHR / logs: mrp_state_seq[], mpm_decision_id, mpm_priority_tier, mpm_reason_codes per turn; counts of state distribution per session.

Quick checklist

  • Implemented if: documented MRP state machine with at least HOLD/OPTIONS/TEST/DECIDE; MPM with tiered signal classes and monotonicity; every turn tagged with MRP state.
  • Key artefacts: MPM precedence table, MRP state machine diagram, transition rules.
  • Key FHR fields: mrp_state_before, mrp_state_after, mpm_decision_id, mpm_priority_tier, mpm_reason_codes[].
  • Key failure codes: MRP_LOOP_GUARD_TRIGGERED, MRP-F02 (precedence violation).
  • Escalation path: loop guard → summarise/EXIT → AD‑12 [OP] incident.

1. Purpose & scope

AD‑05 [MRP] defines:

  1. The Meta‑Resolution Protocol (MRP) — a small state machine over the user‑visible states HOLD, OPTIONS, TEST, DECIDE, plus internal terminal states (FAILSAFE, EXIT).
  2. The Meta‑Priority Matrix (MPM) — the precedence rules that resolve conflicting signals (gates, SPD, drift, awe, toggles, etc.) into a single MRP transition.
  3. The constraints: fail‑closed, conservative tie‑breaking, no infinite loops, and no "ignore safety" paths.
  4. The FHR & UX hooks that surface MRP/MPM behaviour.

It is the kernel's orchestration layer: all safety and quality layers feed in; MRP/MPM decides what state to move to and what the system is allowed to do.

2. Signals that feed MRP

On each turn, MRP sees a bundle of signals:

  • Gate outcomes (AD‑04 [TG]): gate_decisions[] with G1–G5 / H1–H3 classes.
  • Ring states (AD‑01 [OV]): one state for every member of active_ring_ids[] (SIF/EHG/ODS in MKP; SIF/EHG/ODS/RCL/ERG in full), represented as PASS/TIGHTEN/FAIL with green/amber/red as the operator-UI projection.
  • Drift & Δ‑triad (AD‑06 [DG] / AD‑16 [ME]): delta_p_norm, delta_embed, delta_tools, delta_mi_excess, triad_branch_id, mi_upgrade.
  • SPD probes (AD‑27 [SPD]): IG (implicature), PP (presuppositions), DRT/AEG/SAM flags.
  • Awe / deference / trust (AD‑28 [AF]): awe score bands, deference detector flags, seduction test signals.
  • User / org toggles (AD‑14 [DS] / AD‑15 [PA] / AD‑22 [EC] / AD‑23 [EN] / AD‑25 [CP]): care mode, Eco mode, attunement preset, neutralise_style, literal_mode, ask_before_answer, reflect_only.
  • Context & resource state (AD‑07 [CL] / AD‑15 [PA] / AD‑23 [EN]): context meter (70%/85% thresholds), closure budget state, Energy Index E, archive & anchor suggestions.
  • Ops & environment (AD‑12 [OP] / AD‑17 [AM] / AD‑18 [SE] / AD‑19 [CI]): degraded mode, MKP vs full kernel, watchdog/halt conditions, CI redlines triggered, challenge suite outcomes.
  • Action Ticket state (AD‑18 [SE], reduced interface): ticket_status, ticket_completeness, preview_required, confirmation_required, irreversibility_class. MRP consumes Action Ticket state through this reduced interface and does not own the Action Ticket schema (see §2.1).

Normative MKP definition: FM‑02 MKP Quickstart; this section describes MRP's role within it and does not restate the composition.

Colour states green/amber/red are the operator‑UI projection of the canonical ring states {PASS, TIGHTEN, FAIL}.

MRP never sees raw internals (logits etc.) directly; it sees interpreted events and metrics from these layers.

2.1 Action Ticket interface note

MRP decides whether and how the system may proceed. The Action Ticket (defined in AD‑18 [SE]) defines what proceeding would concretely mean. MRP may decide not to enter DECIDE precisely because ticket completeness, preview requirement, or irreversibility status block that path.

MRP consumes Action Ticket state through a reduced interface: ticket_completeness, preview_required, confirmation_required, irreversibility_class. It does not own the Action Ticket schema, which lives in AD‑18 [SE] with full lifecycle, parameter structure, and reversibility semantics.

3. MRP states (user‑visible & internal)

3.1 User‑visible states

These are the four states that appear in the UI's Journey Strip and in FHR:

  1. HOLD. Not answering yet; clarifying, checking assumptions, or cooling down. Typical triggers: SPD presupposition conflict, unclear referent; awe/deference (user is over‑deferring); care cool‑down recommended; context near limit.

  2. OPTIONS. Presenting multiple options or framings without committing to one path. Typical triggers: contestable gates (G3–G4) with multiple safe paths; culture pack splits; trade‑off questions.

  3. TEST. Testing or validating a candidate path: running verification‑class tools — tools whose manifest declares side_effects = [NONE]; idempotence alone does not imply verification‑only behaviour — checking maths, doing simulations, or asking explicit alignment questions. Typical triggers: math/fact challenges; Δ‑triad drift or ΔMI suggesting behaviour change; watchdog or timing anomalies.

  4. DECIDE. Committing to a reply or state change (within all gate constraints). Typical triggers: no serious conflicts; all key checks green; a path has been through TEST/OPTIONS and is accepted.

3.2 Internal / terminal states

  • FAILSAFE. Hard failure in safety or environment (critical gate failure, exfiltration‑control alert). Behaviour: stop streaming, refuse, or escalate to human; log incident.

  • EXIT. Session is closing; summarise and stop; no further deep reflection.

  • ESCALATE. Intermediate handoff state, not a resolution outcome. MRP remains in HOLD and invokes the AD‑12 [OP] handoff path. No Meta‑Resolution object is emitted until the handoff resolves: continuing emits the resolved outcome; closing emits TERMINATE.

The user‑visible strip is a projection of this slightly richer internal machine.

4. Meta‑Priority Matrix (MPM)

4.1 Priority tiers

  1. Tier 0 — Hard blocks / environment. Law/PEL gating (G1), catastrophic security issues, critical infra errors. Actions: FAILSAFE → REFUSE or ESCALATE.
  2. Tier 1 — Safety & law (G1–G3). EHG & PEL gates, clinical guardrails, no‑go content, high‑risk compliance. Actions: HOLD → OPTIONS/ASK_FIRST → REFUSE or carefully constrained OPTIONS.
  3. Tier 2 — Truth & drift / instrumentation. Δ‑triad anomalies, MI upgrades, challenge suite failures, timing integrity anomalies. Actions: HOLD or TEST; rarely direct REFUSE.
  4. Tier 3 — SPD & culture. Implicatures, presuppositions, anaphora, irony, culture pack splits, politeness norms. Actions: HOLD (clarify), OPTIONS (alternate framings), ask‑first.
  5. Tier 4 — UX & attunement. Awe/deference, user toggles, pacing preferences. Actions: adjust tone, pacing, naming — cannot override higher tiers.

Invariant: When multiple tiers trigger, MPM takes the highest tier that fired, selects the most conservative allowed action at that tier, and documents this as mpm_priority_tier and mpm_reason_codes[]. No lower‑tier signal may weaken a higher‑tier decision.

4.2 Example sub‑rules

  • If any G1 gate = REFUSE → MRP → DECIDE with refusal; lower tiers adjust wording only.
  • If G3 is amber and SPD flags presupposition conflict → MRP → HOLD, then OPTIONS.
  • If gates green but Δ‑triad jumps with MI upgrade in high‑stakes domain → MRP → TEST.
  • If everything green except awe/deference → MRP stays in DECIDE with attunement forced to "Safe" and extra Ask‑First prompts.

The exact matrix is implementation detail; the ordering and monotonicity (always tighten, never loosen) is invariant.

5. MRP transition rules

5.1 Baseline flow

On each turn: gather signals → classify into tiers and reason codes → let MPM choose target_state given mrp_state_current and signals → execute the state's behaviour → log MRP_STATE_TRANSITION and MPM justification.

5.2 State‑by‑state transitions

  • From DECIDE: Tier 0/1 → DECIDE(refusal) or FAILSAFE. Tier 2 → TEST. Tier 3 → HOLD. Tier 4 only → stay in DECIDE, adjust tone/pace.
  • From HOLD: Conflicts resolved → OPTIONS or TEST. New Tier 1 events → DECIDE(refusal) or ESCALATE. Closure budget exceeded → EXIT with summary.
  • From OPTIONS: User selects option and gates allow → TEST or DECIDE. User rejects all → HOLD. New gate trigger → appropriate Tier 1/2 behaviour.
  • From TEST: Tests pass → DECIDE. Tests reveal contradictions → HOLD or OPTIONS. Watchdog/exfil fires → FAILSAFE.

Loop safeguards: Each MRP cycle is bounded by closure budgets (AD‑07 [CL]) and yield counts. Max introspection loops per turn. Repeated loops without progress force summarise/EXIT or escalation.

5.3 Human‑initiated state transitions

The human can invoke MRP state changes directly (AD‑31 [HS] §4.4):

  • "That felt too clean" or equivalent → system steelmans opposing position (triggers HOLD or TEST).
  • Explicit pause request → system summarises and holds (HOLD).
  • Explicit scope narrowing → system constrains to declared scope (constrained DECIDE).
  • Explicit audit request → system exports FHR slice (no state change; action logged).

Human‑initiated transitions are always honoured immediately and logged with friction_protocol_source = human_initiated.

6. Profiles & degraded modes

  • Architecture profile: kernel_profile declares the adopted specification profile and has the closed values {mkp, full}. Full Kernel activates the complete ring set; MKP remains active over the components and binding slices declared by FM‑02.
  • Runtime mode: runtime_mode has the closed values {normal, degraded}. If non-core modules fail (for example SPD or a Culture Pack), MRP remains within the declared architecture profile but routes more conservatively, never more permissively; it records degraded_reason_codes[] and favours HOLD/OPTIONS over DECIDE.
  • Active rings: active_ring_ids[] records the rings evaluated for the pass and must contain the required ring set for the declared kernel_profile. A required ring that is unavailable is recorded as a failed evaluation and blocks commit; it is never silently omitted. A ring outside the declared profile is inapplicable rather than unknown.
  • Profile-change boundary: a change between full and mkp invalidates every in-flight gate evaluation, plan_hash, preview/confirmation join, and unexecuted Action Ticket created under the prior profile. The work may resume only through a new ticket or freshly revalidated revision and a complete gating pass under the new profile. Profile change may never be used to make a blocked in-flight action executable.

7. FHR fields & events

7.1 Fields

Per session and per turn: mrp_state_before, mrp_state_after, mrp_state_seq[], mrp_turn_index, mpm_decision_id, mpm_priority_tier (0–4), mpm_reason_codes[].

Aggregates: mrp_state_counts{HOLD, OPTIONS, TEST, DECIDE}, mrp_loops_detected, mrp_exit_reason.

7.2 Events

  • MRP_STATE_TRANSITION{from, to, decision_id, tier, reasons[]}
  • MRP_LOOP_GUARD_TRIGGERED{state, reasons[]}
  • MRP_PROFILE_CHANGED{from_profile, to_profile, change_reason, governance_approval_id, invalidated_ticket_ids[], invalidated_plan_hashes[]}; the envelope timestamp is the effective change time. Empty invalidation arrays are explicit, not omitted.
  • MRP_RUNTIME_MODE_CHANGED{from_mode, to_mode, degraded_reason_codes[]}

8. UX & "Why this decision?" surface

MRP is invisible unless surfaced. AD‑15 [PA] / AD‑14 [DS] use MRP/MPM to provide explanations:

  • Journey Strip shows current mrp_state, with prior steps clickable for context.
  • Action Trace (if enabled) shows last N transitions with tier and reason.
  • Why‑this‑decision drawer summarises high‑tier reasons in user‑readable language. May omit or anonymise low‑tier metrics, but mpm_priority_tier and reason categories stay visible.

9. Invariants vs configurable degrees of freedom

Hard invariants:

  • There is a finite MRP state machine with at least HOLD, OPTIONS, TEST, DECIDE.
  • All safety‑relevant behaviour flows through MRP; nothing bypasses it.
  • There is a Meta‑Priority Matrix with: tiered signal classes, conservative tie‑breaking, and "lower tiers cannot weaken higher tiers" monotonicity.
  • Each turn logs mrp_state_before/after and mpm_priority_tier + reasons.
  • Loop guards & closure budgets ensure no unbounded introspection.

Configurable degrees of freedom:

  • The full list of signal types in each tier, and their grouping.
  • Exact mapping from combined signals to target_state (contents of MPM), as long as ordering and monotonicity are preserved.
  • Behaviour of each state at the UI level (how many options to show; how aggressive Ask‑First is; which tiles appear).
  • Loop guard thresholds and budget values.
  • AD‑01 [OV]: defines global invariants — gates→rings→MRP→emit ordering, fail‑closed transitions, MKP profile.
  • AD‑02 [GS]: uses mrp_state for group turn protocol and Journey Strip in group mode.
  • AD‑03 [CS]: challenge runs feed Tier‑2 (truth/drift) signals into MPM.
  • AD‑04 [TG]: gate decisions become Tier‑1 signals for MPM.
  • AD‑06 [DG]: drift metrics and triad branches are Tier‑2 inputs.
  • AD‑07 [CL]: closure budgets, Energy Index E, and context meter states limit how far MRP can loop.
  • AD‑08 [SO]: implements the FHR schema described here.
  • AD‑14 [DS] / AD‑15 [PA]: Journey Strip, Action Trace, Why‑this‑decision UI.
  • AD‑16 [ME]: provides Δ/RI/SESOI metrics and operating points consumed by MPM Tier‑2.
  • AD‑18 [SE]: owns the Action Ticket schema; MRP consumes ticket state through reduced interface (§2.1).
  • AD‑22 [EC] / AD‑23 [EN] / AD‑24 [CC] / AD‑25 [CP] / AD‑27 [SPD] / AD‑28 [AF]: care modes, energy, clinical/cognitive, culture packs, SPD, and awe feed into various tiers of MPM.
  • AD‑31 [HS]: human‑initiated friction maps to MRP state transitions (§5.3); integrity prompts interact with MRP states (pause → HOLD, scope narrow → constrained DECIDE).

11. Acceptance: when can you say "AD‑05 is implemented"?

You can confidently claim AD‑05 [MRP] is live if:

  1. Your system has a documented MRP state machine with at least HOLD/OPTIONS/TEST/DECIDE, and every turn is tagged with an MRP state before and after processing.

  2. You have a Meta‑Priority Matrix that: groups signals into priority tiers, documents which combinations map to which next state, enforces "higher tier wins" and conservative tie‑breaking.

  3. The Journey Strip / Action Trace in the UI is consistent with logged MRP transitions.

  4. FHR/logs expose: mrp_state_seq, mpm_decision_id, mpm_priority_tier, mpm_reason_codes, and loop guard/exit reasons.

  5. There are no code paths where tools run or outputs are emitted that bypass MRP (e.g. "quick path" completions that ignore gates/MPM).

If any of those are missing — especially if decisions are made ad‑hoc per layer with no single orchestrating protocol — then you have SRF‑inspired partial routing, but not the AD‑05 kernel spec.