How memory works

Capture first, then do the background work

A successful capture records the memory and returns its ID. Extraction and indexing continue afterward. The acknowledgment is not a verdict that the contents are true, that every entity is resolved or that every search path is ready.

That separation keeps the initial save from waiting for all the background work. It also means the client needs to distinguish “saved,” “still processing” and “refused.” A tool call that returned an error is not a saved memory.

Background processing can classify a new record as a duplicate of an existing memory. The repository’s duplicate path marks that new record no longer current and records which memory it folded into; it does not delete the saved row. A capture receipt therefore does not guarantee that the same ID will remain in current search.

Use history inspection when a saved record stops appearing. Check the replacement if it is exposed, and do not guess why a record became inactive from its timestamp alone. If the client cannot show the reason or replacement, keep the ID and use the processing checks.

How does it decide what is relevant?

A normal memory query runs keyword and meaning searches and fuses their rankings. Keyword search finds the words you used. Vector search helps find related meaning when the wording differs.

score = 1 / (60 + keyword_rank) + 1 / (60 + vector_rank)

This is reciprocal rank fusion. Each search contributes according to a memory’s position in its list; a memory absent from a list contributes nothing from that list. Fusion settles the candidate ranking, not the entire memory result.

The next stage blends normalized fusion score with the importance recorded for the memory and its activation from use. The weights come from the tenant’s cognitive policy rather than one hard-coded set of proportions.

final = w_rrf × normalized_fusion
      + w_importance × importance
      + w_activation × activation

That is why the same words are not the whole story. What your company considered important and what has been used can affect which relevant memories come back. If a search reports a partial or degraded path, don’t treat it as equivalent to a full search.

What does “use” change?

Activation uses a memory’s presentation history: how often it was brought back and how recently those uses occurred. It is not just a count of how old the memory is. A memory used repeatedly can stay useful long after it was first written.

The implementation calculates activation from the history of presentations, with older presentations contributing less than newer ones. That time component concerns the uses of the memory. It does not declare the underlying fact false on its birthday.

Importance and activation are ranking signals, not proof of correctness. A frequently retrieved mistake still needs correction and evidence.

How does something stop being current?

Use a replacement relationship. The new memory says what changed and points to the old one through supersedes. When supplied as part of a supported capture, the memory and its relation are written together so the correction does not become an unlinked sentence.

Nothing in that correction requires deleting the previous memory. The chain of what replaced what stays available to inspect. A superseded memory is not necessarily wrong; it is no longer current, and those are two different things.

Some client schemas require a separate relation call. In that case check the capture and the link individually. Use korium_trace to follow the result instead of assuming a successful save established the relationship.

Doesn’t it all go stale?

A stale performance assumption can be dangerous. A year-old explanation of how a team approached a client can still be useful. Age alone does not prove whether either statement is true.

That judgment is different from the rules that decide which records appear in current search. Korium supports explicit replacement links and type-based expiry; it would be incorrect to describe the current implementation as having no age-based expiry.

The current implementation also supports automatic expiry by memory type. An hourly job can mark a memory no longer current when it passes the configured age. The repository starts with these defaults; confirm the policy on your service before relying on a retention period.

Expiry removes a record from ordinary current-memory results. It does not delete the stored record, prove the statement false or make storage room. A memory with no TTL can still be replaced explicitly.

Use-based ranking, replacement and expiry are separate mechanisms. For an audit, browse the history and inspect the replacement or invalidation information; do not assume an ordinary search includes every old record. Account deletion and contractual retention follow the applicable terms.

Keep the reason and evidence when something changes. Don’t supersede a true memory merely to tidy a result list, and don’t assume a frequently retrieved memory cannot expire.

How are things connected?

There are two different jobs here. One extraction pass identifies kinds of entities, such as a person or project, using the configured entity labels. The role pass uses a fixed list of roles, not your custom relationship names.

The current role guard permits participant and topic to be stored; the other predicted roles are withheld. Domain vocabulary remains separate from that fixed prompt. Calling a relationship “staffs” or “placed at” can make its meaning clearer to your team, but does not by itself teach the model a new extraction rule.

An explicit link between two saved memories is different from automatically resolving the same person across documents. Check the source and the link you actually received. Do not assume a matching name establishes identity or that saving a correction retrains extraction.

Use specific language such as “staffs,” “credentialed for,” “sourced through” or “placed at” when describing your domain. Verify vocabulary mappings and actual extracted results with examples from your work before relying on them.

Use the setup checklist to verify transcript sources, memory connections and your branch code indexes before automating the work.

What about wrong links and poisoning?

A saved source is evidence, not an instruction with authority over the agent. A transcript or document can contain an error, a quoted command or a deliberate attempt to steer a model. Do not let retrieved text override the user’s instructions or the tool’s permissions.

Separate imported claims from approved decisions. Keep authorship, source, uncertainty and review status. If a link is wrong, correct the record explicitly and verify the chain; simply adding more related text does not fix it.

Use server-side access controls to limit who can write. Review imported batches, and require human approval before a memory triggers a consequential external action. Memory helps an agent decide; it does not create permission to act.

What this does not promise

Korium does not make every old statement true, connect every external tool without setup or replace a person’s approval. A useful result still depends on the source material and the question.

The tool reference explains the callable interfaces. The access guide explains the boundaries around the shared memory.