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

# Core concepts

> The mental model behind 4StaX. Memory, vault, consent, and how they connect.

Understanding these four concepts will make everything else in the docs click.

## Memory

A **memory** is a discrete, structured piece of context derived from your AI conversations. It is not a raw transcript. It is a classified, ranked unit of information.

```
{
  content: "Prefers TypeScript. Dislikes class components.",
  type: "preference",
  domain: "engineering",
  importance: 0.8,
  created_at: "2026-03-27T00:00:00Z"
}
```

Memories are stored in your vault and retrieved selectively. Only what is relevant to the current session gets injected into the prompt. Not everything and not nothing.

## The vault

Your **vault** is the storage layer where memories live. Today, with kontxt, that vault is a local SQLite database at `~/.kontxt/vault.db`. The encrypted, permissioned vault (and hosted sync) are on the 4StaX roadmap.

Consent logging, granular permissions, and revocation are also part of the Vault roadmap.

## Relevance ranking

When your AI client needs context, kontxt doesn't dump your entire memory archive into the prompt. It ranks candidates using four signals:

| Signal                  | What it measures                                    |
| ----------------------- | --------------------------------------------------- |
| **Semantic similarity** | How closely the memory matches the current task     |
| **Recency**             | How recently the memory was created or accessed     |
| **Access frequency**    | How often this memory has been useful before        |
| **Explicit importance** | The importance score set when the memory was stored |

The result is a compact, relevant bundle. It is not noise.

## Memory types

| Type         | Examples                                                      |
| ------------ | ------------------------------------------------------------- |
| `fact`       | Your name, role, team, tech stack                             |
| `preference` | Language choices, formatting preferences, communication style |
| `project`    | Project names, goals, ongoing context                         |
| `decision`   | Architectural decisions, tradeoffs, “we chose X because Y”    |
| `skill`      | Things you can do (and how you do them)                       |
| `episodic`   | Session-specific context worth retaining for later            |

## MCP and how it connects

**MCP (Model Context Protocol)** is the standard that lets AI clients talk to external tools and data sources. kontxt implements an MCP server that exposes your vault to any compatible client.

When you ask Cursor or Claude Desktop something, the MCP client calls kontxt tools, retrieves relevant memories, and injects them into your prompt automatically. You do not see it happening. It just works.

## Open source vs cloud

|         | kontxt (OSS)      | 4StaX cloud       |
| ------- | ----------------- | ----------------- |
| Storage | Local SQLite      | Hosted, encrypted |
| Sync    | Single machine    | Cross-device      |
| Access  | No account needed | Account required  |
| Status  | Available now     | Waitlist          |

The MCP tool surface is identical between both. Integrations built on kontxt will work with 4StaX cloud without changes.