Glossary
The terms used across Lore and these docs.
Look up a Lore term here. Terms are in alphabetical order, and each row links to the page that explains the term in full.
Terms
| Term | Meaning | Read more |
|---|---|---|
| Boot | The fixed baseline Lore sends at session start: global guidance and the boot nodes. | How Lore works |
| Boot node | A memory in the boot list: core://agent, core://soul, preferences://user, or core://agent/<client_type>. | How Lore works |
| Client type | The runtime's name, such as claudecode, which plugins send with every event as client_type. | Connect agents |
| Cue terms | The query terms that matched a recalled memory. They appear after the URI in each recall line. | Recall |
| Disclosure | A short statement of the one situation in which a memory should surface. | Disclosure and glossary |
| Domain | The part of a URI before ://, such as core, preferences, or project. | Paths and domains |
| Dream | Scheduled maintenance run by the View LLM. It finds and fixes duplicates, vague triggers, and stale nodes. | Dream |
| Dream diary | The summary and narrative that Dream writes for each run. | Dream |
| Embedding | A list of numbers that represents the meaning of text. Lore uses embeddings for semantic recall. | Recall |
| Fail open | When Lore is unreachable or slow, plugins return nothing, and the agent continues without memory for that step. | How Lore works |
| Glossary | Keywords and aliases on a node that help recall match it, such as product names and error names. | Disclosure and glossary |
| History | The recorded events for a node: each create, update, move, and delete. | Memory model |
| Lifecycle event | A message a plugin sends at a session or prompt milestone, such as session.start or prompt.submit. | How Lore works |
| Memory node | A plain-text memory with a path, content, priority, disclosure, glossary, and views. | Memory model |
| Memory path (URI) | A node's stable address in the form domain://path, such as project://checkout_api/webhooks. | Paths and domains |
| Organization | In Loremem Cloud, the container for your projects. The first sign-in creates a personal one. | Loremem Cloud |
| Priority | An integer rank: 0 for core identity, 1 for key facts, and 2 and up for general memories. | Priority |
| Priority budget | The caps on how many memories can use priority 0 (5) and priority 1 (15). | Priority |
| Project | In Loremem Cloud, a separate memory space with its own graph, analytics, Dream, settings, tokens, and skills. | Loremem Cloud |
| Read before trust | The rule that an agent opens a recalled node before it relies on the content. | How Lore works |
| Recall | Lore's per-prompt search for memories that match the prompt. Results are candidates, not facts. | Recall |
| Recall block | The <recall> text Lore injects before a prompt. Each line holds a score, a URI, and cue terms. | How Lore works |
| Skill | A folder with a SKILL.md and optional files that agents can load when relevant. Loremem Cloud only. | Skills |
| Startup recall | Recall at session start, based on the working directory and repository name. | How Lore works |
| Token | The credential a client sends to Lore. Loremem Cloud tokens look like lm_…; self-hosted servers use API_TOKEN. | Loremem Cloud |
| View (gist/question) | A generated summary of a node that powers semantic search: a gist of the content and a question the node answers. | Memory model |
| View LLM | The model Lore uses to write views and run Dream. You set it during first-run setup. | First-run setup |
| Work copy | A local copy of a skill's files under ~/.lore/skills/ that agents read. | Skills |