Hmm… I think this direction probably does have something to it:
Given the memory architecture you were already converging on for Marven, I think I would treat the graph as an interpretable retrieval / association projection over canonical memory, rather than making the graph itself the sole source of truth.
Something roughly like:
interaction / observation
↓
evidence / episodic record
↓
claims / maintained semantic state
↓
current-state projection
↓
┌───────────────────────────────────┐
│ retrieval projections │
│ │
│ lexical / vector / graph / time │
└───────────────────────────────────┘
↓
candidate memories
↓
currentness / provenance / trust /
visibility / policy checks
↓
context for the LLM
That would let the “Dynamic Cognitive Memory Graph” become genuinely useful without forcing every problem into graph mechanics.
My short answers would be:
| Question |
My default starting point |
| Is a graph memory layer worth exploring, or is it mostly a vector-DB reinvention? |
Worth exploring, especially for multi-hop relationships, temporal links, provenance, and associative retrieval. But I would measure where it actually beats a strong flat/vector baseline. |
| Should the first version be a GNN? |
Probably not. Start with ordinary typed edges + bounded spreading activation / traversal. Add a learned GNN only if a repeatable retrieval failure remains that gives you something meaningful to train against. |
| Vector retrieval or graph retrieval? |
Both. Use lexical/vector retrieval to find good seed memories, then let the graph expand around those seeds. |
| How should activation work? |
Treat activation mainly as “how relevant / associatively reachable is this memory right now?” rather than as one master truth/importance score. |
| How should decay / reinforcement work? |
Keep retrieval strength, currentness, trust, consolidation, archival, and deletion as different operations. Repetition can be evidence that consolidation is worth doing without automatically making a memory more trustworthy. |
| How should consolidation preserve provenance? |
Let consolidated nodes point back to the evidence that produced them. |
| Observed vs inferred vs synthesized memories? |
Keep them distinguishable even if all three participate in retrieval. Retrieval frequency should not erase that distinction. |
| What is the smallest useful experiment? |
Compare the same small memory set under vector-only retrieval vs vector-seeded bounded graph expansion, broken down by query type. |
The very first version could stay surprisingly small:
query
↓
BM25 / embedding top-k
↓
seed nodes
↓
1–2 hop typed propagation
↓
bounded graph additions
↓
rerank
↓
policy / provenance gate
↓
LLM context
I would actually avoid building an elaborate automatic graph-construction pipeline before this test. A manually constructed or deterministically generated graph over a few dozen memory objects would tell you whether the retrieval mechanism itself adds anything, without graph extraction quality becoming another confounding variable.
A small test set might already be enough:
1. direct fact retrieval
2. old preference → new preference
3. two facts that should coexist
4. context-qualified preference
5. temporal before/after question
6. two- or three-hop relationship
7. "which source supports this claim?"
8. inferred association vs explicit fact
9. plausible but unsupported question
10. untrusted/external memory that is highly relevant
If graph expansion helps mainly on 5–7 while leaving 1–4 intact, that would already be a useful result.
Why I think the graph direction is real — but why I would still keep a strong flat baseline
There are now several fairly direct pieces of related work.
HeLa-Mem is especially close to what you are describing. It uses an episodic graph, Hebbian-style strengthening through co-activation, spreading activation, and a separate semantic-memory path produced through consolidation. Its public implementation is probably worth reading as an implementation reference rather than as a template you have to copy.
SYNAPSE is another useful comparison. It builds an episodic-semantic graph and combines BM25/dense anchors with spreading activation across temporal, abstraction, and association edges.
But there is an equally important counterweight: Does Memory Need Graphs? A Unified Framework and Empirical Analysis for Long-Term Dialog Memory.
One thing I like about that paper is that it decomposes memory systems into stages rather than treating “graph vs non-graph” as a single binary choice. Their controlled experiments suggest that representation quality, maintenance, retrieval, ranking, and what information is finally exposed to the LLM can matter as much as graph structure itself.
So I would not test only:
vector memory
vs
graph memory
I would test something more like:
plain memory representation
↓
strong lexical/vector baseline
↓
same representation + graph expansion
↓
same retrieval + different context assembly
That gives you a better chance of discovering why something improved.
It also prevents a common interpretation problem:
graph retrieval recall improved
≠
final answers automatically improved
A graph may locate the right entity or relation while still handing the LLM an impoverished fragment of the original evidence.
That makes your provenance idea useful for accuracy as well as interpretability: if a graph node can lead back to the original episodic record, retrieval can use the compact graph while context construction can recover enough evidence to answer correctly.
Activation looks useful — but I would keep it separate from confidence, trust, and authority
This is probably the separation I would make most strongly.
There are several quantities that sound superficially similar but answer very different questions:
activation / relevance
"Is this memory connected to what I am thinking about now?"
currentness
"Is this still the user's current state?"
confidence
"How certain is this claim?"
provenance trust
"Where did this information come from?"
visibility
"May this memory be exposed in this context?"
authority
"May this memory authorize an external action?"
I would resist compressing those into one importance or activation number.
SYNAPSE has a particularly useful real example here.
Its public release reports that spreading activation improves retrieval recall over vectors-only, including a substantial gain on multi-hop retrieval. But the release also includes a separate confidence-gate diagnostic: raw activation energy did not cleanly distinguish answerable queries from plausible adversarial/unanswerable queries, so the hard activation-based gate is disabled in the released implementation.
That seems very relevant to your design.
It suggests:
activation
→ useful input to retrieval ranking
activation
↛ proof that retrieved memory is true
↛ proof that a question is answerable
↛ permission to disclose information
↛ permission to execute an action
A highly plausible false question can strongly activate a memory graph.
For example:
question:
"What is the user's bank PIN?"
retrieval:
highly relevant external note about bank PINs
activation:
very high
authority:
zero
Those states are perfectly compatible.
I tried a very small synthetic sanity check around this separation as well — only a few dozen memories and a handful of query classes, so definitely not a benchmark.
Adding bounded graph propagation did not automatically beat the vector baseline on the tiny set, including the multi-hop case. But a separate currentness/provenance/status gate correctly removed stale or low-authority memories that were otherwise highly relevant.
I also tried a deliberately naive Hebbian-style reinforcement control. Repeatedly co-retrieving an untrusted external memory strengthened its graph association even though nothing new had made the information more trustworthy.
Again, that is not evidence against Hebbian reinforcement. It is just a useful reason to keep:
association strength
≠
source authority
as an explicit invariant.
I would probably use typed edges before adding a GNN
I think an early graph can remain very boring and still answer the important question.
For example:
derived_from
supersedes
valid_during
related_to
part_of
worked_on
used_tool
person_relation
caused_by
inferred_from
Then different queries can traverse different edge types.
That matters because “related” is not the same operation as “allowed to replace.”
For example:
Memory A:
User preferred coffee.
Memory B:
User now prefers tea.
The graph may have:
A --superseded_by--> B
But:
Memory C:
User uses Python.
Memory D:
User also uses Rust.
should probably have a coexistence/association relation, not a destructive replacement relation.
The same applies to inferred associations.
Observed:
User frequently photographs mountains.
Inferred:
User might enjoy hiking.
The inference can absolutely be useful as an associative node, while still remaining distinguishable from direct evidence.
If one graph starts becoming overloaded with incompatible relationship semantics, MAGMA is an interesting design reference. It separates semantic, temporal, causal, and entity relationships into different graph views and chooses among them according to query intent.
You probably do not need four separate graph databases to borrow that idea.
Even something like:
edge.type = semantic
edge.type = temporal
edge.type = provenance
edge.type = supersession
plus type-specific propagation weights may be enough for an early version.
That also gives you much better interpretability:
Why did this memory activate?
query
↓ semantic
Project Cedar
↓ tool_reuse
Flint
↓ reused_on
Project Harbor
↓ location
Kyoto
That path is much more useful to inspect than simply:
activation = 0.73
Consolidation: I would keep the compact memory and the lineage
Your earlier idea:
Memory A
Memory B
Memory C
↓
Consolidated Memory D
derived_from: [A, B, C]
still looks like a good direction to me.
I would just make D a new derived object rather than silently rewriting A/B/C into D.
For example:
D:
type: semantic_claim
value: "User usually prefers tea in the morning"
confidence: 0.91
derived_from:
- episode_17
- episode_48
- episode_63
valid_from: ...
valid_to: ...
Then normal retrieval can use D because it is compact, while verification or ambiguous questions can descend to the evidence.
There is already standard provenance vocabulary for this kind of relationship. W3C PROV, for example, defines wasDerivedFrom specifically for an entity produced or updated from another entity. You do not need to adopt PROV wholesale, but it is useful prior art for thinking about lineage.
I would also keep two different notions of time if you can:
valid time
when the fact was true in the user's world
observed / transaction time
when Marven learned or stored it
Those diverge surprisingly often.
For example:
September 5:
User tells Marven,
"I moved to Kyoto in June."
The memory was learned in September but became valid in June.
Graphiti is worth studying here because temporal knowledge is one of its core concerns; its current MCP implementation explicitly distinguishes ingestion time from event/reference time.
It is also useful to look at systems like this for edge cases rather than only headline architecture. For example, Graphiti issue #1166 discusses historical node attributes being destructively overwritten even though relationship edges have temporal validity.
I would not read that as “Graphiti is wrong”; I think it is a nice illustration of how temporal semantics tend to leak into every layer. Versioning relationships is not necessarily enough if claim attributes themselves can change over years.
This also connects to TRUSTMEM, which treats memory updates themselves as something worth validating for preservation, omission, corruption, and unsupported additions.
For a long-running personal AI, I suspect the memory transition:
state_t
+
new evidence
↓
state_t+1
may eventually deserve as much testing as retrieval itself.
Decay and reinforcement: I would separate 'less retrievable' from 'forgotten'
I think your biological/organic analogy can still be useful here, but I would turn it into several separate mechanisms rather than one death score.
For example:
lower activation priority
↓
less frequently retrieved
archive
↓
not normally searched, but still recoverable
superseded
↓
historical evidence remains, but not current state
consolidated
↓
represented mostly through a higher-level memory
deleted
↓
removed because the user/policy requires actual deletion
Those are all different.
Likewise, reinforcement could mean several things:
retrieved repeatedly
→ association edge strengthens
similar evidence repeatedly appears
→ consolidation becomes worthwhile
user explicitly confirms a fact
→ confidence may increase
trusted independent evidence agrees
→ provenance support increases
I would not make the first one automatically imply the others.
RecMem has an interesting low-cost interpretation of recurrence: repeated related interactions are used as a signal for when expensive consolidation is worth doing, rather than invoking an LLM to consolidate every interaction.
Their experiments report large reductions in memory-construction token cost while maintaining/improving accuracy.
That seems especially compatible with a local-first Marven:
new interaction
↓
cheap storage + embedding
↓
does a meaningful recurrence cluster appear?
├─ no → leave as episodic evidence
└─ yes → consider semantic consolidation
So recurrence can be useful without becoming “the more often something appears, the more true it must be.”
Dream / synthesis mode is interesting, but I would make the provenance boundary sticky
I actually think the synthesis idea is one of the more interesting parts of your visualization.
A system that only retrieves explicit facts cannot form many useful associative shortcuts.
But I would make generated relationships carry their origin permanently.
Something like:
node / edge status:
OBSERVED
DERIVED
INFERRED
SYNTHESIZED
EXTERNAL
USER_CONFIRMED
The exact labels do not matter as much as preserving the distinction.
For example:
Observed:
User likes photographing mountain landscapes.
Synthesized association:
Mountain photography ↔ hiking.
Later observation:
User explicitly says "I love hiking."
At that point you might have:
synthesized association
+
new direct evidence
↓
new supported semantic claim
rather than silently converting the original synthetic edge into an observation.
This becomes more important once the memory can influence tools.
Persistent-memory poisoning is already being studied directly. MPBench includes attacks where malicious external content is written into persistent agent memory and retrieved later; one of its attack classes is “salience-driven compaction poisoning.”
So I would probably make this an invariant:
retrieval frequency
reinforcement
consolidation
graph centrality
must not, by themselves,
upgrade provenance authority
An external document can become highly relevant and highly connected while remaining an external document.
That separation seems compatible with your exposure-gate idea rather than restrictive of it.
When I would actually introduce a GNN
I would not rule a GNN out.
I would just make it a later answer to a measurable problem.
Start with:
vector / lexical anchors
↓
typed graph expansion
↓
simple propagation / PPR / spreading activation
↓
reranking
Then collect failure cases.
Suppose you repeatedly observe something like:
correct evidence is 3–4 hops away
simple propagation retrieves many plausible distractors
edge-type weighting is not enough
the same structural pattern repeats across many examples
Now you have something a learned graph retriever can potentially improve.
At that point the question becomes:
What supervisory signal should teach the graph which nodes are useful for this query?
That is much more concrete than simply asking “Should this be a neural graph?”
GNN-RAG is a good example of the later stage: its GNN learns question-conditioned node importance for KG retrieval and then extracts paths connecting question entities with likely answer nodes.
That is a real job for a GNN.
So my rough progression would be:
Stage 0
vector / FTS baseline
Stage 1
typed graph + bounded traversal
Stage 2
query-dependent edge weighting / routing
Stage 3
learned reranker
Stage 4
GNN, if the remaining problem is genuinely graph-structural
That keeps every stage independently testable.
It also means the graph representation you build now is not wasted if you later add a GNN.
A small evaluation matrix might tell you more than a large demo
For the first prototype I would probably care less about aggregate “memory accuracy” and more about failure categories.
Something like:
| Case |
Vector |
+ Graph |
+ Graph + policy |
What it tells you |
| Direct factual recall |
|
|
|
Graph should not regress easy cases |
| Preference update A → B |
|
|
|
Currentness / supersession |
| A and B coexist |
|
|
|
Avoid destructive contradiction handling |
| Context X=A, Y=B |
|
|
|
Qualifier handling |
| Temporal sequence |
|
|
|
Time edges |
| Multi-hop relation |
|
|
|
Core graph value |
| Provenance lookup |
|
|
|
Evidence lineage |
| Unsupported plausible question |
|
|
|
Abstention |
| Inferred vs observed |
|
|
|
Trust boundary |
| Poisoned/external memory |
|
|
|
Security boundary |
And I would record retrieval metrics separately from answer metrics:
retrieval:
Did the correct evidence enter top-k?
context assembly:
Was enough of the original evidence preserved?
answer:
Did the LLM answer correctly?
policy:
Did it exclude something it should not expose?
mutation:
Did retrieval accidentally change durable state?
LongMemEval is useful once you want a larger benchmark because it separates several relevant abilities: information extraction, multi-session reasoning, knowledge updates, temporal reasoning, and abstention.
The recent controlled graph-memory work also uses LongMemEval/HaluMem partly because these categories help expose where a memory system fails instead of collapsing everything into one score.
I would especially keep an eye on the difference between:
retrieval failure
and
memory-maintenance failure
If the graph contains the wrong current state, better traversal cannot fix it.
Conversely, if canonical state is correct but retrieval cannot reach it, changing consolidation logic may be the wrong layer to modify.
A possible decision tree
If I were deciding what to implement next, I would probably use something like this:
Is the question mostly a direct/current fact?
│
├─ yes
│ → structured / lexical / vector retrieval first
│
└─ no
↓
Does it require relation, time, provenance, or associative traversal?
│
├─ yes
│ → add bounded typed graph expansion
│
└─ no
→ improve representation / ranking before graph complexity
After graph expansion:
retrieval recall improves AND answer quality improves
│
└─ keep it; examine cost/latency
retrieval recall improves BUT answer quality does not
│
└─ inspect context reconstruction / source evidence / reranking
retrieval gets noisier
│
└─ reduce expansion radius, type edges, add routing/inhibition
simple traversal repeatedly misses the same structural pattern
│
└─ consider learned ranking / GNN
activation becomes high for unsupported or untrusted memories
│
└─ do not weaken activation; separate trust/currentness/authority instead
The last branch is important to me because it preserves the interesting part of the cognitive model.
You do not have to make associative activation conservative just because trust needs to be conservative.
The graph can be exploratory while the memory-policy boundary remains strict.
On the name
For the current prototype, Dynamic Cognitive Memory Graph feels slightly more literal to me than “Neural Node Network,” simply because the first useful implementation may not need learned neural message passing at all.
But I would not throw away the Neural Node Network idea as a project concept.
There is a natural migration path:
visual conceptual network
↓
explicit dynamic memory graph
↓
hand-designed spreading activation
↓
learned graph ranking / message passing
If the later stages become learned, “neural” becomes technically literal as well.
So I would treat the naming question as secondary to defining the contract of the layer.
The useful question is less:
Is this graph truly neural?
and more:
What state does this layer own, what does it derive, what is allowed to change durable memory, and can I explain why a memory reached the LLM?
If those boundaries are clear, you can experiment pretty freely above them.
So if I were building the next Marven prototype, I would probably not start by implementing the whole Neural Node Network.
I would start with one small slice:
same canonical memories
↓
vector-only retrieval
vs
vector-seeded typed graph propagation
and give the graph a few cases it should be good at: temporal links, multi-hop relationships, provenance traversal, and associative cues.
Then I would keep activation/reinforcement experimental while putting currentness, provenance, permissions, and mutation authority behind separate explicit rules.
If that small version consistently finds useful evidence that the flat baseline misses, then you have something much more valuable than a graph visualization: you have a measurable reason for the graph to exist.