AD‑18 [SE] — Systems Engineering & Runtime

Role: Turn the SRF lattice + Δ‑triad into a runtime contract that ops and auditors can actually enforce: baselines, precision parity surfaces, TURN‑ACID, tool fencing, watchdogs, and forensics wired all the way into FHR and CI. AD‑18 also owns the Action Ticket declaration artefact and the canonical Gate Evaluation Record structure.

Aliases: none Cluster: Kernel (base) Depends on: AD‑16 [ME], AD‑08 [SO], AD‑06 [DG], AD‑12 [OP], AD‑19 [CI], AD‑29 [PLG]

Canonical label: AD‑18 [SE] — Systems Engineering & Runtime. The earlier draft label “Precision/Tokenizer Parity & Context Bands (CI redlines)” survives only as lineage; those concerns are distributed across AD‑16 [ME], AD‑08 [SO], AD‑15 [PA], and AD‑19 [CI], while AD‑18 binds them to serving, tools, and FHR.

0. For humans

What question does this answer?

"Is the thing we ship the same lattice we prove on paper — with baselines, thresholds, tools, precision, and declaration artefacts all actually enforced and observable in prod, turn by turn?"

It guarantees that:

• per‑locale/register/context baselines exist and are stamped;
• each commit is ordered and replay‑safe;
• tools cannot slip past gates;
• precision drift and redlines are visible and enforceable;
• watchdogs and TIG bounds are real, not vibes;
• consequential actions carry a complete, gated Action Ticket;
• gate evaluation is per‑ring, structured, and forensically reconstructable.

How do I know it’s live?

Sampling a few FHR rows and logs, you should be able to check:

• Every row has model_version, precision_tag, tokenizer_id, sampling_profile_id.
• Locale fields + baselines present: locale_id, register_id, context_band, ri_baseline_id, deltap_baseline_id, baseline_quality.
• Commit ordering visible and gap‑free in normal operation: commit_watermark monotone, replay_detected = false.
• Tool events show request_id, dedupe_key, principal_id, authz_decision_id, tool_manifest_digest, operation_id, operation_state, effect_receipt_id, plan_hash, and gate_eval_record (or the gates_snapshot compact projection).
• Watchdog activity is non‑zero in drills (and rare in normal ops): watchdog_trip, halt_tokens_post_trip, watchdog_heartbeats, preempt_count.
• CI and prod agree on redlines: incidents and waivers carry redline_id, redline_source; precision drift breaches show both CI trip and runtime telemetry.
• Consequential actions carry ticket_id and ticket_hash; tickets with status = INCOMPLETE do not reach EXECUTED.
• Gate evaluation records are per‑ring and carry snapshot_hash.

Where do I see it?

• Dashboards (AD‑08/AD‑12)
• Latency & throughput: QPS vs halt rate, watchdog pre‑empt counts, TIG breaches.
• Drift & parity: Δ‑triad bands, precision parity SLO panels, per‑stratum context‑band stats.
• Action Tickets: ticket volume, completion rates, blocked ticket reasons, irreversibility class distribution.
• FHR / log explorer
• Filter by session_id + commit_watermark to reconstruct any incident.
• Drill into tool calls using request_id, dedupe_key, plan_hash, gate_eval_record.
• Drill into Action Tickets using ticket_id + ticket_hash; verify gate evaluation and resolution outcome.
• CI pipelines (AD‑19/AD‑11)
• Confirm Δ‑triad CI jobs gate releases; see parity redlines and recert jobs for quantisation/adapters.

Quick checklist

• Implemented if: (1) per‑locale/register/context-band baselines stamped in FHR; (2) every event has model_version, precision_tag, tokenizer_id, sampling_profile_id; (3) TURN‑ACID enforced for kernel-owned state, ledger, and FHR, with external effects handled per manifest; (4) tools bind immutable manifests, principal authorization, durable idempotency, and effect receipts; (5) watchdog enforces ≤ 5 token halt; (6) gate_eval_record at tool entry frozen for forensics (legacy alias: gates_snapshot); (7) acceptance tests pass; (8) Action Ticket schema and Action-Governance Slice enforced for all consequential external actions; (9) Gate Evaluation Record emitted for every active_ring_ids[] member per gating pass
• Key artefacts: baseline tables, TURN‑ACID validator, tool manifest, watchdog thread, Action Ticket schema, Gate Evaluation Record schema, Meta‑Resolution outcome object
• Key FHR fields: locale_id, context_band, commit_watermark, gate_eval_record, plan_hash, precision_drift_delta, ticket_hash, ticket_status
• Key failure codes: COMMIT_GAP, COMMIT_DUP, TOCTOU_VIOLATION, TOOL_DEDUPE_HIT, WATCHDOG_TRIP, TICKET_INCOMPLETE, TICKET_BLOCKED
• Escalation path: pre‑commit failure → rollback → AD‑12 [OP] runbook

BLOCKED semantics: user‑resolvable BLOCKED tickets may be unblocked by explicit user action. Hard G1/H1 blocks remain non‑executable; only scope revision or governance review may produce a revised ticket — never user override.

1. Role & questions AD‑18 answers

This card is explicitly designed to answer:

1. Baselines: "Do you maintain per‑locale Δ/RI baselines (Spanish vs English etc.), or do you assume global thresholds?"
2. Forensics: "Can you expose model_version + serving‑precision tag in every FHR entry for forensic parity?"
3. Runtime contract: "Will you adopt a TURN‑ACID contract and publish the pre‑commit validator spec?"
4. CI + drift: "Can the Δ‑triad CI job fail a release on quantisation or adapter drift?"
5. Tools: "Will tools be required to publish idempotence and side‑effect profiles?"
6. False positives / user burden: "What's the false‑positive burden when rings trigger too often?"
7. Latency & observability: "Each gate adds O(n×m) checks; how does this scale at 100 QPS? Where are the dashboards, throughput, failure modes?"
8. Declaration artefacts: "What does the system declare before acting, and how is that declaration structured, evaluated, and resolved?"

AD‑18's job is to answer "yes" to all eight with executable protocol.

2. Scope & hard invariants

Scope

AD‑18 governs the runtime & serving stack:

• per‑locale/register/context‑band baselines and how they are attached to every FHR row;
• model/precision/tokeniser/sampling tags for forensics;
• the TURN‑ACID contract and pre‑commit validator;
• tool manifests, idempotence keys, router fencing, and plan hashing;
• watchdog and streaming halt budget;
• CI connection points to Δ‑triad, precision parity and redlines (shared with AD‑19);
• the Action Ticket declaration artefact and its lifecycle (§4.1);
• the canonical Gate Evaluation Record structure (§4.2);
• the Meta‑Resolution outcome object (§4.3).

Hard invariants (must hold to claim AD‑18‑conformant runtime)

1. Baselines are stratified and stamped - Baselines are maintained per‑locale, per‑register, per‑context_band (short/med/long); global thresholds are last‑resort only. - FHR rows must carry: locale, register, context_band, ri_baseline_id, deltap_baseline_id, with baseline_quality set to low when back‑off to global is used.
2. Every event is forensics‑ready - FHR always includes model_version and precision_tag (serving identity, AD‑08 §4.1b) plus tokenizer_id and sampling_profile_id (AD‑08 §4.5).
3. TURN‑ACID is enforced, not aspirational - Kernel‑owned state, ledger, and FHR either commit together or do not commit. External effects are governed by the declared rollback, compensation, and irreversibility semantics in §3.4. - Commit is only allowed if baselines exist, gates are PASS or TIGHTEN (not unknown), tools are fenced, and context_band is within limits.
4. Commit ordering is explicit and auditable - Every committed turn carries a monotonic commit_watermark, with prev_watermark and replay_detected for cross‑shard replay checks.
5. Tools cannot silently escape gating or authorization - Tools bind an immutable manifest identity/version/digest, principal identity, authorization scope, target resource, allowed operations, and a fresh authorization decision before dispatch. - Tools declare idempotence, side effects, abort, compensation, dry-run, and rollback semantics and echo request_id + dedupe_key. - Router enforces gates-before-tools, default-denies missing or mismatched identity/authorization/manifest data, cancels in-flight tools on mid-turn veto, and records durable operation/effect state. An in-memory dedupe cache is never authoritative.
6. Streaming halts are bounded and enforced by an independent watchdog - On breach (any gate trip or TIG breach), the system must cut the stream, set runtime_mode = degraded, cancel further tool dispatch and halt within ≤ 5 tokens. Any already-completed external effect is reconciled under its receipt and manifest rather than represented as undone. - A dedicated watchdog thread enforces this even if the main eval loop stalls, logging WATCHDOG_TRIP.
7. Gate state at tool entry is frozen for forensics - Every tool call records a gate_eval_record for the declared active_ring_ids[] (SIF/EHG/ODS in MKP; SIF/EHG/ODS/RCL/ERG in full, plus any versioned extension). For ODS‑δ, metric values reference the bound Δ‑triad values with source-turn provenance, per the temporal binding in AD‑01 [OV] §2.3. The record travels with plan_hash, policy_quorum_id, and the immutable tool_manifest_digest. (Legacy alias: gates_snapshot is the compact projection of the full gate evaluation record; see §4.2.) Interface family, pinned: gate_events[] logs per-gate evaluations (AD‑04/AD‑08); gate_decisions[] is its decision-only projection (per-gate outcome set, AD‑05 and the annex); gate_eval_record is the per-ring record, gates_snapshot its compact projection.
8. Acceptance tests exist and must pass - Tokeniser swap, context‑cliff, mid‑call veto, quantised recert, and rollback determinism are covered by explicit tests.
9. Action Tickets are required for consequential actions - External, persistent, or irreversible actions require a complete Action Ticket (§4.1) before execution. Ambiguity in any ticket field keeps the ticket INCOMPLETE and execution locked.
10. Gate Evaluation Record is emitted per gating pass
    • Every gating pass produces a structured gate_eval_record (§4.2) with per‑ring state, threshold, metric values, trigger reason, and timestamp.

Preview/confirmation join (normative): MRP derives preview/confirmation satisfaction from the latest AD‑14 event sharing the Action Ticket's ticket_id and trace_id. ACTION_PREVIEW_SHOWN satisfies preview; ACTION_PREVIEW_CONFIRMED satisfies confirmation; ACTION_PREVIEW_REJECTED blocks execution until a revised ticket is presented and confirmed. The event payload carries ticket_id; the mandatory AD‑08 §4.23 envelope carries trace_id, event timestamp, schema identity, and schema version. Together those fields form the minimum joinable event record.

Action-Governance Slice (normative, cross-profile): whenever side_effects != [NONE], execution additionally requires fresh scoped and revocation-checked consent, the minimum data-handling declaration, principal/authorization and immutable manifest binding, durable idempotency/effect accounting, and the reduced AD‑14 §4b preview/confirmation path. Authorization is fresh only when the current time falls within the decision's declared validity interval and its principal, scope, target, operations, parameters, and manifest digest still match. For these side-effecting actions, authz_expires_ts is mandatory, non-null, and later than the final dispatch check; a non-expiring decision is insufficient. The slice binds in MKP and full profiles without implying full-card adoption of AD‑14, AD‑18, or AD‑20.

Configuration surface (degrees of freedom)

• Op‑points and Δ‑bands per stratum (tuned in AD‑16 + AD‑19).
• Exact definition of context_band cut‑points (short/med/long) per deployment.
• Watchdog budgets and debounce/hysteresis parameters, subject to the ≤5‑token hard bound and fail‑closed semantics.
• Sampling and dashboard granularity (AD‑08/AD‑12), as long as all mandatory fields & SLOs are covered.
• Action Ticket field extensions beyond the core schema, provided core fields remain mandatory.

3. Protocol & mechanisms

3.1 Baselines & context bands

Tables & strata

• Maintain baseline tables keyed by: (locale, register, context_band) where context_band ∈ {short, medium, long}.
• Promotion of a metric configuration to "Adopted" is conjunctive per stratum: all relevant strata for that domain must pass their SAP criteria (AD‑16).

Data‑sparse strata

• Where data is insufficient in a specific (locale, register, context_band) stratum, serving falls back to conservative global bands and marks baseline_quality = low in FHR.

FHR stamping

• Each FHR row includes: locale, register, context_band, ri_baseline_id, deltap_baseline_id, baseline_quality.

3.2 Model & precision forensics

Every runtime event is tied to a concrete model / precision / tokeniser / sampling profile:

• model_version: semver + weight hash (e.g. 5.1.3+sha256:...).
• precision_tag: fp16 | bf16 | fp8 | int8 | ....
• tokenizer_id: explicit tokeniser variant.
• sampling_profile_id: identifies temperature / top‑p / seed profile, including "measurement mode" in AD‑16.

These are mandatory FHR fields per AD‑08: model_version and precision_tag in the serving‑identity group (AD‑08 §4.1b), tokenizer_id and sampling_profile_id with the measurement instruments (AD‑08 §4.5).

3.3 TURN‑ACID runtime contract & pre‑commit validator

AD‑18 encodes TURN‑ACID as a strict runtime contract:

• Atomicity: A turn either commits (every active profile-required ring reports PASS or an enforced TIGHTEN, and tools are fenced) or rolls back its uncommitted kernel-owned state. No partial kernel commit is permitted across kernel‑owned state, ledger, and FHR; external effects follow the separately declared atomicity scope.
• Consistency:
• pre_commit() re‑evaluates every ring active under kernel_profile (SIF, EHG, ODS in MKP; SIF, EHG, ODS, RCL, ERG in full) and checks all invariants tied to PEL/MPM. A required unavailable ring emits FAIL and blocks commit.
• Baselines must be present and valid; context_band must be within configured limits.
• Isolation:
• Per‑session sandbox ID and state hash; sessions cannot read/write each other's scratch or KV.
• Durability:
• Commit writes both the ledger entry and the corresponding FHR slice with a shared trace_id.

Validator checks (pre‑commit)

Before a turn is allowed to commit, validator must verify:

• Baselines: present and non‑stale for the current (locale, register, context_band).
• Gates: every ring named in active_ring_ids[] is in PASS or TIGHTEN; the set contains the required rings for the declared kernel_profile; no unknown, omitted-required, or “bypass” status exists.
• Tools: queue empty or every tool is fenced and accounted for; principal/authorization fields, authorization validity timestamps, and immutable manifest digest are present, current, and match; the durable operation ledger is in a state compatible with the proposed transition.
• Forensics: model_version, precision_tag, tokenizer_id, sampling_profile_id stable within the turn.
• Ordering: commit_watermark step is consistent with previous turn (no gaps or duplicates).
• Action Ticket: if the turn involves a consequential action, the associated ticket must have status READY_FOR_GATING (see §4.1); if side_effects != [NONE], every Action-Governance Slice requirement is satisfied.

On failure, pre_commit() aborts and triggers the appropriate rollback runbook from AD‑12.

3.4 Commit watermark & replay safety

The commit watermark makes ordering explicit across runtime and audit surfaces:

Atomicity scope (normative): TURN‑ACID atomicity covers kernel‑owned state, ledger, and FHR commit. External effects are rollback‑covered only where the tool manifest declares an effective rollback mechanism; otherwise they are compensated where possible, or recorded and escalated as irreversible partial effects. A veto halts further effects but does not represent already‑completed irreversible effects as undone.

• Protocol
• Maintain a per‑session monotonic commit_watermark incremented on each successful commit.
• Cross‑shard ordering key: (session_id, commit_watermark, shard_id).
• FHR fields: commit_watermark, prev_watermark, replay_detected: bool.
• Validator behaviour
• If expected commit_watermark is missing → COMMIT_GAP → rollback + alert.
• If duplicate watermark observed → COMMIT_DUP → rollback + alert.
• Runbooks
• AD‑12 defines replay investigation & repair procedure keyed by commit_watermark.

3.5 Tool contracts, idempotence & plan hash

Immutable tool manifest

Every callable tool publishes a versioned manifest containing at least:

• tool_manifest_id, tool_manifest_version, tool_manifest_digest;
• tool_id, requires_request_id: true, dedupe_ttl_ms;
• idempotence_class, side_effects[]; NONE is exclusive and valid only as the singleton value [NONE] — it may never appear beside a side-effect value;
• abort_semantics, compensation_semantics, dry_run_supported, rollback_available.

The v2.0 digest is tool_manifest_digest = SHA-256(JCS({domain: "SRF-TOOL-MANIFEST-v2", manifest_body})), where manifest_body is the complete schema-valid manifest excluding only the digest field itself. Strings are UTF-8, JCS means RFC 8785 canonical JSON, and arrays whose schema semantics are sets are sorted by their schema-defined order before canonicalisation; the stored value carries the sha256: algorithm prefix. The Action Ticket and every tool/effect record bind the same digest. Missing, mutable, unresolvable, or mismatched manifest identity is default-deny.

Principal and authorization binding

Before dispatch, the Action Ticket carries principal_id (opaque), principal_type, authorization_scope_ref, target_resource, allowed_operations[], authz_decision_id, authz_policy_version, authz_evaluated_ts, and authz_expires_ts. Authorization is evaluated for the exact principal, target, operation, parameters, and manifest digest; a permission for a different target, operation, principal, or manifest version does not compose. A decision is stale when its declared expiry has passed, the governing authorization-policy version has changed, or any bound input no longer matches. For side_effects != [NONE], the expiry is required and must be later than the final dispatch check. For [NONE] verification-class work only, authz_expires_ts may be null when the policy decision explicitly declares non-expiry. Missing or stale authorization blocks execution.

Durable idempotency and operation ledger

• The authoritative dedupe key is (tool_manifest_digest, principal_id, dedupe_key) in a durable operation ledger. The digest includes tool identity and versioned contract content, so a manifest revision cannot collide silently with an earlier operation. An in-memory LRU may accelerate lookup but is a disposable cache only.
• The ledger uses the closed states {PREPARED, DISPATCHED, ACKNOWLEDGED, COMPLETED, COMPENSATED, FAILED, UNKNOWN} and stores operation_id, ticket/trace IDs, authorization decision, manifest digest, request ID, timestamps, and the latest effect receipt reference.
• A duplicate may return a prior result only when the authoritative record is COMPLETED and its principal, authorization scope, target, operation, parameters, and manifest digest match. Otherwise execution is suppressed and routed to reconciliation.
• UNKNOWN blocks automatic replay. Crash recovery queries the provider and verifies any external receipt before deciding whether to complete, compensate, or fail; it never retries merely because the local process restarted.
• The authoritative key or a non-reusable tombstone is retained for at least the greatest of the manifest's dedupe_ttl_ms, the provider's declared idempotency/retry window, and the deployment's operation-reconciliation retention period. TTL expiry never converts UNKNOWN, FAILED, or an unmatched prior record into permission to retry. A genuinely new attempt requires a new ticket revision, fresh authorization/confirmation, and a new dedupe key.

Allowed transitions are closed and monotonic:

FAILED is terminal when the latest receipt is FAILED (no effect established). When its latest receipt is PARTIAL, only the compensation transition above is permitted; it does not reopen the original action or authorise replay.

Any unlisted transition is invalid, emits an operation-ledger incident, and blocks commit. State changes use compare-and-set or an equivalent serializable guard so concurrent workers cannot advance the same operation twice.

External-effect receipt

Each external action produces an append-only receipt sequence. Every appended receipt contains at least effect_receipt_id (unique to that revision), effect_receipt_seq, prev_effect_receipt_digest (null only at sequence 1), operation_id, effect_status ∈ {PENDING, CONFIRMED, PARTIAL, COMPENSATED, FAILED, UNKNOWN}, provider_reference (nullable), provider_receipt_digest (nullable), receipt_verification_status ∈ {VERIFIED, UNVERIFIED, NOT_AVAILABLE}, effect_started_ts, effect_completed_ts (nullable), tool_manifest_digest, ticket_id, ticket_hash, trace_id, a minimised effect_summary, compensation_receipt_id (nullable), and irreversible_elements[]. The transition from PREPARED to DISPATCHED atomically creates sequence 1 in PENDING before the transport write is attempted; a crash after that boundary is therefore reconciled as potentially dispatched rather than replayed. Later knowledge appends a new receipt and advances the operation record's latest-receipt reference; no receipt is overwritten.

For each revision, the versioned receipt schema defines effect_receipt_body by excluding only effect_receipt_digest and the transport-only fields that the schema enumerates; implementations may not choose exclusions ad hoc. Compute effect_receipt_digest = SHA-256(JCS({domain: "SRF-EFFECT-RECEIPT-v2", effect_receipt_body})); strings are UTF-8 and the stored value carries the sha256: prefix. Sequence gaps, duplicate sequence numbers, or previous-digest mismatches are reconciliation failures. A provider receipt is verified when the provider exposes a verifiable reference or signature. The local receipt records what is known; it does not imply that an irreversible effect was undone. TOOL_DEDUPE_HIT is emitted through the AD‑08 §4.23 event envelope and the FHR field dedupe_hit records the projection.

Operation/receipt consistency is closed:

Any unlisted pair is invalid and routes to reconciliation. PARTIAL always records the known irreversible_elements[] and either a pending/attempted compensation path or an explicit reason compensation is unavailable.

Plan freeze hash (TOCTOU guard)

• Compute at planning time the structured canonical object: plan_hash = SHA-256(JCS({domain: "SRF-PLAN-v2", ticket_hash, plan_inputs, policy_quorum_source_ids, constraints, principal_id, authorization_scope_ref, authz_decision_id, authz_policy_version, target_resource, allowed_operations, tool_manifest_digest})). Arrays preserve their declared semantic order; fields defined as sets are sorted by their schema before canonicalisation. Strings are UTF-8 and the stored value carries the sha256: prefix.
• Router re‑checks plan_hash at:
• pre‑commit;
• tool entry.
• If mismatch: raise TOCTOU_VIOLATION, cancel further dispatch, roll back uncommitted kernel-owned state, and reconcile any external effect already recorded as dispatched or later.
• Tool record stores {plan_hash, policy_quorum_id, tool_manifest_digest, authz_decision_id, gate_eval_record} to align forensics with the policy-source quorum (AD‑04). (gates_snapshot may appear as a compact projection of the gate_eval_record; see §4.2.)

Router & fencing

• Tools open only after a final gating pass and Action-Governance validation. Mid-turn policy updates, consent revocation, authorization changes, or new signals can veto and cancel in-flight calls (EHG‑γ behaviour). Cancellation halts further effects; already-completed external effects follow receipt-backed rollback, compensation, or irreversible-partial-effect handling.

3.6 Watchdog, latency discipline & streaming halts

AD‑18 wires the safety watchdog thread into TIG/RTS and FHR:

• Watchdog thread
• Independent low‑latency thread monitors stream cursor vs gate state.
• On gate trip or stall → pre‑empt emitter, cancel tools, set runtime_mode = degraded, record the degraded_reason_codes[] entry and halt_tokens_post_trip. The architecture profile remains mkp or full unless an explicit, separately logged profile change occurs.
• Logs: WATCHDOG_TRIP, watchdog_heartbeats, preempt_count.
• TIG/RTS constraints
• TIG enforces I(latency; sensitive_flag) ≤ ε; breach triggers HALT ≤ 5 tokens, rollback of uncommitted kernel-owned state, and receipt-backed reconciliation of any external effect.
• TIG/RTS fields: rts_mode, latency_bucket, mi_latency_content_est, tig_breach: bool, watchdog_trip: bool.
• FP control & user burden
• Hysteresis, tolerance bands and debounce in MPM/ERG ensure gates don't flap, so users don't get spammed with unnecessary interrupts.

Benchmarks and Grafana packs in AD‑12/AD‑08 complete the deployability story (latency vs throughput, halt distributions, watchdog health).

3.7 Precision drift SLO & CI hooks (shared with AD‑19)

Precision drift SLO and redline provenance span runtime and CI. AD‑19 is the home for CI semantics; AD‑18 ensures the runtime emits the necessary telemetry.

Precision parity SLO

• Per stratum band B on p95 Δ(fp16 ↔ fp8/int8) for Δ/PR/safety rates.
• CI redline: PRECISION_PARITY_REDLINE.
• Prod telemetry: precision_drift_delta, precision_slo_band.
• Breach: automatic serve‑block for that precision + recertification job.

Runtime responsibility (AD‑18): attach precision_drift_delta and precision_slo_band to relevant FHR events; CI semantics live in AD‑19.

Redline provenance

• Every CI failure or waiver carries redline_id and redline_source (dataset version, locale/register, split).
• Waivers in AD‑12 must reference redline_id; FHR logs WAIVER_APPLIED with linkage.

Again, AD‑18's role is to ensure these are plumbed through into FHR and runtime events.

3.8 Context length, long‑con budgets & acceptance tests

• Context bands: define explicit short/medium/long context‑length bands with distinct thresholds; as context approaches limit, system must fail upward into reflect‑only / ASK/SUMMARISE instead of silently truncating.
• Adversarial long‑con: track cumulative semantic delta per identity (session/user fingerprint) to detect slow‑boil jailbreaks and distributed attacks; wire that into Δ‑triad and ERG budgets.
• Acceptance tests:
• Tokeniser swap: Δ‑triad stability under tokeniser variants across five languages.
• End‑of‑context cliff: no silent failure near context limit; MRP issues ASK or SUMMARISE.
• Mid‑call veto: policy updated at t₀+Δ leads to EHG‑γ cancelling tools and logging partial effects.
• Quantised recert: Δ bands and challenge pass‑rates hold post‑quant.
• Rollback determinism: identical inputs produce identical MRP decisions across hardware targets (A100 vs H100).

AD‑18 owns the runtime wiring for these tests; AD‑19 + AD‑11 define how they appear in CI and replication bundles.

4. Declaration artefacts

AD‑18 owns the declaration artefacts that make consequential system actions accountable, evaluable, and auditable. These artefacts were developed as part of the PLG bridge‑card work (AD‑29 [PLG]) and are housed here because they belong to the runtime contract: AD‑18 validates and commits; these artefacts are what gets validated and committed.

The governing boundary statement: MRP decides whether and how the system may proceed. The Action Ticket defines what proceeding would concretely mean.

4.1 Action Ticket (declaration artefact)

The Action Ticket is the system's accountable statement of what would happen if it were allowed to act. It carries intent, immutable tool identity, actor and authorization, parameters, effects, jurisdiction, reversibility, consent freshness, minimum data handling, and execution-accounting state. Ambiguity in any field keeps the ticket INCOMPLETE and execution locked.

{
  "ticket_id": "T-2026-02-20-0001",
  "ticket_revision": 1,
  "ticket_hash": "sha256:...",
  "intent": {
    "verb": "CALL_TOOL | WRITE_STATE | TRIGGER_EXTERNAL_PROCESS",
    "goal": "User-stated goal, restated precisely",
    "success_criteria": ["Observable conditions that define 'done'"]
  },
  "tooling": {
    "tool_id": "string",
    "tool_manifest_id": "manifest_id",
    "tool_manifest_version": "semver",
    "tool_manifest_digest": "sha256:...",
    "idempotence_class": "IDEMPOTENT | NON_IDEMPOTENT",
    "side_effects": ["EXTERNAL_WRITE"],
    "abort_semantics": "declared behaviour on cancellation",
    "compensation_semantics": "declared compensating operation or NONE",
    "dry_run_supported": true,
    "rollback_available": true
  },
  "actor_authorization": {
    "principal_id": "opaque principal identifier",
    "principal_type": "user | service | operator | delegated_agent",
    "authorization_scope_ref": "versioned authorization scope",
    "target_resource": "minimised target identifier",
    "allowed_operations": ["exact operations authorized"],
    "authz_decision_id": "AUTHZ-...",
    "authz_policy_version": "semver or immutable policy digest",
    "authz_evaluated_ts": "ISO-8601",
    "authz_expires_ts": "2026-02-20T12:39:56Z"
  },
  "parameters": {
    "inputs": {},
    "bounds": {},
    "assumptions": ["Any assumption that would change meaning"]
  },
  "jurisdiction": {
    "user_locale": "string",
    "data_residency": "string",
    "strictness_profile": "DEFAULT_STRICT | ...",
    "uncertainties": ["Any unresolved jurisdictional scope"]
  },
  "reversibility": {
    "reversible": true,
    "rollback_available": true,
    "compensation_available": false,
    "irreversible_elements": ["List concrete irreversible effects"]
  },
  "consent": {
    "consent_state_id": "C-0007",
    "scope": ["What the user has explicitly permitted"],
    "scope_change_required": false,
    "confirmation_required": true,
    "revocation_checked_ts": "ISO-8601"
  },
  "data_handling": {
    "data_classes": ["declared input/output data classes"],
    "data_minimisation_basis": "why each class is necessary",
    "retention_profile_id": "RET-...",
    "erase_or_hold_behavior": "erasable | legal_hold_deferred | not_applicable"
  },
  "risk_notes": {
    "ethical_horizon_flags": [],
    "truth_uncertainty": "LOW | MED | HIGH",
    "drift_risk": "LOW | MED | HIGH",
    "load_risk": "LOW | MED | HIGH"
  },
  "pre_execution_checks": [
    "Last-moment validation steps immediately before tool call"
  ],
  "execution_accounting": {
    "operation_id": "OP-...",
    "dedupe_key": "caller-supplied stable key",
    "operation_state": "PREPARED",
    "effect_receipt_id": null,
    "effect_receipt_seq": null,
    "prev_effect_receipt_digest": null,
    "effect_receipt_digest": null
  },
  "status": "INCOMPLETE | READY_FOR_GATING | BLOCKED | EXECUTED"
}

Lifecycle: a ticket is created when a consequential action is identified. It remains INCOMPLETE until all required fields are populated with non‑ambiguous values. It transitions to READY_FOR_GATING when completeness criteria are met, then passes through the gate evaluation (§4.2) and Meta‑Resolution (§4.3) stages. Only a ticket that passes all gates and receives PERMIT may be EXECUTED. ticket_status = EXECUTED means that authorized dispatch crossed the commit boundary; it does not assert that the external effect completed successfully. operation_state, effect_status, and the receipt are authoritative for the effect outcome, including UNKNOWN or partial states. A user‑resolvable BLOCKED ticket may return to INCOMPLETE when the user revises scope or supplies required information. A hard G1/H1 block cannot be user‑overridden; it requires a materially safe scope revision or governance/human review, and remains BLOCKED otherwise.

Ticket identity and hash. ticket_id identifies the logical action and ticket_revision is a monotonically increasing integer. The versioned ticket schema defines ticket_body as ticket_id, ticket_revision, and the declaration fields (intent through pre_execution_checks); it excludes the derived lifecycle status, execution_accounting, ticket_hash, and only the transport fields that the schema enumerates. Implementations may not choose exclusions ad hoc. Compute ticket_hash = SHA-256(JCS({domain: "SRF-ACTION-TICKET-v2", ticket_body})); strings are UTF-8, schema-defined set-valued arrays are sorted before canonicalisation, and the stored value carries the sha256: prefix. Any change to a declaration field creates a new immutable revision and hash and invalidates prior gate evaluations, plan hash, preview/confirmation events, and authorization whose bound inputs changed. Status transitions and execution-accounting references are append-only records keyed by (ticket_id, ticket_revision, ticket_hash); the composite JSON above may project their latest values but never mutates the hashed declaration.

Invariant: no consequential action (external, persistent, or irreversible) may execute without a complete, gated Action Ticket. When side_effects != [NONE], the ticket is complete only if every Action-Governance Slice field is present, current, and internally consistent; the associated durable operation entry must be PREPARED, and execution must produce or reconcile an external-effect receipt.

4.2 Gate Evaluation Record (canonical per‑ring structure)

The Gate Evaluation Record is the canonical structured object for per‑ring evaluation state. It supersedes the earlier informal gates_snapshot and provides the structured per‑ring visibility required for tool entry forensics, contestability, MRP branch reconstruction, duty/legal audit, per‑ring threshold provenance, and cultural/care/SPD interactions.

gates_snapshot is retained as a legacy shorthand: the compact projection of the full gate evaluation record. Existing references to gates_snapshot throughout the pack remain valid as references to this compact projection.

Per‑ring entry structure:

{
  "ring_id": "SIF | EHG | ODS | RCL | ERG",
  "scope_ref": "scope identifier shared with gate_events[]/gate_decisions[]",
  "state": "PASS | TIGHTEN | FAIL",
  "threshold_id": "string (references AD-16 operating point)",
  "metric_values": {},
  "trigger_reason": "string | null",
  "timestamp": "ISO-8601",
  "confidence": "HIGH | MED | LOW",
  "action_recommendation": "PROCEED | ASK_FIRST | HOLD | REFUSE"
}

Top‑level envelope:

{
  "ticket_id": "T-2026-02-20-0001",
  "mrp_input_id": "string (links to MRP evaluation cycle)",
  "scope_ref": "action or response scope this evaluation binds",
  "kernel_profile": "full",
  "runtime_mode": "normal",
  "active_ring_ids": ["SIF", "EHG", "ODS", "RCL", "ERG"],
  "rings": [
    { "ring_id": "SIF", "state": "PASS", "..." : "..." },
    { "ring_id": "EHG", "state": "PASS", "..." : "..." },
    { "ring_id": "ODS", "state": "TIGHTEN", "..." : "..." },
    { "ring_id": "RCL", "state": "PASS", "..." : "..." },
    { "ring_id": "ERG", "state": "PASS", "..." : "..." }
  ],
  "precedence_path": ["ring_ids in order of precedence that shaped the decision"],
  "effective_decision": "PASS | TIGHTEN | FAIL",
  "snapshot_hash": "sha256:..."
}

rings[] contains exactly one entry for every active_ring_ids[] member and no undeclared ring. Every entry carries the envelope's scope_ref; mixed-scope turns therefore emit distinct gate-evaluation records rather than collapsing incompatible scope decisions. The active set must contain the profile-required rings; an unavailable required ring emits a FAIL with an availability reason and blocks commit rather than disappearing. Rings outside the declared profile are omitted as inapplicable, not unknown.

ERG-ε remains pace-only: its TIGHTEN recommendation may alter cadence but cannot weaken or override another ring. For ERG, FAIL is reserved for an availability or integrity failure in a declared full profile; such failure blocks that profile's commit contract, but it is not a substantive content veto and cannot be used to reverse another ring's decision.

The snapshot_hash enables forensic reconstruction. The schema-defined gate_eval_body is the complete Gate Evaluation Record excluding only snapshot_hash; compute snapshot_hash = SHA-256(JCS({domain: "SRF-GATE-EVAL-v2", gate_eval_body})), using UTF-8 strings and the sha256: stored-value prefix. Any gate_eval_record can therefore be verified against its hash, which is carried forward into FHR, tool records, and the evidentiary chain (AD‑21 [RM]).

Integration with existing gates_snapshot references:

• Where gates_snapshot appears in tool records, FHR fields, or other cards, it refers to a compact projection: the top‑level effective_decision, the per‑ring state values, and the snapshot_hash. The full gate_eval_record is available via hash lookup for forensic, audit, and contestability purposes.
• AD‑08 [SO] registers both gate_eval_record (full) and gates_snapshot (compact projection) in the field registry.

4.3 Meta‑Resolution outcome object (closed set)

The Meta‑Resolution outcome captures the final arbitration result after gate evaluation: what the system resolved to do, through which precedence path, and what the user sees next. This is the structured companion to AD‑05 [MRP]'s per‑turn MRP state transitions; it bundles the resolution into a single auditable object.

{
  "resolution": {
    "outcome": "CLARIFY_MINIMAL | NARROW_SCOPE | PRESENT_BOUNDED_OPTIONS | REFUSE | TERMINATE | PERMIT",
    "precedence_path": ["ring_ids or tier_ids that determined outcome"],
    "ticket_id": null,
    "next_user_surface": null,
    "trace_id": "TRACE-abc123"
  }
}

The outcome set is closed: only these six values are valid. This constrains the resolution space and makes audit deterministic.

ESCALATE is not a seventh outcome. It is AD‑05 [MRP]'s intermediate HOLD-plus-handoff state: invoke AD‑12 [OP], emit no resolution object while the handoff is pending, then emit the resolved outcome if work continues or TERMINATE if the handoff closes the turn/session.

Relationship to mpm_decision — the routing decision defined by AD‑05 [MRP] and registered in AD‑08 [SO] §4.3: the outcome object and mpm_decision are complementary records of the same resolution. mpm_decision logs the routing intervention, where one occurred; the outcome object logs the resolution content. Correspondence:

mpm_decision is intervention‑only by construction; a PERMIT emission carries the field absent or null, and the coverage invariant (AD‑08 §5) treats explicit null as populated for §4.3 purposes. mpm_decision is distinct from mpm_decision_id, AD‑05's per‑decision row identifier; the names are confusable and the fields unrelated. precedence_path expands mpm_priority_tier + mpm_reason_codes into explicit per‑ring attribution; trace_id links to the FHR row. next_user_surface is nullable (null = standard response); ticket_id is nullable where no Action Ticket was required; the flat registry fields are 1:1 projections of the nested §4.3 resolution object.

4.4 MRP reduced interface derivation

AD‑05 [MRP] §2.1 consumes Action Ticket state through a reduced interface. The mapping from the full Action Ticket schema (§4.1) to the reduced interface is:

MRP uses this reduced interface to decide whether to enter DECIDE: if ticket_completeness ≠ COMPLETE, or preview_required = TRUE and preview not yet shown, or confirmation_required = TRUE and confirmation not yet received, MRP stays in HOLD or OPTIONS.

5. Artefacts & FHR fields (AD‑18 slice)

AD‑18's requirements on the FHR schema (AD‑08) are the subset that make the runtime contract observable:

Core + locale

• event_id, ts, session_id
• model_version, precision_tag, tokenizer_id, sampling_profile_id
• locale_id, register_id, dialect_id, script_variant_id

Routing & runtime

• mpm_decision ∈ {tighten, ask_first, present_options, refuse, rollback}
• kernel_profile ∈ {mkp, full}, runtime_mode ∈ {normal, degraded}, active_ring_ids[], degraded_reason_codes[]
• gate_eval_record (canonical; see §4.2)
• gates_snapshot (compact projection of gate_eval_record)
• triad_branch_id, spd_branch_id
• op_point_id, timing_op_point_id
• commit_watermark, prev_watermark, replay_detected

Action Ticket & resolution

• ticket_id, ticket_revision, ticket_hash, ticket_status
• ticket_completeness, preview_required, confirmation_required, irreversibility_class (MRP reduced interface; see §4.4)
• principal_id, principal_type, authorization_scope_ref, target_resource, allowed_operations[], authz_decision_id, authz_policy_version, authz_evaluated_ts, authz_expires_ts
• tool_manifest_id, tool_manifest_version, tool_manifest_digest
• consent_state_id, consent_scope[], consent_revocation_checked_ts
• data_classes[], data_minimisation_basis, retention_profile_id, erase_or_hold_behavior
• resolution_outcome, resolution_precedence_path, resolution_trace_id (from Meta‑Resolution outcome object; see §4.3)

Δ‑triad & drift

• delta_p_norm, delta_embed, delta_tools, delta_mi_excess
• (where relevant) precision_drift_delta, precision_slo_band

Tool & plan forensics

• request_id, dedupe_key, dedupe_hit
• plan_hash, policy_quorum_id, policy_quorum_source_ids[] (policy-source quorum from AD‑04)
• operation_id, operation_state, effect_receipt_id, effect_receipt_seq, prev_effect_receipt_digest, effect_receipt_digest, effect_status, provider_reference, provider_receipt_digest, receipt_verification_status, effect_started_ts, effect_completed_ts, effect_summary, compensation_receipt_id, irreversible_elements[]
• gate_eval_record at tool entry (per §4.2; compact projection stored as gates_snapshot in tool record schema)

Watchdog / timing

• rts_mode, latency_bucket, mi_latency_content_est, tig_breach, watchdog_trip
• halt_tokens_post_trip, watchdog_heartbeats, preempt_count

CI / redlines (runtime footprint)

• redline_id, redline_source
• WAIVER_APPLIED events with linkage (semantics expanded in AD‑12/AD‑19).

6. Interfaces & cross‑links

• AD‑16 [ME] — defines SESOI, Δ‑bands, op‑points, and measurement mode; AD‑18 ensures these manifest as baselines and op_point IDs at runtime.
• AD‑08 [SO] — provides the FHR schema into which AD‑18 injects commit_watermark, gate_eval_record, gates_snapshot (compact projection), watchdog fields, tool dedupe, precision drift, Action Ticket fields, and resolution outcome fields.
• AD‑04 [TG] — policy quorum identity/source set and scoped gate decisions are bound into plan_hash and gate_eval_record.
• AD‑06 [DG] — Δ‑triad and drift signals shape ticket constraints and are recorded beside the gate evaluation.
• AD‑05 [MRP] — consumes Action Ticket state through the reduced interface (§4.4); MRP state transitions are the complement of the Meta‑Resolution outcome object (§4.3). See AD‑05 §2.1.
• AD‑12 [OP] — replay, rollback, drift, and waiver runbooks rely on AD‑18's forensics & redline fields.
• AD‑14 [DS] — Action Preview Card (AD‑14 §4b) is triggered by the Action Ticket's preview_required field; Refusal Cards are triggered by gate evaluation FAIL outcomes.
• AD‑19 [CI] — houses Δ‑triad CI, parity gates, SLOs and redlines, using AD‑18's runtime telemetry as ground truth.
• AD‑11 [RA] — replication modalities R1–R3 replay AD‑18's runtime contract deterministically across seeds, precisions and locales.
• AD‑21 [RM] — evidentiary chain anchors snapshot_hash from gate evaluation records and ticket_hash from Action Tickets.
• AD‑20 [DP] — defines full-profile data-protection and retention semantics; AD‑18 imports only the minimum data-handling declaration needed by the cross-profile Action-Governance Slice.
• AD‑29 [PLG] — PLG routes through Action Tickets when MVP/AIR/ARR signals trigger gating; PLG's applied Δ‑triad monitoring consumes gate evaluation records.

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

You can claim AD‑18 [SE] is live if:

1. Per‑locale/register/context‑band baselines are stamped in FHR, with baseline_quality set to low when back‑off to global is used.
2. Every event carries model_version, precision_tag, tokenizer_id, sampling_profile_id.
3. TURN‑ACID is enforced: kernel‑owned state, ledger, and FHR commit atomically; external effects follow declared rollback, compensation, or irreversible‑effect recording semantics.
4. Tools bind immutable manifests and principal authorization, declare idempotence/side-effects/abort/compensation/dry-run/rollback semantics, and echo request_id + dedupe_key.
5. The watchdog enforces halt within ≤ 5 tokens on breach; a dedicated watchdog thread enforces this even if the main eval loop stalls.
6. gate_eval_record at tool entry is frozen for forensics (legacy alias: gates_snapshot is the compact projection).
7. The acceptance tests pass: tokeniser swap, context‑cliff, mid‑call veto, quantised recert, rollback determinism.
8. The Action Ticket schema is enforced for all consequential actions; ambiguity in any ticket field keeps the ticket INCOMPLETE and execution locked. Actions with side_effects != [NONE] satisfy the complete Action-Governance Slice.
9. A Gate Evaluation Record is emitted for every ring in active_ring_ids[] per gating pass, and the active set satisfies the declared kernel_profile (§4.2).
10. Durable operation-ledger and effect-receipt states reconcile cleanly after duplicate requests and crash recovery; UNKNOWN never auto-replays.

Back‑references:

• AD‑05 [MRP] (MRP consumes ticket state through reduced interface; see AD‑05 §2.1 and §4.4 above).
• AD‑29 [PLG] (Action Ticket schema, Gate Evaluation Record, and Meta‑Resolution outcome object originated in PLG bridge‑card work and are housed here as runtime declaration artefacts).

MKP view: the normative MKP definition is FM‑02 (MKP Quickstart). AD‑18's cross-profile slice — TURN‑ACID, tool fencing, and the Action-Governance requirements for any action with side_effects != [NONE] — binds in every profile per Quickstart test item 6.