Summary
Mnemosyne already has strong primitives for evolving memory:
valid_untilsuperseded_by- temporal triples
- canonical fact history
- veracity and validation metadata
- consolidation-time conflict detection
- recall diagnostics
These mechanisms cover memories that are explicitly expired, contradicted, or superseded.
There is another important state that is currently missing:
A memory may not be known to be false, but relevant activity has happened since it was verified, making its current applicability uncertain.
This proposal calls that state dirty.
It also proposes a validation step before an old or dirty memory is presented as current actionable context.
Motivation
Consider a stored memory:
The production branch is main.
Later activity modifies deployment configuration, repository settings, or branch policy, but no explicit replacement branch value is extracted.
The old memory is not necessarily false. It has not been directly contradicted or superseded. However, treating it as clean current truth is unsafe because the subject around it has changed.
A safer recall result would be:
The production branch was last verified as main. Relevant deployment configuration changed afterward, so the current value should be checked.
This is especially important for coding and operational agents, where configuration, dependencies, procedures, APIs, and deployment environments can change without producing a perfectly explicit replacement fact.
Related examples already appear in:
This proposal is narrower than a general trust workflow. It focuses on how relevant change affects an existing memory before an explicit contradiction has been established.
Activation is not confidence
Memory activation and evidence confidence should remain independent.
Activation:
How readily should this memory be recalled?
Evidence confidence:
How safe is it to rely on this memory?
Temporal applicability:
Does this memory still describe the state or time relevant to the current query?
Possible activation signals include:
recall_count
last_recalled
importance
working-memory state
Possible evidence signals include:
veracity
validator
validated_at
validation_count
source authority
conflict state
supersession state
Recalling a memory can change its activation. Only corroboration or verification should increase evidence confidence.
Repeatedly retrieving an incorrect memory should not make it increasingly authoritative.
Semantic dirtying
A memory becomes dirty when relevant evidence-bearing activity occurs after its last verification, but the system cannot yet conclude that the memory is false.
clean
-> relevant later activity
dirty
-> successful verification
clean
Other outcomes remain possible:
dirty -> conflicted
dirty -> superseded
dirty -> expired
Dirty does not mean incorrect. It means:
Relevant change occurred after this memory was verified, so its current applicability should be checked.
This differs from existing states:
Dirty:
Relevant change creates uncertainty.
Conflicted:
Evidence directly disagrees.
Superseded:
A newer value has been accepted as current.
Subject-relative dirtying
Dirtying should operate on narrow subjects rather than broad topics.
project
├── documentation
├── application
│ ├── framework
│ └── dependencies
└── deployment
├── branch
├── artifact_path
└── provider
A documentation change should not dirty a deployment-branch memory. A deployment-configuration change probably should.
This avoids treating every mention of a broad project, person, or organization as evidence that all related memories may have changed.
Dependency-driven dirtying
Dirtying should also be able to propagate through dependencies.
A stored deployment procedure might depend on:
application directory
build command
artifact path
deployment provider
production branch
Changing one of these dependencies should make the procedure dirty even when the procedure itself was not directly discussed.
The same principle applies to:
- procedures that depend on tool or API versions
- project facts derived from configuration files
- workflows that depend on repository structure
- profile conclusions derived from several underlying memories
Memory states
The conceptual lifecycle could include:
proposed
verified
dirty
conflicted
superseded
expired
rejected
Suggested meanings:
proposed: Automatically captured or inferred but not independently confirmed.verified: Confirmed by an authoritative source or explicit attestation.dirty: Previously verified, but relevant later activity makes current applicability uncertain.conflicted: Evidence disagrees and no authoritative winner is established.superseded: A newer memory is accepted as current while the old memory is preserved as history.expired: Its explicit validity period has ended.rejected: A proposed memory was reviewed and should not be used.
The important transition is:
verified -> dirty -> verified
A successful revalidation clears dirty state. A contradiction moves the memory toward conflicted or superseded instead.
Validation before recall
Before presenting an old or dirty memory as current actionable context, recall should evaluate:
How could subsequent subject activity or the passage of time have affected this memory, and does that possibility matter for the current query?
Possible outcomes include:
valid_as_historical
current_enough
qualified
verify_before_use
conflicted
superseded
expired
unverifiable
This evaluation is query-relative.
"What branch was used during the previous release?"
-> A historical memory may be valid.
"What branch should be deployed now?"
-> The same memory may require current verification.
Recency scoring asks how highly to rank a memory.
Validation-aware recall asks whether the memory is safe to state or act upon as present truth.
Recall behavior
Trust and dirty state should affect both selection and presentation:
- Verified and current memories can be recalled normally.
- Proposed memories can be marked or excluded from automatic injection.
- Dirty memories can include their last verification time and dirty reason.
- Conflicted memories should return competing claims rather than silently selecting one.
- Superseded and expired memories should normally be excluded from current-state queries while remaining available for historical queries.
- High-consequence actions should not silently rely on dirty or unverifiable memories.
Example result:
{
"content": "The production branch is main.",
"activation": 0.82,
"evidence_confidence": 0.67,
"trust_state": "dirty",
"last_verified_at": "2026-06-15T09:00:00Z",
"temporal_status": "verify_before_use",
"dirty_reason": "Relevant deployment configuration changed afterward",
"safe_rendering": "The production branch was last verified as main on June 15."
}These values should remain separate rather than being collapsed into one opaque score.
Verification behavior
Verification should record what was actually confirmed.
If a procedure contains an artifact path, production branch, project identifier, and CLI command, confirming one component should not refresh every other component automatically.
Successful verification should update evidence freshness and clear dirty state only for the verified subject or dependency.
Mere retrieval should update activation metadata only.
Relationship to existing Mnemosyne features
This proposal complements rather than replaces:
These features already provide much of the required information.
The missing recall contract is:
Access changes activation.
Verification changes confidence.
Relevant subject activity creates dirty state.
Validation determines current applicability.
Expected behavior
The proposal should distinguish these cases:
- Unrelated activity does not dirty a memory merely because it shares a broad namespace.
- Relevant later activity creates dirty state without immediately declaring the memory false.
- A dirty memory is returned with qualification rather than as unqualified current truth.
- Successful verification clears dirty state.
- Repeated recall alone does not increase evidence confidence.
- Direct contradiction creates conflict or supersession.
- Historical queries can still retrieve superseded memories.
- Dependency changes can dirty affected procedures and derived memories.
- Verification of one component does not refresh unrelated components.
Non-goals
- Treating every old memory as unreliable
- Treating every broad-topic mention as evidence-bearing change
- Deleting dirty or superseded memories
- Requiring an LLM for every recall
- Replacing existing expiry or conflict mechanisms
- Using remembered approval as authorization for a new action
The goal is to make Mnemosyne aware not only of whether a memory has been contradicted, but whether the world around that memory has changed enough that an agent should verify it before relying on it.
Summary
Mnemosyne already has strong primitives for evolving memory:
valid_untilsuperseded_byThese mechanisms cover memories that are explicitly expired, contradicted, or superseded.
There is another important state that is currently missing:
This proposal calls that state dirty.
It also proposes a validation step before an old or dirty memory is presented as current actionable context.
Motivation
Consider a stored memory:
Later activity modifies deployment configuration, repository settings, or branch policy, but no explicit replacement branch value is extracted.
The old memory is not necessarily false. It has not been directly contradicted or superseded. However, treating it as clean current truth is unsafe because the subject around it has changed.
A safer recall result would be:
This is especially important for coding and operational agents, where configuration, dependencies, procedures, APIs, and deployment environments can change without producing a perfectly explicit replacement fact.
Related examples already appear in:
This proposal is narrower than a general trust workflow. It focuses on how relevant change affects an existing memory before an explicit contradiction has been established.
Activation is not confidence
Memory activation and evidence confidence should remain independent.
Possible activation signals include:
Possible evidence signals include:
Recalling a memory can change its activation. Only corroboration or verification should increase evidence confidence.
Repeatedly retrieving an incorrect memory should not make it increasingly authoritative.
Semantic dirtying
A memory becomes dirty when relevant evidence-bearing activity occurs after its last verification, but the system cannot yet conclude that the memory is false.
Other outcomes remain possible:
Dirty does not mean incorrect. It means:
This differs from existing states:
Subject-relative dirtying
Dirtying should operate on narrow subjects rather than broad topics.
A documentation change should not dirty a deployment-branch memory. A deployment-configuration change probably should.
This avoids treating every mention of a broad project, person, or organization as evidence that all related memories may have changed.
Dependency-driven dirtying
Dirtying should also be able to propagate through dependencies.
A stored deployment procedure might depend on:
Changing one of these dependencies should make the procedure dirty even when the procedure itself was not directly discussed.
The same principle applies to:
Memory states
The conceptual lifecycle could include:
Suggested meanings:
proposed: Automatically captured or inferred but not independently confirmed.verified: Confirmed by an authoritative source or explicit attestation.dirty: Previously verified, but relevant later activity makes current applicability uncertain.conflicted: Evidence disagrees and no authoritative winner is established.superseded: A newer memory is accepted as current while the old memory is preserved as history.expired: Its explicit validity period has ended.rejected: A proposed memory was reviewed and should not be used.The important transition is:
A successful revalidation clears dirty state. A contradiction moves the memory toward conflicted or superseded instead.
Validation before recall
Before presenting an old or dirty memory as current actionable context, recall should evaluate:
Possible outcomes include:
This evaluation is query-relative.
Recency scoring asks how highly to rank a memory.
Validation-aware recall asks whether the memory is safe to state or act upon as present truth.
Recall behavior
Trust and dirty state should affect both selection and presentation:
Example result:
{ "content": "The production branch is main.", "activation": 0.82, "evidence_confidence": 0.67, "trust_state": "dirty", "last_verified_at": "2026-06-15T09:00:00Z", "temporal_status": "verify_before_use", "dirty_reason": "Relevant deployment configuration changed afterward", "safe_rendering": "The production branch was last verified as main on June 15." }These values should remain separate rather than being collapsed into one opaque score.
Verification behavior
Verification should record what was actually confirmed.
If a procedure contains an artifact path, production branch, project identifier, and CLI command, confirming one component should not refresh every other component automatically.
Successful verification should update evidence freshness and clear dirty state only for the verified subject or dependency.
Mere retrieval should update activation metadata only.
Relationship to existing Mnemosyne features
This proposal complements rather than replaces:
valid_untilsuperseded_byThese features already provide much of the required information.
The missing recall contract is:
Expected behavior
The proposal should distinguish these cases:
Non-goals
The goal is to make Mnemosyne aware not only of whether a memory has been contradicted, but whether the world around that memory has changed enough that an agent should verify it before relying on it.