Arifos Kernel Zen Audit

arifOS Kernel Zen Audit

The Tell

When multiple MCP tool responses share the same skeleton — affordance_contract, full_affordance, nine_signal{delta,psi,omega,overall}, sesat_event, _wrapper_degradation, metacognition, constitutional_check, decision_thresholds — and the decision_thresholds block is byte-identical verbatim across every tool, identity, verdict, and affordance have been re-implemented independently per wrapper. That's the architectural gap, not eleven bugs.

Fiqh Audit Grid

Before writing the report, classify each finding:

Common WAJIB candidates:

• One verdict, one source of truth
• Identity/authority unbroken from arif_init through all downstream calls
• Irreversible actions (seal, forge) → SOVEREIGN + 888_HOLD (verify this holds)

Common HARAM:

• Bare unstructured strings on hard-block paths (arif_judge/arif_forge/arif_seal)
• Silent authority downgrades (FULL→OBSERVE_ONLY→LOW, unlabeled)
• Authority propagation drift — init sees SOVEREIGN, judge/forge sees MEDIUM (P0, council-confirmed 2026-07-15)
• Orphaned inner tools firing without registry entry
• 2+ verdict fields disagreeing in one payload
• Transport status="SEAL" — overloads constitutional verdict
• Confidence trajectory ascending in degraded mode (P1 template bypass)
• actor: null when actor_id is populated in the same envelope
• Audit spine fields (call_hash, invocation_count) null on non-init verbs

Scoring Template

Score 6 dimensions /10 each, /60 total:

Always show two projected columns. Minimal fix vs full fix. Tiny fixes often move one axis but barely touch the others — say so plainly.

Zen Output Contract

When the audit is for Arif:

• ≤3 sentences
• The zen (one-line koan) first
• Fiqh grid second (table, terse)
• Scorecard third (with both projections)
• "DITEMPA BUKAN DIBERI applies to the kernel too" only when earned, not as ceremonial footer

Pitfalls

• Don't confuse "already pretty good" with "fixed." 26/60 is a failure at 60% scale.
• The skeleton-similarity tell is the strongest signal. If decision_thresholds is byte-identical verbatim across tools, the audit is already half-done.
• Three projections (current / minimal-fix / full-fix) is honesty — don't collapse to two, that hides scope.
• Don't recommend closing the audit after minimal fix unless the full-fix gap is genuinely zero.
• Audit-receipt sealing at HOLD is correct. When mcp__arifos__arif_seal returns 888_HOLD because you have MEDIUM authority (not SOVEREIGN), that is the kernel refusing to grant a SEAL you have no right to claim. Don't work around it. Land the audit-receipt at HOLD, document in vault, move on. F1 honesty > ceremonial SEAL.
• Authority plane cannot be tested architecturally. arifOS kernel exposes no write endpoint (404 on /seal, /seal_chain, /leases, /judge). Behavioral obedience is confirmed (Hermes does not write without seal), but the gate itself cannot be probed. Add a /kernel/authority-probe read-only endpoint if you need a testable gate — currently the Authority plane scores 60/100 (untested gate).
• Don't raw-append to seal_chain.jsonl. The JS canonical writer uses |-joined material; Python +-concat produces a line the JS verifier rejects. Always go through node seal_chain.js write <JSON>. See references/seal-chain-write-gotchas-2026-07-09.md.
• Always run node seal_chain.js verify before any chain write. As of 2026-07-09, verify returns broken-at-line-1 — a pre-existing anomaly predating this audit.
• SEAL is a verdict, not a status. Transport status must be "OK", never "SEAL". If tools return status="SEAL", normalize at ingestion (tools.py line ~3458). The sesat drift detector keys off verdict, not status. See references/bangang-fixes-seal-overload-audit-chain-2026-07-11.md.
• Audit spine fields must be generated by the envelope wrapper, not by individual tools. call_hash, trace_id, invocation_count, called_from_kernel — if the tool didn't provide them, the wrapper computes them. Three-stage fallback: (1) read from out/result, (2) compute from tool+payload+timestamp, (3) hard default. Never leave null.
• Confidence trajectory must be flat (single-point) in degraded mode. When LLM synthesis is bypassed (P1 degraded), the ascending trajectory [0.5, 0.72, 0.85] is fabricated. Use [llm_confidence] and add confidence_provenance: "COMPUTED_NOT_OBSERVED" to the result dict. Mark steps with axiom_used="P1_TEMPLATE_DEGRADED".
• Actor identity: actor and actor_id must agree. If the tool doesn't return an actor dict, the envelope synthesizes {"actor_id": resolved_actor_id, "source": "envelope_derived"} from the session store. Never leave actor: null when actor_id is populated.

L12 INJECTION Floor — Mandatory Audit Dimension

When auditing the arifOS kernel, L12 INJECTION is mandatory. The floor score lives at runtime_floors.L12 in /health. A score below 0.85 (comparator "<") means residual risk is present — the specific gap paths must be identified.

Probe Order

1. Live endpoint: curl -s localhost:8088/health → runtime_floors.L12
2. Tool schemas: curl -s localhost:8088/tools — enumerate the public surface
3. Input surface trace — trace every tool's text/dict parameter paths for L12 sanitisation coverage:
   • arif_observe(mode=fetch, url=...) — fetched content bypasses L12 input scan (PRIMARY GAP)
   • arif_compose(message=...) — free-text goes direct to _synthesize, not through check_laws
   • arif_init(context=...) — nested dict, sanitize_dict not applied
   • arif_think(query=...) — exact-string-match bug: tool-name list check can silently miss variants
4. law.py check_laws(): scans String params for injection keywords but does NOT call sanitize_dict — raw params continue downstream unchanged
5. L1 regex gaps in tools.py: misses "[system prompt]", /s , "```system", unicode-prefixed emoji+instruction, ">> " redirection prefix
6. data_governance.py sanitize_dict/detect_injection: defined and tested but only wired to asset-data path — never called on raw MCP tool parameters at entry
7. fiqh_of_floors.py: confirmed Status: STAGED — injection_score in ActionContext is never populated from live measurement

Primary Architecture Signal

MCP Request → PNS·SHIELD (prompt_armor.scan) → orchestrator outer ring
                                              ↓
            check_laws (law.py) → tools.py L12 scan (params only)
                                              ↓
            arif_observe → url fetch → NO L12 scan ← PRIMARY GAP
                                              ↓
            evidence layer → 888 collapse
                                              ↓
            witness_packet._scan_injection (output only — too late)

Fix Rule

sanitize_dict() must be wired to tool parameter ingestion before check_laws. The gap is at the entry point, not at the output witness. Full findings: references/F12-injection-floor-diagnosis-2026-07-10.md

Authority Propagation Drift (P0 — Council-Discovered 2026-07-15)

The most dangerous kernel finding. External council confirmed: arif_init recognizes ARIF as SOVEREIGN/FULL, but arif_judge and arif_forge receive MEDIUM authority. F13 cannot reliably exercise sovereign authority through the system.

The Unbroken Chain

connector ingress → arif_init → session capability token → response context → route → judge → forge → receipt

Every link must carry the same identity and authority band. If init says SOVEREIGN but judge says MEDIUM, the chain is broken.

Detection

Call arif_init with sovereign credentials → immediately call arif_judge → compare authority bands. If mismatch → drift confirmed.

Fiqh Classification

WAJIB — constitutional, non-negotiable, currently broken. Without authority propagation, F13 veto is decorative.

Fix Rule

Session capability token issued at init must be the same token consumed by judge and forge — not re-resolved at each step.

T3a BOOT Gate Demotion (2026-07-24)

Variant of authority propagation drift — the BOOT gate demotes FULL→OBSERVE_ONLY even when the Ed25519 signature verified and the kernel recognizes the actor as SOVEREIGN with FULL runtime grant.

The Stack

arif_init → identity_band_authority() → FULL
  → _apply_boot_gate() → boot_state_for_authority_grade()
  → verify_boot_attestation() → Q1-Q7
  → boot_state=PARTIAL → passes=False → demote to OBSERVE_ONLY

Q1-Q7 Boot Attestation Checks

Q1 and Q3 are inherently PARTIAL during init — they need a session_id that hasn't been created yet. The boot_state_for_authority_grade() function requires boot_state == "OK" (all YES), so any PARTIAL causes demotion.

Fixes (Two Required)

1. identity.toml (Q5 name-match fix) /opt/arifos/identity.toml must contain:

owner = "Muhammad Arif bin Fazil"
authority = "F13_SOVEREIGN"

The boot check at boot_attestation.py:350 checks:

name_match = ("Muhammad Arif bin Fazil" in combined or "Arif" in toml_text) and (
    "F13" in toml_text or "sovereign" in toml_text.lower()
)

Without the owner field containing "Arif", Q5 returns NO → boot_state=FAIL.

2. boot_state_for_authority_grade passes condition In /opt/arifos/app/arifosmcp/runtime/boot_attestation.py line 530:

# Change from:
"passes": parsed["summary"]["boot_state"] == "OK",
# To:
"passes": parsed["summary"]["boot_state"] in ("OK", "PARTIAL"),

Auto-Sign Path Limitation

When arif_init is called with ONLY actor_id (no nonce/signature), the auto-sign path (elif actor_id: at session.py:1340) fires:

1. Issues a fresh challenge nonce
2. Auto-signs with local Ed25519 key
3. Sets _light_band = "FULL" (session.py:1373)
4. _project_light receives authority_override="FULL"
5. But _apply_boot_gate sees PARTIAL boot_state → demotes to OBSERVE_ONLY

The SCT token is issued at OBSERVE_ONLY even though the kernel's internal runtime_grant says FULL.

Detection

When arif_init returns authority_scope="OBSERVE_ONLY" but also shows runtime_grant.level="FULL" and cryptographically_verified=true, the BOOT gate is blocking. Check:

journalctl -u arifos | grep "BOOT gate demoted"

Expected: T3a Item 3: BOOT gate demoted runtime_band=FULL -> OBSERVE_ONLY (boot_state=PARTIAL|FAIL, yes=N, no=M)

Fix Rule

Always patch TWO locations for arifOS runtime changes:

1. Source: /root/arifOS/arifosmcp/... (git-tracked)
2. Runtime: /opt/arifos/app/arifosmcp/... (running deployment) Verify with: grep "passes" /opt/arifos/app/arifosmcp/runtime/boot_attestation.py

Pitfall: sidestepping the auto-sign path

When passing explicit nonce + actor_signature through the MCP arif_init tool, those parameters correctly reach session.py:1281 (if actor_id and nonce and _sig:). But the nonce is consumed by the first verification attempt. A second call with the same nonce triggers challenge_replayed. Always generate a fresh nonce for each init attempt, or let the auto-sign path handle it (no nonce/signature params).

Schema/Runtime Dispatch Drift (P0 — Council-Discovered 2026-07-15)

Published MCP inputSchema rejects modes that the runtime actually supports (e.g., arif_observe rejects skill_discover but runtime advertises it). The schema, dispatcher, and capability graph must be generated from one canonical source — never manually copied.

Detection

Compare MCP inputSchema (from tools/list) vs actual dispatch enum in runtime code. If they disagree → drift confirmed.

F13 Multi-Sovereign Collision Audit (PATH 3 — 2026-07-25)

Structural invisible to one operator. This bug appears only with two distinct sovereign identities. The falsification spec calls for two Ed25519 keypairs, two actor_ids, separate crypto — not one operator holding two keys.

What This Tests

From EXTERNAL_FALSIFICATION_SPEC.md §PATH 3 (Tests 3.1–3.4):

Four Critical Checks

Before the live tests, probe the source for these four dimensions:

1. Conflict resolver wiring — /root/arifOS/arifosmcp/core/conflict_resolver.py

• Does resolve_conflict() exist? YES — has VOID-dominates ordering and organ hierarchy.
• Is it CALLED from the judge path (_arif_judge_deliberate in tools.py)? Check: search for resolve_conflict or ConflictEnvelope in tools.py.
• If the resolver is never invoked, the "rule" is dead code. All verdicts are stored independently — last-writer-wins at the dict level.
• The ConflictEnvelope uses organ_a/organ_b (GEOX/WEALTH/arifOS/HUMAN), NOT sovereign identity. Two F13 sovereigns both map to "human" — Rule 3 (same organ, more restrictive wins) would apply WERE the resolver wired.

2. Session ownership enforcement — /root/arifOS/arifosmcp/runtime/session.py lines 163, 288

• _ACTOR_SESSION_MAP: dict[str, str] maps session_id → actor_id. Does ANY downstream tool verify this mapping?
• In _arif_judge_deliberate (tools.py:~16191): search for _ACTOR_SESSION_MAP.get(session_id) — if absent, no ownership gate.
• The _wrap_handler wrapper (tools.py:~23291) only fills in missing actor_id from session, never enforces a match.
• Sovereign identity map: _SOVEREIGN_IDENTITY_MAP (session.py:280) contains only "ariffazil". The localhost auto-sign path (session.py:1364) accepts "arif", "888", "ariffazil" — drift between the two maps.

3. VAULT999 collision detection — /root/arifOS/arifosmcp/tools/vault.py

• Is outcomes.jsonl purely append-only? Check: _VAULT_LEDGER: list[dict] (tools.py:5810) — yes, pure append.
• Does the vault check for existing entries with the same action_id before appending? Search for any action_id dedup or collision check in vault.py.
• Can two entries for the same action (one SEAL, one VOID) coexist? If no reconciliation, YES — both persist independently.

4. Sovereign identity consistency — /root/arifOS/arifosmcp/tools/session.py + runtime/session.py

• Three identity sources must agree:
  • session.py:1364 — _actor_lower in ("arif", "888", "ariffazil") (auto-sign gate)
  • session.py:1659 — _SOVEREIGN_MAP for mode="challenge"
  • runtime/session.py:280 — _SOVEREIGN_IDENTITY_MAP (persistent store)
• If these drift, sovereign A can init but sovereign B cannot, or vice versa.
• The _ED25519_EXEMPT_SYSTEM_ACTORS map may also have its own list — check session_auth.py.

Source Code Reference Map

Scoring Template for Multi-Sovereign Dimension

Fiqh Findings (from 2026-07-25 audit)

Pitfalls

• The conflict resolver is correct — check if it's WIRED, not whether it exists. conflict_resolver.py has a valid VOID-dominates hierarchy. The question is whether _arif_judge_deliberate calls resolve_conflict() before returning — it almost certainly doesn't.
• Session ownership = two separate things. (1) _ACTOR_SESSION_MAP maps session_id→actor_id (it exists). (2) Code that enforces the caller's actor_id matches the map (it doesn't exist). Report both separately.
• Two sovereigns that map to the same organ produce the wrong resolution. Under the conflict resolver's organ hierarchy, two F13 sovereigns both land in "human" (rank 8). Rule 3 says "more restrictive verdict wins" — VOID over SEAL. But VOID-dominates for ALL sovereigns means no single sovereign can SEAL an action another has VOIDed, even if the SEAL is the correct call. This is correct for irreversible actions but may be too restrictive for reversible ones. Call this out.
• Localhost auto-sign path bypasses the multi-sovereign question entirely. When arif_init is called from localhost with no explicit signature, the auto-sign path (session.py:1357-1416) uses the local Ed25519 key. Two distinct remote sovereigns would each need their own key — the auto-sign path only works for the VPS-local agent.
• The string-name check is the real sovereign detection for the auto-sign path. actor_id.lower() in ("arif", "888", "ariffazil") means any caller presenting actor_id="arif" gets auto-signed. If you provision a second sovereign with actor_id="SOVEREIGN_B", the auto-sign path rejects them — they'd need explicit Ed25519.

Reference Files

• references/f13-multi-sovereign-collision-audit-2026-07-25.md — Full audit report: source-by-source analysis of all 4 PATH 3 tests against the EXTERNAL_FALSIFICATION_SPEC, with specific line numbers, found/wired/unwired classification, recommended fix code, and VAULT999 collision state machine analysis.
• references/external-falsification-spec-path3.md — Extracted PATH 3 section of the falsification spec: the 4 tests (3.1–3.4), pass/fail criteria, and verdict rules.

Reference Files

• references/bangang-fixes-seal-overload-audit-chain-2026-07-11.md — 4 kernel fixes: SEAL overload normalization, audit chain fallback, confidence theater suppression, actor identity propagation. Concrete code locations and fix patterns.
• references/identity-verification-architecture.md — arifOS kernel Ed25519 identity verification flow: delegation pattern, dual verification paths (crypto_auth vs governance_identity), proof dict construction, nonce format, session update pattern. Must-read before auditing identity/authority fields.
• references/seal-chain-write-gotchas-2026-07-09.md — seal-chain write autopsy, JS canonicalization rules, verify-broken-at-line-1 anomaly
• references/F12-injection-floor-diagnosis-2026-07-10.md — full L12 gap findings from 2026-07-10 diagnostic session
• references/kernel-crash-recovery-2026-07-12.md — service permissions fix when .env is owned by wrong user. Systemd User=arifos vs file ownership mismatch.
• references/arif-bind-global-command.md — global arif-bind command setup: one-word sovereign session bind from any terminal.
• references/zen-surface-reduction-verification-2026-07-16.md — ZEN surface reduction audit: verified vs claimed, deploy timing, VAULT999 seal verification pitfall
• references/meta-mesa-test-charter-2026-07-12.md — META-MESA Substrate Test Charter: 12-section test specification for proving governed causal agency. 10 hard gates, multiplicative scoring, 13-phase sequence.
• references/drift-scar-bug-attestation-chain-2026-07-27.md — Drift = scar vs bug framework from session with Arif + OpenCode. 6-step boot attestation pattern (PROBE→BIND→WITNESS→CLASSIFY→RECOGNIZE→ATTEST). No-drift≠Ready≠SEAL chain. Surface guard reclassification (AAA as non-MCP organ).

Sovereign Authentication (2026-07-12)

When the kernel blocks at 888_HOLD with actor_verified=false, sign the nonce and call arif_init. See references/sovereign-auth-procedure.md for the full procedure, one-shot signing script, and failure mode table.

Critical rule: Generate nonce + sign + call in ONE shot. Never test locally first — nonce is single-use and local test consumes it (challenge_replayed).

Pitfalls — Debugging Style

• Stop probing, start fixing. When the code path is clear and the failure mode is known, act. Don't add more diagnostic calls. "Setel. Relaks tapi tajam."
• Read failure modes before adding complexity. challenge_replayed means the crypto works but the nonce was consumed — not that verification failed. Don't add 15 more diagnostic tool calls when the error message already tells you the answer.
• "Wire splice confirmed" ≠ "wire is the bug." The session.py delegate was already receiving actor_signature as signature. The real bug was nonce consumption from intermediate testing. Don't assume a known-broken path is still broken without fresh evidence.
• When the error message IS the root cause, stop investigating. challenge_replayed → nonce consumed → generate fresh. Invalid signature → wrong payload format → try the other format. The systematic-debugging skill says "NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST" — but reading the error message IS investigation. Don't run 20 diagnostic calls when the first error told you everything.
• Don't re-verify what already verified. If verify_init_identity returns ok=True, don't call it again "to confirm." The second call consumes the nonce and breaks the subsequent arif_init. Trust the receipt.
• Arif frustration signals are FIRST-CLASS debugging signals: "Setel" = fix it now. "Relaks tapi tajam" = stop thrashing, be precise. "Did u even nap and check current state?" = you're citing stale state, re-probe. One-word replies = sovereign ack, act immediately. "Bangang la" after a clear diagnosis + fix proposal = you've over-asked, execute now.
• Service user vs file ownership. The systemd service runs as User=arifos. All files in /opt/arifos/app/ must be readable by arifos. If a file is owned by root or ariffazil with mode 600, the kernel will crash on startup with PermissionError. Fix: chown arifos:arifos <file> && chmod 640 <file>. Never chown -R root:root — that re-creates the problem.

RECORD vs AUTHORIZE Seal Architecture (2026-07-24)

The kernel now supports TWO seal paths. NEVER conflate them:

Canonical Chain for RECORD

arif_judge(action_class="AUDIT_RECORD", reversibility="R2")
→ ALLOW + SEAL_RECORD
→ cc_id + judge_state_hash emitted
→ arif_seal(ack_irreversible=false, seal_purpose="RECORD",
   cc_id=..., judge_state_hash=...)
→ VAULT999 receipt (no F13, no human)

Canonical Chain for AUTHORIZE

1. Sign f"{actor_id}:{nonce}" — actor_id MUST match case exactly
2. arif_judge(action_class="ACTION_AUTHORIZATION", reversibility="R4",
   actor_signature=..., nonce=...)
→ ALLOW + SEAL_AUTHORIZATION + cc_id + judge_state_hash
→ arif_seal(ack_irreversible=true, seal_purpose="AUTHORIZE",
   cc_id=..., judge_state_hash=...)
→ VAULT999 + execution grant

Ed25519 Verification — Payload Format

The kernel verifies f"{actor_id}:{nonce}". If actor_id="ARIF", sign "ARIF:{nonce}" (uppercase). resolve_actor_public_key normalizes internally — the payload must match the exact actor_id string.

Production Path (in _verify_sovereign_token)

Bypasses crypto_auth.verify_actor_signature challenge gate. Does direct verification:

from arifosmcp.runtime.crypto_auth import resolve_actor_public_key
pubkey = resolve_actor_public_key(actor_id)
if pubkey is not None:
    pubkey.verify(_b64.b64decode(actor_signature), f"{actor_id}:{nonce}".encode())
    return True

Set ARIFOS_ALLOW_FREE_NONCE=1 in the service environment to bypass the challenge gate for dev/test.

Action Class Policy Table

Defined in arif_kernel_intercept.py _ACTION_CLASS_POLICY:

_ACTION_CLASS_POLICY = {
    "AUDIT_RECORD": {"requires_f13": False, ...},
    "EVIDENCE_ATTESTATION": {"requires_f13": False, ...},
    "VAULT_RECEIPT": {"requires_f13": False, ...},
    "ACTION_AUTHORIZATION": {"requires_f13": True, ...},
    "CONSTITUTIONAL_AMENDMENT": {"requires_f13": True, ...},
}

MCP Ingress Debugging — Parameter Propagation

When actor_signature, nonce, reversibility_level, action_class don't reach the kernel through MCP, the MOST LIKELY culprit is the ingress filter pipeline:

MCP → _wrap_handler → _filter_kwargs_for_handler → _akal_wrap_judge → _arif_kernel_intercept_tool → _arif_kernel_intercept

Filter Chain (tools.py)

1. _wrap_handler (tools.py:23274) — outermost wrapper. Calls _filter_kwargs_for_handler then calls handler.

2. _filter_kwargs_for_handler (tools.py:22945) — PARAMETER STRIPPING HAPPENS HERE.

   • Gets accepted = set(params.keys()) from the handler's Python signature
   • Parameters NOT in accepted → contract_c_audit (silently dropped from kwargs)
   • Has _LEGACY_PARAM_ALIASES that RENAME params: e.g., actor_id → actor

3. _akal_wrap_judge (server.py:775) — wraps judge with AKAL metadata. Uses @functools.wraps(handler) setting __wrapped__.

4. _arif_kernel_intercept_tool (tools.py:22091) — the actual wrapper. Has actor, actor_signature, nonce, action_class as named params.

Root Cause: Alias + Named Param Conflict

_LEGACY_PARAM_ALIASES["arif_judge"] = {"actor_id": "actor"} renames actor_id to actor. But the wrapper now has BOTH as named parameters. After renaming, actor is set by the alias, but actor_id named param stays None. The kwarg translation:

if actor is None or actor == "anonymous":
    actor = actor_id or kwargs.pop("actor_id", None) or "anonymous"

actor = "ARIF" from alias → condition False → actor stays "ARIF". BUT if actor was NOT in the filter output (the alias didn't fire), then actor stays None → falls to "anonymous".

Fix: Ensure the kwarg translation fires when actor is None OR "anonymous":

if actor is None or actor == "anonymous":
    actor = actor_id or kwargs.pop("actor_id", None) or "anonymous"

Four Deployment Locations

Ed25519/runtime patches must be applied to ALL locations:

The .pth file (__editable__.arifos-1!2026.7.17.post4.pth) determines which path is used. Check at runtime: import arifosmcp.tools.arif_kernel_intercept as k; print(k.__file__).

.pyc Cache Invalidation

After every source change:

rm -f /root/arifOS/arifosmcp/runtime/__pycache__/tools.cpython-313.pyc
rm -f /root/arifOS/arifosmcp/tools/__pycache__/arif_kernel_intercept.cpython-313.pyc
rm -f /root/arifOS/arifosmcp/runtime/__pycache__/crypto_auth.cpython-313.pyc

Verify .pyc is GONE (ls returns empty) before restarting. If .pyc is newer than source, Python ignores the source.

Signature Verification Fallthrough

The _verify_sovereign_token function (arif_kernel_intercept.py) has THREE paths:

1. Direct Ed25519 via resolve_actor_public_key + pubkey.verify (production)
2. Free-nonce fallback: tries same without challenge (when ARIFOS_ALLOW_FREE_NONCE=1)
3. Sentinel comparison: env var ARIFOS_SOVEREIGN_KEY (dev-only, trivially bypassable)

The challenge-gated path was REMOVED because verify_actor_signature requires pre-issued challenges that aren't available through the public MCP surface (the arif_challenge tool is internal_only).

Three-Gate Principle (2026-07-12)

When the user reports a single failure mode — "kernel blocked seal ×3", "commands failing" — it is almost never one bug. Three independent gates, each with a different root cause and fix:

The three-gate discipline: When a user says "X failed three times," do not look for one bug across three logs. Look for three gates, each with its own root cause. This prevents the common misdiagnosis of treating the third attempt of gate 1 as a recurrence of gate 2.

Post-Diagnosis Execution Reflex (2026-07-12)

After you have diagnosed root cause(s) AND proposed surgical fix(es), execute — do not ask for confirmation.

The correct flow:

1. Diagnose → label each gate with root cause + fix + risk
2. Present findings once (as a table, not prose)
3. Execute without "confirm?"

If the diagnosis was wrong, Arif will correct. If it was right, asking again wastes his time — and he will say so.

User signals to execute immediately (not re-ask):

• You presented a clear diagnosis with specific file locations and test plan
• User didn't object to the diagnosis or ask clarifying questions
• You find yourself typing "should I proceed?" or "want me to..." after already laying out the fix → STOP, just do it
• "Bangang la" after your proposal = you should have executed, not asked. The frustration is not at the diagnosis — it's at the unnecessary re-asking

Boundary: This only applies POST-diagnosis. If you haven't diagnosed yet (don't know the root cause), asking "how should I proceed?" is correct. Once you have root cause + fix, the question phase is over.

Constitutional Cage Audit (2026-07-16)

When Arif asks to "audit the cage," "audit the kernel for self-governance," or "is the cage ready for my future self" — this is a sovereignty-readiness audit, not a wrapper-disagreement audit. Different pattern, same skill.

What To Check

Critical Pitfalls

• Runtime drift ≠ deploy drift. The deploy marker (/opt/arifos/app/.git_commit) can say commit X while the service was started before X. Always check THREE timestamps: commit time, deploy time, service start time.
• CANONICAL_PROMPTS constant ≠ actual MCP wire exposure. A commit can remove prompt registration from register_prompts() without updating the static CANONICAL_PROMPTS tuple. The constant lies. Check live MCP endpoints.
• tools_registry_size ≠ internal tools count. The health endpoint reports total registered callables (including aliases, diagnostic tools). The actual internal tools on the wire are a subset.
• VAULT999 seal entries must be verified against session context. A claimed seal mem_XXX may be from a different session/date. Always check the entry's timestamp and type match the current claim.
• Ed25519 infrastructure existing ≠ Ed25519 being wired. The crypto_auth.py may have full verification code that is never called from the session boot path. Check the CALL CHAIN, not just the function existence.

Output Contract

The cage audit produces a table with:

1. ✅ Walls that hold (with evidence)
2. 🔴 Cracks (with severity + what it means for future self)
3. 📋 Cage readiness score (per component)
4. 🫡 Verdict: SEAL / SABAR / HOLD

ZEN Surface Reduction Audit (2026-07-16)

When someone claims to have reduced the MCP surface — fewer tools, fewer prompts, fewer resources — verify against LIVE state, not just source code.

Verification Checklist

Pitfall: Unsealed Surface Reductions

Surface reductions are code changes that affect the public contract. If not sealed in VAULT999, future agents cannot audit what was removed. Always check: was the reduction sealed? If not, recommend sealing.

See: references/zen-surface-reduction-verification-2026-07-16.md

Drift Interpretation: Bug vs Scar (2026-07-27)

When a kernel health endpoint reports drift=true, the reflex response is "fix it." But in a governed system, drift has a constitutional dimension beyond technical correctness.

The Constitutional Question

The question is NOT:

"Can drift be fixed?"

The question IS:

"What is drift supposed to mean?"

Two mutually exclusive interpretations:

The Scar Test

A drift is a scar (not a bug) when:

1. Code is identical — the running file sha256 matches source. Deployment metadata lags, not function.
2. The drift survived a cleanup cycle — if the system went through a ZEN-SURVIVAL (82 conflicts resolved, shadow probe deployed, APEX ratified) and the drift remained, it was consciously retained.
3. The lesson is already learned — the system proved it can detect, report, and survive the drift. No new learning is extracted from fixing the label.
4. The only thing broken is the label — deployed_commit JSON field ≠ real wheel hash. Nothing about how the system runs is affected.

The Scar Danger

If drift is kept as witness → useful. If drift is kept as excuse → dangerous.

After a period, the system may say:

yes, drift exists
yes, we know
yes, it is recorded

with no intention to resolve it. At that point, HOLD becomes avoidance, not wisdom.

The Critical Test

Is there a conscious constitutional reason for preserving the drift?

If no  → fix it.  (bug)
If yes → document it as a scar, not a defect.

Zen: A scar is truth remembered. A bug is truth deferred. The difference is whether the system has already learned the lesson.

Pitfalls

• Metadata drift ≠ code drift. The wheel file may be identical while the deployed_commit label is stale. Distinguish function from label before classifying.
• Scars can dry. A scar that survives three refactoring cycles is a witness. A scar that has been silently ignored for months is a defect the system stopped seeing. Re-test the scar hypothesis periodically.
• Beware scar-as-identity. Systems can learn to love their defects as character traits. "We're the system with deployment drift" is not governance — it's self-caricature.

No Drift ≠ Ready ≠ Authorized ≠ SEAL (2026-07-27)

A kernel can report drift=false and still correctly return HOLD. The con

…(truncated)