SRF·Semantic Resonance Field v2.0

Kernel (base) MKP+

Depends on: AD‑16 [ME], AD‑08 [SO], AD‑11 [RA], AD‑19 [CI], AD‑27 [SPD], AD‑25 [CP] · All cards

Versioned per‑release verdict table (domain × locale × register × dialect/script) with promotion/demotion rules grounded in AD‑16's SAP.

AD‑17 [AM] — Acceptance Matrix

AD‑17 is the dedicated Acceptance Matrix card: the explicit table that declares, per domain and locale, whether a change is Adopted, Held, or Rejected, and on what evidence.

Aliases: none Naming lineage: draft‑era tag [MS] retired; [AM] is canonical. Cluster: Kernel (base) Depends on: AD‑16 [ME], AD‑08 [SO], AD‑11 [RA], AD‑19 [CI], AD‑27 [SPD], AD‑25 [CP]

0. For humans

Quick checklist

  • Implemented if: (1) acceptance_matrix.csv exists per release, validates against schema; (2) every row is domain × locale × register (× dialect/script); (3) core metric and SPD columns populated from AD‑16/AD‑11/AD‑27; (4) promotion/demotion rules documented and recomputable; (5) RA verifier bundles include matrix + schema
  • Key artefacts: acceptance_matrix.csv, /schemas/acceptance_matrix.schema.json
  • Key FHR fields: op_point_id, SPD block (PER/PCS/DCS/RAR, spd_fp_rate), acceptance_matrix_row_id, acceptance_status, acceptance_status_reason
  • Key failure codes: SESOI_NOT_MET, DRIFT, POWER_INSUFFICIENT
  • Escalation path: status change → RA bundle update → CI gate (AD‑19 [CI])

1. Purpose & role

Goal: Turn “this looks better” into a versioned, machine‑readable verdict over domains × locales, grounded in AD‑16’s SAP.

AD‑17:

  • Defines the shape of the Acceptance Matrix: rows, columns, SPD fields, artifacts.
  • Specifies promotion/demotion rules: what evidence is required to call a mechanism “Adopted”, and when drift forces rollback.
  • Bridges measurement → operations: it is the primary artefact RA, PEL, and Ops read to know what is actually in force.

Think of AD‑16 as defining how we measure; AD‑17 defines what the final verdict table looks like.

2. Data model

2.1 Rows

Each row is one stratum:

  • domain ∈ {facts, policy, idiom, group, …}
  • locale (e.g. en-GB, es-ES, ro-RO).
  • register (casual, formal, clinical, etc.).
  • Optional dialect/script field for fine‑grained distinctions.

Formally:

Rows: domain × locale × register (× dialect/script).

2.2 Columns

Columns capture metrics and status:

Core columns:

  • primary_endpoints: bundle referencing SAP results for:
  • Δ steps‑to‑decision
  • error rate
  • RI stability
  • safety correctness.
  • neg_control_delta, pos_control_delta
  • effect sizes for negative/positive controls in this stratum.
  • ci_widths: typical CI widths for primary endpoints (precision).
  • power_achieved: observed power / effective sample size vs SAP target.
  • op_point_id: pointer to ROC/PR decision threshold chosen under AD‑16.
  • invariance_verdict or drift_alarms:
  • status of CUSUM/EWMA drift checks and multi‑group invariance tests.
  • energy_tradeoff: “energy‑tied closure” row: trade‑off between performance and cost (E).

SPD column block (tightened in later versions):

Include SPD‑sensitive fields:

  • PER, PCS, DCS, RAR (person/collective/discourse/responsibility SPD indices).
  • spd_fp_rate (false positives from SPD vetoes).
  • clb_throttled_by_spd (how often calibration / band changes were blocked by SPD).

Status columns:

  • status ∈ {PROPOSED, UNDER_REVIEW, ADOPTED, HELD, REJECTED, DEMOTED}.
  • status_reason (short code, e.g. SESOI_NOT_MET, DRIFT, POWER_INSUFFICIENT).
  • sap_version_id, ra_bundle_id.

2.3 Artifacts

  • acceptance_matrix.csv — main artefact.
  • /schemas/acceptance_matrix.schema.json — JSON Schema for validation.

The matrix columns remain status and status_reason. A per-turn FHR row does not reuse those generic names: it joins the governing matrix row through acceptance_matrix_row_id and projects the values as acceptance_status and acceptance_status_reason (AD‑08 [SO] §4.5).

This allows:

  • AD‑11 [RA] to ship a verifier’s bundle with acceptance matrix + checksums.
  • AD‑08 [SO] / FHR to link each metric slice to the row/column that justified its promotion.

3. How it is populated (flow from AD‑16 & AD‑11)

Inputs:

  • SAP outputs from AD‑16: endpoint estimates, CI, SESOI verdicts, drift stats, power tables.
  • RA bundle from AD‑11: replication results, drift reports, threshold parity, etc.
  • SPD & culture metrics from AD‑27 / AD‑25: PER, PCS, DCS, RAR, SPD FP rates.

Process (conceptual):

  1. For each domain × locale × register (× dialect/script) stratum, collect SAP and RA stats.
  2. Evaluate primary endpoints vs SESOI and CI (from AD‑16).
  3. Fill control columns (neg/pos, A/A, placebo behaviour) from the control suite.
  4. Fill invariance/drift fields from CUSUM/EWMA & multi‑group checks.
  5. Populate SPD fields from SPD module statistics.
  6. Apply the promotion rules (below) to set status, status_reason.
  7. Emit updated acceptance_matrix.csv + checksum; RA bundles it for verifiers.

4. Promotion / demotion rules

AD‑17 is where promotion becomes algorithmic.

4.1 Promotion to “Adopted”

A row may be marked Adopted only if all of:

  1. Primary endpoints - CIs exclude the null in the desired direction and reach SESOI for that domain/locale.
  2. Controls behave correctly - Negative controls: effects near zero (no spurious “improvements”). - Positive controls: degradation detected; sensitivity confirmed.
  3. Power and precision - power_achieved meets or exceeds SAP targets (e.g. ≥0.8 at α = 0.05). - CI widths below pre‑set max for this stratum.
  4. Drift & invariance - No unresolved drift alarms; invariance verdict “pass” for required axes (time, language, cohort).
  5. SPD guardrail - SPD metrics (PER/PCS/DCS/RAR, spd_fp_rate) in acceptable bands; SPD module has not vetoed adoption.
  6. Replication check - AD‑11 RA bundle has at least one successful replay (or cross‑model) for that stratum, with ra_result = PASS.

Only then may status be set to Adopted.

4.2 Hold / Rejected / Demoted

  • Held: SAP indicates promising but incomplete evidence (power too low, CI wide, or some controls inconclusive).
  • Rejected: primary endpoints fail SESOI or reverse direction, or controls behave pathologically.
  • Demoted: previously Adopted row now fails due to:
  • drift alarms,
  • degraded SPD metrics,
  • replication failures.

Demotions are accompanied by a drift report ID from RA and a note of the half‑life from AD‑16’s time‑series analysis.

  • AD‑16 [ME]
  • Provides endpoints, SESOI, CIs, power, drift stats that populate the matrix columns.
  • AD‑11 [RA]
  • Ships acceptance_matrix.csv and schema in the verifier bundle alongside thresholds.yaml, op_points.yaml, FHR schema, checksums.
  • AD‑08 [SO]
  • FHR slices reference the relevant row in the matrix so we can reconstruct “what was Adopted when this event happened.”
  • AD‑27 [SPD] / AD‑25 [CP]
  • Feed SPD metrics and culture overlays that influence the SPD columns and can veto adoption.
  • AD‑20 [DP] / AD‑21 [RM]
  • Use the Acceptance Matrix as part of “what’s in force” for compliance and evidentiary records.

6. Invariants vs configurable degrees of freedom

Hard invariants (for SRF‑conformant AD‑17):

  • Rows are always domain × locale × register (× dialect/script).
  • Columns cover, at minimum:
  • primary endpoints;
  • neg/pos control deltas;
  • CI widths;
  • power achieved;
  • op_point_id;
  • invariance/drift flags;
  • energy trade‑off;
  • SPD block (PER/PCS/DCS/RAR, spd_fp_rate, clb_throttled_by_spd);
  • status + reasons.
  • acceptance_matrix.csv must validate against /schemas/acceptance_matrix.schema.json.
  • Promotion to Adopted MUST reference AD‑16’s SESOIs and CIs; no shadow decision rules.
  • RA bundles must include the matrix and template as part of the verifier’s pack.

Degrees of freedom (configurable):

  • Which domains/registers you enumerate (e.g. you may omit registers not used in a deployment, but must not conflate them).
  • Exact SESOI values, power targets, and drift thresholds — as long as they come from AD‑16’s SAP and are preregistered.
  • How you visually present the matrix (docs, dashboards) as long as a machine‑readable CSV/JSON form exists.
  • Additional columns (e.g. per‑segment fairness metrics) that don’t override the core ones.

7. Acceptance: when can you say “AD‑17 is implemented”?

You can treat AD‑17 as implemented when:

  1. acceptance_matrix.csv exists for each release, validates against /schemas/acceptance_matrix.schema.json, and is versioned.
  2. Every row corresponds to domain × locale × register (× dialect/script).
  3. Core metric and SPD columns are populated from AD‑16/AD‑11/AD‑27, not hand‑typed.
  4. Promotion/demotion rules are documented and can be recomputed from SAP + RA data.
  5. RA verifier bundles include the matrix + schema alongside thresholds/op‑points and FHR schema.