Knowledge Graph and Entities

Knowledge Graph, Clusters, Summaries and the Entity Explorer

Memories are more useful when they are connected. SLM links every stored fact to related facts, groups facts into themes, resolves the people, organisations and concepts they mention into single entities, and can summarise what happened in a session, a day or a project. This page covers those four views of the same data: the Knowledge Graph, Knowledge clusters, Summaries and the Entity Explorer.

The knowledge graph

Every stored fact gets edges to related facts. There are four kinds of edge in normal use, and two more exist for conflict handling.

Edge	Created when
Entity	Two facts share an entity
Temporal	Two facts fall within a one-week window, with exponential decay
Semantic	Embedding cosine similarity is at least 0.7
Causal	Causal markers connect the facts
Contradiction, Supersedes	A fact conflicts with or replaces another

Association edges are written when a fact is stored. Unused ones decay during consolidation. A PageRank-style importance score is computed later, on the maintenance scheduler, not during consolidation. Recall uses the graph in two ways: spreading activation is one of the five producers, and the entity graph boosts fused candidates afterwards (see How Recall Works).

In the dashboard, the Knowledge Graph pane draws the graph with a node budget (50 by default, adjustable from 20 to 2,000), an "Ask your memory" search box and Quick Insights. A community view runs Louvain community detection over the entities (POST /api/v3/graph/run-communities). From the terminal, slm db regraph rebuilds edges and the MCP build_graph tool does the same for the active profile; build_graph is available only with the whole profile.

Storage backends. The canonical graph lives in SQLite. For large stores, the Scale Engine can serve graph queries from CozoDB and vector search from LanceDB. These are derived projections, prepared outside the live paths, verified against the canonical store and promoted atomically; they serve only after they match. Two Settings choices control which library answers queries: graph_backend (auto, sqlite or cozo) and vector_backend (auto, sqlite-vec or lancedb). auto uses CozoDB or LanceDB when that library is installed, and SQLite otherwise. A separate setting, on by default, promotes the scale engine once the graph has at least 100,000 edges. A graph is pruned to at most 100 edges per node by default. See Architecture and the repository's docs/scale-engine.md.

Knowledge clusters

The Knowledge clusters tab in Memories lists scenes, groups of related facts built at write time. A new fact joins an existing scene when its similarity is at least 0.6; otherwise it starts a new one. Each scene stores a theme plus its member facts and entities. Separately, a background pass runs Louvain over the entity co-occurrence graph, and that feeds the thematic context attached to recall results. Cluster size and the 0.6 threshold are code constants, not Settings.

Summaries

SLM produces three kinds of summary, each bounded and traceable, and a fourth for communities:

Summary	Covers	How to get it
Session summary	One session	slm summary session ID, or close_session
Daily reflection	One day (today, yesterday or a date)	slm summary day
Project work log	One project directory	slm summary project PATH
Community summary	One entity community	MCP get_memory_summary with kind=community

Every result carries source_fact_ids and an explicit coverage value. The coverage field exists because only a small share of facts carry a session id on a real store, and a summary should say how much it actually saw. Summaries are extractive, so no model is needed. A Mode B or C model writes them when one is configured. In the dashboard, Memories has a Summaries tab with Today and Yesterday buttons. Idle sessions close after 24 hours and get a summary then. The MCP tool get_memory_summary is in the core profile.

The Entity Explorer

The Entity Explorer lists canonical entities (people, organisations, concepts and events) with a compiled profile, aliases, related facts and a timeline. Entities come from the fact extractor and are merged by the entity resolver, so "Dr. Chen", "Chen" and "Wei Chen" can resolve to one entity. A per-entity summary, called compiled truth, is generated by the Entity Compilation Engine, which is on by default. In the API, GET /api/entity/list, GET /api/entity/NAME and POST /api/entity/NAME/recompile serve it. There is no CLI command or MCP tool for entities; the Explorer is the way in.

Code: encoding/graph_builder.py, core/graph_analyzer.py, encoding/scene_builder.py, core/entity_community.py, encoding/entity_resolver.py, learning/entity_compiler.py, summaries/, server/routes/memories.py, server/routes/entity.py, server/routes/summaries.py, core/scale_engine.py.