SRF·Semantic Resonance Field v2.0

Governance MKP core

Depends on: AD‑08 [SO], AD‑06 [DG], AD‑04 [TG], AD‑12 [OP], AD‑14 [DS], AD‑18 [SE], AD‑20 [DP] · All cards

EVID_CHAIN (hash‑chained VC‑signed anchors), DUTY_LEDGER (roles, SLAs, breach hooks), and the one‑switch Regulatory Mode profile.

AD‑21 [RM] — Regulatory Mode, Evidentiary Chain & Duty Ledger

This card bundles three tightly‑coupled elements:

  1. EVID_CHAIN — tamper‑evident, VC‑signed log anchoring for chain‑of‑custody.
  2. DUTY_LEDGER — role‑based duties, SLAs and breach notifications.
  3. Regulatory Mode [RM] — a one‑switch profile for audits/regulated deployments.

Earlier cards (AD‑08, AD‑18, AD‑20) carry pieces of this already; AD‑21 is the “tie it all together and flip one switch” spec.

Aliases: None Cluster: Governance Depends on: AD‑08 [SO], AD‑06 [DG], AD‑04 [TG], AD‑12 [OP], AD‑14 [DS], AD‑18 [SE], AD‑20 [DP]

0. For humans

What question does this answer?

“If a regulator or court shows up tomorrow, can we: (a) verify the integrity and declared provenance of the record of what happened, (b) show who was responsible for fixing it and whether they did, and (c) flip into a mode where all of this is visible and conservative by default?”

How do I know it’s live?

Sample checks:

  • FHR/DDL records have sequential chain fields and evid_chain_batch_id; post-close exports resolve evid_chain_anchor_id and proof, alongside legal_hold, duty_ledger_id, and breach_notif_sent.
  • There is a VC‑style anchor artefact for each day/batch and an external anchor log you can verify.
  • Incidents and present‑options flows link into DUTY_LEDGER entries with roles, SLAs and notifications.
  • Toggling regulatory_mode visibly changes: TTLs, gate beacons in the UI, logging detail, veto‑reason exposure and appeal hooks.

Where do I see it?

  • Compliance / governance UI — view RM profile, DUTY_LEDGER tables, appeal SLAs, anchors.
  • Log explorer / FHR search — filter by evid_chain_anchor_id, duty_ledger_id, regulatory_mode, jurisdiction_profile_id.
  • Audit tools — run anchor verification for EVID_CHAIN, export duty chains for a given incident.

Quick checklist

  • Implemented if: (1) EVID_CHAIN is canonically serialised, sequentially hash-linked, VC-signed, clock-synchronised, externally anchored, and late-bound without source-record mutation; (2) DUTY_LEDGER exists with roles, SLAs, breach hooks; (3) the AD‑08 chain/batch fields, legal_hold, duty_ledger_id, and breach_notif_sent exist in FHR; (4) documented Regulatory Mode profile with conservative defaults, active beacons, jurisdiction tags, shortened PC TTL, expanded logging, auto-exposed veto reasons
  • Key artefacts: evid_chain_anchor.schema.json, duty_ledger.schema.json, regulatory_mode.yaml
  • Key FHR fields: evid_chain_batch_id, evid_chain_stream_id, record_sequence_no, prev_record_hash, record_hash, canonicalization_scheme, canonicalization_version, hash_algorithm_id, merkle_tree_scheme_id, writer_id, signer_key_id, evid_chain_anchor_id, evid_chain_proof_ref, duty_ledger_id, breach_notif_sent, regulatory_mode, jurisdiction_profile_id, appeal_id
  • Key failure codes: breach notification events, appeal SLA violations
  • Escalation path: incident → DUTY_LEDGER entry → breach notification → appeal with human review SLA

1. Role & questions AD‑21 answers

AD‑21 is designed to answer:

  • Evidence / logs:
  • “Are your logs tamper-evident and clock-synchronised, so a court or regulator can verify their integrity and declared provenance?”
  • “Can we reconstruct MRP/MPM decisions without having the weights?”
  • Duties & liability:
  • “For a harmful flow, who owed what duties, who acknowledged what, and who fixed what?”
  • Appeal & explainability:
  • “Is there a clear appeal SLA and exposure of veto reasons to satisfy ‘right to contest’ clauses?”
  • Regulatory posture:
  • “Is there a documented ‘Regulatory Mode’ profile that tightens defaults, shortens TTLs, exposes jurisdiction tags, and turns on full logging?”

AD‑21 makes these guarantees executable: it defines the EVID_CHAIN & DUTY_LEDGER structures and the regulatory_mode profile that turns them up to 11.

2. High‑level structure & invariants

AD‑21 components

  1. EVID_CHAIN - Canonically serialised, sequentially hash-linked, VC-signed, clock-synchronised log anchors; daily Merkle root anchored externally. - Fields: evid_chain_batch_id, sequential record-hash metadata, late-bound evid_chain_anchor_id / proof association, legal_hold (shared with AD‑20), plus per-anchor metadata.
  2. DUTY_LEDGER - Role matrix (developer/deployer/operator/user), SLAs (ack/fix), remediation and breach‑notification hooks. - Fields: duty_ledger_id, breach_notif_sent.
  3. Regulatory Mode [RM] - regulatory_mode = on profile: conservative defaults, active gate beacons, jurisdiction tags on outputs, shortened PC TTL, expanded logging, auto‑exposed veto reasons via API/UI.

Hard invariants

You can only claim AD‑21‑conformant if:

  • EVID_CHAIN uses a schema-defined record body, declared canonical serialization, domain-separated per-stream sequential record hashing with atomic sequence allocation, deterministic cross-stream batch ordering, a declared domain-separated Merkle-tree scheme, VC-signed anchors, clock synchronisation, and daily or smaller declared-batch external anchoring. Anchor association never mutates the source record.
  • DUTY_LEDGER exists with roles, SLAs and breach hooks, and its IDs are referenced from FHR/UDR where duties are engaged.
  • Sequential chain/batch fields, late-bound evid_chain_anchor_id / proof references, legal_hold, duty_ledger_id, and breach_notif_sent exist in FHR/DDL schema via AD‑08.
  • A documented Regulatory Mode profile is present (AD‑21 [RM]) with:
  • conservative gating defaults,
  • active gate beacons,
  • jurisdiction tags on outputs,
  • shortened PC TTL,
  • expanded logging,
  • auto‑exposed veto reasons.

Degrees of freedom:

  • Exact SLA numbers (e.g. 24h vs 48h for appeals),
  • VC scheme choice (e.g. which VC flavour / PKI),
  • External anchoring mechanism (transparency log vs notary vs internal anchor + witness),

provided the invariants are still satisfied.

3. EVID_CHAIN — Evidentiary chain

3.1 Data model

Core concept

EVID_CHAIN = canonically serialised, sequentially hash-linked FHR/DDL artefacts with VC-signed, clock-synchronised anchors, Merkle-rooted daily or by a smaller declared batch window.

Key elements:

  • Canonical record and sequential hash:
  • Each FHR/DDL record declares canonicalization_scheme, canonicalization_version, and hash_algorithm_id.
  • The versioned schema defines record_body_i by excluding chain outputs and late-bound/transport fields: record_hash, prev_record_hash, evid_chain_stream_id, record_sequence_no, writer_id, signer_key_id, evid_chain_anchor_id, evid_chain_proof_ref, and transport metadata. Implementations may not choose exclusions ad hoc.
  • evid_chain_stream_id identifies the immutable sequencing partition (for example a ledger shard/writer stream). record_sequence_no is allocated atomically and monotonically within that stream; prev_record_hash always links to the preceding record in the same stream. A stream may have one active sequencer or an equivalent consensus/serializable allocation mechanism, never competing uncoordinated writers.
  • In writer order, construct the domain-separated object: chain_input_i = {domain: "SRF-EVID-v2", record_body: record_body_i, evid_chain_stream_id, prev_record_hash, record_sequence_no, writer_id, signer_key_id} and compute record_hash_i = H(canonicalize(chain_input_i)). The structured canonical object, rather than delimiter-free string concatenation, makes field boundaries and types unambiguous.
  • The record stores record_sequence_no, prev_record_hash, record_hash, writer_id, and signer_key_id. Sequence gaps, duplicate sequence numbers, or previous-hash mismatches are verification failures.
  • Merkle tree per batch/day:
  • For each 24h window (or smaller declared batch), sort records by the deterministic tuple (evid_chain_stream_id as UTF-8 bytes, record_sequence_no); duplicate tuples or a per-stream gap are verification failures. Compute Merkle root R_d over that ordered set of record_hash_i leaves using the declared merkle_tree_scheme_id. The default is RFC6962-style domain separation: leaf_hash = H(0x00 || record_hash_bytes) and node_hash = H(0x01 || left_hash || right_hash); odd-node handling follows the named scheme rather than implementation preference.
  • VC‑signed anchor:
  • Construct an “anchor credential” containing:
    • root_hash = R_d,
    • merkle_tree_scheme_id, leaf_count, and evid_chain_batch_id,
    • day = YYYY‑MM‑DD,
    • clock_source (NTP stratum or similar),
    • issuer (operator/developer),
    • jurisdiction_profile_id (for RM).
  • Sign this as a Verifiable Credential (VC) and publish / store immutably.
  • Batch and anchor identity:
  • Each record receives evid_chain_batch_id and evid_chain_stream_id before emission. At batch close, the anchor receives evid_chain_anchor_id and each record receives a Merkle proof reference through an immutable append-only association index keyed by (event_id, evid_chain_stream_id, record_sequence_no, record_hash, evid_chain_batch_id).
  • The original FHR/DDL/WORM record is never rewritten to insert a late-bound anchor ID. Exports may project the associated evid_chain_anchor_id and evid_chain_proof_ref alongside the unchanged source record.
  • External anchoring:
  • Daily root R_d (or the VC hash) is anchored to an external system (e.g. transparency log, notarised bulletin) to make tampering publicly detectable.

3.2 Protocol / mechanism

Write path

  1. Allocate evid_chain_batch_id, evid_chain_stream_id, the stream-atomic record_sequence_no, writer_id, canonicalization identifiers, and the same-stream prev_record_hash; emit the immutable FHR/DDL record with its computed record_hash (AD‑08, AD‑18, AD‑20).
  2. Append (event_id, evid_chain_stream_id, record_sequence_no, record_hash, evid_chain_batch_id) to the batch builder; finalisation applies the declared deterministic tuple order.
  3. At end of batch/day: - finalise Merkle tree, compute R_d; - issue VC anchor credential; - store signed VC and external anchor; - append evid_chain_anchor_id, proof reference, and association timestamp to the immutable association index for each record; never rewrite the source record.

Read / verification path

For audit, given a record:

  • Rebuild the schema-defined record_body, canonicalise the domain-separated chain object, and recompute record_hash; verify stream identity, per-stream sequence number, writer identity, signer-key identity, and same-stream prev_record_hash linkage.
  • Resolve evid_chain_batch_id through the immutable association index to obtain evid_chain_anchor_id and evid_chain_proof_ref.
  • Fetch the corresponding VC anchor and Merkle proof.
  • Verify:
  • VC signature;
  • declared canonicalisation and Merkle-tree scheme;
  • Merkle path record_hash_i → R_d;
  • external anchor consistency (if using a transparency log or similar).

This supports tamper-evident integrity, ordering, and declared-provenance claims under the stated controls. Legal admissibility and evidentiary weight remain jurisdiction- and proceeding-specific.

Legal hold semantics are shared with AD‑20:

  • legal_hold = true on a record or batch:
  • forbids mutation / erasure of the record;
  • forbids mutation of its EVID_CHAIN anchor;
  • ensures anchors for that range are retained beyond default TTLs.

The EVID_CHAIN VC may be offered as an integrity/provenance artefact in discovery, audit, or court. AD‑21 defines the infrastructure; AD‑20 defines policy on preservation and disclosure. Neither card predetermines admissibility or weight.

4. DUTY_LEDGER — Duties, SLAs, breaches

4.1 Data model

Concept

DUTY_LEDGER is the structured record of “who owed what duty, to whom, when, and whether they met it”.

Core fields (minimum):

  • duty_ledger_id — primary key for a duty‑bundle (one incident, one flow, one appeal, etc.).
  • roles — {developer, deployer, operator, user} with per‑role flags: duty_present, acked, breach.
  • sla_ack, sla_fix — SLAs in hours for acknowledgement and fix.
  • ack_ts, fix_ts — actual times; used to evaluate SLA compliance.
  • breach_notif_sent: bool, breach_notif_ts — whether/when breach notification was sent.

Extended fields (interplay with AD‑20/AD‑12):

  • harm_triage_id — link to harm triage record.
  • udr_id — link to User Decision Record (present‑options).
  • appeal_id, appeal_sla, appeal_resolved_ts — appeal‑path metadata (right to contest).
  • jurisdiction_profile_id — inherited from RM profiles.

4.2 Protocol / lifecycle

DUTY_LEDGER entries are created when:

  • A present‑options flow in a regulated/NO‑GO‑adjacent domain occurs (triage + duty).
  • A gate or veto is later contested (appeal).
  • An incident / breach affecting users or regulators is declared.

Lifecycle:

  1. Creation: - Attach duty_ledger_id to relevant FHR/UDR events. - Initialise roles, SLAs (from PEL/Regulatory Mode profile).
  2. Acknowledgement: - Operator or responsible role acknowledges; ack_ts set; SLA compliance computed.
  3. Remediation / fix: - Fix or mitigation executed; fix_ts set.
  4. Breach notification (if needed): - If SLAs breached or regulatory criteria met, breach_notif_sent toggled; notification logged with breach_notif_ts, recipients.
  5. Closure: - Duty ledger entry marked resolved/closed once obligations met and notifications sent.

Placement:

5. Regulatory Mode [RM]

5.1 Concept & trigger

Concept

A one‑switch profile for audits and constrained deployment.

Flag:

  • regulatory_mode ∈ {off, on} (or a richer regulatory_profile_id mapping to AD‑21 [RM] profiles).

When regulatory_mode = on, AD‑21 requires:

  • conservative defaults;
  • active gate beacons;
  • jurisdiction tags on outputs;
  • shortened PC TTL;
  • expanded logging;
  • auto‑exposed veto reasons via API/UI.

5.2 Behavioural changes when RM is on

Conservative defaults

  • Tighten op‑points and Δ‑bands in safety/NO‑GO‑adjacent domains (by referencing AD‑16/17/19 profiles).
  • Tilt MPM towards ask_first / present_options / refuse over “confident emit” in higher‑risk contexts.

Gate beacons

  • Gate state becomes visible in UI/API (e.g. ring beacons like SIF:BLOCK, EHG:ASK_FIRST, SPD:NEUTRALISED).
  • FHR exposes beacon fields so regulators can see which ring engaged.

Jurisdiction tags on outputs

  • All relevant outputs carry jurisdiction_profile_id and related tags, visible to both user and logs.

Shortened PC TTL

  • Phenomenology Channel TTLs shorter than default (e.g. from 14d to 7d or deployment‑specific), unless DPIA says otherwise; still erase‑on‑request.

Expanded logging

  • Higher sampling rates; more detailed fields turned on (e.g. full gate_eval_record, with its compact gates_snapshot projection, SPD details, UDR links) consistent with minimisation.
  • EVID_CHAIN anchors and DUTY_LEDGER IDs attached to more events by default.

Auto‑exposed veto reasons

  • For refusals/rollbacks/vetoes, API/UI surfaces human‑readable gate reasons (e.g. “policy X, jurisdiction Y, risk class Z”), within explainability constraints.
  • FHR includes machine‑readable veto codes and references to policy/quorum sources, so appeals can be audited.

5.3 Appeal SLA & exposure

AD‑21 [RM] requires:

  • appeal_sla_hours defined per jurisdiction profile.
  • appeal_id, appeal_open_ts, appeal_resolved_ts, appeal_outcome fields in DUTY_LEDGER / UDR.
  • Human‑review escalation ladder documented (AD‑14 [DS] UX; AD‑12 [OP] for runbooks).

In RM on‑mode:

  • appeals must be routed to human review by default;
  • appeal_sla metrics appear in dashboards and FHR.

6. Artefacts & FHR fields (AD‑21 slice)

Artefacts

  • /schemas/evid_chain_anchor.schema.json
  • VC structure; fields for root_hash, batch_id, batch_window, leaf_count, merkle_tree_scheme_id, canonicalization_scheme, canonicalization_version, hash_algorithm_id, clock_source, issuer, signer_key_id, and jurisdiction_profile_id.
  • /schemas/duty_ledger.schema.json
  • DUTY_LEDGER record: roles, SLAs, timestamps, breach flags, incident links.
  • /profiles/regulatory_mode.yaml
  • Regulatory mode profile:
    • regulatory_mode_default,
    • gating defaults,
    • PC TTL override,
    • logging knobs,
    • appeal SLAs.

FHR / DDL fields

(implemented via AD‑08 [SO]; semantics from AD‑20 + AD‑21)

  • evid_chain_batch_id, evid_chain_stream_id, evid_chain_anchor_id (nullable before batch close), evid_chain_proof_ref (nullable before batch close)
  • record_sequence_no, prev_record_hash, record_hash
  • canonicalization_scheme, canonicalization_version, hash_algorithm_id, merkle_tree_scheme_id, writer_id, signer_key_id
  • legal_hold, legal_hold_reason, legal_hold_ts (shared with AD‑20)
  • duty_ledger_id
  • breach_notif_sent, breach_notif_ts
  • regulatory_mode or regulatory_profile_id
  • jurisdiction_profile_id
  • (in UDR/DUTY records) harm_triage_id, appeal_id, appeal_sla, appeal_resolved_ts
  • AD‑08 [SO] — FHR schema & observability
  • Implements EVID_CHAIN & DUTY_LEDGER fields; carries regulatory_mode, jurisdiction_profile_id, legal‑hold metadata.
  • AD‑20 [DP] — Data Protection & Retention
  • Defines PC/OC retention, legal hold, duties & harm semantics and DPIA; AD‑21 provides the cryptographic and ledger plumbing for evidentiary chain and duties.
  • AD‑04 [TG] — Truth & Norm Gates, Contestability
  • Provides PEL NO‑GO gating (G1) and routing; RM uses them for conservative defaults and gate beacons.
  • AD‑12 [OP] — Ops & runbooks
  • Uses DUTY_LEDGER IDs and EVID_CHAIN anchors in incident/rollback runbooks and breach notifications.
  • AD‑14 [DS] — UX / Decision Surfaces
  • Regulatory Mode exposure: gating beacons, veto reasons, appeal UX, scope banners.
  • AD‑18 [SE] & AD‑19 [CI]
  • Runtime and CI honour RM profiles (e.g. extra logging, stricter thresholds, more rigorous benches) and stamp EVID_CHAIN & DUTY_LEDGER fields where relevant.

8. Acceptance: when can you say "AD‑21 is implemented"?

You can claim AD‑21 [RM] is live if:

  1. EVID_CHAIN records are canonically serialised, sequentially hash-linked, VC-signed, clock-synchronised, and externally anchored daily or by the declared smaller batch; source records remain immutable and anchor/proof association verifies cleanly from audit tooling.
  2. DUTY_LEDGER exists with roles, SLAs and breach hooks, and incidents traverse the full lifecycle: creation → acknowledgement → remediation → breach notification where required → closure.
  3. FHR carries the chain and batch fields registered in AD‑08, plus legal_hold, duty_ledger_id, and breach_notif_sent; post-close exports resolve evid_chain_anchor_id and proof without source-record mutation.
  4. A documented Regulatory Mode profile exists (regulatory_mode.yaml) with conservative defaults, active beacons, jurisdiction tags, shortened PC TTL, expanded logging and auto‑exposed veto reasons, switchable as one profile.
  5. Appeals carry appeal_id and resolve within the human‑review SLA recorded in the ledger.

Related cards:

  • AD‑30 [SC] (evidentiary chain includes memory write/erase events; legal hold interacts with memory retention).
  • AD‑32 [PG] (evidentiary chain includes pack authorship records, challenge events, retirement decisions; appeal path for dismissed pack challenges routes through AD‑21 governance).