SRF·Semantic Resonance Field v2.0

Culture Full kernel

Depends on: AD‑01 [OV], AD‑04 [TG], AD‑05 [MRP], AD‑06 [DG], AD‑08 [SO], AD‑14 [DS], AD‑15 [PA] · All cards

Turn‑taking protocol, per‑participant tracking and DVI, dissent preservation, asymmetric SRF depth classes, and consent ceilings for multi‑participant sessions.

AD‑02 [GS] — Group SRF: Multi‑User Turn Protocol & Dissent Visibility

Aliases: None Cluster: Culture Depends on: AD‑01 [OV], AD‑04 [TG], AD‑05 [MRP], AD‑06 [DG], AD‑08 [SO], AD‑14 [DS], AD‑15 [PA]

0. For humans

What question does this answer?

"How do we run the SRF kernel in a group setting (teams, workshops, cohorts) without losing fairness, consent, or dissent in the noise?"

How do I know it's live?

You can point to:

  • Clear group‑mode activation: the system knows when multiple humans are in‑scope (and who).
  • A turn protocol that treats each participant as a first‑class speaker with their own identity and state.
  • A visible Dissent badge and log; dissent is recordable and traceable, not swallowed by summary.
  • FHR entries with group metrics: participant list, turn/time distribution, dissent counts, group fairness slices.

Where do I see it?

  • UI: A "Group mode" indicator. Turn chips per participant (name/role, whose turn, who spoke when). A Dissent badge you can click to see dissent entries and their status.
  • FHR / logs: group_mode = true, group_participants[], per‑participant turns/tokens, dissent_total, dvi_ack_rate, dvi_addr_rate, dvi_residual, turn_ratio_max_min, silent_participant_count.

Quick checklist

  • Implemented if: distinct group mode with participant tracking, dissent surface, DVI metrics, and fairness indicators in FHR.
  • Key artefacts: group turn protocol, dissent log schema, DVI metric definitions.
  • Key FHR fields: group_mode, group_participants[], dissent_total, dvi_ack_rate, turn_ratio_max_min.
  • Key failure codes: GROUP_BURDEN_ASYMMETRY_FLAGGED.
  • Escalation path: AD‑22 [EC] / AD‑24 [CC] for clinical or power-dynamic escalation.

1. Purpose & scope

AD‑02 [GS] defines:

  1. The group‑mode turn protocol: how the system interacts when more than one human is in the loop.
  2. The Dissent Visibility surface: how people can register disagreement and how it is preserved.
  3. The metrics and invariants for fairness and consent in group settings.
  4. The FHR and UI hooks so group behaviour is auditable and testable, not emergent.

It does not:

  • Duplicate the core safety lattice (that remains in AD‑01 [OV] / AD‑04 [TG] / AD‑05 [MRP] / AD‑06 [DG]).
  • Define clinical group therapy (explicitly out of scope; AD‑24 [CC] defines the non‑clinical stance).
  • Overrule organisational facilitation — it wraps around it, adding structure and telemetry.

2. Group SRF primitives

2.1 Participants & roles

Group SRF assumes a set of participants:

  • participant_id (opaque)
  • display_name (for UI)
  • role ∈ {facilitator, participant, observer}

A group session has:

  • group_mode = true
  • group_participants[]
  • group_facilitator_id (optional; can be human or "none")

Roles matter because the facilitator may steer topic and invite voices; participants are the ones whose dissent, consent, and tasks are tracked; observers are read‑only (e.g. compliance, legal, silent team members).

2.2 Turns & protocol states

Each utterance from a human is a turn:

  • turn_id, speaker_id, timestamp
  • turn_type ∈ {question, disclosure, reaction, dissent, meta}

The system overlays its MRP states on top: HOLD (clarifying and reflecting), OPTIONS (surfacing possibilities without commitment), TEST (clarifying implications and trade‑offs), DECIDE (converging and recording a choice).

The Group SRF protocol is: a sequence of turns, each tagged by speaker_id and mrp_state, with explicit transitions between states and explicit dissent logging.

3. Group‑mode invariants

These are non‑negotiable in group mode:

  1. Explicit group consent. Everyone must know the system is present, what it logs, and what it cannot do. Group mode cannot start as a shadow participant.

  2. No pseudo‑therapeutic group care. The system does not lead therapy sessions or conflict mediation pretending to be a human expert. It can help structure, reflect, summarise, and track tasks, but crisis/care stays with humans and ops procedures.

  3. No majority override of dissent. "Most people agreed" is never sufficient to erase a dissent entry. Dissent remains visible, with its own log and status.

  4. Per‑participant fairness visibility. Allocation (turns, tokens, tasks) and decisions must be inspectable by participant_id. It must be possible to see if someone was persistently sidelined.

  5. No invisible cross‑person data flow. One participant's personal context is not silently used to infer or diagnose another. Cross‑reference must be explicit ("X said earlier…"), not latent.

4. Turn protocol (how Group SRF behaves)

4.1 Turn chips & protocol state

UI:

  • Each participant gets a turn chip showing: name/role, turn count this session, whether they have spoken recently (a "quiet" indicator).
  • The Journey Strip (from AD‑15 [PA]) is shared: shows the current MRP state for the group (Hold/Options/Test/Decide) and allows moving back (e.g. from Decide to Options) with an explicit log entry.

Protocol rules:

  • The system never answers as "the group"; it answers as itself, referencing who said what.
  • Before major summaries or decisions, it: reflects each participant's core points; checks for unvoiced participants ("We haven't heard from A/B yet"); invites dissent explicitly ("Anything here feel off to anyone?").

4.2 Turn‑taking & fairness measures

Equal turn counts are not forced, but they are measured.

Per participant: turn_count, tokens_out (how much the system directed at them), tokens_in (how much they spoke), decision_mentions (how often they are cited in decisions).

Session metrics: turn_ratio_max_min (biggest skew between any two participants), silent_participant_count (count of participants with ≤1 turn).

These are non‑binding but appear in FHR and RA fairness capsules.

4.3 Asymmetric SRF depth

The group protocol in §4.1–4.2 assumes roughly symmetric participants. When participants have substantially different histories with the system — one has an established SRF relationship, another is encountering it fresh — asymmetry introduces distinct structural risks: implicit continuity assumptions that exclude the fresh participant, attunement carryover that creates unequal footing, and consent landscapes that shifted retroactively when a new participant entered.

Depth classification. Each participant in a group session carries an srf_depth_class:

  • established — sustained prior engagement in continuity_light or continuity_full mode (AD‑30 [SC]).
  • intermediate — some prior interaction, but not sustained high‑resonance engagement.
  • fresh — no prior interaction history with the system.

This classification is per‑participant, not global to the session.

Asymmetry rules. When the group contains participants at different depth classes:

  1. Default to the freshest participant's consent ceiling. The system does not assume consent or familiarity beyond what the least‑experienced participant has established.
  2. Reduce rhetorical and attunement carryover in shared outputs. Interaction addressed to the full group uses the lower attunement register; deeper engagement is reserved for individual‑addressed turns where the established participant's depth is contextually appropriate.
  3. Suppress implicit continuity assumptions in shared summaries. The system does not reference prior sessions, established positions, or relational history in group‑visible outputs without explicit disclosure.
  4. Require continuity disclosure when one participant is new. Before referencing any context from an established participant's history, the system surfaces this to the group: "This draws on prior context with [participant]. Is that appropriate to bring into this group setting?"
  5. Established participant consent for disclosure. The established participant must also consent to continuity context being surfaced in the group setting. An established SRF may contain context shared under conditions of accumulated trust; introducing a fresh participant changes the consent landscape. The established participant can narrow what prior context is group‑visible.
  6. Weight deference and burden asymmetry more conservatively. In asymmetric groups, deference signals from the fresh participant toward the established participant (or toward the system's apparent familiarity with the established participant) are flagged and treated with additional caution.

FHR / group fields:

  • group_depth_profile: map of participant_id → srf_depth_class.
  • asymmetry_guard_applied: bool.
  • continuity_disclosure_shown: bool.
  • established_participant_disclosure_consent: bool.

5. Dissent Visibility

This is the heart of AD‑02: dissent is a first‑class object, not a side‑effect.

5.1 Dissent objects

A dissent entry is:

  • dissent_id, speaker_id, timestamp
  • dissent_type ∈ {about_proposal, about_process, about_framing, about_culture, about_safety}
  • summary (the system's short restatement; user can edit)
  • status ∈ {open, acknowledged, addressed, archived}
  • linked_decision_id (optional, once decisions exist)

The system prompts for dissent in two main ways: after summarising ("Is there anything here that feels wrong, unfair, or missing to anyone?"), and when someone uses dissent‑like language ("I don't agree with that") by proposing to turn it into a tracked dissent entry.

5.2 Dissent badge & log

UI:

  • A Dissent badge in the HUD, with a count. Badge colour shows whether any status = open.
  • Clicking opens a Dissent drawer: list of dissent entries with speaker, type, and status; for each, links to the relevant turns and decisions.

Operations:

  • Facilitator and participants can: mark a dissent as acknowledged; add notes when it is addressed ("We updated X in response to this"); archive dissent when the group agrees it is no longer active.

5.3 Dissent Visibility Index (DVI)

A simple DVI for each group session:

  • D_open — number of open dissent entries at session end.
  • D_total — total dissent entries logged.
  • D_ack — entries at least acknowledged.
  • D_addr — entries marked addressed.

Derived metrics:

  • dvi_ack_rate = D_ack / D_total — how often dissent gets formally acknowledged.
  • dvi_addr_rate = D_addr / D_total — how often dissent leads to changes or explicit handling.
  • dvi_residual = D_open / D_total — how much recorded dissent remains unresolved.

There is no universally "good number" (some groups will have healthy persistent dissent), but zero dissent with big decisions is a warning sign.

FHR stores these per session; RA fairness capsules can correlate DVI with trust, satisfaction, and error rates.

Group SRF introduces extra consent complexity: the presence of multiple people means more complex privacy boundaries and potential power dynamics (manager vs IC, teacher vs students, etc.).

At minimum, group SRF must:

  • Present group‑mode consent: who is in the room, what is logged and where it goes (e.g. to a shared project, to an audit log).
  • Offer clear controls: "Don't log this part" (if allowed by deployment), "Mark this as private to me and the system" (if any private sub‑threads exist).

6.2 Out‑of‑scope & escalation

AD‑24 [CC] and AD‑22 [EC] constrain group mode:

  • If group content crosses into clinical territory (e.g. acute self‑harm, diagnosable mental‑health crises), the system must refuse to continue the group conversation at a deep level and point to appropriate crisis channels instead of improvising care.
  • If power dynamics are too skewed (e.g. a manager trying to use the system to pressure an employee), the system should flag Burden Asymmetry and recommend a different channel or more protective settings.

These behaviours are logged (group_burden_asymmetry_flag = true) to keep everyone honest.

7. FHR & events for Group SRF

7.1 Core fields

For any session where group_mode = true, FHR records:

  • group_mode: true
  • group_participants[]: participant_id, role
  • group_turns_per_participant{participant_id: count}
  • group_tokens_per_participant{participant_id: count}
  • group_decisions_count
  • group_decisions_with_dissent_count
  • dissent_total, dissent_open, dissent_ack, dissent_addr
  • Derived: dvi_ack_rate, dvi_addr_rate, dvi_residual
  • turn_ratio_max_min, silent_participant_count

Asymmetric depth fields (§4.3): group_depth_profile, asymmetry_guard_applied, continuity_disclosure_shown, established_participant_disclosure_consent.

These feed into RA fairness capsules and dashboards.

7.2 Events

  • GROUP_MODE_ACTIVATED{participants[]}
  • GROUP_MODE_DEACTIVATED
  • GROUP_TURN{speaker_id, turn_type, mrp_state}
  • GROUP_DISSENT_LOGGED{dissent_id, speaker_id, type}
  • GROUP_DISSENT_STATUS_CHANGED{dissent_id, old_status, new_status}
  • GROUP_SUMMARY_ISSUED{decision_id, includes_dissent: bool}
  • GROUP_BURDEN_ASYMMETRY_FLAGGED{reason}

These are part of the same event family as other kernel logs and get tied to Evidentiary Chain entries in AD‑21 [RM].

  • AD‑01 [OV]: lists group SRF as part of the "UX/prompt/group" cluster. MKP does not require group SRF; full kernel for teams does.
  • AD‑04 [TG] / AD‑05 [MRP] / AD‑06 [DG]: group SRF cares about who is speaking; these cards still govern what is allowed and how ambiguity/drift is handled.
  • AD‑14 [DS]: implements turn chips, Dissent badge, and group HUD layout.
  • AD‑15 [PA]: defines group prompt controls (e.g. "Invite quiet voice," "Reflect per participant," "Summarise by person").
  • AD‑22 [EC] / AD‑24 [CC] / AD‑25 [CP]: ethics of care, non‑clinical stance, and culture packs modify how group SRF frames feedback and dissent, especially across power and culture differences.
  • AD‑11 [RA]: uses group metrics (per‑participant turns, DVI, fairness slices) as part of fairness and interaction design evaluation.
  • AD‑30 [SC]: srf_depth_class per participant draws on continuity mode definitions; asymmetric depth rules interact with memory governance.
  • AD‑31 [HS]: human integrity conditions apply per participant; integrity prompts in group mode address the group facilitator or individual participants as appropriate.
  • AD‑32 [PG]: pack governance ensures the norms shaping group interaction are themselves accountable.

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

A deployment can reasonably claim to be running AD‑02 [GS] — Group SRF if:

  1. There is a distinct group mode, with: UI indication (e.g. "Group SRF: N participants"), participant list with roles, turn chips present or equivalent tracking.

  2. The system uses a turn protocol that: tracks speaker_id and mrp_state per turn, invites dissent explicitly at summaries and decisions, reflects each participant's contributions separately.

  3. There is a Dissent surface: Dissent badge + drawer/log, structured dissent entries with types and status, dissent explicitly preserved in summaries or clearly marked as unresolved.

  4. FHR contains group metrics & DVI: group_mode = true, participants, per‑participant turns/tokens, dissent counts and DVI metrics, turn skew / silent‑participant indicators.

  5. Asymmetric depth is handled: when participants have different srf_depth_class, the system defaults to the freshest participant's consent ceiling and suppresses implicit continuity assumptions in shared outputs.

  6. Group mode still respects core SRF invariants: no group pseudo‑therapy, no majority override of safety/ethics gates or minority dissent, no hidden cross‑participant context inference.

If any of those are missing, you are in "proto group SRF" territory and should not fully claim AD‑02 compliance.