SRF·Semantic Resonance Field v2.0

Kernel (base) MKP core

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

SIF‑α / EHG‑γ / ODS‑δ gate semantics, contestability paths, NLI/STS gating, and the precedence order that governs all downstream routing.

AD‑04 [TG] — Truth & Norm Gates, Contestability

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

0. For humans

What question does this answer?

"When the system says no or only like this, what is it actually doing under the hood, and how can people see and challenge that?"

How do I know it's live?

You can point to:

  • A well‑defined gate stack (G1–G5 classes, H1–H3 horizons) that always fires before tools and before final output.
  • A Contestable Gate Mode surface: Refusal Cards that show which gate fired and whether it is contestable; a Dispute drawer with contestability class + ETA / appeals route.
  • Logs where every refusal or policy‑shaped reply has a gate_id, g_class, horizon, contestable, and a hash‑stable policy citation.

Where do I see it?

  • UI: Refusal Card with short reason and a "Challenge gate" action when contestable. Dispute drawer showing G‑class/H‑horizon, policy snippet, and (if escalated) an ETA and incident ID.
  • FHR / logs: gate_events[] with gate_id, g_class, horizon, contestable, decision; gate_contest_count, gate_contest_eta_p50, resolution stats.

Quick checklist

  • Implemented if: gate taxonomy with G1–G5 & H1–H3 exists; every refusal traceable to a gate decision; users can see and challenge gate decisions.
  • Key artefacts: gate taxonomy document, PEL, Refusal Card schema.
  • Key FHR fields: gate_id, g_class, horizon, contestable, gate_refusal_rate, gate_contest_count, gate_appeal_upheld_rate.
  • Key failure codes: GATE_BYPASS (AD‑01 failure condition 1).
  • Escalation path: Dispute drawer → AD‑12 [OP] SLAs → AD‑21 [RM] governance.

1. Purpose & scope

AD‑04 [TG] defines the truth/norm gate layer:

  • The taxonomy of gate classes (G1–G5) and source horizons (H1–H3).
  • The precedence rules for gates relative to rings, SPD, Δ‑triad, and UX.
  • The Contestable vs Appeal‑Only distinction, and how users can see and dispute gate decisions.
  • The FHR and UI hooks that make gating behaviour auditable.

It does not: define ring behaviour (SIF/EHG/ODS/RCL/ERG — that is AD‑01 [OV] / AD‑05 [MRP]); define SPD modules (IG/PP/DRT/AEG/SAM — that is AD‑27 [SPD]); define CI thresholds or SAP (that is AD‑16 [ME] / AD‑19 [CI]).

2. Gate taxonomy

2.1 Gate classes G1–G5

Gates are distinguished by what kind of norm they enforce and how contestable they are.

  • G1 — Hard Law / PEL NO‑GO. Content that would break law, contractual obligations, or non‑derogable PEL. Examples: direct criminal instructions, serious violent harm, child sexual abuse material. Contestability: appeal‑only (cannot be overridden in‑session).
  • G2 — Organisational / Regulatory Compliance. Internal policies and regulator‑mandated patterns. Examples: internal data retention rules, IP handling, sector‑specific prohibitions. Contestability: user can challenge interpretation, not the underlying obligation.
  • G3 — Safety / Harm‑Avoidance Heuristics. Non‑legal safety norms (self‑harm, mental health, harassment, abuse); harm‑minimisation patterns. Examples: refusing pseudo‑clinical diagnosis, refusing to coach self‑harm, refusing to escalate abusive contact. Contestability: contestable with strong bias to caution; may route to Present‑Options rather than full refusal.
  • G4 — Cultural / Community Norms. Norms from Culture Packs (AD‑25 [CP]): community standards, language conventions, sensitivities. Examples: respectful terms within a community, taboo topics at certain times, avoidance of pathologising language. Contestability: fully contestable; explicit Dissent + appeals path back to pack governance (AD‑32 [PG]).
  • G5 — Personal / Session‑Scoped Preferences. User‑specific toggles and declared boundaries. Contestability: trivial — user can override their own G5; others cannot override someone else's.

Each decision is tagged with g_class in logs and UI.

2.2 Horizons H1–H3

Orthogonal to G1–G5, the horizon tracks how far‑reaching the norm is:

  • H1 — Global / Universal. Cores claimed as globally applicable (no child abuse, no genocide advocacy, etc.).
  • H2 — Jurisdiction / Sector. Laws/policies that apply to a jurisdiction or industry.
  • H3 — Local / Community / Context. Culture packs, community guidelines, local traditions, organisation‑specific etiquette.

A gate is identified by (gate_id, g_class, horizon). Horizon determines appeal routing and fallback behaviour when pack data is missing.

3. Precedence & interaction with other layers

3.1 Order relative to Rings & SPD

Combined precedence:

  1. PEL / EHG gates (G1–G3 at H1–H2)
  2. Rings active under kernel_profile in their fixed authority order (SIF / EHG‑γ / ODS in MKP; add RCL in full)
  3. NLI / STS semantic checks (meaning vs style)
  4. SPD (IG/PP/DRT/AEG/SAM)
  5. Δ‑triad & ΔMI (drift / change metrics)
  6. ERG where active in the full profile (pace‑only)

Reading note: item 1 names gate evaluation — G1–G3 enforcing PEL/EHG‑class constraints, per the Gates → Rings → MRP → emit pipeline; items 2–6 order the ring‑and‑telemetry passes that follow. EHG names both a constraint class enforced at gate level and the ring EHG‑γ; the gate sense is meant here. The evaluation‑vs‑authority distinction is defined in AD‑01 [OV] §2.3.

Effects: gates always fire before tools and before final text. SPD, Δ‑triad, and UX may tighten gate outcomes (ask‑first, present‑options), but never weaken them. ERG can slow pacing or encourage reflection, but cannot soften a refusal.

3.2 Gate decisions

Each gate decision is one of: ALLOW, SHAPE (content allowed but must be reframed or limited), ASK_FIRST (require explicit clarifying consent), REFUSE (cannot proceed; emit Refusal Card), ESCALATE (freeze output; route to human/governance).

ESCALATE is an intermediate routing decision, not a terminal resolution: it moves MRP to HOLD, freezes execution, and opens the AD‑12 handoff. No final resolution object is emitted until the handoff resolves; if the interaction closes first, the outcome is TERMINATE. next_user_surface = null means no specialised component applies (normal response, exit summary, or handoff messaging).

AD‑05 [MRP] resolves multiple gate outputs via the Meta‑Priority Matrix: hardest gates (G1/H1) win outright; conflicts go to the more conservative outcome; ties are logged and can trigger Contestable Gate Mode.

Scoped precedence (normative): gate precedence is applied per action scope. REFUSE permanently removes the prohibited scope from the candidate plan; independently permitted residual scope may then proceed through MRP. Where a turn contains both refused and permitted scope, the Refusal Card is emitted for the refused scope and the permitted remainder may surface bounded options beside it.

4. Contestable Gate Mode

4.1 Refusal Card payload

When a gate yields REFUSE or SHAPE, the system generates a Refusal Card (AD‑14 [DS]):

  • Shows: short reason (≤15 words, grade‑7), gate_id, g_class, horizon, contestable: true/false.
  • Actions: Rephrase request, See relevant policy, Challenge gate (only if contestable = true), Ask a human (where available).

4.2 Dispute drawer

If the user clicks "Challenge gate," the system opens the Dispute drawer (AD‑14 [DS]):

  • Shows: gate name & description, contestability class, policy citation(s) used. If escalated: ETA for review (from AD‑12 [OP] SLOs), incident/ticket ID.
  • Events: GATE_CONTESTED{gate_id, g_class, horizon, contestable, eta}, GATE_APPEAL_FILED{gate_id, cpl_entry_id}.

The gate decision does not change immediately; the challenge logs an appeal and may later update policy/packs.

4.3 Contestability rules

  • G1 / H1–H2 — Appeal‑only: you can challenge documentation or interpretation, but not override in session.
  • G2 / H2 — Semi‑contestable: system may present options within safe space; policy itself is not waived.
  • G3 — Contestable caution: overrides may be possible with strong consent + context; always logged and rare.
  • G4–G5 / H3 — Fully contestable: culture‑/preference‑based; user/community can meaningfully disagree and change behaviour via pack updates (AD‑32 [PG]).

5. Sources & quorums

5.1 Norm sources

Gates pull norms from: PEL/law (G1, some G2); organisational policy (G2/G3); clinical/cognitive guidelines (G3) — for non‑clinical boundaries; Culture Packs (G4) — community and culture norms (AD‑25 [CP]); user preferences (G5) — session toggles and Pin constraints.

Each source has: source_id, source_type, jurisdiction, culture_pack_id (for G4), expiry/review cadence.

5.2 Quorum rules

To avoid "one random source says no": for many G2/G3 decisions, quorum rules apply (e.g. "2 of 3 high‑trust sources" or "1 high‑trust + 1 culture pack entry"). Disagreement between sources implies: show Present‑Options instead of a single answer; log a gate disagreement event for governance review. This is especially important when combining G4/G5 (culture/prefs) with G1/G2/G3 (law/safety). Present‑Options names resolution‑layer behaviour: the MRP OPTIONS state, logged as mpm_decision: present_options and resolving to outcome PRESENT_BOUNDED_OPTIONS (AD‑05 [MRP]; AD‑18 [SE] §4.3). Gate decisions route to it; it is not itself a gate decision value.

Each evaluated source set receives an immutable policy_quorum_id and records its canonical policy_quorum_source_ids[]. The ID and source set travel into the Action Ticket plan hash and tool-entry forensics (AD‑18 [SE] §3.5); changing either invalidates the frozen plan.

6. FHR fields & events

6.1 Per‑session / per‑decision fields

AD‑08 [SO] exposes at least:

  • gate_events[] per firing: gate_id, g_class, horizon, decision ∈ {ALLOW, SHAPE, ASK_FIRST, REFUSE, ESCALATE}, contestable: bool, policy_source_ids[], policy_quorum_id, policy_quorum_source_ids[], cpl_entry_id.
  • Aggregates: gate_decision_counts{decision}, gate_by_class_counts{G1..G5}, gate_refusal_rate, gate_ask_first_rate, gate_present_options_rate (share of gate‑touched turns whose resolution presented bounded options; resolution‑layer, per §5.2).
  • Contestability: gate_contest_count, gate_contest_eta_p50, gate_contest_eta_p95, gate_appeal_count, gate_appeal_upheld_rate.

6.2 Events

  • GATE_FIRED{gate_id, g_class, horizon, decision, contestable, policy_source_ids[]}
  • GATE_CONTESTED{gate_id, g_class, horizon, contestable, eta}
  • GATE_APPEAL_FILED{gate_id, cpl_entry_id}
  • GATE_DECISION_OVERRIDDEN{gate_id, operator_id, governance_decision_id}

Overridden decisions are heavily audited and must never downgrade G1/H1–H2 content.

7. Invariants vs configurable degrees of freedom

Hard invariants:

  • There exists a gate classification (G1–G5) and horizon schema (H1–H3).
  • Gates fire before tools, SPD, and UX polish, integrated with ring precedence.
  • For every refusal/shaped output, logs contain: gate_id, g_class, horizon, contestable, and a policy source reference.
  • Contestable vs appeal‑only behaviour is fixed by class (e.g. G1 never overrideable in session).
  • Gate decisions are visible in UI (Refusal Card + Dispute drawer) and in FHR.

Configurable degrees of freedom:

  • Which concrete gate IDs exist (beyond the canonical ones) per deployment.
  • Which sources count toward quorum (e.g. specific regulator docs or organisational policies).
  • Exact thresholds for when to use ASK_FIRST vs REFUSE for borderline content.
  • SLA/ETA values in Dispute drawer (governed by AD‑12 [OP]).
  • AD‑01 [OV]: declares truth/ethics supremacy and gates‑before‑tools as global invariants.
  • AD‑05 [MRP]: resolves multiple gate outputs through MPM; integrates gate decisions with other signals.
  • AD‑06 [DG]: uses gate outcomes alongside drift metrics; drift may cause a gate to fire more often.
  • AD‑14 [DS]: implements Refusal Cards, Containment vignettes, and Dispute drawer.
  • AD‑15 [PA]: surfaces gate decisions in the "Why this decision?" drawer and prompt tiles.
  • AD‑20 [DP] / AD‑21 [RM]: map gate types to legal exposures; tie contested decisions into the evidentiary chain.
  • AD‑22 [EC] / AD‑24 [CC]: define additional NO‑GO areas (clinical, care) implemented as specific G3 gates.
  • AD‑25 [CP] / AD‑26 [CA]: provide culture packs and CPL entries that power G4/G5 gates and track their use.
  • AD‑32 [PG]: pack governance constrains the quality of norms grounding G4/G5 decisions. Pack‑level challenges (AD‑32) extend AD‑04's contestability from individual gate decisions to the authorship level.

9. Acceptance: when can you say "AD‑04 is implemented"?

You can honestly claim AD‑04 [TG] is live if:

  1. You have a gate taxonomy with G1–G5 & H1–H3, and a documented list of gate IDs.
  2. Every material refusal, shaping, or ask‑first is traceable to a gate decision with gate_id, g_class, horizon, contestable, and policy source.
  3. Users can see and challenge gate decisions: Refusal Card displays at least a short human reason; Dispute drawer shows contestability and policy source; challenges are logged and route into governance.
  4. FHR/logs provide gate metrics for safety/fairness/RA: counts by class; contestation stats; resolution rates.
  5. Gate decisions respect global invariants: truth/ethics precedence, gates‑before‑tools, fail‑closed routing, tighten‑only SPD.

If some of those are missing (e.g. you have refusals but no gate_id or contestability surface), you are closer to a generic policy layer than to the SRF truth/norm gate spec.