docs: reinstate graph memory terminology (native entity linking) (#5601)

docs/migration/oss-v2-to-v3.mdx

@@ -328,27 +328,27 @@ The new algorithm automatically creates a parallel entity store collection named
 Make sure your vector store user/credentials have permission to create new collections. If you're using a managed vector database with restricted permissions, pre-create the `{collection_name}_entities` collection with the same embedding dimensions as your main collection.
 </Warning>
 
-## Graph Memory → Entity Linking
+## Graph Memory: Now Built-In
 
-Graph store support has been removed from the open-source SDK. It is replaced by **built-in entity linking**, which runs natively with no external dependencies.
+External graph **store** support has been removed from the open-source SDK and replaced by **built-in graph memory** (entity linking), which runs natively with no external dependencies.
 
 **What was removed:**
 - `enable_graph` / `enableGraph` config flag
 - `graph_store` / `graphStore` configuration block (Neo4j, Memgraph, Kuzu, Apache AGE, Neptune)
-- All graph memory code paths (~4000 lines)
+- All external graph store code paths (~4000 lines)
 
 **What replaces it:**
 
-Entity linking extracts entities (proper nouns, quoted text, compound noun phrases) from every memory during the add pipeline and stores them in a parallel collection (`{collection}_entities`) inside your existing vector store. At search time, entities from the query are matched against this collection and used to boost relevant memories. The boost is folded into the combined `score` on each result.
+Mem0 now builds the graph itself. It extracts entities (proper nouns, quoted text, compound noun phrases) from every memory during the add pipeline and stores them in a parallel collection (`{collection}_entities`) inside your existing vector store. Memories that share an entity are linked, and at search time entities from the query are matched against this collection to boost connected memories. The boost is folded into the combined `score` on each result.
 
 **Migration:**
 - Remove `enable_graph` / `enableGraph` from your config
 - Remove the `graph_store` / `graphStore` block — it is no longer read
-- Uninstall graph drivers (neo4j, memgraph, etc.) if you were using them only for Mem0
-- No data migration is required. Entity linking activates automatically on the next `add()` call.
+- Uninstall external graph drivers (neo4j, memgraph, etc.) if you were using them only for Mem0
+- No data migration is required. Built-in graph memory activates automatically on the next `add()` call.
 
 <Warning>
-Graph relationships exposed via the old `relations` field on search results are no longer populated. Entity relationships are consumed indirectly through retrieval ranking, not exposed as a queryable graph structure. If your application depended on traversing graph relationships directly, you will need to redesign that part against the new API.
+The old `relations` field on search results (populated by the external graph store) is no longer returned. Entity connections are now applied through retrieval ranking rather than exposed as a separate, directly traversable structure. If your application read or traversed the `relations` array, you will need to redesign that part against the new API.
 </Warning>
 
 ## How the New Algorithm Works

docs/migration/platform-v2-to-v3.mdx

@@ -1,6 +1,6 @@
 ---
 title: "Platform: Migrating to the New Memory Algorithm"
-description: "Guide for Mem0 Platform users to adopt the new memory algorithm with single-pass extraction, entity linking, and multi-signal retrieval."
+description: "Guide for Mem0 Platform users to adopt the new memory algorithm with single-pass extraction, built-in graph memory, and multi-signal retrieval."
 icon: "arrow-right"
 iconType: "solid"
 ---
@@ -18,8 +18,7 @@ The new Mem0 memory algorithm is a ground-up redesign of how memories are extrac
 | **Extraction** | Two LLM passes (extract + merge) | Single-pass ADD-only (one LLM call) |
 | **Memory mutations** | ADD, UPDATE, DELETE | ADD only — nothing is overwritten or deleted |
 | **Agent-generated facts** | Often ignored | First-class, stored with equal weight |
-| **Entity linking** | Not available | Entities extracted and linked across memories |
-| **Graph memory** | Separate graph store + dashboard visualization | Replaced by built-in entity linking, no graph visuals on platform dashboard |
+| **Graph memory** | External graph store (Neo4j, etc.) + manual setup | Built-in and automatic; entities extracted and linked across memories natively, no external store |
 | **Retrieval** | Semantic (vector) only | Hybrid retrieval combining multiple signals |
 
 ## What This Means for Your Application
@@ -249,19 +248,18 @@ await client.search("query", {
 For the full list of parameter changes across all SDKs, see the [OSS migration guide](/migration/oss-v2-to-v3#removed-parameters-reference).
 </Info>
 
-## Graph Memory → Entity Linking
+## Graph Memory Is Now Built-In
 
-Graph memory has been replaced by **built-in entity linking**. The changes:
+Graph memory no longer requires an external graph database. It is now **native to the platform** and automatic. The changes:
 
-- **Graph visualizations removed from the platform dashboard.** The graph view in your project dashboard is no longer available.
-- **`enable_graph` project setting removed.** The toggle is gone from the dashboard; the API parameter is ignored.
-- **No external graph store to configure.** Previously graph memory required a separate Neo4j (or similar) deployment. Entity linking runs natively inside the platform — nothing to provision, no connection strings to manage.
-- **Entity linking is the native replacement.** Entities (proper nouns, quoted text, compound noun phrases) are automatically extracted from every memory and linked across memories belonging to the same user. At search time, entities from the query are matched against this index and used to boost ranking. The boost is folded into the combined `score` returned on each result.
+- **No external graph store to configure.** Previously, graph memory required a separate Neo4j (or similar) deployment. Mem0 now builds the graph itself from your memories, so there is nothing to provision and no connection strings to manage.
+- **Always on, no flag.** The `enable_graph` project setting is no longer needed; graph memory activates automatically. (The API parameter is now ignored if sent.)
+- **Connections power retrieval directly.** Entities (proper nouns, quoted text, compound noun phrases) are automatically extracted from every memory and linked across memories belonging to the same user. At search time, entities from the query are matched against the graph and used to boost ranking. The boost is folded into the combined `score` returned on each result.
 
-**No migration work is required.** Entity linking activates automatically for all projects on the new algorithm. Existing memories are not re-processed, but any new memories you add will be indexed for entity-based retrieval going forward.
+**No migration work is required.** Graph memory activates automatically for all projects on the new algorithm. Existing memories are not re-processed, but any new memories you add are added to the graph going forward. See [Graph Memory](/platform/features/graph-memory) for how the built-in graph works.
 
 <Note>
-If your application previously read graph relations from the API response (`relations` field on search results), note that this field is no longer populated. Entity relationships are now consumed indirectly through retrieval ranking, not exposed as a separate graph structure.
+If your application previously read graph relations from the API response (`relations` field on search results), note that this field is no longer populated. Entity connections are now applied through retrieval ranking rather than returned as a separate `relations` array.
 </Note>
 
 ## Migration Checklist