decay_cycle.py: ACT-R base-level path has no production caller, and its name collides with the live ADAPTIVE_DECAY mechanism

[cdeust]

Reported by an external reader (Claude Discord) who read mcp_server/core/decay_cycle.py and concluded that heat is ACT-R frequency-driven — B_i = ln(n) − d·ln(L), retrieval feeds heat, therefore ossification risk. That reading is wrong about live behaviour, but the file gives them no way to know it. Verified 2026-08-02.

Two distinct defects

1. Dead code. compute_decay_updates (decay_cycle.py:264) and the whole ACT-R block it dispatches to — compute_actr_base_level:134, actr_activation_to_heat:155, _compute_actr_decay:168 — have no production caller. The consolidation path imports only compute_entity_decay:

mcp_server/handlers/consolidation/decay.py:19:from mcp_server.core.decay_cycle import compute_entity_decay

The only remaining references are tests_py/core/test_decay_cycle.py and tests_py/benchmarks/benchmark_harness.py. This violates coding-standards.md §9: "Dead code … with no current caller. If it's built, it must be called."

2. Name collision with a live, published mechanism. The ADAPTIVE_DECAY reported in the LoCoMo v3 ablation table (ΔMRR −0.0163 / ΔR@10 −0.020, benchmarks/results/ablation/locomo_v3/summary.csv) is not this ACT-R code. The live mechanism is an adaptive rate on the Ebbinghaus path:

• mcp_server/core/thermodynamics.py:286 — is_mechanism_disabled(Mechanism.ADAPTIVE_DECAY) inside compute_decay
• mcp_server/core/pg_recall.py:253
• mcp_server/infrastructure/memory_config.py:146-148 — ADAPTIVE_DECAY_ENABLED, ADAPTIVE_DECAY_MIN_RATE=0.90, ADAPTIVE_DECAY_MAX_RATE=0.999

A reader who goes from the file to the ablation table connects two unrelated things, and the published number gets attributed to code that never runs.

Why this matters beyond tidiness

The actual design property — retrieval never resets the decay clock, so a popularity-ossification loop cannot form — is real and currently invisible. update_memory_access (pg_store.py:855-861) writes only last_accessed and access_count; effective_heat() (pg_schema.py:1073-1130) decays from heat_base_set_at, stamped at write. The dead ACT-R block actively argues the opposite to anyone reading the source.

Proposed fix

1. Delete compute_decay_updates + the three ACT-R functions + _ACT_R_DECAY_D / _ACT_R_NOISE_S, and the tests that exist only to cover them.
2. If the ACT-R model is wanted later, it comes back with a caller, not before.
3. Rename or document the surviving ADAPTIVE_DECAY so the ablation table and the code agree on what the name denotes.
4. State the write-anchored/no-reheat property explicitly where a reader will hit it — decay_cycle.py module docstring and the effective_heat header.

Acceptance

• grep -rn "compute_decay_updates\|compute_actr_base_level" mcp_server/ tests_py/ returns nothing.
• The ADAPTIVE_DECAY name resolves to exactly one mechanism, and benchmarks/results/ablation/locomo_v3/summary.csv can be traced to it from the code without ambiguity.
• No benchmark regression: LoCoMo MRR/R@10 unchanged within the ±0.002 per-row noise floor at n=1986 (the ACT-R path is uncalled, so the expected delta is exactly zero).

[cdeust]

Correction — the third claim in this issue is WRONG, and it is the load-bearing one

Adversarial re-verification (2026-08-02) refutes the claim in the "Why this matters beyond tidiness" section above. Retrieval does reset the decay clock in production. Anyone reading this issue should treat that paragraph as retracted.

The mechanism I missed is reconsolidation, not update_memory_access:

• mcp_server/core/pg_recall.py:437 — reconsolidation_apply(candidates, query=query, store=store) runs as a mandatory post-WRRF stage on every recall().
• mcp_server/core/recall_pipeline.py:1244-1249 — for each top-K candidate whose outcome.heat_delta != 0.0, calls store.bump_heat_raw(memory_id, new_heat).
• mcp_server/infrastructure/pg_store.py:724-741 — bump_heat_raw executes UPDATE memories SET heat_base = %s, heat_base_set_at = NOW() WHERE id = %s, resetting precisely the anchor that effective_heat (pg_schema.py:1073-1130) decays from.
• On by default: gated only by the ablation-only CORTEX_ABLATE_RECONSOLIDATION=1 (reconsolidation.py:172-174). heat_delta is bounded to [-0.10, +0.05] (reconsolidation.py:384-385), not identically zero.

My original evidence (update_memory_access at pg_store.py:855-861 writing only last_accessed / access_count) was correct in isolation and incomplete as an argument — it is not the only writer on the retrieval path.

This matches the published paper, which I contradicted. docs/arxiv-thermodynamic/main.tex:294 states heat "decays exponentially over time and is reheated on access", and :433 builds the steady-state argument on it: "a power law (long tail of cold items, short head of repeatedly-accessed hot items)". Reading the paper would have settled this immediately.

Consequence: "a popularity-ossification loop cannot form by construction" is false. Whether one forms in practice is an empirical question — it depends on the sign and magnitude distribution of decide_action's heat_delta for repeatedly-retrieved items — and it is untested. That is now the interesting open question, and it is worth its own issue.

What survives

• The dead-ACT-R claim stands, and should cite better evidence. compute_decay_updates + compute_actr_base_level / actr_activation_to_heat / _compute_actr_decay / _compute_single_decay have zero production callers on either backend (run_decay_cycle is backend-agnostic over the generic MemoryStore interface). The only callers are tests_py/core/test_decay_cycle.py and tests_py/benchmarks/benchmark_harness.py:761,825 — the latter a standalone __main__ script whose functions are named benchmark_*, so pytest never runs them. Replace the argument-from-absent-grep with the code's own statement: handlers/consolidation/decay.py:1-11 documents that heat decay moved to SQL effective_heat() at the A3 migration, and decay.py:47 returns "reason_for_zero": "lazy_decay_via_effective_heat". This is documented residue from a completed migration, not neglected code.
• The ADAPTIVE_DECAY name-collision claim stands. benchmarks/lib/ablation_runner.py:76-81 maps Mechanism.ADAPTIVE_DECAY to a patch of thermodynamics.compute_decay, and pg_recall.py:253 zeroes the heat fusion weight — neither is in decay_cycle.py. The published ΔMRR −0.0163 / ΔR@10 −0.020 reflects flattening the heat signal in WRRF fusion.

Follow-up worth checking separately

main.tex:298-299 cites thermodynamics.py::compute_decay as "Cortex's decay", but that function's only non-test caller is _compute_single_decay, which is itself uncalled in production. Whether the paper is describing a function that is off the live path needs its own verification before anything is asserted about it.