> ## Documentation Index > Fetch the complete documentation index at: https://docs.embedder.com/llms.txt > Use this file to discover all available pages before exploring further. # Project memory > Understand how Embedder saves, recalls, updates, pins, and removes durable project knowledge across sessions and how to inspect stored memory. Project memory keeps durable facts available across conversations. Use it for knowledge that should change how future work is done in the same project, such as a build constraint, an architectural decision, or a confirmed hardware issue. Conversation history and project memory are separate. Clearing a conversation does not remove saved project memory. ## What belongs in memory Each entry has one of four kinds: * `pattern`: a recurring implementation or project convention * `preference`: an explicit or confirmed way you want work handled * `decision`: an architectural or product choice and the reason it was made * `issue`: a durable, known problem or constraint An entry also records: * One to five broad area tags, such as `build`, `dma`, or `auth` * Up to ten specific search keywords * A one-line preview and detailed content * Optional related file paths * A source of `explicit` or `inferred` * An optional pinned state * Creation and update timestamps Use memory for stable project knowledge. Keep temporary debugging observations, guesses, and task progress in the current conversation. ## Save or update an entry Ask Embedder to remember a confirmed fact: ```txt theme={"system"} Remember that release builds use the bootloader linker script in cmake/toolchains/release.cmake. Tag it with build and bootloader. ``` Embedder prepares a `save_memory` operation and shows you the proposed entry before writing it. Saving always requires your confirmation. To update an entry, Embedder searches for the existing memory, expands it, and saves the replacement using the same entry ID. This preserves its creation time and updates its modification time. The store rejects common sources of clutter: * A new entry cannot duplicate a similar preview of the same kind. Update the returned existing ID instead. * A new broad tag cannot be almost identical to an existing tag. Reuse the suggested tag. * The project can hold at most 50 entries. * At most five entries can be pinned. Paths inside the project are stored relative to the project root. External absolute paths stay absolute. ## Recall memory Embedder uses three read operations: * `memory_search` searches previews, keywords, paths, and full content. Use it for broad questions. * `memory_list_area` returns entries with one exact broad tag. Use it when you already know the area from the startup index. * `memory_expand` loads the full content for up to ten entry IDs returned by search or area listing. For example: ```txt theme={"system"} What do we already know about the DMA buffer allocator? ``` Embedder should search memory before reading the codebase when the startup index shows a related area. Search results contain previews and IDs, so it expands only the entries needed for the answer. Search scores phrase and word matches across previews, keywords, paths, and content. Preview matches receive the highest weights. Pinned and recently updated entries break equal-score ties. ## Pin an entry Pinned entries are for constraints the agent must see at the start of every conversation. A pin includes the entry's full content in the startup context. Unpinned entries stay searchable. At startup, Embedder includes only the tag index and entry counts for them, which keeps the context small. Use pins sparingly: ```txt theme={"system"} Pin the memory that says production firmware must not allocate from the heap. ``` Updating an entry can pin or unpin it. The five-pin limit prevents project memory from becoming another large instruction file. ## Forget an entry Ask Embedder to remove knowledge that is wrong, obsolete, or irrelevant: ```txt theme={"system"} Forget the memory about the old J-Link flash sequence. The bootloader now handles external flash initialization. ``` Embedder resolves the entry ID, shows a destructive confirmation, and then runs `forget_memory`. Memory deletion is available in Act mode. Read and save operations are also available in Plan mode. ## Limits The entry format enforces these bounds: * Tags: 1 to 5 per entry, with a 20-character limit per normalized tag * Keywords: up to 10 per entry * Preview: up to 150 characters * Content: up to 2,000 characters * Search and area listing: up to 20 previews per call * Expansion: up to 10 IDs per call * Store: 50 entries, including up to 5 pinned entries Embedder normalizes tags to lowercase, removes duplicate tags and keywords, and writes the store under a cross-process lock. ## Storage and recovery For a writable project, memory is stored in: ```txt theme={"system"} .embedder/memory.json ``` Writes use a temporary file and an atomic rename. If the JSON file is corrupt, Embedder moves it to a timestamped `.memory.json.corrupt.*` file and starts with an empty store. The quarantined file remains available for manual recovery. Do not edit `memory.json` while Embedder is saving an entry. Use the memory operations so validation, locking, duplicate checks, and pin limits remain active.