> ## Documentation Index
> Fetch the complete documentation index at: https://docs.getcore.me/llms.txt
> Use this file to discover all available pages before exploring further.

# Memory overview

> The memory primitives, storage layout, and how they connect.

## Primitives

* `Episode`: atomic unit of ingested content. One conversation, email, or sync becomes one episode. The original content is preserved as the source of truth.
* `Entity`: node in the graph. 11 types are defined (`Person`, `Organization`, `Place`, `Event`, `Project`, `Task`, `Technology`, `Product`, `Standard`, `Concept`, `Predicate`). See [entity types](/memory/entity_types).
* `Statement`: atomic fact extracted from an episode, classified by aspect. 12 aspects are defined (`Identity`, `Knowledge`, `Belief`, `Preference`, `Habit`, `Goal`, `Task`, `Directive`, `Decision`, `Event`, `Problem`, `Relationship`).
* `Aspect`: the classification tag on a statement. See [aspects](/memory/aspects).
* `Label`: workspace-scoped tag on episodes, sessions, and documents. Has an embedding in the `LABEL` vector namespace and is the primary scoping mechanism for V2 search. See [labels](/memory/labels).

## Storage layout

Statements split across two stores by aspect:

* Graph aspects (`Identity`, `Knowledge`, `Decision`, `Event`, `Problem`, `Relationship`) are decomposed into subject, predicate, object triples and stored in Neo4j. The `Predicate` entity type represents the edges, not the nodes.
* Voice aspects (`VOICE_ASPECTS`: `Directive`, `Preference`, `Habit`, `Belief`, `Goal`, `Task`) are stored as complete statements in the Aspects Store, since they carry meaning that does not decompose cleanly into triples.

Episodes are stored as documents, linked to the entities and statements they produced.

Embeddings live across six vector namespaces: `ENTITY`, `STATEMENT`, `EPISODE`, `COMPACTED_SESSION`, `LABEL`, `ASPECT`.

## How memory grows

Memory grows automatically through connected integrations (each sync produces episodes) and through conversations with the Butler (every exchange is ingested).

Manual additions come through three paths: uploading documents from the dashboard, calling the MCP `memory_ingest` tool, or sending content directly to the Butler ("Save my last 10 emails"). See [how CORE ingests](/memory/how-core-ingests).

## How memory is retrieved

The MCP `memory_search` tool runs the V2 pipeline. A router classifies the query into one of 6 query types: `aspect_query`, `entity_lookup` (with `attribute` or `broad` modes), `temporal`, `temporal_facets`, `exploratory`, `relationship`. The router uses vector search on the `LABEL` namespace plus an LLM aspect extraction step. Each query type dispatches to a dedicated handler, results are merged, optionally reranked with Cohere, and trimmed to a token budget.

V2 does not use BM25. Workspaces with `version !== "V3"` fall back to a legacy V1 pipeline that combines BM25, vector search, and BFS graph traversal when V2 returns empty. See [how CORE searches](/memory/how-core-searches) and [query types](/memory/query_types).

## How memory handles conflicts

Entities are deduped by name normalization plus vector similarity in the `ENTITY` namespace, so "Sarah", "Sarah Chen", and "sarah\_chen" collapse to one node when context supports it.

Contradicting facts form a temporal chain. When a new statement conflicts with an existing one, the old statement is marked as superseded with an end timestamp, and the new statement becomes current. History is preserved, not overwritten.

## Related

* [How CORE searches](/memory/how-core-searches)
* [How CORE ingests](/memory/how-core-ingests)
* [Aspects](/memory/aspects)
* [Entity types](/memory/entity_types)
* [Query types](/memory/query_types)
* [Labels](/memory/labels)
* [Reference](/memory/reference)