Skip to main content

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.

​
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.
  • 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.
  • 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.

​
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.

​
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 and 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.