# GraphRAG Memory Engine

MemorDesk does not store meeting transcripts as flat text. Every meeting is processed into a **knowledge graph** that connects people, projects, decisions, and blockers across time. When you ask Kojo a question, the answer is assembled from this graph -- not from a keyword search.

## How it works end-to-end

### 1. Semantic chunking

After each transcript is cleaned, a semantic chunking module splits it into coherent paragraphs. Each paragraph is then embedded by MemorDesk's locally-hosted embedding model, producing a high-dimensional cosine-normalized vector. The model runs entirely on MemorDesk's servers and is never sent to a third-party embedding API.

**Desktop:** Settings > **Knowledge** (`/dashboard/settings/knowledge`) -- controls which meetings are indexed.

**Mobile:** Settings (gear) > **Knowledge Base** -- same controls on the native screen.

### 2. Vector search with partition isolation

Chunk and entity vectors are stored in a dedicated vector index. Every search is pinned to either your personal account or your organization's team space. There is no cross-user scanning: partition isolation is **structural**, enforced at query time by mandatory filter predicates. One user's embeddings are physically unreachable by another user's query, regardless of application-layer bugs.

Search scopes:

| Scope | What is searched |
|-------|-----------------|
| Personal | Only your own meetings and documents |
| Team | Only your organization's shared meetings |
| All | Both personal and team partitions (no cross-user leakage) |

### 3. Entity extraction

MemorDesk extracts six entity types from each meeting:

| Type | Examples |
|------|---------|
| PERSON | Meeting participants, mentioned stakeholders |
| PROJECT | Product names, initiatives |
| FEATURE | Specific capabilities or deliverables |
| TOOL | Software and services discussed |
| DECISION | Choices made during the meeting |
| BLOCKER | Open risks, dependencies, or blockers |

Each entity is committed to the knowledge graph with full provenance back to the source meetings.

### 4. Bi-temporal relationship tracking

Every edge in the graph carries start and end timestamps. When a relationship changes (e.g. a decision is reversed, a person changes role), the old edge is closed and a new edge is opened. The graph is a full historical record, not a snapshot.

This means Kojo can answer questions anchored to a point in time: "What did we decide about the API contract three weeks ago?" returns the state of the graph at that date, not the current state.

### 5. Graph walk and retrieval

When you ask Kojo a question, retrieval runs in four steps:

1. **Embed the query** -- the same local embedding model converts your question into a vector.
2. **Seed entity search** -- top-5 entity matches by cosine similarity, scoped to your partition.
3. **Graph walk** -- a graph traversal engine performs a breadth-first traversal up to 3 hops from each seed entity. This step is vector-free: it traverses the relationship graph directly.
4. **Chunk retrieval** -- top-12 transcript chunks filtered to the meeting IDs the graph walk surfaced, retrieved by vector similarity.

The result is a structured context block injected into the LLM prompt.

### 6. User context summary

Each user has a working memory layer maintained by the memory engine:

- **Active projects** -- current initiatives you are involved in
- **Key people** -- frequent collaborators
- **Open blockers** -- unresolved risks from recent meetings
- **Recent decisions** -- decisions made in the last knowledge window
- **Context summary** -- a free-text summary injected into every Kojo prompt

This is the layer that makes Kojo feel context-aware even at the start of a new conversation.

### 7. Memory window and plan gating

| Plan | Knowledge window |
|------|-----------------|
| Free | 14 days |
| Lite | 21 days |
| Pro, Team, Business, Enterprise | Unlimited |

**Desktop:** Settings > **Knowledge** (`/dashboard/settings/knowledge`) -- shows your current window and indexed meeting count.

**Mobile:** Settings (gear) > **Knowledge Base**.

## Provision and scaling

Dedicated partitions are provisioned automatically at signup. New partitions require no manual intervention and add no overhead to other users' queries.