Cortex 3.12.0 — `consolidate` field report

[darval]

The previous report were done on copies of this db. I upgraded my main install to 3.12 and this was the results of running consolidate.

Cortex 3.12.0 — consolidate field report

Date: 2026-04-16
Version: cortex 3.12.0 (MCP plugin, alloy Postgres backend)
Store size: 66,277 memories (25,603 episodic / 40,675 semantic, 3,111 protected)
Context: First consolidate run after upgrade to 3.12.0; store includes a recent large claude-mem backfill import.

---

Summary

consolidate completes with status: "partial" due to one hard failure (emergence), plus three cycles whose output looks suspicious (cls, memify, homeostatic). Separately, post-consolidate recall behavior suggests homeostatic scaling is not effectively re-balancing a bimodal heat distribution.

Total duration: 1037s (17.3 min) on 66k memories.

---

Issue 1 — emergence stage crash (hard failure, causes status: partial)

"emergence": {
  "error": "AttributeError: module 'mcp_server.core.emergence_tracker' has no attribute 'generate_emergence_report'",
  "duration_ms": 0
}

• Stage runs last in the consolidate pipeline.
• AttributeError on mcp_server.core.emergence_tracker.generate_emergence_report.
• duration_ms: 0 — blows up at import/attribute-lookup, not mid-execution.
• Causes the whole consolidate call to report status: "partial" with failed_stages: ["emergence"] even though 8 preceding cycles succeeded.

Likely cause: 3.12.0 refactor renamed/moved generate_emergence_report but the caller wasn't updated. Fix is one of:

1. Restore the attribute on emergence_tracker.
2. Update the caller to the new name/location.
3. Guard with hasattr() + skip-with-warning so the emergence stage doesn't poison an otherwise-healthy consolidate.

Repro:

consolidate(decay=true, compress=true, cls=true, memify=true, deep=false)

on a store of ~66k memories.

---

Issue 2 — cls produces zero output across every axis

"cls": {
  "patterns_found": 0,
  "new_semantics_created": 0,
  "skipped_inconsistent": 0,
  "skipped_duplicate": 0,
  "causal_edges_found": 0,
  "episodic_scanned": 2000,
  "duration_ms": 16110
}

• Scanned 2,000 episodic memories in 16 s and produced zero patterns, zero new semantics, zero causal edges, and zero skips of any kind (skipped_inconsistent and skipped_duplicate both 0).
• All-zeros across every axis is suspicious. The store has 25,603 episodic + 40,675 semantic memories — in a corpus this size, finding zero patterns and zero near-duplicates simultaneously is implausible.
• Suggests one of:
  • Threshold tightened too aggressively in 3.12.0.
  • Scan window isn't selecting the right memories (e.g., only hot ones, only recent ones, only one domain).
  • Cycle early-returns before doing work due to a silent config miss, and just reports the zeros.

Ask: what signal confirms cls "actually ran" vs. "early-returned and wrote zeros"?

---

Issue 3 — memify strengthened/pruned zero, reweighted thousands

"memify": { "pruned": 0, "strengthened": 0, "reweighted": 2671, "duration_ms": 23769 }

• 2,671 reweighted is plausible, but 0 strengthened AND 0 pruned over 24 s is odd. May be intentional gating (reweight-only path) but worth confirming.

---

Issue 4 — heat distribution bimodality after decay; recall pinned to import bucket

"homeostatic": {
  "scaling_applied": true,
  "health_score": 0.2566,
  "mean_heat": 0.6553,
  "std_heat": 0.319,
  "bimodality": 0.8461,
  "memories_scanned": 66277,
  "duration_ms": 688447
}

Symptom at the user level: recall("hcrdashboard") and recall("UniFi dashboard Rust axum accessibility") return zero project-relevant results. Every top-8 hit is a backfilled claude-mem / homebase / thedotmack / simmer memory with heat ≥ 0.93. Hcrdashboard-specific memories either don't surface at all or are buried below the backfill bucket.

Readings consistent with a scaling bug:

• bimodality: 0.8461 — very high; heat is two distinct populations, not one distribution.
• health_score: 0.2566 — low.
• scaling_applied: true — the cycle claims to have renormalized, yet the bimodality and recall behavior say it didn't pull down the over-heated cluster.

Ask: does scaling_applied: true mean "successfully renormalized the distribution" or just "ran without raising"? If the former, the renormalization isn't doing what its name implies on this store. If the latter, the flag is misleading.

User workaround attempted: running decay=true (62,820 decayed in 249 s) did not meaningfully change recall ordering — the backfill bucket is still at ~0.94 heat after one full cycle.

---

Performance breakdown

Total consolidate: 1,037,502 ms (17.3 min) on 66,277 memories.

Stage	Duration (ms)	% of total
homeostatic	688,447	66.4 %
decay	249,461	24.0 %
memify	23,769	2.3 %
cascade	17,921	1.7 %
plasticity	17,495	1.7 %
cls	16,110	1.6 %
compression	4,421	0.4 %
pruning	3,235	0.3 %
emergence	0	0.0 % (crashed)

If the 3.12.0 release notes advertised consolidate performance improvements, the remaining bottleneck is homeostatic — two-thirds of wall time, scanning every memory. 688 s on 66 k rows scales poorly.

Ask: is the homeostatic cycle doing work that needs to touch every row on every run, or can it be incrementalized / batched / sampled like plasticity (2,000 sampled) and cls (2,000 scanned)?

---

What succeeded (for completeness)

Stage	Counts
decay	62,820 memories decayed; 8,069 entities decayed; 66,267 metabolic updates
plasticity	964 LTP / 3,224 LTD / 4,188 edges updated; 676,656 co-access pairs; 2,000 sampled
pruning	2,587 edges pruned; 1,454 entities archived
compression	176 compressed to gist; 3,111 protected skipped; 38,536 semantic skipped
cascade	502 advanced (labile → early_ltp); 1,234 scanned; 730 heartbeats written

These look healthy. No regressions observed in these stages.

---

Environment

• macOS (Darwin 25.4.0)
• MCP plugin: cortex 3.12.0
• Storage backend: alloy Postgres (DATABASE_URL-based, not SQLite)
• Vector search: enabled (has_vector_search: true)
• Last prior consolidation: 2026-04-15 14:06:55 UTC (~24 h before this run)
• Recent activity: claude-mem backfill import; ~330 new memories since last consolidate

---

Priority (from my seat)

1. P0 — fix emergence crash. It's a one-attribute error flipping otherwise-healthy runs to partial.
2. P1 — confirm or fix homeostatic scaling. If recall stays pinned to the import bucket after consolidate, the scaling cycle isn't delivering its promised renormalization, which is the most user-visible symptom.
3. P2 — investigate cls all-zeros. Could be a real finding, could be silent early-return; either way the result is indistinguishable from "didn't run" and deserves a diagnostic signal.
4. P3 — homeostatic performance. 66 % of wall time on a single cycle is worth a profile pass.

[cdeust]

Thanks for the field report — the JSON excerpts per stage plus the
user-level "recall(hcrdashboard) returns the wrong bucket" symptom made
diagnosis fast. Status per issue:

Issue 1 — emergence AttributeError — FIXED on main

Root cause exactly as you suspected: generate_emergence_report moved
from emergence_tracker into emergence_metrics when the module was
split to satisfy the 300-line file cap, but the caller in consolidate.py
wasn't updated. Same class of bug as the homeostatic_health import
fixed in 69d81fb.

Fix merged to main: c5a1862
(import change). The regression guard via invariant I2 — spelled out in
docs/invariants/cortex-invariants.md
— lands as a pytest in tests_py/invariants/test_I2_canonical_writer.py
this weekend so the next rename/split can't reintroduce the same class
of bug.

v3.12.1 release tag is not cut yet; planned this weekend as a hotfix
containing just this fix so you don't have to wait for the larger
refactor.

Issue 4 — homeostatic scaling isn't rebalancing — root cause found

Your diagnosis ("scaling_applied: true but the distribution stays
bimodal") is correct and the fix isn't in the homeostatic cycle — it's
upstream, in the write path.

Found the real culprit in mcp_server/handlers/remember.py:221-222:

heat = thermodynamics.apply_surprise_boost(
    1.0, gate["score"], get_memory_settings().SURPRISE_BOOST
)

Every new memory starts at baseline heat = 1.0. A backfill of 330+
memories in one minute all land in the [0.9, 1.0] bucket. That creates
the sharp peak you observed (bimodality: 0.85).

Turrigiano scaling (homeostatic_plasticity.compute_scaling_factor) is
mathematically order-preserving — its defining property per Tetzlaff
et al. 2011 Eq. 3. Multiplying every row by factor = 1.03 shifts the
mean but cannot flatten two peaks into one. So scaling_applied: true
technically ran; it just mathematically cannot do what you reasonably
expected.

Two changes land this weekend:

1. Backfill heat assignment fix: backfill_memories and
   import_sessions will compute an initial heat that reflects the age
   of the original conversation (a 6-month-old imported memory starts at
   heat ≈ 0.3, not 1.0), so the bulk cohort doesn't form at the top of
   the distribution to begin with. Optional initial_heat parameter on
   remember for callers that know the memory is historical.

2. Bimodality-aware homeostatic primitive: when
   bimodality_coefficient > 0.5, switch from multiplicative scaling to
   cohort-aware subtractive renormalization. The scaling_applied flag
   becomes scaling_applied: true/false + scaling_kind: "multiplicative" | "subtractive_cohort" | "none" so the output reports what actually
   happened, not just that the function returned.

3. Truth in reporting: scaling_applied gets renamed
   scaling_reduced_bimodality with an explicit before/after metric, so
   "ran without raising" is no longer indistinguishable from "rebalanced
   the distribution". That fixes your "flag is misleading" complaint at
   the primitive.

Issue 2 — cls all-zeros — diagnostic gap confirmed

Your read is right: with episodic_scanned: 2000 and every output at 0
(including skipped_inconsistent and skipped_duplicate), the output is
indistinguishable from "early-returned silently" vs "ran and found
nothing meaningful". Neither answer is useful.

Weekend fix: add reason_for_zero to the cls stats when all counts are
0, one of:

• below_min_confidence (threshold gate rejected everything)
• no_qualifying_entities (the entity filter starved the sample)
• insufficient_pairs (clustering couldn't form groups)
• passed_through (actually ran all the work, genuinely nothing new)

This is part of a broader audit we're running on every consolidation
stage: if a stage exits with zero mutations, it must report WHY in a way
that's greppable and alertable.

Issue 3 — memify 0 strengthened / 0 pruned / 2671 reweighted

Less urgent, but filed. Likely intentional gating (a reweight-only cycle
when no stage-transition thresholds are crossed), but the report should
disambiguate the same way as cls.

Performance — homeostatic 66% of wall time

Separate workstream you effectively kicked off in
#13. A multi-agent
scalability audit produced a structured plan to address this: the
homeostatic cycle stops touching rows at all, becoming an O(1) write to
a per-domain homeostatic_state row, with heat computed lazily at recall
time via a PL/pgSQL effective_heat() function. Plan in
docs/program/;
invariants and governance in
docs/invariants/
and ADR-0045.
Target: homeostatic wall-time < 100 ms on your 66 K store post-A3. That
migration is two weekends away, not this weekend.

Weekend deliverable summary (not yet tagged)

• v3.12.1 hotfix: the emergence_tracker import fix (already on main)
  plus the I2 regression test. Tag + release this weekend.
• v3.12.2 (if it converges over the weekend): backfill heat
  assignment fix, bimodality-aware homeostatic, cls + memify diagnostic
  signals. If it doesn't converge cleanly, it becomes next-week scope
  rather than a rushed release.

If you're open to it, running consolidate once more on your store after
v3.12.2 and sharing the JSON would close the loop on the user-level
symptom ("hcrdashboard buried under the claude-mem bucket"). And if the
run_a.json / run_b.json dumps from your earlier benchmark are still
around, they'd become the before-picture for the larger A3 migration.

Cheers.

[cdeust]

A3 landed this morning. Posting the delivery update so you know the
scalability refactor is finished and regression-validated before the
next v3.13 tag.

What A3 changed

Rewrote the heat subsystem around the principle that heat is a function,
not a stored state vector:

• memories.heat column renamed to heat_base (baseline, written once
  per real touch) + heat_base_set_at + no_decay pin flag.
• New effective_heat(m, now, factor) REAL PL/pgSQL function: computes
  the decayed view at read time using Kandel 2001 stage-dependent α,
  Yonelinas & Ritchey 2015 emotional damping β, Bahrick 1984 permastore
  floors. Single source of truth for invariants I1, I5, I7, I8.
• homeostatic_state(domain PRIMARY KEY, factor REAL) table. One row per
  domain. The homeostatic cycle writes ONE scalar per run instead of
  per-row Turrigiano scaling across the whole store.
• recall_memories() PL/pgSQL rewritten around a candidates CTE that
  prefilters on heat_base >= min_heat / factor (monotonic transform;
  index still usable). Every CTE reads from candidates; every m.heat
  became effective_heat(c, NOW(), factor).
• Decay cycle deleted. DECAY_MEMORIES_FN gone. The consolidate
  handler's decay stage now only cools entity heat (D2 out of scope);
  memory decay is lazy.
• Fold fallback: if |log(factor)| > log(2) (factor drifts outside
  [0.5, 2.0]), one batched UPDATE heat_base *= factor, factor = 1
  writes the accumulated correction back. Amortized to ~once per month
  per domain under normal load.
• All 8 pre-A3 heat writer sites collapsed to one canonical pair
  (bump_heat_raw + update_memories_heat_batch). I2 invariant
  allow-list shrunk from 11 to 7 sites, all on heat_base. Legacy
  SET heat = ... pattern fenced off by
  test_I2_no_legacy_heat_column_writes.
• Anchor, preemptive_context, mark_stale, pg_store, sqlite_store all
  refactored to the single A3 path. Zero flag-branching in Python —
  the kill switch is a DDL-level effective_heat_frozen() swap per
  design doc §9, not a runtime conditional.

Benchmark regression gate — all three PASS

Ran the full v3.11 benchmark suite against cortex_bench post-A3. Floors
from the README.

Benchmark	Cortex A3	README Floor	Delta	Status
LongMemEval R@10 (500 Q)	97.8%	97.8%	0.0 pp	PASS (exact)
LongMemEval MRR	0.881	0.882	−0.001	PASS (noise)
LoCoMo R@10 (1982 Q)	92.3%	92.6%	−0.3 pp	PASS (< 0.5pp)
LoCoMo MRR	0.791	0.794	−0.003	PASS (< 0.5pp)
BEAM-100K MRR (100 Q)	0.591	0.591	0.000	PASS (exact)
BEAM-100K R@10	79.0%	79.0%	0.0 pp	PASS (exact)

All deltas are within the 0.5pp measurement-noise tolerance set in the
design doc §8. BEAM-10M runs overnight; adding that result in a follow-up.

The zero-delta on BEAM-100K is the mathematical cleanest case:
benchmarks insert memories with heat_base_set_at = NOW() seconds
before the query, so hours_elapsed ≈ 0 → POWER(0.99787, 0) = 1.0 →
effective_heat = heat_base * factor = 1.0 * 1.0 = 1.0 — identical
to the pre-A3 stored heat = 1.0. WRRF sums preserved exactly.

What this means for the homeostatic 66% wall-time

The homeostatic cycle now writes one row (homeostatic_state.factor)
per run in the common case, regardless of store size. On your 66K store,
that's a 66,000× reduction in heat writes per consolidate run. The
dominant fsync/HOT-violation path from the original field report is
structurally removed, not tuned.

The fold fallback (rare) still writes per-row, but it's bounded by the
domain partition and triggers when the scalar has drifted outside
[0.5, 2.0] — expected ~once/month per domain under steady load. Not
a hot path.

What's next

• BEAM-10M overnight (floor 0.471 with Temporal Context Assembler).
  Result committed tomorrow.
• Phase 5: psycopg_pool + admission control + separate batch
  connection. This is the throughput side; A3 was the write-amplification
  side.
• v3.13.0 tag after BEAM-10M confirms the full regression envelope.

If you'd run consolidate on your store after tag cut and post the
new JSON, it closes the 66%-wall-time loop from your original report.

Commits for the A3 landing (main branch):

• 5e15a0b — single A3 path, legacy deleted
• 1db5ee3 — effective_heat underflow guards
• 1ef1376 — LongMemEval 500-Q PASS
• a071d89 — LoCoMo 1982-Q PASS
• d5b6711 — BEAM-100K PASS

Cheers.

[darval]

Cortex 3.13.2 — consolidate field report

Date: 2026-04-17
Version: cortex 3.13.2 (MCP plugin, Postgres backend)
Previous report: cortex-3.12.0-consolidate-report.md
Store size (pre-run): 66,440 memories (25,760 episodic / 40,680 semantic, 3,123 protected)
Store size (post-run): 66,442 memories (25,762 episodic / 40,680 semantic, 3,123 protected)
Context: First consolidate run after upgrade from 3.12.0 → 3.13.2. Previous consolidation: 2026-04-16T15:00:14 UTC (~22 h prior).

---

Summary

consolidate completes status: "ok" with failed_stages: [] — a clean bill of health.
The three P0/P1/P2 items called out in the 3.12.0 report are all addressed. Two observations remain
(not regressions), called out in §Observations below.

Total duration: 431 s (7.2 min) on 66 k memories — a 58 % reduction from 3.12.0 (1,037 s).
The homeostatic stage is still the hot spot (336 s, 78 % of wall time) but its absolute cost
dropped by half.

Metric	3.12.0	3.13.2	Δ
status	partial	ok	✅
failed_stages	["emergence"]	[]	✅
Total duration	1,037 s	431 s	−58 %
homeostatic duration	688 s	336 s	−51 %
avg_heat (post-run)	~0.655	0.567	↓ (heat pulled down)
Recall quality on active-project query	all top-8 hits from a single import bucket	top-8 results shifted to genuinely relevant memories	✅

---

What got fixed

✅ P0 — emergence crash is gone

3.12.0 raised AttributeError: module 'mcp_server.core.emergence_tracker' has no attribute 'generate_emergence_report'
at stage entry, flipping the whole run to partial.

3.13.2 returns a structured emergence payload with forgetting-curve fit, schema-acceleration,
phase-locking metrics, stage distribution, and interference — evidence the attribute was
re-exposed (or the caller re-wired) correctly:

"emergence": {
  "timestamp": "2026-04-17T13:25:41.474415+00:00",
  "memory_count": 66439,
  "forgetting_curve": { "curve_type": "exponential", "r_squared": 0.0016,
                        "half_life_hours": 9180.8, "retention_at_24h": 0.6354,
                        "decay_rate": 7.5e-05, "initial_retention": 0.6365 },
  "phase_locking":    { "encoding_phase_count": 33233, "retrieval_phase_count": 33206,
                        "encoding_phase_avg_heat": 0.9153, "retrieval_phase_avg_heat": 0.3819,
                        "phase_benefit": 0.5334,
                        "encoding_phase_survival": 0.9944, "retrieval_phase_survival": 0.9943 },
  "stage_distribution": { "early_ltp": 4675, "labile": 61530, "late_ltp": 233, "consolidated": 1 },
  "avg_interference": 0.1632,
  "duration_ms": 222
}

✅ P1 — homeostatic scaling now makes a visible difference

3.12.0 reported scaling_applied: true but bimodality: 0.8461, health_score: 0.2566,
avg_heat: 0.655 — and recall stayed pinned to a single heavily-imported memory bucket
(all top-8 results came from one backfill source at heat ≥ 0.93).

3.13.2 reports a named scaling kind (cohort_correction), a cohort size it operated on
(33,604), and both before/after bimodality readings so the operator can see whether the
cycle actually moved the distribution:

"homeostatic": {
  "scaling_applied": true,
  "scaling_kind": "cohort_correction",
  "bimodality_before": 0.8433,
  "bimodality_after":  0.8427,
  "cohort_size": 33604,
  "health_score": 0.2567,
  "mean_heat": 0.6487,
  "std_heat": 0.3162,
  "bimodality": 0.8433,
  "memories_scanned": 66439,
  "duration_ms": 335984
}

User-visible outcome: recall against a query for the currently-active project now returns
the project's own memories in the top ranks (scores 1.30, 1.26, 1.23, 1.22, 1.13, 1.11, 1.10),
with heat in the 0.39–0.82 band. The over-heated import bucket no longer dominates. A second
probe — a more specific multi-keyword query — returned 7/8 on-topic hits, the 8th being a
legitimate cross-domain match. Strategic ordering and reranking both report true in the
response enhancements block. This is the most important behavioural improvement in the
release for a store in this shape.

Caveat worth flagging: the bimodality_before/after delta this run was tiny
(0.8433 → 0.8427, a 0.07 % reduction). The recall ordering improved dramatically anyway,
which suggests the operative fix may be elsewhere (reranker, query dispatch, heat-weight
interaction) rather than in the bimodality number itself. The bimodality field still shows
a highly bimodal distribution — so the diagnostic signal has not changed, only the
observable impact on recall has.

✅ P2 — cls and memify all-zeros now carry a reason code

3.12.0 emitted "cls": {"patterns_found": 0, …, "episodic_scanned": 2000, "duration_ms": 16110}
with no way to distinguish "early-return on config" from "genuinely nothing to do."

3.13.2 adds reason_for_zero / reason_for_inaction:

"cls":   { "patterns_found": 0, "episodic_scanned": 2000,
           "reason_for_zero": "below_min_pattern_size",
           "duration_ms": 21403 },
"memify":{ "pruned": 0, "strengthened": 0, "reweighted": 2662,
           "reason_for_inaction": "reweight_only_gate",
           "duration_ms": 20839 }

Both reasons are self-explanatory (below_min_pattern_size = 2 k-sample is under the cluster
threshold; reweight_only_gate = this path is intentionally reweight-only). This resolves
the P2 observability concern from the earlier report.

✅ Performance — homeostatic cut in half

3.12.0: 688 s / 1,037 s total = 66 % of wall time.
3.13.2: 336 s / 431 s total = 78 % of wall time (still dominant, but total cost ↓ 51 %).

---

Performance breakdown (3.13.2)

Total consolidate: 430,874 ms (7.2 min) on 66,439 memories.

Stage	3.13.2 ms	% of total	3.12.0 ms	Δ
homeostatic	335,984	78.0 %	688,447	−51 %
cls	21,403	5.0 %	16,110	+33 %
memify	20,839	4.8 %	23,769	−12 %
cascade	17,245	4.0 %	17,921	−4 %
compression	12,594	2.9 %	4,421	+185 %
pruning	3,645	0.8 %	3,235	+13 %
plasticity	1,081	0.3 %	17,495	−94 %
decay	210	0.0 %	249,461	−99.9 %
emergence	222	0.1 %	0	(crashed in 3.12)

The decay collapse is explained by a new mechanism visible in the output:
"reason_for_zero": "lazy_decay_via_effective_heat" — decay is now computed on-read rather
than in a batched sweep (0 memories actively decayed vs. 62,820 last time; 1,350 entities
decayed vs. 8,069 last time). Same with plasticity — 2,000 sampled (unchanged) but 1 s
instead of 17 s. These look like legitimate algorithmic improvements, not missed work.

compression rose from 4.4 s to 12.6 s while compressing 252 memories (vs. 176 in 3.12.0),
so throughput per-memory is similar; the extra time is proportional to work done.

---

What succeeded (for completeness)

Stage	Counts (3.13.2)
decay	0 memories decayed (lazy via effective heat); 1,350 entities decayed
plasticity	42 LTP / 5,010 LTD / 5,052 edges updated; 1,932 co-access pairs; 2,000 sampled
pruning	2,405 edges pruned; 1,623 entities archived
compression	252 compressed to gist; 3,123 protected skipped; 38,539 semantic skipped
cascade	504 advanced (labile → early_ltp); 1,235 scanned; 726 heartbeats written
emergence	Full metrics emitted; avg_interference: 0.163; phase_benefit: 0.533

---

Observations (not regressions)

O1 — bimodality remains high; cohort_correction moved it <0.1 %

homeostatic.bimodality_before: 0.8433 → bimodality_after: 0.8427. The scaling is now
instrumented, which is the correct fix to the P1 observability gap, but the underlying
distribution still looks bimodal. Recall quality improved dramatically anyway (see P1
outcome above), which suggests:

• Either the bimodality metric is over-weighting tails that don't affect retrieval, OR
• The user-visible improvement came from a different change in 3.13.2 (e.g., rerank, query
  dispatch, heat-weight mix) and cohort_correction is additive but small.

Ask for upstream: if cohort_correction is intended to collapse bimodality, why did a
336 s cycle move it 0.07 %? Is the target population correctly scoped? (cohort_size: 33,604
= roughly half the store.)

O2 — schema_acceleration reports inconsistent_count: 66439, consistent_count: 0

"schema_acceleration": {
  "consistent_count": 0,
  "inconsistent_count": 66439,
  "consistent_consolidated_fraction": 0.0,
  "inconsistent_consolidated_fraction": 0.0,
  "acceleration_ratio": 1.0
}

Every memory classified as "inconsistent" and zero as "consistent" is a suspicious all-or-
nothing. Either the schema-check is strict to the point of being binary in practice, or the
"consistent" bucket has a bootstrap problem (nothing has ever been marked consistent on this
store). acceleration_ratio: 1.0 is the default when both fractions are zero — neutral, but
uninformative.

Ask for upstream: what classifies a memory as "schema-consistent"? If it requires a
pre-existing schema to match against and no schemas have been promoted yet, this metric may
only become meaningful after the first cls pass crosses its threshold (currently gated
by below_min_pattern_size).

O3 — forgetting_curve.r_squared: 0.0016

"forgetting_curve": {
  "curve_type": "exponential", "r_squared": 0.0016,
  "half_life_hours": 9180.8, "retention_at_24h": 0.6354,
  "decay_rate": 7.5e-05, "initial_retention": 0.6365
}

An r² of 0.0016 on an exponential fit means the model explains ~0.2 % of variance —
essentially, the store's retention pattern does not follow a single exponential. This may
be correct (bimodal store → two decay regimes won't fit one exponential), but the
half_life_hours: 9180.8 (~382 days) is being reported with a fit that the r² says doesn't
describe the data. Consumers of this number may be misled.

Ask for upstream: should emergence.forgetting_curve gate its derived metrics
(half_life_hours, retention_at_24h) on a minimum r²? Or emit them with a
"fit_quality": "poor" flag?

---

Recall probes (user-visible verification)

Two queries were run against the store after consolidate:

• Probe 1 — a single-token query naming the currently-active working project.
  3.12.0 behaviour: all top-8 hits came from an unrelated high-heat import bucket.
  3.13.2 behaviour: 8/8 top hits are drawn from the active project's own memories
  (score range 1.07–1.30, heat range 0.39–0.82).
• Probe 2 — a 5-token phrase combining the project, its language, its HTTP framework,
  and a quality attribute.
  3.13.2 behaviour: 7/8 top hits directly match the project's design-decision memories
  (score range 1.18–1.95); the 8th is a benign cross-domain match on the shared keyword.

In both probes the response enhancements block reports reranked: true and
strategic_ordering: true, with query_expanded: false and multihop_applied: false. The
ordering clearly prioritizes design-decision memories over tool-log noise.

This is the exact failure mode 3.12.0 exhibited (every hit was an over-heated import memory
at heat ≥ 0.93) and it is demonstrably fixed in 3.13.2.

---

Priority (from my seat)

1. P2 — bimodality reporting vs. cohort_correction effectiveness. Instrumentation is
   now correct (before/after + kind + cohort_size). Remaining question is whether the 336 s
   cycle is actually moving the number meaningfully or if the user-visible improvement comes
   from elsewhere in the pipeline. See Observation O1.
2. P2 — schema_acceleration all-or-nothing. 0 / 66,439 split is likely a bootstrap
   artifact; should become informative once cls promotes the first schemas. See O2.
3. P3 — forgetting_curve.r_squared quality gating. Emit a fit-quality flag when r² is
   very low, so consumers don't take half_life_hours as load-bearing. See O3.
4. (nice-to-have) homeostatic remains the 78 % wall-time slice. Now 336 s — half of what
   it was — but still the obvious next target if further throughput is needed.

All three P0/P1/P2 items from the 3.12.0 report are addressed. This release is a clear
forward step for this store.

---

Environment

• macOS (Darwin 25.4.0)
• MCP plugin: cortex 3.13.2 (upgraded from 3.12.0 on 2026-04-16)
• Storage backend: Postgres (DATABASE_URL-based, not SQLite)
• Vector search: enabled (has_vector_search: true)
• Last prior consolidation: 2026-04-16T15:00:14 UTC (~22 h before this run)
• Recent activity: ~165 new memories since last consolidate