← all posts

A Memory System Is an Admission Policy

Retention keeps a memory from filling up. Admission and retrieval determine whether it helps with the work in front of the agent.

When you're building a memory system, the first version is often just a fact store. palOMine began that way—a place to store facts with decay and contradiction handling. The core loop was simple: a repeated preference reinforced an existing record, a contradiction superseded the earlier one while keeping its history, and neglected observations decayed from the active set.

This design solved one problem: retention. Once you've admitted a fact, how do you keep it current without it becoming an ever-growing transcript? I described that original design in Fact-Based Memory: Decay, Abstraction, and Contradiction Versioning.

But making it useful in real work exposed a prior problem. Useful signals came from conversations, project instructions, Obsidian notes, and source trees. Most of that material should neither become durable memory nor enter the next model call. The memory system therefore became an admission and retrieval system around the original fact lifecycle.

What may become a fact?

Scanning every available source and storing model-generated summaries would reproduce the accumulation problem before the fact store even sees the data. Conversations contain tool output, abandoned approaches, and procedural remarks. Source trees contain generated files, dependencies, and implementation detail. Notes may describe inactive work.

An admission policy classifies the source and restricts the claims it may produce. It answers whether the candidate is durable, whether it concerns the user or the current work, and whether its source should remain available for inspection.

A conversation can explain why an agent knows something without establishing that it should know it permanently.

Conversations produce candidates, not automatic memories

palOMine scans saved sessions through a bounded extraction pass. Tool messages and session actions are excluded. "The user committed a change" records an event. "The user prefers Rust for systems work" may be a durable preference.

The extractor returns structured triples, but the runtime also rejects file paths, shell commands, generated artifacts, action verbs, and malformed predicates. A statement doesn't become long-lived merely because it appeared in a successful session.

Conversation-derived facts retain the originating session. The system records whether each scan completed or failed and the number of facts admitted, without keeping the transcript or provider error text in that audit record. Promotion is now observable rather than an implicit side effect of a conversation.

Notes and code require source-specific extraction

Notes state intent more directly than conversations. Code contains durable structure alongside incidental implementation detail. Treating either as raw text would give the extractor too much noise and no useful boundary.

The scanner accepts a directory, excludes dependency trees, build output, caches, lock files, and similar noise, then produces an intent view for supported file types. Rust input becomes declarations and documentation rather than function bodies. Markdown input becomes headings. The scanner chunks this reduced material before extraction.

Admitted facts are tagged as identity, preference, project, tool, habit, or knowledge. The tags limit how the system classifies a claim; they are not a claim of semantic certainty.

The provenance boundary is incomplete. Conversation facts retain a session reference. Vault and source-scan facts are currently stored as derived facts without a fact-level reference to the exact note or declaration. The scanner knows its input during extraction, but the user cannot yet inspect that link after promotion. The missing link is a defined limitation, not an excuse to ignore the source.

Retrieval selects the working set

An admitted fact helps only when the next request retrieves it. When the provider supports embeddings, palOMine embeds the user message and searches embedded active facts by cosine similarity. If that returns no useful result, it falls back to lexical recall. The prompt contains at most fifteen recalled facts.

Project context follows the same pattern. Instruction files can be chunked and embedded so the agent receives the relevant paragraphs instead of the complete file. Context and memory remain separate stores, but both require a bounded working set.

Semantic similarity is a candidate selector, not an authority decision. It applies only to embedded facts, and a close vector does not establish relevance or scope. Lifecycle state and the prompt budget still constrain the result.

The fact system remains the core

Decay removes neglected observations from competition. Contradiction handling preserves a changed preference as history rather than silently overwriting it. Reinforcement separates repeated evidence from a new claim. Retrieval relies on those properties because it should search active facts, not every record ever written.

The original design solved the lifecycle of an admitted fact. The current design adds the boundary before it: source selection, restricted extraction, provenance, and bounded recall. Together, those decisions determine whether the agent retains a useful fact or merely stores nearby text.

Previous: Fact-Based Memory: Decay, Abstraction, and Contradiction Versioning

Next: The Model Only Sees the Context You Send

The one-line version

Decay keeps memory from filling up; admission and retrieval determine whether the facts that remain can help with the work now.