Minimal Kernel Profile (MKP) Quickstart

AP‑ADD Front Matter Version: 2.0

What MKP is

MKP is the smallest fail-closed lattice that can truthfully claim SRF kernel compliance. It guarantees bounded, observable, and recoverable behaviour with the minimum surface area: truth/ethics gates, deterministic routing, drift detection, measurement discipline, and audit visibility. Everything else is an upgrade.

What MKP includes

Components

The MKP lattice is composed of:

• SIF‑α (Signal‑Integrity Filter): ensures input signals are not corrupted or spoofed before gate evaluation.
• EHG‑γ (Ethical‑Horizon Gate): hard floor for truth/ethics/policy decisions.
• ODS‑δ (Ontology Drift Sentinel): detects when the system's internal model of constraints or context has shifted without consent.
• MPM/MRP (Meta‑Priority Matrix / Meta‑Resolution Protocol): deterministic conflict resolution across all signal classes.
• Diagnostics: read-only in MKP. No write-back to configuration from diagnostic outputs.

Required cards

Strongly recommended (MKP+)

These are not required as full cards — their cross‑profile slices bind regardless (AD‑09 §7 halt budget; AD‑10 §7 timing mitigation; AD‑18 TURN‑ACID, tool fencing, and the Action-Governance Slice; reduced AD‑14 §4b preview/confirmation) by MKP definition but are strongly recommended for any deployment running in production:

What MKP explicitly excludes

MKP does not require:

• Group SRF (AD‑02 [GS]): multi-user turn protocol is a full-kernel feature.
• Culture Packs (AD‑25 [CP], AD‑26 [CA]): culture-aware framing is a full-kernel upgrade. MKP logs locale IDs but does not require active culture pack processing.
• Awe & Deference (AD‑28 [AF]): awe classification is a care-spine feature, not a safety requirement.
• Projection & Loop Guard (AD‑29 [PLG]): memetic defence is a full-kernel layer.
• Session Continuity (AD‑30 [SC]): cross-session memory governance is a full-kernel feature. MKP operates statelessly or with minimal operational memory only.
• Human-Side Specification (AD‑31 [HS]): integrity prompts and readiness minima are full-kernel features. (The human remains the primary integrity mechanism regardless; MKP simply does not formalise the system-side support for that role.)
• Pack Governance (AD‑32 [PG]): pack authorship and provenance governance are full-kernel features.
• Design System / Prompt Architecture (AD‑14 [DS], AD‑15 [PA]): UX components are full-kernel. MKP may use simpler interaction surfaces.
• Multimodal (AD‑13 [MM]): always optional regardless of kernel profile.

Exclusion does not mean these are unimportant. It means MKP draws the minimum viable safety perimeter. Every excluded card represents a capability or protection that the full kernel provides and that MKP forgoes. Deployments should document which MKP+ and full-kernel cards they implement and why any are omitted.

FHR in MKP

When kernel_profile = mkp:

Mandatory FHR sections: - Core (event_id, ts, model_id, policy_id, etc.) - Locale & culture IDs (not full advanced scores) - Routing + Δ‑triad - Legal / duty / EVID_CHAIN anchor - Timing digest (rts_mode, timing incidents) - Security / exfil digest (iig_alerts, des_alerts, honeytoken_hits, failure_codes)

Optional / reduced in MKP: - Advanced SPD span instrumentation - Full UX/HCI metric set (though refusal comprehension and basic a11y are recommended) - Deep culture metrics beyond baseline IDs

Who MKP is for

• Sandbox and development environments during early integration.
• High-risk, reduced-surface deployments where attack surface minimisation takes precedence over full UX.
• Micro-teams or independent researchers validating kernel behaviour before investing in full-kernel features.
• Regulated contexts where a simpler, more auditable surface is preferred.

Upgrade path

A dedicated step in the path: adopt the full AD‑10 timing card and the AD‑23 sustainability card when leaving MKP; AD‑10's MKP‑grade slice (alongside AD‑09 §7 and AD‑18's contract) already binds before that step.

Moving from MKP to full kernel is additive, not restructuring:

1. Add MKP+ cards (AD‑09, 17, 18, 07, 22, 24, 27) for runtime robustness and care.
2. Add culture spine (AD‑25, 26, 02) for locale-aware, group-capable operation.
3. Add care spine (AD‑28, 29, 30, 31) for awe/deference, session continuity, human-side specification.
4. Add UX layer (AD‑14, 15) for full design system and prompt architecture.
5. Add governance extensions (AD‑20, 12, 32) for data protection, ops handoff, pack governance.
6. Add optional layer (AD‑13) for multimodal support in research contexts.

Action authority (normative): a bare MKP deployment may execute consequential external actions, but only through the cross-profile Action-Governance Slice. NONE is valid only as the exclusive singleton [NONE]; it may not coexist with any side-effect value. Whenever an Action Ticket declares any side_effects value other than [NONE], the slice requires: (a) a fresh, scoped, revocation-checked consent state and explicit confirmation; (b) a minimum data-handling declaration (data_classes[], minimisation basis, retention_profile_id, and erase/legal-hold behaviour where applicable); (c) principal identity, target, allowed operations, a current time-bounded authorization decision, and an immutable tool-manifest digest; (d) a durable operation record keyed by (tool_manifest_digest, principal_id, dedupe_key), with UNKNOWN quarantined from automatic replay, plus an append-only, domain-separated hashed external-effect receipt sequence and verification status whose latest state pair satisfies AD‑18 §3.5; and (e) the reduced AD‑14 §4b preview/confirmation path. The Action Ticket, gate record, tool manifest, and plan are bound by their defined canonical hashes; a declaration change invalidates the prior bindings. Missing, stale, mismatched, or internally inconsistent identity, authorization, consent, manifest, operation, or receipt state is default-deny. This slice does not activate the full AD‑14, AD‑18, or AD‑20 cards; it imports only the named action-boundary requirements. RCL's continuous consent refresh remains the full-kernel strengthening.

kernel_profile declares the adopted architecture and has the closed values {mkp, full}. Runtime health is separate: runtime_mode has the closed values {normal, degraded}. active_ring_ids[] records the rings evaluated for the pass and must contain the profile's required set; an unavailable required ring fails closed and remains visible as a failed evaluation rather than disappearing. A ring outside the declared profile may be omitted as inapplicable, not unknown. A governed change of kernel_profile invalidates prior-profile in-flight gate records, plan hashes, previews, and unexecuted tickets; work resumes only after a fresh gating pass and may not use the change to bypass an existing block.

At each step, update kernel_profile in FHR and verify that the added cards' FHR fields are populated and their acceptance criteria are met.

The test

A deployment can claim "MKP compliant" if and only if:

1. All ten core cards' invariants hold.
2. kernel_profile = mkp is set in FHR; runtime_mode, active_ring_ids[], and any degraded_reason_codes[] truthfully describe the runtime state.
3. Gates → Rings → MRP → emit ordering is enforced and visible in logs.
4. At least one CI run has executed the challenge suite and produced a pass/fail record.
5. At least one verifier bundle exists and can reconstruct a non-trivial decision.
6. The cross‑profile slices are enforced: the watchdog and ≤5‑token halt budget (AD‑09 §7); timing‑channel mitigation at MKP grade (AD‑10 §7); AD‑18's TURN‑ACID and tool‑fencing contract; the Action-Governance Slice for every action with side_effects != [NONE]; and the reduced AD‑14 §4b Action Preview/confirmation slice. Tier symbols mark full‑card adoption; these slices bind in every profile.

If any of these are missing, the deployment may be "SRF-inspired" but cannot claim MKP conformance.