kenaz 0.0.0-stage → 0.3.2

package/core/.kenaz/designs/METAPLASTICITY_CONFIDENCE_DESIGN.md

@@ -0,0 +1,537 @@
+# Metaplasticity for Rune Confidence Updates — Design Specification
+
+**Task**: TASK_1243  
+**Author**: unit (Formation agent)  
+**Date**: 2026-04-17  
+**Status**: Design Only — NO implementation
+
+---
+
+## 1. Executive Summary
+
+This document evaluates whether CH-HNN metaplasticity principles (Nature Communications 2025) and Meta-CLS layer-wise plasticity gradients (bioRxiv 2025) can be applied to KenazAI's rune confidence update mechanism. The current mechanism is static: confidence is set once at inscription and updated only by a flat +0.05 boost when `acted_on_rate > 0.5`. This design proposes a weight-dependent update rule and rune-type plasticity tiering.
+
+**Verdict at a Glance**: **CONDITIONAL GO** — the CH-HNN formula maps cleanly to the confidence-as-weight analogy; the Meta-CLS layer gradient maps cleanly to rune-type tiering. Implementation risk is low (SQLite-only change, no schema migration needed). A dry-run simulation against historical `rune_usage_log` is required before shipping.
+
+---
+
+## 2. Current Confidence Lifecycle Analysis
+
+### 2.1 How Confidence Is Set
+
+Confidence is set by the inscribing agent at `synapse_inscribe` time:
+
+- **Range**: `[0.6, 0.99]` enforced by two mechanisms:
+  - `validate_confidence(c)` in `memory.rs:393` rejects `c < 0.6`
+  - SQL `CHECK(confidence >= 0.6)` on the `runes` table (line 753)
+  - Application cap at `0.99` in `apply_usage_boosts` (line 4674)
+- **Typical distribution**: Agents inscribe 0.7–0.95; high-signal runes get 0.85–0.95
+- **No automatic initial value**: The caller always supplies confidence explicitly
+
+### 2.2 When and How Confidence Is Updated
+
+There is exactly **one stored update path** and **one ephemeral update path**:
+
+#### Stored: Phase 5c `apply_usage_boosts` (memory.rs:4611–4688)
+
+```
+Eligibility: acted_on_count / total_recall_count > 0.50 (90-day window)
+Formula:     confidence += min(0.05, 0.99 - confidence)
+Trigger:     Called by synapse_apply_usage_boosts MCP tool
+```
+
+- Flat +0.05 regardless of current confidence level
+- Saturates at 0.99
+- No per-type differentiation
+- No negative (decay) path stored to DB
+
+#### Ephemeral: Heimdall score-time decay (memory.rs:4692–4720)
+
+```
+Eligibility: confidence < 0.9 AND 0 recalls in last 30 days
+Formula:     effective_score *= 0.85  (NEVER written to runes table)
+```
+
+- Only affects ranking presentation; stored confidence is unchanged
+- Runes with `confidence >= 0.9` are **protected from decay**
+
+### 2.3 Key Observations
+
+1. **The boost is type-agnostic**: An `ash` rune (stable, 45-day half-life cross-session insight) gets the same +0.05 as an `insight` rune (fresh, hypothesis-level)
+2. **No contradiction-driven decay**: A new contradicting rune does not reduce the old rune's confidence
+3. **No recall-count gradient**: A rune recalled 100 times gets the same boost as one recalled 2 times, as long as the rate > 0.5
+4. **The floor is never reached**: Nothing drives confidence below its inception value; the 0.6 floor is theoretical only
+5. **Asymmetry**: Only positive reinforcement is stored; negative reinforcement is ephemeral and capped at score-time
+
+---
+
+## 3. Cross-Domain Evidence
+
+### 3.1 CH-HNN: Metaplasticity Formula
+
+**Source**: "Hybrid neural networks for continual learning inspired by corticohippocampal circuits" — Nature Communications, 2025 (https://www.nature.com/articles/s41467-025-56405-9)
+
+The CH-HNN paper introduces metaplasticity to prevent catastrophic forgetting in continual learning. The core mechanism:
+
+**Metaplastic learning rate**: `f(m, W) = e^(-m · W)`
+
+Where:
+- `W` = current synaptic weight magnitude
+- `m` = metaplastic state (tracks cumulative learning pressure)
+- `f(m, W)` = effective learning rate for this synapse
+
+**Key properties**:
+1. Synapses with high weight magnitude have **exponentially lower** learning capacity
+2. This naturally "protects" well-established synapses while keeping low-weight synapses plastic
+3. No replay buffer needed — protection is intrinsic to the weight structure
+4. Continual learning across task sequences without forgetting prior tasks
+
+**Transfer to rune confidence**: If we treat rune `confidence` as analogous to `W` (the weight), then the update magnitude should scale as `e^(-β · confidence)`. A rune at confidence 0.95 has factor `e^(-β·0.95)` — much smaller than a rune at 0.65 with factor `e^(-β·0.65)`.
+
+**Transfer weakness** (honest assessment): CH-HNN operates on continuous weight dynamics at millisecond timescale in ANN/SNN training. Rune confidence updates happen at daily/session granularity via discrete events. The formula is being applied in a very different regime — it captures the *intuition* but not the *dynamics*. The formula's mathematical justification (gradient stabilization in neural training) does not directly transfer. We are borrowing shape, not mechanics.
+
+### 3.2 Meta-CLS: Layer-wise Plasticity Gradient
+
+**Source**: "A Gradient of Complementary Learning Systems Emerges Through Meta-Learning" — bioRxiv 2025 (https://www.biorxiv.org/content/10.1101/2025.07.10.664201v1), code: https://github.com/schapirolab/meta-CLS
+
+The Meta-CLS paper extends La-MAML to meta-learn per-layer learning rates (`alpha_lr` as learnable parameters per layer). Key findings:
+
+1. **Higher layers → faster plasticity, sparser representation**: Adapts quickly to new tasks; sparse codes reduce interference
+2. **Lower layers → slower plasticity, denser representation**: Preserves general features; dense codes support transfer
+3. **Plasticity gradient emerges naturally** from interference-minimization pressure — it's not hand-designed
+4. **Two-pathway networks** (mimicking hippocampus + neocortex) show stronger gradient than single-pathway
+
+**Transfer to rune types**: Rune types map naturally to the "layer" concept:
+- `ash` = neocortical-equivalent (distilled, stable, cross-session) → low plasticity
+- `insight` = hippocampal-equivalent (fresh, episodic, hypothesis) → high plasticity
+
+This mapping is **stronger** than the CH-HNN transfer because it is structurally analogous (dual complementary systems), not just metaphorically similar.
+
+**Transfer weakness**: Meta-CLS derives its gradient from gradient-based meta-learning (MAML), which requires a training signal and backpropagation. KenazAI's rune system has no backpropagation — the "training signal" is discrete agent behavior (acted_on, recall, contradiction). The gradient shape must be hand-designed rather than meta-learned.
+
+---
+
+## 4. Candidate Update Signals
+
+### Signal A: `acted_on_rate` (Existing)
+
+**Definition**: `acted_on_count / total_recall_count` over the last 90 days
+
+**Mechanism**: When `synapse_inscribe` is called with `related_rune_ids`, those rune IDs get `acted_on = 1` in `rune_usage_log` via `mark_acted_on()`. This indicates the recalled rune influenced the decision to inscribe.
+
+**Pros**:
+- Already implemented and tracked
+- Captures causal influence: the rune shaped agent behavior
+- Denominator (total_recalls) normalizes for recall frequency
+
+**Cons**:
+- Binary per-recall event; no magnitude signal
+- Only captured when `related_rune_ids` is explicitly passed by the agent
+- Many recall events are passive (browsing) — they inflate the denominator without meaningful signal
+
+**Recommended use**: Primary positive reinforcement signal. Good acted_on_rate = high quality.
+
+### Signal B: Recall Frequency (New)
+
+**Definition**: `total_recall_count` in the last N days (normalized to per-week)
+
+**Mechanism**: `rune_usage_log` already tracks every recall event with timestamp. Frequency can be computed without schema changes.
+
+**Pros**:
+- Captures "demand" — how often agents need this knowledge
+- High-frequency runes are clearly valuable even if `acted_on` is not always marked
+- Simple to compute from existing data
+
+**Cons**:
+- Does not distinguish quality — a wrong rune recalled repeatedly is still "high frequency"
+- Biased toward runes on high-churn code symbols
+- Does not capture causation (only correlation)
+
+**Recommended use**: Secondary positive signal; weight lower than acted_on_rate (0.3× multiplier).
+
+### Signal C: Contradiction Detection (New)
+
+**Definition**: Binary flag — `synapse_rune_conflicts()` returns HIGH or MEDIUM conflict for this rune against a newer rune on the same symbol
+
+**Mechanism**: `synapse_rune_conflicts` already scans for rune conflicts. When a new rune contradicts an existing one, the existing rune's confidence should decrease. Currently, contradiction only triggers the supersede mechanism (which requires the agent to explicitly supersede), not an automatic confidence update.
+
+**Pros**:
+- Direct quality signal — contradiction means the rune is wrong or outdated
+- Enables soft decay without deletion: rune confidence drops, then agent can investigate
+- Prevents zombie runes (high confidence, contradicted, never superseded)
+
+**Cons**:
+- Conflict detection is heuristic (keyword overlap, symbol match) — false positive risk
+- Requires `synapse_rune_conflicts` to be called at update time (overhead)
+- May create oscillations if two valid runes legitimately contradict (e.g., two approaches to a problem)
+
+**Recommended use**: Negative signal (confidence decrement). Apply only for HIGH conflict severity; ignore MEDIUM.
+
+### Signal D: Heimdall Session Health Delta (New)
+
+**Definition**: For sessions where a rune was recalled AND acted_on=1, measure the session health delta before/after task completion. Positive delta → rune was used in a successful task → reinforce. Negative delta → rune was used in a harmful task → weaken.
+
+**Mechanism**: Requires joining `rune_usage_log.task_id` to Heimdall's health measurement log. The `task_id` field is already tracked in `rune_usage_log`.
+
+**Pros**:
+- Outcome-based signal (not just behavior) — measures actual impact
+- Most semantically aligned with "did this rune help?"
+- No false positives: health delta is an objective measurement
+
+**Cons**:
+- Heimdall health measurement is not always available (requires Heimdall patrol to have run)
+- Requires cross-database join (rune_usage_log in memory.db, health data in Heimdall)
+- Latency: Heimdall data is available hours/days after the task, not in real-time
+- Signal sparsity: most runes will have insufficient paired health observations
+
+**Recommended use**: Reserved for future phase. Not recommended for initial implementation due to data sparsity.
+
+---
+
+## 5. Candidate Update Rules
+
+### Rule 1: CH-HNN-Inspired Metaplastic Rule (Recommended)
+
+**Formula**:
+
+```
+# Positive update (acted_on_rate > threshold OR high recall frequency)
+Δc_positive = α_type × signal_up × e^(-β × c)
+
+# Negative update (contradiction detected)
+Δc_negative = -α_type × signal_down × (1 - e^(-β × c))
+
+# Combined
+c_new = clamp(c + Δc_positive + Δc_negative, 0.60, 0.99)
+```
+
+Where:
+- `c` = current confidence value
+- `α_type` = per-rune-type base learning rate (see Section 6)
+- `signal_up` = composite positive signal: `0.7 × acted_on_rate + 0.3 × recall_frequency_normalized`
+- `signal_down` = contradiction signal: 1.0 if HIGH conflict, 0 otherwise
+- `β` = metaplastic steepness (proposed: β = 3.0)
+
+**Behavioral examples** (with β=3.0, α=0.05 for `insight` type):
+
+| c | Positive factor e^(-β·c) | Max Δc_positive | Negative factor (1-e^(-β·c)) | Max Δc_negative |
+|---|--------------------------|-----------------|-------------------------------|-----------------|
+| 0.65 | e^(-1.95) = 0.142 | 0.0071 | 0.858 | -0.043 |
+| 0.75 | e^(-2.25) = 0.105 | 0.0053 | 0.895 | -0.045 |
+| 0.85 | e^(-2.55) = 0.078 | 0.0039 | 0.922 | -0.046 |
+| 0.95 | e^(-2.85) = 0.058 | 0.0029 | 0.942 | -0.047 |
+
+**Key properties**:
+1. High-confidence runes receive **smaller positive updates** — stability preservation
+2. High-confidence runes receive **larger negative updates** — harder to maintain if contradicted
+3. This asymmetry is intentional: it's easier to establish than to maintain against evidence
+4. Convergence to ~0.99 requires many consistently acted_on recalls
+
+**Comparison to current Phase 5c**: Current flat +0.05 boost is equivalent to α=0.05, factor=1.0 regardless of c. The proposed rule replaces this with a decaying factor. At c=0.65, Δ is much smaller (0.007 vs 0.05), which actually makes low-confidence runes **slower to boost** — this seems counterintuitive but is correct: a new rune at 0.65 hasn't proven itself yet.
+
+**Calibration note**: β=3.0 is a starting proposal. β=1.0 would make the factor e^(-1·0.95) ≈ 0.39 (significant boost even at high confidence). β=5.0 would make e^(-5·0.95) ≈ 0.009 (almost no boost above 0.9). β=3.0 provides a meaningful gradient across the full [0.6, 0.99] range.
+
+### Rule 2: Simple Stability-Weighted Rule (Alternative)
+
+**Formula**:
+
+```
+# Positive update
+Δc = α_type × acted_on_rate × (1 - c)   # Saturating: slows as c approaches 1
+
+# Negative update  
+Δc = -α_type × 0.5 × c                  # Proportional: bigger runes fall harder
+
+c_new = clamp(c + Δc, 0.60, 0.99)
+```
+
+**Key properties**:
+1. Positive update uses `(1 - c)` as a natural saturation factor (simpler than exponential)
+2. Negative update is proportional to c — higher confidence runes decay faster on contradiction
+3. No free parameter β — fewer knobs to calibrate
+4. Mathematical behavior very similar to Rule 1 in [0.6, 0.99] range
+
+**Comparison**: Rule 2 is simpler and requires less justification. The exponential in Rule 1 adds steepness that may matter at high confidence values (0.92–0.99) but is minimal in the middle range. Rule 2 is more transparent and easier to reason about.
+
+**Recommendation**: Use Rule 2 for initial implementation, with Rule 1 available as an option via a configurable `β` parameter. If β is set, exponential mode activates; if absent, linear saturation mode is used.
+
+---
+
+## 6. Rune-Type Plasticity Tiering
+
+Inspired by Meta-CLS layer-wise learning rate gradient, the following tiering maps rune types to plasticity (α_type values):
+
+| Tier | Rune Types | α_type | Rationale |
+|------|-----------|--------|-----------|
+| **Ultra-stable** (neocortical) | `ash` | 0.01 | Distilled cross-session insights with 45-day half-life; these represent validated wisdom across many sessions. Should only change with overwhelming evidence. |
+| **Stable** (structural) | `decision`, `fix` | 0.02 | Architectural decisions and bug fixes represent committed choices. Contradictions should be taken seriously but not easily overturned. |
+| **Moderate** (operational) | `pattern`, `risk` | 0.03 | Code patterns and risk assessments are reusable but context-dependent. Risk levels can legitimately change as systems evolve. |
+| **Plastic** (hippocampal) | `insight`, `summary` | 0.05 | Fresh observations and summaries are hypothesis-level. They should update readily based on new evidence. |
+
+**Justification for tiering**:
+- `ash` runes are explicitly designed to be "distilled, stable" — applying the full α=0.05 would undermine this property
+- `decision` runes record why a design choice was made — changing them too easily erases architectural memory
+- `insight` runes are the most analogous to hippocampal fast-binding (CLS theory) — they should be plastic
+- `summary` runes can safely drift as the summarized content evolves
+
+**Interaction with supersede mechanism**: The tiering does NOT prevent superseding. An agent can always explicitly supersede a rune. The tiering only controls the automatic confidence update rate. A `decision` rune can still be corrected by a new `decision` rune via `synapse_inscribe(supersedes=...)`.
+
+---
+
+## 7. Floor and Ceiling Behavior
+
+### Confidence Floor (0.60)
+
+**Current behavior**: The floor is enforced by SQL CHECK constraint but never approached in practice — no mechanism drives confidence downward in storage.
+
+**Proposed behavior for negative updates**: 
+- Floor remains 0.60 — do not lower it or remove the CHECK constraint
+- A rune at 0.60 is "lowest confidence retained" — it signals "this knowledge is uncertain"
+- Do NOT auto-supersede at floor: allow runes to sit at 0.60 as "weak hypotheses"
+- If confidence reaches 0.60 and contradiction persists, require explicit human/agent action to supersede
+
+**Rationale**: Auto-superseding at floor would cause silent knowledge loss. The rune should remain visible to agents who can decide whether to supersede or recover it.
+
+### Confidence Ceiling (0.99)
+
+**Current behavior**: Enforced by `min(0.05, 0.99 - c)` in Phase 5c. Never reaches 1.0.
+
+**Proposed behavior**: Retain 0.99 ceiling. Rationale:
+- 1.0 would imply absolute certainty, which is epistemically inappropriate for agent-generated knowledge
+- 0.99 provides a meaningful "near-certain" signal while preserving epistemic humility
+- The `confidence >= 0.9` decay exemption already protects high-confidence runes
+
+**Rune protection at ceiling**: Consider adding a "frozen" state for runes that have been at `confidence >= 0.95` for 30+ days AND have never been contradicted. These would be immune to the automatic update rule (only explicit supersede can change them). This mirrors CH-HNN's long-term potentiation analogy.
+
+---
+
+## 8. Risk Analysis
+
+### Risk 1: Confidence Distribution Shift
+
+**Description**: If the update rule runs frequently, high-acted-on runes converge to 0.99 faster. The top confidence tier grows → ranking becomes less differentiated.
+
+**Impact**: `recall_with_mode` uses `confidence * 0.12` as a score boost (observed in `score_breakdown`). If many runes cluster at 0.99, this term becomes a constant and stops differentiating quality.
+
+**Mitigation**: 
+- Apply update at most once per rune per 7-day window (not every `apply_usage_boosts` invocation)
+- Simulate distribution before deploying (see Section 10)
+- Consider reducing the boost multiplier in score calculation if top-cluster problem emerges
+
+### Risk 2: Contradiction Race Condition
+
+**Description**: Two agents working in parallel inscribe contradicting runes on the same symbol. Both runes detect each other via `synapse_rune_conflicts`. Both get confidence decremented. Neither agent supersedes. Both runes survive at low confidence.
+
+**Impact**: Knowledge fragmentation — two contradicting low-confidence runes both remain in the system, both returned in recall.
+
+**Mitigation**: 
+- Require minimum N=2 contradiction observations before applying negative update (single conflict may be transient)
+- Add a `contradiction_count` field to runes table (future schema change, not in this spec)
+- Current `superseded_by` mechanism remains the authoritative conflict resolution path
+
+### Risk 3: Backward Compatibility of Confidence Distribution
+
+**Description**: Downstream consumers of `synapse_recall` depend on the current confidence distribution. External tools (Cortex, Hippocampus) that rank or filter by confidence would be affected if the distribution shifts significantly.
+
+**Impact**: Runes that were mid-ranked might rise/fall unexpectedly. Score-based thresholds (e.g., Cortex's 0.85 filter) might change what's returned.
+
+**Mitigation**:
+- The proposed update stays within [0.60, 0.99] — no out-of-range values
+- Changes are gradual (max Δ per update ≈ 0.007 for high-confidence runes) — no sudden jumps
+- The `recall_with_mode` score formula is resilient to small confidence changes
+
+### Risk 4: Signal Sparsity for New Runes
+
+**Description**: A rune inscribed 2 days ago has minimal recall history. The `acted_on_rate` is unstable (1 event = 100% rate or 0%). The update rule might apply aggressive updates to new runes before sufficient evidence accumulates.
+
+**Mitigation**:
+- Apply update only if `total_recall_count >= 3` in the window (minimum sample size)
+- New runes (< 7 days old) are exempt from automatic updates
+
+### Risk 5: FTS5 Trigger on Confidence Update
+
+**Current system**: `runes_au` trigger in memory.rs:1222 fires `AFTER UPDATE ON runes` and re-indexes FTS5. If `apply_usage_boosts` updates many runes in a batch, each update triggers a separate FTS5 re-index.
+
+**Impact**: For a batch of 50 confidence updates, that's 50 FTS5 write operations — potential lock contention (the very bug documented in lines 26-37 of memory.rs).
+
+**Mitigation**: 
+- Wrap the update batch in a single SQLite transaction
+- Current `apply_usage_boosts` does not use a transaction — this should be added regardless of metaplasticity adoption
+
+---
+
+## 9. Interaction with Existing Mechanisms
+
+### 9.1 Phase 5c Boost
+
+The proposed Rule 1/2 **replaces** the current flat `+0.05` boost in `apply_usage_boosts()`. The eligibility criteria can remain the same (`acted_on_rate > 0.5`), but the boost magnitude changes from flat to type-weighted and confidence-scaled.
+
+The current rule:
+```rust
+let boost = (0.05_f64).min(0.99 - confidence);
+```
+
+Would become (Rule 2 example, α=0.05 for insight):
+```rust
+let boost = (α_type * acted_on_rate * (1.0 - confidence)).min(0.99 - confidence);
+```
+
+### 9.2 Score-Time Decay (Heimdall)
+
+The Heimdall ephemeral decay (`effective_score *= 0.85`) is **unchanged**. It operates at presentation time and does not write to the DB. The two mechanisms are orthogonal:
+- Stored confidence = long-term quality signal
+- Score-time factor = short-term recency/decay signal
+
+This is analogous to CLS theory's fast-binding (hippocampal/score-time) vs. slow consolidation (neocortical/stored).
+
+### 9.3 Strategy Sigil Confidence Evolution
+
+Sigils use a separate confidence evolution system (`record_strategy_outcome`: success +0.05, failure -0.10). This mechanism is appropriate for strategy sigils (which track success/failure counts explicitly) and is **not changed** by this proposal. The rune update rule is only for the `runes` table.
+
+### 9.4 Curiosity System (EFE)
+
+The Curiosity system in `curiosity.rs:449` uses `acted_on_rate` from `rune_usage_log` to compute knowledge gap scores. If confidence updates are triggered by the same signal, there could be feedback: higher confidence → lower curiosity → fewer recall events → slower future confidence updates. This dampening is actually desirable — it prevents runaway confidence for runes that no longer need attention.
+
+---
+
+## 10. Simulation Plan
+
+Before any implementation, a dry-run simulation must validate the update rule against historical data.
+
+### 10.1 Data Collection
+
+```sql
+-- Query 1: Current rune confidence distribution
+SELECT type, 
+       COUNT(*) as count,
+       AVG(confidence) as avg_conf,
+       MIN(confidence) as min_conf,
+       MAX(confidence) as max_conf
+FROM runes
+WHERE superseded_by = '' AND verified != 'rejected'
+GROUP BY type;
+
+-- Query 2: Recall history per rune (last 90 days)
+SELECT r.id, r.type, r.confidence,
+       COUNT(rul.rowid) as total_recalls,
+       COALESCE(SUM(rul.acted_on), 0) as acted_on_count
+FROM runes r
+LEFT JOIN rune_usage_log rul ON rul.rune_id = r.id
+  AND rul.recalled_at >= (strftime('%s','now') - 90*86400)
+WHERE r.superseded_by = '' AND r.verified != 'rejected'
+GROUP BY r.id;
+```
+
+### 10.2 Simulation Logic (Python pseudocode)
+
+```python
+import math, sqlite3
+
+def proposed_boost(confidence, rune_type, acted_on_rate, total_recalls):
+    # Skip if insufficient data
+    if total_recalls < 3:
+        return 0.0
+    if acted_on_rate <= 0.5:
+        return 0.0
+    
+    # Type-based alpha
+    alpha = {
+        'ash': 0.01, 'decision': 0.02, 'fix': 0.02,
+        'pattern': 0.03, 'risk': 0.03,
+        'insight': 0.05, 'summary': 0.05
+    }.get(rune_type, 0.03)
+    
+    # Rule 2 (simple saturation)
+    boost = alpha * acted_on_rate * (1.0 - confidence)
+    return min(boost, 0.99 - confidence)
+
+# Load data from SQLite memory.db
+conn = sqlite3.connect('.synapse/memory.db')
+runes = conn.execute("""
+    SELECT r.id, r.type, r.confidence,
+           COUNT(rul.rowid), COALESCE(SUM(rul.acted_on), 0)
+    FROM runes r
+    LEFT JOIN rune_usage_log rul ON rul.rune_id = r.id
+      AND rul.recalled_at >= strftime('%s','now') - 90*86400
+    WHERE r.superseded_by = '' AND r.verified != 'rejected'
+    GROUP BY r.id
+""").fetchall()
+
+results = []
+for rune_id, rune_type, conf, total_recalls, acted_on in runes:
+    rate = acted_on / total_recalls if total_recalls > 0 else 0
+    current_boost = min(0.05, 0.99 - conf) if rate > 0.5 else 0
+    proposed = proposed_boost(conf, rune_type, rate, total_recalls)
+    results.append({
+        'id': rune_id, 'type': rune_type, 'confidence': conf,
+        'current_boost': current_boost, 'proposed_boost': proposed,
+        'delta': proposed - current_boost
+    })
+```
+
+### 10.3 Success Criteria for Simulation
+
+1. **No out-of-range values**: All `confidence + proposed_boost` stays in [0.60, 0.99]
+2. **Monotonicity preserved**: Higher acted_on_rate → larger boost (for same type and confidence)
+3. **Type ordering preserved**: For same acted_on_rate and confidence, `ash` boost < `decision` boost < `insight` boost
+4. **Distribution shift bounded**: P90 confidence after simulation should not exceed current P90 + 0.05
+5. **No regression on zero-signal runes**: Runes with 0 recalls are unchanged
+
+### 10.4 Historical Validation
+
+For runes that have been explicitly superseded (i.e., judged "wrong" by agents), check whether the proposed rule would have lowered their confidence before supersede. If contradiction detection was available, would their confidence have dropped? This provides a retrospective validation signal.
+
+---
+
+## 11. Verdict
+
+### GO / NO-GO / NEEDS-MORE-EVIDENCE
+
+**VERDICT: CONDITIONAL GO**
+
+### Supporting Evidence
+
+1. **CH-HNN transfer is plausible**: The core intuition — high-weight synapses are more stable — maps naturally to "high-confidence runes should be harder to move." The exponential formula captures this shape. The mathematical derivation from neural training does not transfer, but the behavioral analogy is sound.
+
+2. **Meta-CLS transfer is strong**: Layer-wise plasticity gradient → rune-type tiering is structurally analogous. `ash` runes behave like neocortical slow-binding; `insight` runes behave like hippocampal fast-binding. This is not metaphor — it is the same functional architecture KenazAI was designed to emulate.
+
+3. **Low implementation risk**: The change is confined to `apply_usage_boosts()` in memory.rs — a single function, no schema migration, no KuzuDB changes. The new formula is a drop-in replacement for the flat +0.05 boost.
+
+4. **Existing infrastructure supports it**: `rune_usage_log` already tracks `acted_on` and `task_id`. The signal needed for Rule 2 is already being collected. No new telemetry is needed for the first phase.
+
+### Conditions for GO
+
+1. **Simulation must pass** (Section 10.3 criteria) before implementation
+2. **Minimum recall threshold** (≥3 recalls) must be enforced to avoid noisy updates on sparse data
+3. **Transaction batch** must be added to `apply_usage_boosts` to prevent FTS5 lock contention (Risk 5)
+4. **Contradiction signal** (Signal C) deferred to Phase 2 — initial implementation uses only Signal A (acted_on_rate)
+
+### Why NOT a NO-GO
+
+The existing Phase 5c mechanism is already a form of plasticity (flat +0.05). The proposed change is an improvement in calibration, not a philosophical shift. The risk of breaking existing semantics is low because: (a) updates are small and bounded, (b) no schema changes are needed, (c) the confidence floor/ceiling enforcement is preserved.
+
+### What Would Change This Verdict
+
+- If simulation shows that the proposed rule creates **runaway clustering** at 0.99 for well-recalled runes (which would reduce ranking diversity), the β parameter should be increased or the update frequency reduced
+- If contradiction detection (Signal C) proves unreliable (high false positive rate), skip it entirely and rely solely on acted_on_rate
+- If Heimdall health deltas (Signal D) become reliably available across sessions, upgrade Signal D to primary — it is the highest-quality outcome signal available
+
+---
+
+## 12. Appendix: Code Locations
+
+| Component | File | Lines |
+|-----------|------|-------|
+| `apply_usage_boosts` (Phase 5c) | `memory.rs` | 4611–4688 |
+| `mark_acted_on` | `memory.rs` | 4583–4608 |
+| `inscribe_rune` | `memory.rs` | 1615–1668 |
+| `validate_confidence` | `memory.rs` | 393–400 |
+| Rune schema (CHECK constraint) | `memory.rs` | 748–756 |
+| `rune_usage_log` schema | `memory.rs` | 1163–1173 |
+| Score-time decay (Heimdall) | `memory.rs` | 4691–4720 |
+| `acted_on_rate` in curiosity | `curiosity.rs` | 449–468 |
+| FTS5 update trigger | `memory.rs` | 1222–1227 |
+
+---
+
+*Design Only — Implementation tracked separately. Next action: run simulation script against live memory.db and validate against Section 10.3 success criteria.*