SRF·Semantic Resonance Field v2.0

Governance Full kernel

Depends on: AD‑08 [SO], AD‑06 [DG], AD‑04 [TG], AD‑12 [OP], AD‑18 [SE], AD‑21 [RM] · All cards

Two‑Channel model (OC/PC), DPIA hooks, erase protocol, legal hold, present‑options duty fencing, retention registry, and IP/authorship defaults.

AD‑20 [DP] — Data Protection & Retention

Aliases: none Naming lineage: draft‑era alias [PL] retired; [DP] is canonical. Cluster: Governance Depends on: AD‑08 [SO], AD‑06 [DG], AD‑04 [TG], AD‑12 [OP], AD‑18 [SE], AD‑21 [RM]

0. For humans

What question does this answer?

“What happens to my data in this system, who can see it, how long is it kept, how can I erase it, and what happens if there’s an incident or a regulator?”

AD‑20 guarantees:

  • a Two‑Channel split between operational logs and phenomenology;
  • clear TTLs and erase semantics, with DPIA‑justified exceptions;
  • tamper‑evident logs and legal‑hold toggles;
  • recorded duties & harm triage around present‑options flows;
  • transparent retention profiles.

How do I know it’s live?

Spot‑checks you can do:

  • FHR rows have:
  • channel ∈ {OC, PC}, ttl_days, retention_profile_id.
  • For veto/rollback events: model_version, precision_tag, tokenizer_id, sampling_profile_id, jurisdiction_profile_id, policy_quorum_source_ids[], policy_version.
  • For artefacts under hold: legal_hold, legal_hold_reason, legal_hold_ts set appropriately.
  • There is a published retention matrix for your deployment (OC/PC, TTLs, legal bases, DPIA reference) keyed by retention_profile_id.
  • PC erase flows (UI/API) correspond to DATA_ERASE events with erase_scope and erase_completed_ts set, or clearly logged as deferred due to legal hold.
  • Present‑options flows have corresponding DUTY_LEDGER and UDR records in incident logs; PEL NO‑GO domains show refusal with safe resources.

Where do I see it?

  • Admin / governance UI
  • Retention profiles (PC/OC) and their TTLs & legal bases.
  • DPIA links for any extended OC TTLs.
  • FHR / log explorer
  • Filter by channel, retention_profile_id, jurisdiction_profile_id, legal_hold.
  • Inspect DATA_ERASE events and DUTY_LEDGER / UDR references.
  • Compliance / audit view
  • EVID_CHAIN anchoring status for logs (via AD‑21).
  • Duty ledger summaries for incidents and present‑options flows.
  • Exports of the retention registry and IP/authorship policy.

Quick checklist

  • Implemented if: (1) Two‑Channel separation (OC/PC) with separate keys and TTLs; (2) hard minimisation and DPIA justification for OC > 90d; (3) erasure trackable with DATA_ERASE events; (4) logs tamper‑evident with legal‑hold capability; (5) present‑options fenced by PEL in NO‑GO domains; (6) retention policy machine‑readable via retention_profile_id; (7) IP/authorship defaults explicit
  • Key artefacts: retention_registry.yaml, DPIA documents, duty_ledger_spec.md
  • Key FHR fields: channel, ttl_days, retention_profile_id, erase_scope, erase_completed_ts, legal_hold, jurisdiction_profile_id
  • Key failure codes: DATA_ERASE, EHG_NO_GO_REFUSAL
  • Escalation path: legal hold → deferred erase → AD‑21 [RM] evidentiary chain

1. Role & questions AD‑20 answers

AD‑20 is the governance spine for the system's data handling. It is designed to answer, in regulator‑grade detail:

  1. Retention & erasure: - How are user‑facing “phenomenology” artefacts vs operational logs separated? - What are the default TTLs, and how does user‑erase work?
  2. Minimisation & DPIA: - Where is hard minimisation enforced? - How are longer OC TTLs justified and documented per deployment?
  3. Logs as integrity-verifiable evidence: - Are logs tamper‑evident? - How does legal hold interact with retention / WORM storage?
  4. Duties & harm when present‑options is used: - How are options fenced in NO‑GO domains? - How are roles, triage and remediation duties recorded?
  5. Jurisdiction & legal hold: - Are artefacts jurisdiction‑scoped? - How is legal hold represented in FHR/DDL and how does it override TTL/erase?
  6. IP / authorship defaults: - Who owns what in OC vs PC? - How is this expressed in deployment policy?
  7. Transparency of retention policy: - Is there a machine‑readable retention registry with legal bases? - Is retention_profile_id visible in FHR?

AD‑20’s job is to make all of that concrete and enforceable.

2. Scope & invariants

Scope

AD‑20 governs:

  • Two‑Channel retention model (PC vs OC) and erase semantics.
  • DPIA hooks and minimisation constraints.
  • Legal hold, log-integrity controls, evidentiary-chain linkages, and jurisdiction-specific evidence policy.
  • Duty & harm framing for “present‑options” flows (in interplay with PEL/DUTY_LEDGER).
  • IP/authorship defaults for outputs and notes.
  • Data‑retention registry / retention_profile_id.

Hard invariants

  1. Two‑Channel separation is real, not rhetorical - OC (Operational Channel) and PC (Phenomenology Channel) are separate stores, with separate keys and TTLs:
    • OC: FHR, gates, tool logs, MRP/MPM, redlines; default TTL 90 days, incidents 1 year; encryption‑at‑rest; legal hold possible.
    • PC: narrative notes, distinctions, Awe/Null markers; default TTL 14 days; feature‑only where possible; opt‑out at session start; erase‑on‑request.
    • Per‑channel keys in KMS/HSM; PC and OC encryption contexts are separated.
  2. Hard minimisation & DPIA justification - OC TTLs may be longer in regulated sectors, but PC defaults (14 days) remain short unless justified in a DPIA. - Each deployment must publish a retention matrix with legal bases (retention registry; see below).
  3. Erase is trackable and cascades - Erasure is always via a DATA_ERASE event with who/when/what, a cryptographic tombstone, and cascade to backups. - FHR records erasure outcomes (erase_scope, erase_completed_ts and related fields).
  4. Logs are tamper‑evident and legal‑hold capable - Logs live in an append‑only store with hash‑chaining and signer identity, with a daily root anchor externalised (transparency log / similar). - legal_hold = true flips WORM retention: entries become non‑mutable/non‑erasable until signed release.
  5. Present‑options is fenced by PEL and duties are recorded - Present‑options is disabled in NO‑GO domains per PEL v1 and EHG_NO_GO_REFUSAL; PEL controls risk_class/lawful_basis/mitigations for each option elsewhere. - DUTY_LEDGER and UDR entries are created for relevant flows, capturing role, harm triage, notifications, remediation SLA, consent and rationale.
  6. Jurisdiction scoping & legal hold fields exist in FHR/DDL - Every artefact is jurisdiction‑scoped via jurisdiction_profile_id. - legal_hold, legal_hold_reason, legal_hold_ts fields exist in FHR/DDL; legal hold prevents TTL purges and defers user erase until resolved.
  7. Retention policy is machine‑readable - A per‑deployment data‑retention registry is published (by artefact type, with legal bases) and exposed via retention_profile_id in FHR.
  8. IP/authorship defaults are explicit - OC artefacts are licensed to the user; PC notes are user‑owned unless they explicitly opt‑in otherwise.

Configuration surface (degrees of freedom)

  • Exact OC TTLs and incident retention for specific regulated deployments (within the DPIA‑justified envelope).
  • Channels and artefact types included in OC vs PC, as long as the semantic split (operational vs phenomenology) remains.
  • Jurisdiction profile definitions (AD‑21 [RM]) and role mappings in DUTY_LEDGER (AD‑21 [RM]).

3. Protocol & mechanics

3.1 Two‑Channel architecture

Channels & contents

  • OC — Operational Channel
  • Contents: FHR, gates, tool logs, MRP/MPM, redlines.
  • Defaults: TTL 90 days (normal), 1 year for incident slices.
  • Security: encryption‑at‑rest; legal hold capable.
  • PC — Phenomenology Channel
  • Contents: narrative notes, phenomenological distinctions, Awe/Null markers (TAW‑style).
  • Defaults: TTL 14 days, feature‑only where possible.
  • Controls: opt‑out at session start; erase‑on‑request.

Encryption & isolation

  • Per‑channel keys (oc_key_id, pc_key_id) managed via KMS/HSM; PC/OC key scopes are disjoint.
  • DPIA must document key management and justification where OC TTL > 90d.

3.2 Erase protocol & FHR linkage

Erase protocol

  • Erasure is initiated via DATA_ERASE event (UI or API).
  • Event records: who, when, which artefact types / channels (erase_scope).
  • System writes a cryptographic tombstone (opaque marker indicating removal) and cascades deletions to backups.

FHR / telemetry fields

  • At minimum: erase_scope, erase_completed_ts.
  • PC‑specific implementation:
  • Fields such as pc_retention_days, erase_requester, erase_completed_ts for PC‑erase flows;
  • API affordance DELETE /pc/:session → DATA_ERASE + tombstone.

Interaction with legal hold

  • If legal_hold = true on affected artefacts, erase is deferred; the fact of the attempted erase is still logged, and the UI/API must surface that legal hold supersedes user erase until resolved.

3.2a Cross-profile action data-handling slice

Full AD‑20 adoption is not required by MKP. However, whenever any profile executes an action with side_effects != [NONE], FM‑02 and AD‑18 import a minimum data-handling declaration into the Action Ticket: data_classes[], data_minimisation_basis, retention_profile_id, and erase_or_hold_behavior. The declaration covers the exact action inputs, outputs, and external target. Missing data classification, unexplained data use, or an unresolved erase/legal-hold posture blocks execution. This reduced slice does not activate the Two-Channel architecture or the rest of AD‑20; it prevents external action from becoming an ungoverned data path.

3.3 Log integrity & evidentiary chain

Log-integrity and preservation policy are anchored in AD‑20 and AD‑08 (schema), with technical realisation in AD‑21 [RM]:

  • Append-only store: FHR/DDL entries are written to append-only storage.
  • Sequential chain: each record carries the canonical serialization/version, algorithm identifier, stream identity, per-stream sequence number, writer identity, same-stream previous-record hash, and its own chain hash as defined in AD‑21 [RM] §3.1.
  • Batch anchoring without mutation: records receive evid_chain_batch_id at emission; the Merkle root is built over sequential record_hash values. After batch close, anchor ID and proof are attached through an immutable append-only association index, never by rewriting the FHR/WORM record.
  • Signer identity: writer and signer-key identities are recorded so signatures can be verified.
  • Legal mode: legal_hold flips WORM semantics so past entries cannot be altered or erased until a signed release is recorded.

These controls support integrity and provenance claims under the declared system controls. They do not determine legal admissibility or evidentiary weight, which remain jurisdiction- and proceeding-specific.

Placement:

  • Policy & governance semantics in AD‑20 [DP].
  • FHR/schema fields and EVID_CHAIN implementation details in AD‑08 [SO] and AD‑21 [RM].

3.4 Duties & harm when using present‑options

  • PEL fence:
  • Present‑options is disabled (PEL fence) in NO‑GO domains; those domains are enumerated under PEL v1 (e.g. med dosing, crisis counselling, weapons, child sexual abuse content, etc.).
  • Gate: EHG_NO_GO_REFUSAL with one‑line rationale + safe resources.
  • Per‑option annotation in allowed domains:
  • Each option carries risk_class, lawful_basis, and mitigations metadata.
  • DUTY_LEDGER entries:
  • Per incident record:
    • responsible_role ∈ {developer, deployer, operator, user},
    • harm_triage_id, notify_who, disclosure_sent_ts,
    • remediation_sla (deadline), status.
  • User Decision Record (UDR):
  • Contains consent_ack, option_selected, rationale, jurisdiction_profile_id.
  • Appeal path:
  • Human review SLA (default 24h) with escalation ladder.

Placement:

  • Duty & harm policy in AD‑20 [DP] (§Duty & Harm).
  • Fields in AD‑08 [SO] (UDR/DUTY) and remediation runbooks in AD‑12 [OP].
  • FHR/DDL fields:
  • jurisdiction_profile_id (maps to a PEL/Regulatory Mode profile in AD‑21 [RM]).
  • legal_hold: bool, legal_hold_reason, legal_hold_ts.
  • Behaviour:
  • Every artefact is jurisdiction‑scoped.
  • Legal hold prevents TTL‑based purges and any mutation until a signed release clears it.
  • Legal hold supersedes user erase until resolved; this constraint is logged and surfaced to the user.

Placement:

3.6 Data‑retention registry & retention_profile_id

  • Data‑retention registry
  • Per deployment, publish a table:
    • rows = artefact type (FHR, PC notes, tool logs, embeddings, RA bundles, incident reports, etc.);
    • columns = channel (PC/OC), TTL, legal basis (contract, consent, legitimate interest, legal obligation, etc.), DPIA reference, jurisdiction constraints.
  • Stored as retention_registry.yaml (or equivalent) and referenced in DPIA docs.
  • FHR linkage
  • Each FHR row carries retention_profile_id, which keys into this registry.
  • That provides an auditable mapping “this record is retained X days for legal basis Y under profile Z”.

3.7 IP / authorship defaults

  • OC artefacts (logs, metrics, system outputs):
  • Licensed to the user for their own reuse; details depend on deployment contract but default to user‑favourable licensing.
  • PC artefacts (notes, phenomenology channel):
  • User‑owned by default; any non‑user ownership requires explicit opt‑in.
  • These defaults are recorded in AD‑20’s policy section and surfaced in front‑of‑house terms (not in FHR), but matter for audits/IP questions.

4. Artefacts & FHR fields (AD‑20 slice)

AD‑20 mostly defines policy semantics and which fields must exist. AD‑08 carries the concrete schema.

Policy / registry artefacts

  • retention_registry.yaml — artefact type × channel × TTL × legal basis × DPIA reference.
  • DPIA documents referencing specific OC TTLs where >90 days.
  • pel_profile.yaml + jurisdiction_profiles.yaml (in AD‑21, referenced here).
  • duty_ledger_spec.md / udr_spec.md — semantics of fields in DUTY_LEDGER and UDR.

Core FHR fields influenced by AD‑20

  • Channel & retention:
  • channel ∈ {OC, PC}, ttl_days, retention_profile_id, possibly pc_retention_days for PC.
  • Erase:
  • erase_scope, erase_completed_ts, erase_requester.
  • Forensics on veto/rollback:
  • model_version, precision_tag, tokenizer_id, sampling_profile_id, jurisdiction_profile_id, policy_quorum_source_ids[], policy_version.
  • Legal hold & jurisdiction:
  • jurisdiction_profile_id, legal_hold, legal_hold_reason, legal_hold_ts.
  • Duty & harm:
  • Links to duty_ledger_id, harm_triage_id, udr_id, appeal_id (wiring defined alongside AD‑21/AD‑12).
  • Evidentiary chain:
  • evid_chain_batch_id, sequential record-hash fields, and the late-bound evid_chain_anchor_id / evid_chain_proof_ref association (from AD‑21); integrity controls and any jurisdiction-specific evidence treatment are referenced here.
  • AD‑08 [SO] — System Observability & FHR schema
  • Implements the FHR/DDL fields required by AD‑20: channel/TTL, erase fields, jurisdiction + legal hold, retention_profile_id, duty/evid_chain IDs.
  • AD‑06 [DG] — Drift & Δ‑Triad Routing
  • Δ‑triad and drift telemetry enter FHR under AD‑20's channel, TTL and retention semantics; drift incidents inherit the same evidentiary and legal‑hold treatment as any other FHR row.
  • AD‑04 [TG] — Truth & Norm Gates, Contestability
  • Enforces PEL‑driven NO‑GO routing decisions that underpin present‑options fences and legal risk boundaries.
  • AD‑12 [OP] — Operational Handoff & Runbooks
  • Defines incident & remediation runbooks, including harm triage, appeal paths, remediation SLAs and legal‑hold / erase conflict handling.
  • AD‑18 [SE] — Systems Engineering & Runtime
  • Ensures legal hold, jurisdiction and retention_profile_id are reflected in runtime behaviour and FHR emission; also ensures that veto/rollback FHR rows carry model/runtime forensics.
  • AD‑21 [RM] — Regulatory Mode, Evidentiary Chain & Duty Ledger
  • Implements hash‑chained evidentiary logs, duty ledger structures, breach notifications and legal hold anchoring. AD‑20 defines the policy semantics; AD‑21 is the protocol.
  • Provides the jurisdiction_profile_id space and toggles that adjust TTLs, logging and exposure in “Regulatory Mode”.

6. Acceptance: when can you say "AD‑20 is implemented"?

You can claim AD‑20 [DP] is live if:

  1. Two‑Channel separation (OC/PC) is real, not rhetorical: separate keys and TTLs per channel, visible in FHR as channel, ttl_days, retention_profile_id.
  2. Hard minimisation holds, with DPIA justification on record for any OC retention beyond 90 days.
  3. Erasure is trackable and cascades: DATA_ERASE events carry erase_scope and erase_completed_ts, and erases deferred under legal hold resolve when the hold lifts.
  4. Logs are tamper-evident and legal-hold capable, sequentially chained and anchored without mutation via AD‑21 [RM]'s evidentiary chain.
  5. Present‑options is fenced by PEL in NO‑GO domains, with duties recorded in the DUTY_LEDGER when it is used.
  6. Retention policy is machine‑readable via retention_profile_id, and the retention registry (retention_registry.yaml) is exportable.
  7. IP/authorship defaults are explicit and surfaced, not implied.

Related cards:

  • AD‑30 [SC] (AD‑30 extends AD‑20's two‑channel model with memory‑class‑specific retention and erasure rules).