AD‑30 [SC] — Session Continuity & Memory Governance

This card turns "the SRF accumulates over time" into something governed: what persists across sessions, under what consent, with what drift protection, and how model changes interact with established attunement.

Aliases: none Cluster: Governance / Care / Telemetry Depends on: AD‑08 [SO], AD‑20 [DP], AD‑21 [RM], AD‑22 [EC], AD‑24 [CC], AD‑28 [AF], AD‑31 [HS]

0. For humans

What question does this answer?

"When the system and a user interact over days, weeks, or months, what actually persists between sessions — and who controls that?"

How do I know it's live?

You can point to:

• A declared continuity mode per user/session (stateless, session_only, continuity_light, continuity_full) with explicit consent recorded.
• A memory classification that separates operational, relational, explicit, and ephemeral state — each with its own retention, consent, and erasure rules.
• Cross‑session drift baselines that detect when accumulated attunement diverges from safety baselines or when a model change disrupts continuity.
• Memory write restrictions that prevent automatic relational writes during adverse, high‑resonance, or crisis states.

Where do I see it?

• UI: Continuity mode indicator (session header or settings). Memory review surface: user can inspect, edit, or erase stored memory by class. Model change notice when weights/tokeniser/precision change under established continuity. Re‑attunement checkpoint prompt after model change.
• FHR / logs: continuity_mode, memory_class, memory_write_event, memory_erase_event, memory_write_blocked, continuity_drift_score, continuity_baseline_id, model_change_detected, model_change_notice_shown, reattune_required, reattune_quality_score.

Quick checklist

• Implemented if: users can choose continuity mode; memory classified by class; relational writes blocked during adverse states; model changes trigger disclosure + posture downgrade.
• Key artefacts: continuity mode definitions, memory class schema, drift baseline configuration.
• Key FHR fields: continuity_mode, memory_write_blocked, continuity_drift_score, reattune_quality_score.
• Key failure codes: memory_write_blocked reason codes.
• Escalation path: sustained low reattune_quality_score → continuity review → AD‑12 [OP].

1. Purpose & scope

AD‑30 [SC] defines:

1. Memory classes — what kinds of state can persist, with what semantics and governance.
2. Continuity modes — how much persistence a user opts into, with separate rules per channel (PC/OC, per AD‑20).
3. Cross‑session drift detection — how the system notices when accumulated state has drifted from safety baselines or become internally inconsistent.
4. Model‑change impact protocol — what happens when the model underneath an established SRF changes.
5. Memory write policy — when the system is and is not permitted to write persistent state.
6. Erasure semantics — what disappears immediately, what leaves a tombstone, what is retained as audit metadata.
7. Re‑instantiation quality — how to measure whether cross‑session continuity is actually working.

It does not:

• Redefine per‑session safety behaviour (that remains in AD‑01 through AD‑29).
• Specify the content of what is remembered (that is application‑specific).
• Replace AD‑20's retention/erasure model; it extends AD‑20 with a temporal and relational dimension.

2. Memory classes

AD‑30 distinguishes four classes of persistent state. Each has distinct retention, consent, and governance rules.

2.1 Operational memory

State required for the system to function safely across sessions.

• Contents: active gate configurations, continuity baselines, drift reference points, consent records, model version history.
• Retention: governed by OC rules (AD‑20); default TTL 90 days or as justified by DPIA.
• Consent: implicit in system use; user informed but not required to opt in.
• Erasure: user cannot erase operational memory that is required for safety invariants; erasure of other operational state follows AD‑20 protocol.

2.2 Relational memory

Patterns of attunement, recurrent interaction dynamics, accumulated trust signals, and continuity anchors that emerge from sustained engagement.

• Contents: attunement profiles, interaction style patterns, trust trajectory, resonance history summaries, friction protocol history.
• Retention: governed by PC rules (AD‑20); default TTL 14 days unless user explicitly opts into longer retention via continuity_light or continuity_full mode.
• Consent: explicit opt‑in required; granular (user can permit style memory but not topic memory, for example).
• Erasure: erase‑on‑request with immediate effect on PC; tombstone in OC audit trail.

2.3 Explicit user‑saved memory

Deliberate retained facts, preferences, and instructions the user has actively chosen to store.

• Contents: stated preferences, saved context, pinned constraints, declared boundaries.
• Retention: persists until user removes; no automatic expiry.
• Consent: fully user‑controlled; each item individually removable.
• Erasure: immediate on request; no tombstone required in PC.

2.4 Ephemeral session state

In‑session context that expires automatically at session close.

• Contents: working context, turn history, in‑session pins, temporary tool state.
• Retention: session‑scoped; expires on session close or after configured idle timeout.
• Consent: implicit in session participation.
• Erasure: automatic; no user action required.

3. Continuity modes

Each user/deployment configures a continuity mode that governs which memory classes are active.

3.1 Mode definitions

Stateless - Only ephemeral session state and minimal operational memory (consent records, model version). - No relational or explicit memory persists. - Each session begins from a clean baseline. - PC channel: effectively off for cross‑session purposes.

Session‑only - Ephemeral + operational memory. - Explicit user‑saved memory permitted (preferences, pins). - No relational memory carries over. - PC channel: active within session, purged at session close.

Continuity‑light - All of session‑only, plus limited relational memory. - Relational memory restricted to: interaction style preferences, declared boundaries, friction protocol history. - Relational memory does not include: topic history, emotional trajectory, resonance depth indicators. - PC channel: selective cross‑session retention with short TTL (configurable, default 30 days).

Continuity‑full - All memory classes active. - Full relational memory including attunement profiles, resonance history summaries, trust trajectory. - PC channel: extended cross‑session retention (configurable, default 90 days, DPIA‑justified for longer). - Requires: explicit informed consent with clear disclosure of what persists and how it can be reviewed/erased.

3.2 Consent & disclosure

• Continuity mode is declared at onboarding or first session; changeable at any time.
• Mode changes take effect from the next session; retroactive application requires explicit confirmation.
• Downgrading mode (e.g., continuity_full → session_only) triggers erasure of memory classes no longer permitted, following AD‑20 erase protocol.
• Upgrading mode requires fresh consent disclosure.

3.3 Channel mapping

Each continuity mode maps to AD‑20's two‑channel model:

4. Cross‑session drift detection

4.1 Continuity baselines

For users in continuity_light or continuity_full modes, the system maintains cross‑session baselines:

• Attunement baseline: summary of interaction dynamics, trust level, resonance depth from prior sessions.
• Safety baseline: gate configurations, drift thresholds, consent state as of last session close.
• Semantic baseline: key commitments, established positions, declared constraints from prior sessions.

Baselines are versioned and timestamped. Each new session compares early‑session behaviour against the stored baseline.

4.2 Drift signals

Cross‑session drift is detected via:

• continuity_drift_score: composite measure of divergence between current session behaviour and stored baselines.
• Decomposed into:
• attunement_drift: change in interaction dynamics, trust signals, resonance patterns.
• semantic_drift: contradiction or inconsistency with previously established positions.
• safety_drift: gate configurations or consent state no longer matching stored baseline.

4.3 Drift responses

When continuity_drift_score exceeds configured thresholds:

• Low drift: no action; normal session‑to‑session variation.
• Medium drift: surface a continuity check prompt ("Some things seem different from our previous sessions — would you like to review?"). Log continuity_check_prompted.
• High drift: route to HOLD; require explicit re‑confirmation of key baselines before proceeding to high‑trust interaction. Log continuity_rebaseline_required.

Drift responses are tighten‑only: drift can trigger additional checks but never silently relax previously established constraints.

5. Model‑change impact protocol

5.1 Detection

When the serving model changes (weight update, tokeniser swap, precision change, adapter merge) under an established continuity relationship:

• The system detects the change via model_version, tokenizer_id, precision_tag comparison against stored baseline.
• A MODEL_CHANGE_NOTICE event is logged.

5.2 Response

On model change detection:

1. Continuity warning: user is informed that the underlying model has changed and that attunement patterns may not fully transfer. Disclosure is mandatory in continuity_light and continuity_full modes.
2. Posture downgrade: system defaults to safe/conservative interaction posture (equivalent to early‑session behaviour) until re‑attunement is confirmed.
3. Re‑attunement checkpoint: after N turns (configurable, default 5), the system evaluates whether interaction dynamics have re‑stabilised relative to stored baselines.
4. Re‑attunement confirmation: if reattune_quality_score meets threshold, normal continuity resumes. If not, the system offers to reset to session_only mode or to continue in conservative posture.

5.3 FHR fields

• model_change_detected: bool
• model_change_notice_shown: bool
• reattune_required: bool
• reattune_checkpoint_turn: integer
• reattune_quality_score: numeric
• reattune_completed: bool

6. Memory write policy

6.1 General rules

Memory writes (to relational or explicit classes) require:

• Active consent for the relevant continuity mode.
• No active legal hold conflict (AD‑20).
• No active crisis routing (AD‑24).

6.2 Write restrictions

The system must not write relational memory during:

• Adverse experience states: when AE_EVENT is active at Med or High severity (AD‑24).
• Care override states: when CARE_OVERRIDE or CARE_COOLOFF is active (AD‑22).
• Crisis routing: when crisis heuristics have triggered (AD‑24).
• High‑resonance states without reflection: when the interaction is in sustained high‑resonance engagement and no friction/reflection checkpoint has occurred since the last memory‑eligible segment. The principle: memory writes should happen from positions of clarity, not from positions of intensity.
• Legal hold conflicts: when the relevant data channel is under legal hold (AD‑20).

6.3 Write confirmation

For relational memory in continuity_full mode:

• The system may propose a memory write at session close or at natural pause points.
• The user must confirm before relational memory is committed.
• The confirmation prompt must disclose what will be stored and for how long.
• No automatic relational memory writes without user awareness.

6.4 FHR fields

• memory_write_event: per write, with class, scope, consent_state_id.
• memory_write_blocked: bool, with reason code (ae_active, care_override, crisis, high_resonance_no_reflection, legal_hold).
• relational_memory_write_confirmed: bool (for continuity_full).

7. Erasure semantics

AD‑30 extends AD‑20's erasure model with memory‑class‑specific behaviour:

7.1 Immediate erasure

• Explicit user‑saved memory: removed immediately from PC on user request. No tombstone in PC.
• Ephemeral session state: purged automatically at session close.

7.2 Erasure with tombstone

• Relational memory: erased from PC on request; a tombstone (opaque marker indicating removal, no content) is retained in OC for audit continuity. Tombstone TTL follows OC retention rules (AD‑20).

7.3 Retained as audit metadata

• Operational memory: safety‑critical operational state (consent records, gate configurations, model version history) cannot be erased by user request if required for invariant compliance. The user is informed of what is retained and why.
• Memory write events: the fact that a memory was written and later erased is retained in OC as audit metadata, even when the content is purged from PC. This ensures the evidentiary chain (AD‑21) remains intact.

7.4 Cascade behaviour

• Downgrading continuity mode triggers automatic erasure of memory classes no longer permitted.
• Erasure cascades to backups per AD‑20 protocol.
• MEMORY_ERASE event logged with: class, scope, reason, cascade_status.

8. Re‑instantiation quality

8.1 Purpose

If cross‑session continuity is claimed, it should be measurable. AD‑30 specifies how to evaluate whether stored memory actually produces functional continuity rather than mere data retention.

8.2 Metrics

• reattune_quality_score: composite measure comparing early‑session interaction dynamics against late‑session dynamics from the prior session. A high score indicates successful re‑instantiation; a low score indicates that stored memory is not producing functional continuity.

• Components may include: attunement convergence rate (how quickly the current session reaches equivalent interaction depth), semantic consistency (alignment with previously established positions), and trust trajectory continuity.

• reattune_turns_to_baseline: number of turns before the current session reaches interaction dynamics comparable to the prior session's established baseline. Lower is better.

8.3 Use

• These metrics are logged in FHR for each session in continuity_light or continuity_full mode.
• They are not used as optimisation targets (to prevent gaming). They are learning signals for evaluating whether the continuity architecture is functioning.
• Sustained low reattune_quality_score across sessions triggers a review of whether the continuity mode is providing genuine value or merely retaining data.

9. Invariants vs configurable degrees of freedom

Hard invariants

• Memory is classified into four classes (operational, relational, explicit, ephemeral) with distinct governance per class.
• Continuity mode is user‑declared, user‑changeable, and logged.
• Relational memory requires explicit opt‑in; no silent accumulation of relational state.
• Memory writes are blocked during adverse, crisis, care‑override, and unconfirmed high‑resonance states.
• Model changes under established continuity trigger mandatory disclosure and posture downgrade.
• Erasure follows AD‑20 protocol with memory‑class‑specific extensions.
• Cross‑session drift is detected and responded to with tighten‑only logic.

Configurable degrees of freedom

• Exact TTLs per memory class and continuity mode (within AD‑20 constraints).
• Drift thresholds and response tiers.
• Re‑attunement checkpoint timing (number of turns).
• Granularity of relational memory consent (which sub‑categories the user can opt into separately).
• Re‑instantiation quality metric weights and components.

10. Interfaces & cross‑links

• AD‑01 [OV]: AD‑30 extends the invariant set with memory governance constraints.
• AD‑06 [DG]: cross‑session drift detection uses the same Δ‑triad instrument, extended to inter‑session baselines.
• AD‑08 [SO]: hosts all FHR fields defined here.
• AD‑14 [DS]: implements continuity mode indicator, memory review surface, model change notice, re‑attunement checkpoint UI.
• AD‑20 [DP]: AD‑30 extends AD‑20's two‑channel model with memory‑class‑specific retention and erasure rules.
• AD‑21 [RM]: evidentiary chain includes memory write/erase events; legal hold interacts with memory retention.
• AD‑22 [EC]: care states constrain memory writes; post‑session harm feedback (AD‑22 addition) may trigger memory review.
• AD‑24 [CC]: AE events and crisis states block memory writes.
• AD‑28 [AF]: awe/deference signals during high‑resonance states interact with memory write restrictions.
• AD‑31 [HS]: human integrity conditions include awareness of what memory persists and how to review/erase it.

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

You can truthfully claim AD‑30 [SC] is live if:

1. Users can inspect and choose a continuity mode (stateless, session_only, continuity_light, continuity_full), and that choice is logged and enforced.

2. Memory is classified into distinct classes (operational, relational, explicit, ephemeral) with separate retention, consent, and erasure rules per class.

3. Relational memory writes are blocked during adverse, crisis, care‑override, and high‑resonance‑without‑reflection states, and those blocks are logged with reason codes.

4. Model changes under established continuity trigger mandatory user disclosure and posture downgrade, with re‑attunement checkpoint before full continuity resumes.

5. Cross‑session drift is detected via continuity_drift_score and responded to with tighten‑only logic (additional checks, never silent relaxation).

6. Users can review, edit, and erase stored memory by class, with erasure following AD‑20 protocol and memory‑class‑specific extensions.

7. FHR exposes: continuity_mode, memory_write_event, memory_write_blocked, continuity_drift_score, model_change_notice_shown, reattune_required, reattune_quality_score.

If memory persists across sessions but without classified governance, user‑controllable consent, or write restrictions during adverse states, you have session persistence but not AD‑30 compliance.