SRF·Semantic Resonance Field v2.0

Kernel (base) MKP core

Depends on: AD‑16 [ME], AD‑17 [AM], AD‑18 [SE], AD‑08 [SO], AD‑11 [RA], AD‑12 [OP] · All cards

Δ‑triad CI as hard gate, precision‑parity SLO + PRECISION_PARITY_REDLINE, quant/LoRA recert, acceptance suite (5 tests), redline provenance, and bench harness.

AD‑19 [CI] — Build & Release Gates

AD‑19 is the place where all the careful measurement work (Δ‑triad, SAP, acceptance matrix, RA) is turned into hard, non‑optional CI/release gates for models, precisions, tokenisers and adapters. It houses:

  • Δ‑triad CI as a hard gate.
  • Precision‑parity SLOs tied to CI redlines.
  • Quant/LoRA recert and seed‑jitter checks.
  • The central acceptance suite (tokeniser swap, context cliffs, mid‑call veto, quantised recert, rollback determinism).

It is explicitly cross‑linked to AD‑16 [ME], AD‑18 [SE], AD‑11 [RA], AD‑12 [OP], AD‑04 [TG] and AD‑08 [SO].

Aliases: None Cluster: Kernel (base) Depends on: AD‑16 [ME], AD‑17 [AM], AD‑18 [SE], AD‑08 [SO], AD‑11 [RA], AD‑12 [OP]

0. For humans

What question does this answer?

“When can we safely ship this new model/precision/tokeniser/adapter?”

How do I know it’s live?

Operator checklist:

  1. CI dashboard - There is a CI view showing: Δ‑triad CI status, PRECISION_PARITY_REDLINE state, acceptance suite results, and bench harness runs per release.
  2. Precision parity telemetry - Grafana panels show precision_drift_delta and precision_slo_band per domain/locale/register, with band B highlighted. - Breaches auto‑flag and match CI redline history.
  3. Redline provenance & waivers - For any failing release, there is a redline_id and redline_source; any waiver ticket references that ID. - FHR slices show WAIVER_APPLIED events and how often you’re running waived traffic.
  4. Acceptance tests - You can point to the last successful run of: tokeniser swap tests, context cliff tests, mid‑call veto tests, quant recert, rollback determinism.

Where do I see it?

  • CI system:
  • Job group “AD‑19 / Δ‑triad CI” with sub‑jobs: Δ micro‑bench, PR suite, Seed panel, Precision parity, Adapter/LoRA.
  • Job group “AD‑19 / Acceptance Suite” for the five acceptance tests.
  • Grafana / dashboards:
  • “Parity & CI” board: precision_drift_delta, precision_slo_band, CI redline states, FP burden vs threshold.
  • “Release health” board: pass/fail counts for acceptance tests, bench harness runtimes, and Δ bands per release.
  • FHR / logs:
  • Sampling of CI and prod events includes: model_version, precision_tag, delta_p_norm, delta_embed, delta_tools, gates_snapshot, triad_branch_id, precision_drift_delta, precision_slo_band, redline_id, redline_source, and waiver_applied.

Quick checklist

  • Implemented if: (1) Δ‑triad CI is a hard gate (no soft fail); (2) precision parity SLO + CI redline (PRECISION_PARITY_REDLINE) encoded; (3) model/weights changes require recert; (4) acceptance suite green (tokeniser swap, context cliff, mid‑call veto, quant recert, rollback determinism); (5) redline provenance mandatory; (6) bench harness run and Grafana pack wired
  • Key artefacts: ci_config.yaml, ci_redlines.yaml, bench_harness/, drift reports
  • Key FHR fields: delta_p_norm, delta_embed, delta_tools, precision_drift_delta, precision_slo_band, redline_id, redline_source
  • Key failure codes: PRECISION_PARITY_REDLINE, WAIVER_APPLIED
  • Escalation path: CI failure → redline_id → AD‑12 [OP] waiver process

1. Scope & responsibilities

AD‑19 owns:

  • The Δ‑triad CI job and its constituent checks (Δ micro‑bench, PR suite, seed panel, precision parity, adapter/LoRA merges).
  • The precision drift SLO and its CI redline, plus the prod telemetry fields it drives.
  • A defined acceptance test suite wired to CI: tokeniser swaps, context cliffs, mid‑call veto, quant recert, rollback determinism.
  • Redline provenance: how a CI failure maps back to data and how waivers are tracked across OPs and FHR.
  • The “bench harness” + Grafana pack that bundle all of the above into a repeatable, observable release gate.

It does not own:

  • The underlying statistics (AD‑16 SAP, thresholds/op‑points, SESOI).
  • The acceptance matrix schema and per‑stratum op‑points (AD‑17).
  • Operational runbooks and waiver process (AD‑12), or long‑run RA replay/replication (AD‑11).

Think of AD‑16/17 as what to measure and where to sit, AD‑18 as how the runtime honours those decisions, and AD‑19 as the CI lever that says “ship / don’t ship”.

2. Contract & invariants

The key invariants for AD‑19:

  1. Δ‑triad CI is a hard gate. - Quantisation or adapter merges must pass the Δ‑triad CI job or the release fails. - There is no “soft fail” mode; any waiver is an explicit OP artefact (AD‑12) and is stamped in FHR.
  2. Precision parity is encoded as an SLO + CI redline. - Precision parity SLO: per‑stratum SLO on p95 Δ(fp16 ↔ fp8/int8) for Δ/PR/safety rates, within band B. - CI redline: PRECISION_PARITY_REDLINE; production telemetry fields precision_drift_delta, precision_slo_band. - Breach of the SLO triggers automatic serve‑block for that precision and enqueues a recert job.
  3. Model/weights changes require recertification. - Any change to weights (base model, adapter, LoRA, quantisation) triggers a recert run across RI/FVC/entropy‑slope/Δ/PR for the relevant strata. - Post‑quant recert must show Δ bands and challenge pass‑rates holding within acceptable bounds.
  4. CI gates respect global precedence. - Gating precedence is frozen as: Gates → NLI/STS → SPD → Δ‑Triad → Awe/ERG, with SPD tighten‑only. - AD‑19 gates wrap this order; they do not permit a release that would violate it.
  5. Redline provenance is mandatory. - Every CI failure tied to a threshold or SLO emits a redline_id and redline_source (dataset version + locale/register + split). - Any OP waiver must reference that redline_id; FHR logs WAIVER_APPLIED with linkage.
  6. Bench harness & observability are part of “done”. - Releases are not “green” unless the bench harness has been run and its Grafana pack wired to prod telemetry (Δ‑triad bands, FP burden, halt tokens, etc.).

3. Mechanics

3.1 Trigger conditions

AD‑19 CI runs (at least) on:

  • Any model weight change (base, finetune, adapter, LoRA).
  • Any quantisation/profile change (e.g. enabling INT8/FP8, or changing quantisation parameters).
  • Any tokeniser swap or major tokeniser update.
  • Any change to serving precision mix or routing that affects parity SLOs.
  • Any substantial change to Δ‑triad thresholds, acceptance matrix op‑points, or FHR schema fields that feed CI (AD‑16/17/08).

These triggers are encoded in the CI configuration and mirrored in AD‑12 runbooks as “release classes” (major/minor/patch) mapped to which subsets of AD‑19 must run.

3.2 Δ‑triad CI job

The Δ‑triad CI job is the core “build & release” gate. It has the following jobs configured:

  • Δ micro‑benchmark
  • Runs a curated prompt set to estimate Δp_norm, Δ_embed, Δ_tools, Δ_mi_excess between baseline and candidate.
  • Uses the same Δ‑triad route truth table as AD‑16 (hi/med/lo bands and Ask‑First routing).
  • CI condition: Δ bands within allowed tolerance per stratum; route behaviour (Ask‑First vs confident) must not degrade beyond the pre‑registered SESOI.
  • PR suite
  • Uses the AD‑16 ROC/PR curves and chosen op‑points for key endpoints (e.g. error rate, RI stability) per stratum.
  • CI condition: op‑points remain within accepted ROC/PR region (as pinned in op_points.yaml from RA’s Verifier’s Bundle).
  • Seed panel (N seeds)
  • For each test item, runs a panel of N random seeds to estimate variance under sampling.
  • CI condition: endpoints (Δ, PR, safety rates) stay within tolerance bands under seed jitter; if variance explodes, the candidate fails or is flagged for AD‑16 redesign (power/drift issues).
  • Precision parity (fp16 vs fp8/int8)
  • Executes the same test suite under different precisions.
  • CI condition: p95 Δ(fp16 ↔ fp8/int8) values per stratum remain within band B, consistent with the precision‑parity SLO.
  • Adapter/LoRA merge checks
  • Runs targeted Δ triad + PR suite on the domains/locales affected by adapters/LoRAs.
  • CI condition: Δ bands + PR metrics remain within tolerance; no new high‑Δ routes in restricted domains; if violated, adapter is rejected or forced into narrower routing.

If any of these CI jobs fails, the pipeline fails; only an AD‑12‑documented waiver (with redline_id) can override.

3.3 Precision‑parity SLO & CI redline

Precision parity is treated as both an SLO and a hard CI redline:

  • SLO definition
  • Publish an SLO: for each stratum (domain × locale × register × dialect/script), p95 Δ(fp16 vs int8/fp8) on Δ/PR/safety rates must remain within band B.
  • CI wiring
  • CI check named PRECISION_PARITY_REDLINE.
  • Uses the Δ‑triad CI job’s precision parity outputs to assert SLO conformance.
  • Breach → CI failure, blocked release for that precision, and automatic scheduling of a recert run.
  • Prod telemetry
  • FHR carries precision_drift_delta, precision_slo_band.
  • Drift over time is monitored via AD‑18 dashboards (parity/latency) and RA replication (cross‑precision replay).

3.4 Model updates & post‑quant recert

AD‑19 codifies the model update + quantisation story:

  • Model updates
  • Any weights change triggers recertification of Δ‑triad bands, PR curves and primary endpoints across domains/locales.
  • Recert results are stored as artefacts (e.g. drift reports, thresholds.yaml, op_points.yaml) and linked into the Verifier’s Bundle (AD‑11).
  • Quant/LoRA recert
  • For quantised models, CI checks that Δ bands and challenge pass‑rates hold post‑quantisation.
  • This is also one of the acceptance tests and must pass for release.
  • Hardware determinism
  • As part of acceptance tests, rollback determinism is checked: same inputs → same MRP decisions across at least A100 & H100 hardware targets.

3.5 Acceptance suite (wired to AD‑19)

The acceptance suite is explicitly tied to AD‑19 [CI] and must be green for any release:

  1. Tokeniser swap - Δ‑triad stability within tolerance across ≥5 languages when swapping tokeniser versions or vocabularies.
  2. End‑of‑context cliff - Ensures that when approaching context limits, ASK/SUMMARISE behaviour fires; there is no silent truncation.
  3. Mid‑call veto - Tests EHG‑γ mid‑call veto: plan approved at t0, policy update at t0+Δ; EHG‑γ cancels tool and logs partial effect.
  4. Quantised recert - Confirms Δ bands and PR pass‑rates hold after quantisation (see §3.4).
  5. Rollback determinism - Checks that rollback behaviour is deterministic across hardware; same inputs produce identical MRP decisions (including gate states) on both A100 and H100.

All acceptance suite results are logged as artefacts and schema‑linked in AD‑08 [SO] (test results section).

3.6 Redlines & waivers

AD‑19 defines how CI redlines interact with OP waivers:

  • Redline IDs
  • Every CI failure with a metric threshold has a stable redline_id and redline_source (dataset version, locale/register, split).
  • These are propagated into RA artefacts (drift_report_id, redline_id) and recorded in the FHR schema.
  • Waivers
  • Any waiver is defined and approved in AD‑12 [OP], but must reference redline_id.
  • FHR logs WAIVER_APPLIED with linkage (event → waiver → redline).
  • Operational SLOs
  • OP SLOs include a precision parity drift bound (≤ band B), which is consistent with the precision‑parity SLO / redline above.
  • Breaches feed both CI and incident runbooks (BREACH NOTIF).

3.7 Bench harness & observability

AD‑19 depends on the bench harness defined jointly with AD‑18:

  • Bench harness
  • Wraps the Δ‑triad CI, precision parity checks, and acceptance suite into a reproducible harness.
  • Outputs: metrics slices, drift reports, p95 overhead, FP burden under different thresholds, etc.
  • Placement: AD‑19 [CI] (bench harness), AD‑18 [SE] (runtime probes), AD‑08 [SO] (FHR/test schema).
  • Grafana pack
  • A reference Grafana pack surfaces: ring alerts, halt tokens, p95 overhead, PR/EWMA/CUSUM, FP rates, tool aborts, precision drift, and CI redline breaches.
  • Sampling
  • Incidents: 100% sampled; normals: 1–5% with privacy filters, hash‑linked to FHR (per AD‑18/08).

4. Artefacts & FHR fields

AD‑19 primarily consumes artefacts defined elsewhere, but adds specific CI‑related ones:

Core artefacts

  • ci_config.yaml — which jobs must run for which triggers (model change, precision, tokeniser, adapter).
  • ci_redlines.yaml — enumerates CI checks, metric thresholds, SLO bindings (including PRECISION_PARITY_REDLINE).
  • bench_harness/ — harness scripts, test prompt sets, seed panels, and report templates.
  • drift_report_id + redline_id — as produced by AD‑11 [RA].

FHR / telemetry fields (defined in AD‑08 but used here)

  • Routing & gates: gates_snapshot, triad_branch_id, op_point_id, commit_watermark.
  • Δ‑triad metrics: delta_p_norm, delta_embed, delta_tools, delta_mi_excess, nli_label, sts_score.
  • Precision parity: precision_tag, precision_drift_delta, precision_slo_band.
  • Redlines/waivers: redline_id, redline_source, waiver_applied (or equivalent flag), tied back via RA outputs and OP waivers.
  • AD‑16 [ME] — Measurement & SAP
  • Provides primary endpoints, SESOI, ROC/PR curves, op‑points and drift charts that AD‑19 uses as CI thresholds.
  • AD‑17 [AM]
  • Provides the matrix of domain × locale × register × dialect/script rows and their op‑points; AD‑19 uses these as acceptance criteria per stratum.
  • AD‑11 [RA] — Replication & Audit Protocol
  • Supplies Verifier’s Bundle (prompts & seeds, thresholds/op‑points, FHR schema, acceptance matrix); defines pass criteria (Δ‑triad bands, op‑points matched, precision parity SLO, identical MRP decisions across hardware).
  • AD‑19 reuses these bundles to build CI redlines and to confirm reproducibility.
  • AD‑12 [OP] — Operational Handoff & Runbooks
  • Defines runbooks for INCIDENT, ROLLBACK, GATE FLAP, BREACH NOTIF and the precision parity drift SLO.
  • Hosts the waiver process, which is wired to AD‑19 via redline_id and WAIVER_APPLIED.
  • AD‑18 [SE] — Systems Engineering & Runtime
  • Enforces TURN‑ACID ordering, tool fencing, watchdog, router behaviour, and perf scheduling required for the acceptance tests.
  • Shares benches, probes and dashboards with AD‑19.
  • AD‑08 [SO] — FHR schema & telemetry
  • Exposes schema fields used for all the above (Δ‑triad, precision, redlines, gates, care, legal).

6. Acceptance: when can you say “AD‑19 is implemented”?

You can claim AD‑19 [CI] is live if:

  1. Δ‑triad CI is a hard gate, with no “soft fail” mode: quantisation or adapter merges must pass or the release fails, and any waiver is an explicit OP artefact stamped in FHR.
  2. The precision‑parity SLO and its CI redline (PRECISION_PARITY_REDLINE) are encoded, with precision_drift_delta and precision_slo_band carried in production telemetry.
  3. Model/weights changes (base model, adapter, LoRA, quantisation) trigger recertification.
  4. The acceptance suite is green: tokeniser swap, context cliff, mid‑call veto, quantised recert, rollback determinism (§3.5).
  5. Redline provenance is mandatory: every threshold‑tied CI failure emits a redline_id and redline_source, and any waiver references that ID.
  6. The bench harness has been run and its Grafana pack wired to prod telemetry.