epmem: opt-in kernel-mediated copy of long-present constant WMEs into smem, with episode eviction (experimental)

[kimjune01]

What this PR does

Adds an opt-in mechanism that periodically scans episodic memory for constant WMEs continuously present for ≥ N episodes and inserts them into semantic memory via the kernel's CLI_add path, outside the agent's production system. Optionally evicts old episode rows after each run.

All four parameters are off by default. The scan (including eviction) only runs when consolidate=on; setting consolidate-evict-age alone has no effect.

This is kernel-mediated semantic memory insertion

The central architectural choice in this PR is that a kernel-side scan, not the agent's own productions, decides what gets added to semantic memory. The scan is driven by an epmem persistence heuristic (continuous presence for N episodes). This is not a claim about how Soar should derive semantic memory, or about which regularities "deserve" promotion. It is a mechanism that exposes one heuristic and lets users decide when and whether to invoke it.

Any agent that queries smem after a run will observe entries that were not there before. Any agent that queries episodes older than the eviction age will get different retrieval results. These are deliberate semantic changes, not transparent optimizations.

Open for discussion on whether such a mechanism belongs in Soar and under what conditions. Not a merge proposal.

Parameters

Parameter	Type	Default	Description
consolidate	on/off	off	Enable the periodic scan
consolidate-interval	integer	100	Episodes between scans
consolidate-threshold	integer	10	Minimum continuous presence in episodes before a WME qualifies
consolidate-evict-age	integer	0 (off)	Minimum episode age before eviction eligible; 0 disables eviction

Algorithm

Step	Operation
Scan	Constant WMEs present in epmem_wmes_constant_now with start_episode_id ≤ current - threshold
Dedup	Exclude wc_ids already recorded in epmem_consolidated tracking table
Group	Cluster qualifying WMEs by epmem parent node
Sanitize	Reverse-hash attribute/value strings, skip empty or unquotable strings
Write	Build (<c_n> ^attr value ...) string per parent, pass to CLI_add
Mark	Insert consolidated wc_ids into epmem_consolidated to prevent reprocessing
Evict	If consolidate-evict-age > 0, delete point and range rows and episode rows older than current - evict-age; _now intervals are untouched
Trigger	Every consolidate-interval episodes

The scan uses a single SQL statement joining epmem_wmes_constant, epmem_wmes_constant_now, and the dedup table. For WMEs currently open in _now, "continuous presence for N episodes" is detectable by comparing start_episode_id against current - threshold, avoiding aggregation over episode history. This relies on current epmem interval semantics and only considers WMEs in the _now set at scan time. It does not attempt to detect WMEs that were interrupted and re-added during the window, or to deduplicate WMEs that are semantically or structurally equivalent across different wc_ids.

Known limitations

• Constant WMEs only. Identifier (graph-structured) WMEs are not copied; resulting smem LTIs are therefore flat.
• Newly synthesized structures, not transferred objects. Entries grouped by epmem parent-node ID become newly synthesized LTIs with fresh identifiers. They do not carry identity continuity from any epmem episode or prior smem LTI, and may not correspond to any cognitively meaningful semantic object.
• Per-wc_id dedup only. The epmem_consolidated table prevents reprocessing of the same wc_id but does not deduplicate semantically or structurally equivalent WMEs across different wc_ids. Repeated runs can produce multiple smem LTIs covering overlapping content.
• Asymmetric eviction. Evicting from epmem does not retract previously created smem entries. Repeated runs accumulate smem content monotonically; cleaning up is left to the user.
• No cross-tier invalidation. If underlying epmem WMEs change or disappear, the smem entries created from them are not updated or removed.
• _now intervals preserved during eviction. Active WME intervals are never split; only completed ranges, points, and episode rows older than the eviction age are removed.
• Continuous-presence is a narrow heuristic. Frequent-but-interrupted patterns are not caught. Frequency, co-occurrence, and causal structure are not detected.
• No benchmarks of agent-level impact. This PR does not claim that enabling the mechanism improves agent behavior on any task.

Changes

File	Change
episodic_memory.h	4 params, 1 stat, 7 prepared statements, function declaration
episodic_memory.cpp	Param/stat init, SQL statements, schema table + drop, epmem_consolidate() with eviction (~200 lines), hook in epmem_go()
EpMemFunctionalTests.hpp	3 new test declarations
EpMemFunctionalTests.cpp	3 test implementations
2 new .soar test agents	Consolidation and eviction test agents

Tests

46/46 epmem tests pass (43 existing + 3 new), zero regressions:

• testConsolidation — stable WMEs written to smem after consolidation fires
• testConsolidationOff — smem stays empty when feature is disabled
• testConsolidationEviction — old episodes evicted, recent episodes preserved, smem entries intact

Background references

• Derbinsky, N. & Laird, J.E. (2013), "Effective and efficient forgetting of learned knowledge in Soar's working and procedural memories"
• Laird, J. E. (2022), "Introduction to the Soar Cognitive Architecture"

[scijones]

Wow, this and the other pull request. I need to review these, but thanks! These look exciting.

[kimjune01]

Retiring this PR. The assumptions it was built on were wrong:

1. D&L 2013 extrapolation. The prior diagnosis extrapolated from D&L 2013's WM/procedural forgetting work to claim smem/epmem eviction was needed. D&L 2013 does not make this claim — it treats smem as the stable backup store that enables WM forgetting (R4), not as something needing its own eviction.

2. epmem→smem pathway. This PR assumed epmem and smem share a compatible graph representation where episodes accumulate into semantic entries. John Laird rejected this in a 2026-04-09 meeting: smem's data structure is completely different from epmem's. Smem is populated from working memory via deliberate agent action, not derived from epmem. Laird 2022 Figure 6 confirms: smem's source of knowledge is "Existence in Working memory."

3. Scaling motivation. Laird rates Soar's real-time capability "yes, yes" with "millions of items" and diverse knowledge at "tens of millions of rules, facts, and episodes" (§10 items 3, 12). The scaling-is-the-bottleneck framing does not hold.

See the re-intake at june.kim for the corrected SOAP analysis.