Knowledge Graphs

MemNexus doesn't just store memories in a flat list — it builds a graph of relationships between memories, topics, entities, and facts. This graph structure enables queries that flat search can't answer.

Why a graph?

Consider a developer who stores 500 memories over 3 months. With flat search, they can find individual memories. With a graph, they can also:

• Find all memories related to a specific entity (e.g., "Node.js")
• Discover topics that frequently appear together
• Trace how decisions evolved over time
• See which tools and technologies are connected in their workflow

The MemNexus graph

Memory ──[HAS_TOPIC]──────→ Topic
Memory ──[MENTIONS]────────→ Entity
Memory ──[BELONGS_TO]──────→ Conversation
Memory ──[RELATED_TO]──────→ Memory
Fact   ──[HAS_SUBJECT]─────→ Entity
Fact   ──[HAS_OBJECT]──────→ Entity
Topic  ──[RELATED_TO]──────→ Topic

Every node and relationship is stored in a purpose-built graph database that excels at traversing these connections.

Facts as structured knowledge

Facts are the explicit knowledge layer of the graph. Each fact is a subject-predicate-object triple:

MemNexus  →  built_with  →  Node.js
GraphDB   →  is_a        →  Graph Database
core-api  →  uses        →  Express

Facts create a web of relationships that agents can traverse and reason over. Unlike memories (which are episodic), facts represent persistent truths.

Fact confidence

Each fact has a confidence score (0-1) indicating how certain the information is:

• 1.0 — Verified truth
• 0.7-0.9 — High confidence, likely correct
• 0.5-0.7 — Moderate confidence, worth verifying
• Below 0.5 — Low confidence, treat as hypothesis

Entities

Entities are the people, tools, projects, and concepts that appear across your memories. MemNexus extracts and tracks entities to build connections.

When multiple memories mention "Node.js", MemNexus recognizes it as a recurring entity and can show:

• All memories that mention Node.js
• All facts about Node.js
• Topics that co-occur with Node.js
• Other entities related to Node.js

Graph traversal

The real power of a knowledge graph is traversal. Instead of searching by keywords, you can follow relationships:

"What do I know about the tools used in this project?"

Project → [HAS_TOPIC] → deployment
                         → [RELATED_TO] → Docker
                                          → [MENTIONED_IN] → Memory about Dockerfile setup

This traversal connects a project to Docker to a specific memory about Dockerfile configuration — a connection that keyword search alone might miss.

Graph vs. flat search

Capability	Flat search	Graph
Find by meaning	Yes	Yes
Find by keyword	Yes	Yes
Traverse relationships	No	Yes
Discover connections	No	Yes
Topic clustering	No	Yes
Fact reasoning	No	Yes
Cross-entity queries	No	Yes

Building a good graph

• Use consistent topics — "core-api" not sometimes "core api"
• Store facts for key relationships — Don't rely on extraction alone
• Tag entities explicitly — Use topics that match entity names
• Review topic clusters — Periodically check detected clusters for accuracy