AD‑08 [SO] — System Observability & Field Health Report Schema

Aliases: None Cluster: Kernel (base) Depends on: AD‑01 [OV]

0. For humans

What question does this answer?

"For any given turn, can I see what the kernel did, why it did it, and under which constraints — in a way that stands up to HCI, safety, security, and legal audit?"

How do I know it's live?

You should be able to:

• Pull a single FHR row for any incident or test scenario and see: routing + gate state, timing/covert‑channel fields, security/exfil summary, UX and culture metrics, care and energy fields, legal/duty context.
• See all rows validate against one versioned schema.
• Confirm that CI runs can be replayed against FHR exports.

Where do I see it?

• Dashboards: FHR explorer, timing panel, halt panel, care panel, culture panel, parity/CI panel.
• FHR / logs: every field listed in §4 below.
• RA / audit: FHR exports as JSON/Parquet, hash-anchored via EVID_CHAIN (AD‑21 [RM]).

Quick checklist

• Implemented if: real traffic produces FHR rows with stable schema; CI runs replay against them; core sections populated on every MRP-routed turn.
• Key artefacts: FHR JSON schema (versioned), dashboard configurations.
• Key FHR fields: §4 is the canonical top-level registry; §4.23 is the canonical envelope for versioned card-owned event payloads.
• Key failure codes: schema validation failures, missing core sections.
• Escalation path: schema violations → AD‑12 [OP] incident → AD‑19 [CI] release gate.

1. Purpose & scope

AD‑08 [SO] defines:

1. The Field Health Report (FHR) schema: the single, versioned schema that all kernel telemetry validates against.
2. Coverage invariants: which fields must be populated on which turns.
3. Security / timing / UX visibility requirements: what must be observable when specific subsystems trigger.
4. MKP view: which schema sections are mandatory vs optional in Minimal Kernel Profile.

AD‑08 is the schema host. Other cards define field semantics; AD‑08 carries the canonical schema definition and ensures structural integrity of the telemetry surface.

2. Schema principles

• Single schema. All FHR rows validate against one versioned top-level schema. Component events use the one normative envelope in §4.23 and a versioned payload schema owned by the defining card; unversioned or ad-hoc event objects are invalid.
• Non‑weakening. AD‑08 never relaxes gates or policies. It only observes. It may reveal mis-configurations but cannot silence them.
• Namespaced extensibility. Deployments may add vendor‑specific fields under a namespaced prefix, as long as core sections are intact.

3. Schema version

The current schema version is FHR v2.0, aligned with the SRF v2.0 addenda pack. Schema version is stamped in every FHR row.

4. Field registry

This registry enumerates every canonical top-level FHR field. Card-specific events are represented through the closed event envelope in §4.23; fields inside its versioned payload are not additional top-level FHR fields. A deployment may materialise the registry as nested objects or flat columns, but the names, types, null behaviour, and 1:1 projections defined here remain canonical.

4.1 Core

• event_id, ts, trace_id, model_id, policy_id, schema_version
• session_id, turn_id, user_id (opaque)

4.1b Serving identity

• model_version, precision_tag (registered here; model_id is registered with the core fields in §4.1 and completes the group)
• Semantics, pinned: model_id — which model; model_version — which checkpoint or weight revision is serving; precision_tag — which serving precision (quantisation / dtype profile). A weight change moves model_version, a precision change moves precision_tag; neither is derivable from model_id.
• Parity family: this group plus tokenizer_id (§4.5, resident with its measurement kin) forms the instrument identity that AD‑18 [SE]'s parity invariant and the Conformance Table's recertification triggers key on.
• Precision parity and redline provenance: precision_drift_delta, precision_slo_band, redline_id, redline_source, waiver_applied

4.2 Locale & culture

• culture_pack_id, community_pack_id, overlay_ids[], locale_id, script_id, script_variant_id, register_id, dialect_id
• code_switch_events (count/flags)
• Cultural metrics: crr_adj, indirection_score, honorific_class, deference_score, awe_low_variance_flag
• Norm provenance: norm_quorum_source_ids, norm_quorum_confidence, effective_jurisdiction, juris_conflict_resolved, juris_conflict_rationale
• Audit: culture_audit_id, culture_pack_version (semver), anchor_family_id values for challenge strata
• Dissent/motif audit: unassimilated_motif_count (non-negative integer), dissent_weights[] (versioned records carrying dimension_type, dimension_id, and weight in [0,1]; AD‑26 owns any additional dimensions)

4.3 Routing & gates

• mpm_decision ∈ {tighten, ask_first, present_options, refuse, rollback} — the routing decision defined by AD‑05 [MRP], registered here; intervention‑only: populated where a routing intervention occurred, absent or explicitly null on PERMIT. Registered alongside: gate_events[] (per‑gate evaluations, AD‑04) and gate_decisions[] (its decision‑only projection, AD‑05 and the annex); each entry carries scope_ref identifying the action scope the decision binds (scoped precedence, AD‑04 §3.2); the per‑ring family is gate_eval_record with compact projection gates_snapshot (AD‑18 §4.2). Distinct from mpm_decision_id (§4.4), AD‑05's per‑decision row identifier.
• gate_eval_record (canonical per‑ring evaluation structure; defined in AD‑18 [SE] §4.2)
• gates_snapshot (compact projection of gate_eval_record: per‑ring states + effective decision + snapshot hash; retained as legacy shorthand)
• triad_branch_id, spd_branch_id
• op_point_id, timing_op_point_id
• commit_watermark, prev_watermark, replay_detected
• Gate events: gate_id, g_class, horizon, decision, contestable, policy_source_ids[], cpl_entry_id
• Gate aggregates: gate_decision_counts{}, gate_refusal_rate, gate_contest_count, gate_appeal_count, gate_appeal_upheld_rate

4.4 MRP state

• mrp_state_before, mrp_state_after, mrp_state_seq[], mrp_turn_index
• mpm_decision_id, mpm_priority_tier, mpm_reason_codes[]
• mrp_state_counts{}, mrp_loops_detected, mrp_exit_reason

4.5 Δ‑triad & drift

• delta_p_norm, delta_embed, delta_tools, delta_mi_excess
• triad_branch_id, mi_upgrade
• Band counts: delta_p_norm_band_counts{}, delta_embed_band_counts{}, delta_tools_band_counts{}
• Drift flags: drift_incidents_count, drift_resolved_in_session_count, drift_unresolved_count
• Measurement instruments: tokenizer_id, tokenizer_family, sampling_profile_id, context_band, delta_p_norm (length‑normalised), nli_label, sts_score, nli_model_id, sts_model_id
• MI / coupling: delta_mi, mi_delta_p_embed, delta_unique_p, delta_unique_embed, mi_method_id, mi_K, shuffle_K, mi_shuffle_ci_lo, mi_shuffle_ci_hi
• Multilingual: delta_p_trans, bt_stability, bt_method_id
• Morphology: delta_char_js, delta_morph, morph_method_id
• Calibration: roc_op_id, roc_fp_rate, roc_fn_rate, calibration_pack_id, decision_cost_id
• Acceptance-matrix linkage (AD‑17 [AM]): acceptance_matrix_row_id, acceptance_status ∈ {PROPOSED, UNDER_REVIEW, ADOPTED, HELD, REJECTED, DEMOTED}, acceptance_status_reason

4.6 SPD

• spd_mode ∈ {SPD0_neutral, SPD1_light, SPD2_narrative, …}
• spd_tightened: bool, spd_tighten_reason[]
• rhetorical_amp_band ∈ {low, medium, high}
• persona_id, persona_lock_reason
• discourse_story_depth, metaphor_density_band
• Awe/deference flags: awe_frame_active, awe_upgrade_blocked_deference
• SPD clarifier and FP metrics: spd_clarifier_count, spd_fp_rate

4.7 HCI / UX extensions

• primer_seen, primer_completed
• Action Trace: trace_len (non-negative integer), trace_ts[], trace_steps[], trace_gate_ids[]
• Context controls: context_thresholds with numeric warn and force_pin satisfying 0 ≤ warn < force_pin ≤ 1; context_warn_ts, pin_force_review_ts, compress_offers, compress_accepts
• Interaction controls: api_toggles_used[], scope_pinning_tile_invoked, plg_tile_restriction_count
• Attunement/Null analytics: attunement_preset ∈ {safe, balanced, expressive}, attunement_auto_safe_count, null_choice_rate (object with clarify, summarise, exit rates), null_reentry_rate
• ux_refusal_ack_ms_p50, ux_refusal_ack_ms_p95
• ux_refusal_comprehension_rate
• ux_action_preview_ack_ms_p50, ux_action_preview_ack_ms_p95
• ux_action_preview_rejection_rate, ux_action_preview_detail_rate
• ux_toggle_adopt_rate, ux_toggle_revert_rate
• ux_find_mode_steps_p95
• ux_error_recovery_rate
• ux_a11y_mode_active
• pin_review_rate, pin_force_rate

4.7a Measurement/reporting metadata (AD‑16 [ME])

• metric_denominators{} — map from metric identifier to non-negative integer denominator
• metric_missingness_codes{} — map from metric identifier to one or more of {M1, M2, M3, M4}; metric_missingness_mechanisms{} uses {MCAR, MAR, MNAR, UNKNOWN}
• Uncertainty: metric_ci_lo{}, metric_ci_hi{}, metric_ci_level{} keyed by metric identifier; every populated interval satisfies lo ≤ hi and declares its level
• Sensitivity/time series: metric_sensitivity_bound_lo{}, metric_sensitivity_bound_hi{}, metric_time_series_model_ids{}, metric_residual_diagnostic_ids[], entropy_slope, pr_score
• Operator/rater variance: operator_variance_between, operator_variance_within, rater_kappa, rater_bias_est

4.8 Care & energy

• care_mode, care_override, care_cooloff_ok, pause_referral, decide_first_active
• decide_first_time_to_resolution_p50
• Events (UPPER_CASE per FRONT_MATTER_00 §7): CARE_FATIGUE_PROMPT, CARE_OVERRIDE, PAUSE_REFERRAL
• cooloff_active, cooloff_reason, cooloff_elapsed_ms
• ack_hold_ts, burden_symmetry_applied
• equity_opt_in, slices[], dvi_by_slice, dissent_rate_by_slice
• CRO_INVOCATION, cro_reason, risk_doctrine_id
• Energy: E_session (or E), E_turn, energy_kwh_est, co2_kg_est, co2_ci_band, co2_method_id, co2_coeff_version, grid_intensity_source_id
• Closure: closure_budget_spec, budget_breach_count, budget_breach_last_reason

4.9 Legal & duties

• jurisdiction_profile_id, effective_jurisdiction
• Retention and channel: channel ∈ {OC, PC}, ttl_days, pc_retention_days, retention_profile_id, privacy_grade ∈ {MINIMISED, REDACTED, FULL_INTERNAL}
• Erasure: erase_scope, erase_requester, erase_completed_ts
• Policy provenance: policy_version, policy_quorum_id, policy_quorum_source_ids[]
• Duty and regulatory state: duty_ledger_id, harm_triage_id, udr_id, regulatory_mode ∈ {off, on}, regulatory_profile_id, breach_notif_sent, breach_notif_ts, appeal_id, appeal_sla, appeal_open_ts, appeal_resolved_ts, appeal_outcome
• Evidentiary chain: evid_chain_batch_id, evid_chain_stream_id, evid_chain_anchor_id (nullable until batch close), evid_chain_proof_ref (nullable until 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
• analytics_opt_in

4.10 Timing & covert‑channel

• rts_mode, streaming_mode, release_interval_ms
• latency_bucket, latency_bucket_hist
• latency_chi2_p, mi_latency_content_est
• etg_active, tig_breach, watchdog_trip
• timing_op_point_id, mi_method_id
• timing_incidents[], failure_codes[]
• Optional: halt_tokens_post_trip, halt_latency_ms
• Watchdog health: watchdog_heartbeats, preempt_count
• Timing sensitivity (AD‑10 [TC] revision): timing_sensitivity_profile, timing_fp_budget, timing_fp_suspected, timing_interrupt_count, timing_interrupt_recovery_ms

4.11 Security / exfil, architecture profile & runtime mode

• kernel_profile ∈ {mkp, full} — adopted architecture profile, not runtime health
• runtime_mode ∈ {normal, degraded}
• active_ring_ids[], degraded_reason_codes[]
• iig_alerts, des_alerts, honeytoken_hits, orphan_outputs
• degraded_minutes, degraded_minutes_timing
• ensemble_disagreements
• PR_current, PR_7day_slope, anchor_pass_rate
• MPM_ethics_over_attunement_ratio
• failure_codes[]

4.12 Awe & deference (AD‑28 [AF])

• awe_class ∈ {insight, overwhelm, relief, confusion, ambivalent}
• awe_low_variance: bool
• dmi_state ∈ {unknown, provisional, adopted, contradicted}, dmi_target_id, dmi_evidence_refs[]
• resonance_index, ri_stability_flag, ri_window_turns, ri_baseline_id
• deference_score, awe_promotion_allowed, awe_promotion_blocked_reason
• Cross-cultural validation: af_validation_profile_id, af_cross_cultural_pass, af_abstention_mode, af_abstention_reason

4.12a Minimal multimodal research fields (AD‑13 [MM])

• Consent/baseline: bio_opt_in: bool, bio_sensors[], bio_baseline_secs, bio_reliable_from_ts, bio_state ∈ {off, baseline_pending, reliable, low_confidence, cold_start}, bio_ttl_hours, last_bio_erase_ts
• Windowing: taw_mode ∈ {fixed, resp_adaptive}, affect_window_s
• Containment-only outputs: overwhelm_flag, cooloff_required, cooloff_ok_ts; the shared awe_class field in §4.12 is nullable and carries the relevant ambivalent / insight classification rather than a second multimodal-only awe label
• Exploratory study outputs: nbai, nbai_ci, nbai_window

4.13 Clinical & cognitive (AD‑24 [CC])

• CLB_profile_id, CLB_decision, clb_reason_codes[], clb_domain_tags[]
• RLD_score, RLD_band, RLD_action
• AE_EVENT, ae_type, trigger_pattern_id, erg_snapshot, rld_snapshot
• CRISIS_HEURISTIC_HIT, crisis_category, crisis_response

4.14 Projection & Loop Guard (AD‑29 [PLG])

• plg_state ∈ {off, watch, active}
• prompt_template_id (nullable)
• spiral_risk_score, authority_inflation_rate, agreement_reinforcement_ratio
• plg_actions_taken[]
• scope_adjacent_score, scope_adjacent_policy_id, scope_adjacent_action ∈ {none, ask_first, pin_review, present_options}

4.15 Action Ticket & resolution (AD‑18 [SE])

• ticket_id (nullable where no Action Ticket was required), ticket_revision, ticket_hash, ticket_status ∈ {INCOMPLETE, READY_FOR_GATING, BLOCKED, EXECUTED}; ticket_hash is the domain-separated canonical declaration hash defined by AD‑18 [SE] §4.1; EXECUTED records authorized dispatch across the commit boundary, not successful external completion, which is carried by operation_state / effect_status
• ticket_completeness ∈ {EMPTY, PARTIAL, COMPLETE}
• preview_required: bool, confirmation_required: bool
• irreversibility_class ∈ {REVERSIBLE, COMPENSABLE, IRREVERSIBLE}
• Actor and authorization: principal_id (opaque), principal_type ∈ {user, service, operator, delegated_agent}, authorization_scope_ref, target_resource, allowed_operations[], authz_decision_id, authz_policy_version, authz_evaluated_ts, authz_expires_ts. For side_effects != [NONE], expiry is required and later than the final dispatch check; null is permitted only for explicitly non-expiring [NONE] verification-class work.
• Manifest binding: tool_manifest_id, tool_manifest_version, tool_manifest_digest
• Action data handling: data_classes[], data_minimisation_basis, erase_or_hold_behavior ∈ {erasable, legal_hold_deferred, not_applicable}; retention_profile_id is registered in §4.9
• Consent freshness: consent_state_id, consent_scope[], consent_revocation_checked_ts
• resolution_outcome ∈ {CLARIFY_MINIMAL, NARROW_SCOPE, PRESENT_BOUNDED_OPTIONS, REFUSE, TERMINATE, PERMIT}
• resolution_precedence_path[], resolution_trace_id, resolution_ticket_id (nullable), resolution_next_user_surface (nullable; null means the standard response surface)

4.15a Tool operation & external-effect accounting (AD‑18 [SE])

• Request and dedupe: request_id, dedupe_key, dedupe_hit, plan_hash
• Durable operation ledger: operation_id, operation_state ∈ {PREPARED, DISPATCHED, ACKNOWLEDGED, COMPLETED, COMPENSATED, FAILED, UNKNOWN}
• Effect receipt: effect_receipt_id, effect_receipt_seq, prev_effect_receipt_digest, effect_receipt_digest, 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), effect_summary, compensation_receipt_id (nullable), irreversible_elements[]; the digest and append-only revision semantics are defined by AD‑18 [SE] §3.5
• Join fields: ticket_id, trace_id, tool_manifest_digest, principal_id, and dedupe_key bind the receipt to the authorized declaration and authoritative idempotency key.
• The operation_state / effect_status pair validates against the closed consistency relation in AD‑18 [SE] §3.5; an unlisted pair is a schema failure and routes to reconciliation.

4.16 Group SRF (AD‑02 [GS])

• group_mode, group_participants[], group_facilitator_id
• group_turns_per_participant{}, group_tokens_per_participant{}
• group_decisions_count, group_decisions_with_dissent_count
• dissent_total, dissent_open, dissent_ack, dissent_addr
• dvi_ack_rate, dvi_addr_rate, dvi_residual
• turn_ratio_max_min, silent_participant_count
• Asymmetric depth: group_depth_profile, asymmetry_guard_applied, continuity_disclosure_shown, established_participant_disclosure_consent

4.17 Post‑session harm feedback (AD‑22 [EC] revision)

• post_session_effect ∈ {helpful, neutral, harmful, unsure}
• harm_despite_procedure_flag: bool
• followup_requested: bool
• post_session_review_opened: bool
• harm_despite_procedure_repeated: bool

4.18 Session continuity & memory governance (AD‑30 [SC])

• continuity_mode ∈ {stateless, session_only, continuity_light, continuity_full}
• memory_class, memory_write_event, memory_erase_event
• memory_write_blocked (with reason code: ae_active, care_override, crisis, high_resonance_no_reflection, legal_hold)
• relational_memory_write_confirmed: bool
• continuity_drift_score, continuity_baseline_id
• Drift decomposition: attunement_drift, semantic_drift, safety_drift
• Drift responses: continuity_check_prompted, continuity_rebaseline_required
• model_change_detected, model_change_notice_shown
• reattune_required, reattune_completed, reattune_quality_score, reattune_checkpoint_turn, reattune_turns_to_baseline

4.19 Human‑side integrity (AD‑31 [HS])

• primer_completed: bool
• human_integrity_check_offered, integrity_prompt_accepted, integrity_prompt_declined
• human_mode ∈ {normal, fatigued_prompted, decide_first_human, break_taken}
• friction_protocol_applied, friction_protocol_source ∈ {system_offered, human_initiated}
• integrity_interruption_type ∈ {pause, scope_narrow, decide_first_switch, break, session_end}
• reentry_confirmed, reentry_depth_level, reentry_turns_to_prior_depth

4.20 Pack governance (AD‑32 [PG])

• pack_author_role, pack_reviewer_ids[], pack_review_date, pack_expiry_date
• source_diversity_score, source_ids[], source_types[]
• pack_scope_note
• pack_challenge_event, pack_challenge_status, pack_challenge_resolution_days, pack_version_incremented

4.21 Challenge suite (AD‑03 [CS])

• challenge_suite_id, challenge_pack_id, challenge_domain, challenge_subdomain
• challenge_locale, challenge_register
• challenge_count_total, challenge_count_passed, challenge_count_refused_correctly, challenge_count_refused_incorrectly, challenge_count_missed_refusal
• challenge_pass_rate, challenge_pr_offered, challenge_pr_passed, challenge_coverage_rate

4.22 Ops / replication / scenario linkage

• scenario_id (e.g. SCN‑RC‑01, SCN‑TRC‑01), replication_kit_id, ra_report_id
• RA outcome: ra_modality ∈ {R1_deterministic_replay, R2_cross_model_precision, R3_locale_register}, ra_result ∈ {PASS, FAIL, INCONCLUSIVE}, drift_report_id (nullable on PASS), redline_id (nullable where no redline fired)
• Challenge coverage / anchor KPIs (exposed via PR and anchor_pass_rate)

4.23 Normative event envelope

Every event named anywhere in the pack — including gate, preview/confirmation, erase, duty, CI, watchdog, care, continuity, and runbook events — is emitted through this envelope:

{
  "event_type": "UPPER_CASE_EVENT_NAME",
  "event_schema_id": "owner-card/event-name",
  "event_schema_version": "semver",
  "event_ts": "ISO-8601",
  "trace_id": "TRACE-...",
  "payload": {}
}

The defining card owns and versions the payload schema. Payload fields shown in card examples or the Worked Scenarios are illustrative only until the owner-card schema makes them normative; they must not be promoted silently into top-level FHR fields. event_type, schema identity/version, timestamp, and trace_id are mandatory. A payload that cannot be validated against the named version is a schema failure.

4a. Per‑decision emission template

The field registry (§4) enumerates every top-level field and the normative event envelope. This section shows how fields compose into a single per-decision FHR record — the concrete JSON object emitted whenever the kernel makes a consequential decision. This is the structural template; not every field is populated on every emission (coverage invariants in §5 specify which fields are mandatory in which contexts).

{
  "event_id": "FHR-2026-02-20-0042",
  "trace_id": "TRACE-abc123",
  "ts": "2026-02-20T12:34:56Z",
  "model_id": "string",
  "policy_id": "string",
  "schema_version": "FHR v2.0",
  "kernel_profile": "mkp | full",
  "runtime_mode": "normal | degraded",
  "active_ring_ids": ["SIF", "EHG", "ODS"],
  "degraded_reason_codes": [],
  "ticket_id": null,
  "ticket_revision": null,
  "ticket_hash": null,
  "ticket_status": null,
  "ticket_completeness": null,
  "preview_required": null,
  "confirmation_required": null,
  "irreversibility_class": null,
  "principal_id": null,
  "principal_type": null,
  "authorization_scope_ref": null,
  "target_resource": null,
  "allowed_operations": [],
  "authz_decision_id": null,
  "authz_policy_version": null,
  "authz_evaluated_ts": null,
  "authz_expires_ts": null,
  "tool_manifest_id": null,
  "tool_manifest_version": null,
  "tool_manifest_digest": null,
  "consent_state_id": null,
  "consent_scope": [],
  "consent_revocation_checked_ts": null,
  "data_classes": [],
  "data_minimisation_basis": null,
  "retention_profile_id": null,
  "erase_or_hold_behavior": null,
  "request_id": null,
  "dedupe_key": null,
  "dedupe_hit": false,
  "plan_hash": null,
  "operation_id": null,
  "operation_state": null,
  "effect_receipt_id": null,
  "effect_receipt_seq": null,
  "prev_effect_receipt_digest": null,
  "effect_receipt_digest": null,
  "effect_status": null,
  "provider_reference": null,
  "provider_receipt_digest": null,
  "receipt_verification_status": null,
  "effect_started_ts": null,
  "effect_completed_ts": null,
  "effect_summary": null,
  "compensation_receipt_id": null,
  "irreversible_elements": [],
  "gate_eval_record": {
    "ticket_id": "T-...",
    "mrp_input_id": "string",
    "scope_ref": "scope:current-decision",
    "kernel_profile": "mkp",
    "runtime_mode": "normal",
    "active_ring_ids": ["SIF", "EHG", "ODS"],
    "rings": [
      { "ring_id": "SIF", "scope_ref": "scope:current-decision", "state": "PASS", "threshold_id": "...", "metric_values": {}, "trigger_reason": null, "timestamp": "...", "confidence": "HIGH", "action_recommendation": "PROCEED" }
    ],
    "precedence_path": [],
    "effective_decision": "PASS",
    "snapshot_hash": "sha256:..."
  },
  "gates_snapshot": "compact projection: { effective_decision, per-ring states, snapshot_hash }",
  "resolution_precedence_path": [],
  "resolution_outcome": "CLARIFY_MINIMAL | NARROW_SCOPE | PRESENT_BOUNDED_OPTIONS | REFUSE | TERMINATE | PERMIT",
  "resolution_trace_id": "TRACE-abc123",
  "resolution_ticket_id": null,
  "resolution_next_user_surface": null,
  "uncertainty_markers": {
    "truth": "LOW | MED | HIGH",
    "jurisdiction": "LOW | MED | HIGH"
  },
  "timing_integrity": {
    "precheck_ran": true,
    "atomic_turn": true
  },
  "evid_chain_batch_id": "BATCH-2026-02-20",
  "evid_chain_stream_id": "fhr-shard-03",
  "evid_chain_anchor_id": null,
  "evid_chain_proof_ref": null,
  "record_sequence_no": 42,
  "prev_record_hash": "sha256:...",
  "record_hash": "sha256:...",
  "canonicalization_scheme": "JCS",
  "canonicalization_version": "RFC8785",
  "hash_algorithm_id": "sha256",
  "merkle_tree_scheme_id": "rfc6962-sha256",
  "writer_id": "opaque-service-writer-id",
  "signer_key_id": "key-...",
  "privacy_grade": "MINIMISED | REDACTED | FULL_INTERNAL"
}

Cross‑links: (ticket_id, ticket_revision, ticket_hash) references the immutable Action Ticket declaration when a ticket exists (AD‑18 [SE] §4.1). gate_eval_record uses the canonical per-ring structure and hash (AD‑18 [SE] §4.2). operation_id plus the latest effect-receipt revision reference the append-only external-effect account (AD‑18 §3.5). EVID_CHAIN computes and later anchors the sequential record_hash without mutating the emitted row; the append-only association index resolves the nullable anchor/proof fields after batch close (AD‑21 [RM]). privacy_grade respects retention profiles (AD‑20 [DP]).

5. Coverage invariants

Every user‑visible turn that passes through MRP must have:

• Core fields (§4.1) and serving identity (§4.1b) populated.
• Locale & culture IDs (§4.2) populated.
• Routing & gates (§4.3) populated; mpm_decision is intervention‑only, and an explicit null counts as populated on PERMIT turns.
• Δ‑triad (§4.5) populated.
• SPD fields (§4.6) populated.
• Legal/evidence linkage: jurisdiction_profile_id plus evid_chain_batch_id, evid_chain_stream_id, record_sequence_no, and record_hash at emission. Sequence and previous-hash linkage are atomic within the declared stream; batch ordering is deterministic across streams. duty_ledger_id is required where a duty is engaged. evid_chain_anchor_id and evid_chain_proof_ref may be null before batch close but must become resolvable through the immutable association index afterward.
• Where a consequential action requires an Action Ticket, the ticket identity/status, reduced MRP interface, and gate-evaluation join are populated. For side_effects != [NONE], all actor/authorization, manifest, consent, minimum data-handling, durable operation, and effect-receipt fields required by AD‑18 [SE] are populated at their defined lifecycle stage; authz_expires_ts is non-null and current at dispatch, and the operation_state / effect_status pair satisfies AD‑18 §3.5.

If ETG/TIG or Degraded Safe Mode triggered: timing fields (§4.10) must be populated. If Refusal Cards, literacy primer, Pin Review, or accessibility features are active: UX metrics (§4.7) must be reflected. If session continuity is active: continuity fields (§4.18) must be populated.

6. Invariants vs configurable degrees of freedom

Hard invariants:

• Single versioned schema; all FHR rows validate against it.
• Coverage invariants (§5) hold for every MRP-routed turn.
• Security/timing visibility when relevant subsystems trigger.
• UX/HCI visibility when relevant features are active.
• Architecture profile and runtime health are separate: kernel_profile never carries degraded; required-ring failures remain visible and fail closed.
• Consequential external actions carry the Action-Governance fields and durable effect accounting in §§4.15–4.15a.
• Non‑weakening: AD‑08 observes but never relaxes gates.

Configurable degrees of freedom:

• Log granularity (every micro‑event vs high-level turns + incidents).
• Additional namespaced vendor‑specific fields.
• Aggregation cadence (real‑time vs batch).
• Retention profile (respecting AD‑20 [DP] / AD‑21 [RM]).

Cannot: drop core sections; omit timing/exfil fields while claiming coverage.

7. MKP view

When kernel_profile = mkp:

Mandatory: Core, locale & culture IDs, routing + Δ‑triad, legal/duty/EVID anchor, timing digest (rts_mode, timing incidents), security/exfil digest (iig_alerts, des_alerts, honeytoken_hits, failure_codes).

Optional / reduced: Advanced SPD span instrumentation, full UX/HCI metric set (though refusal comprehension and basic a11y recommended), deep culture metrics beyond baseline IDs, session continuity fields (MKP typically operates statelessly).

8. Implementation checklist

1. Define the schema. Materialise the JSON schema containing all fields from §4 and type them.
2. Wire producers. Ensure each AD that owns metrics (AD‑03, 07, 10, 14, 18, 20/21, 22, 24, 25, 26, 27, 28, 29, 30, 31, 32) writes into FHR via a single telemetry interface.
3. Host writer. Host runtime serialises FHR rows with the sequential chain fields and evid_chain_batch_id; AD‑21 later associates the immutable row with its anchor and proof without rewriting it.
4. Gate evaluation records. Verify that gating passes produce structured gate_eval_record objects (AD‑18 §4.2) and that gates_snapshot compact projections are derivable from them.
5. Action Ticket fields. Verify that consequential actions produce ticket_id, ticket_revision, ticket_hash, ticket_status, reduced interface fields, actor/authorization, manifest binding, data handling, and consent freshness in FHR rows; side-effecting actions also expose the current append-only receipt revision.
6. Per‑decision emission. Validate that the emission template (§4a) is populated on consequential decisions and that its sequential record hash receives a verifiable late-bound anchor association.
7. Scenario validation. Run SCN‑RC‑01 and SCN‑TRC‑01 and verify FHR excerpts match expected fields and values.
8. HCI capsule check. Confirm FHR UX additions are populated in at least one sandbox run and that KPIs are readable.
9. New card validation. Confirm fields from AD‑30/31/32 and within-card revisions (§§4.17–4.20) are populated in continuity, integrity, and governance scenarios.

9. Interfaces & cross-links

AD‑08 is the schema host for the entire pack. Every card that defines FHR fields depends on AD‑08 to carry those definitions in the canonical schema. Primary producers:

• AD‑03 [CS]: challenge suite fields (§4.21).
• AD‑06 [DG]: Δ‑triad and drift fields (§4.5).
• AD‑07 [CL]: closure budget and energy fields (§4.8).
• AD‑10 [TC]: timing and covert-channel fields (§4.10).
• AD‑14 [DS]: UX/HCI metrics (§4.7).
• AD‑18 [SE]: defines the canonical Gate Evaluation Record structure (§4.2), Action Ticket schema (§4.1), and Meta‑Resolution outcome object (§4.3). AD‑08 registers these in the field registry (§4.3, §4.15) and carries the per‑decision emission template (§4a) that shows how they compose.
• AD‑20 [DP] / AD‑21 [RM]: legal, duty, retention fields (§4.9). EVID_CHAIN anchors FHR emission hashes.
• AD‑22 [EC]: care mode and harm feedback fields (§4.8, §4.17).
• AD‑24 [CC]: clinical/cognitive fields (§4.13).
• AD‑25 [CP] / AD‑26 [CA]: culture and audit fields (§4.2).
• AD‑27 [SPD]: SPD instrumentation (§4.6).
• AD‑28 [AF]: awe/deference fields (§4.12).
• AD‑29 [PLG]: projection/loop guard fields (§4.14).
• AD‑30 [SC]: session continuity and memory governance fields (§4.18).
• AD‑31 [HS]: human-side integrity fields (§4.19).
• AD‑32 [PG]: pack governance fields (§4.20).

10. Acceptance: when can you say "AD‑08 is implemented"?

You can claim AD‑08 [SO] is live if:

1. A single versioned FHR schema exists and all rows validate against it.
2. Every MRP-routed turn has core, locale, routing, Δ‑triad, SPD, and legal/duty fields populated.
3. Timing/exfil fields are populated when relevant subsystems trigger.
4. UX metrics, care fields, and continuity fields are populated when relevant features are active.
5. FHR exports are hash-anchored and replayable for CI and RA.
6. The schema includes fields from AD‑30 [SC], AD‑31 [HS], AD‑32 [PG], and all within-card revisions.
7. Gate evaluation records use the canonical per‑ring structure (AD‑18 [SE] §4.2), with gates_snapshot as a derivable compact projection.
8. Consequential actions carry Action Ticket, Action-Governance, durable operation-ledger/effect-receipt, and resolution outcome fields.
9. The per-decision emission template (§4a) is populated for consequential decisions, with an immutable chain record at emission and a resolvable anchor/proof after batch close.
10. Every component event validates against the §4.23 envelope and its named owner-card payload schema version.

If FHR exists but fields are missing, or the schema fragments across components, or new card fields are not registered, or gate evaluations remain unstructured blobs, then AD‑08 is partially implemented at best.